USB redux


515 posts   Page 9 of 21   1 ... 6, 7, 8, 9, 10, 11, 12 ... 21
by richardp » Wed Mar 06, 2013 7:37 am
Any updates? 3 weeks since last post, is the USB still a thorny issue?
RaspberryPi's galore
Solid run CuBox
ODroid U2
Posts: 117
Joined: Thu Jan 12, 2012 11:46 am
by obcd » Wed Mar 06, 2013 8:34 am
Gordon is working on the camera board. (See the News section)
I guess that means the usb problems don't have much priority for the foundation, or maybe they have given up trying to fix them. Taking in consideration the openness of the foundation I am sure they will inform us soon.
Posts: 890
Joined: Sun Jul 29, 2012 9:06 pm
by jamesh » Wed Mar 06, 2013 8:48 am
obcd wrote:Gordon is working on the camera board. (See the News section)
I guess that means the usb problems don't have much priority for the foundation, or maybe they have given up trying to fix them. Taking in consideration the openness of the foundation I am sure they will inform us soon.


He's mainly working on USB as far as I know. Others are working on the camera.
Soon to be unemployed software engineer currently specialising in camera drivers and frameworks, but can put mind to most embedded tasks. Got a job in N.Cambridge or surroundings? I'm interested!
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11654
Joined: Sat Jul 30, 2011 7:41 pm
by dom » Wed Mar 06, 2013 1:55 pm
P33M has found a bug relating to split transactions and data toggle errors. See
https://github.com/raspberrypi/linux/pull/242

available with rpi-update.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4011
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by M33P » Wed Mar 06, 2013 2:00 pm
My most recent patch has been merged into the github repository - it should be available from rpi-update.

This adds support for handling of data toggle errors during SPLIT transactions in the driver - previously the Pi would loop forever in an interrupt it never handled. This gives a retry mechanism of up to 3 times which should be plenty for genuine data toggle errors.

Please test if your use case involves
- Serial adapters (USB1.1 devices) behind a hub (or plugged into a model B)
- Without the dwc_otg.speed=1 commandline parameter that "fixed" many of these devices before
- USB 1.1 devices where you previously had random lockups after extended periods of time.

Edit: asdfgh Dom beat me to it
Posts: 199
Joined: Sun Sep 02, 2012 1:14 pm
by paul42 » Wed Mar 06, 2013 2:07 pm
M33P wrote:My most recent patch has been merged into the github repository - it should be available from rpi-update.

This adds support for handling of data toggle errors during SPLIT transactions in the driver - previously the Pi would loop forever in an interrupt it never handled. This gives a retry mechanism of up to 3 times which should be plenty for genuine data toggle errors.

Please test if your use case involves
- Serial adapters (USB1.1 devices) behind a hub (or plugged into a model B)
- Without the dwc_otg.speed=1 commandline parameter that "fixed" many of these devices before
- USB 1.1 devices where you previously had random lockups after extended periods of time.

Edit: asdfgh Dom beat me to it


Can you confirm the "#xxx" number that has this patch please. Can't wait to give it a go...

Edit: Now up & running - showing #389 - will let you know how long it runs (77.5hrs to beat)...
Last edited by paul42 on Wed Mar 06, 2013 2:45 pm, edited 2 times in total.
Posts: 22
Joined: Mon Nov 26, 2012 5:38 pm
by azeam » Wed Mar 06, 2013 2:27 pm
Would this by any chance affect the bug with 24bit audio on USB DACs?

M33P wrote:My most recent patch has been merged into the github repository - it should be available from rpi-update.

This adds support for handling of data toggle errors during SPLIT transactions in the driver - previously the Pi would loop forever in an interrupt it never handled. This gives a retry mechanism of up to 3 times which should be plenty for genuine data toggle errors.

Please test if your use case involves
- Serial adapters (USB1.1 devices) behind a hub (or plugged into a model B)
- Without the dwc_otg.speed=1 commandline parameter that "fixed" many of these devices before
- USB 1.1 devices where you previously had random lockups after extended periods of time.

Edit: asdfgh Dom beat me to it
User avatar
Posts: 192
Joined: Fri Oct 26, 2012 11:13 pm
by M33P » Wed Mar 06, 2013 2:48 pm
azeam wrote:Would this by any chance affect the bug with 24bit audio on USB DACs?


Unless the USB DACs are causing the Pi to freeze hard and become completely unresponsive, then probably not.
Posts: 199
Joined: Sun Sep 02, 2012 1:14 pm
by azeam » Wed Mar 06, 2013 2:53 pm
M33P wrote:Unless the USB DACs are causing the Pi to freeze hard and become completely unresponsive, then probably not.


Ok, thanks. The issue isn't that, it's that the sound is distorted (seems as if it can't push the data fast enough), so I'll wait a bit with the rpi-update. Keep up the good work! :)
User avatar
Posts: 192
Joined: Fri Oct 26, 2012 11:13 pm
by michaeljquinn » Thu Mar 07, 2013 8:45 am
M33P wrote:My most recent patch has been merged into the github repository - it should be available from rpi-update.



This is cool. Currently been running Linux raspberrypi 3.6.11+ #354 , with dwc_otg.speed=1, see below
Its been quite stable
Code: Select all
dwc_otg.microframe_schedule=1 dwc_otg.speed=1 dwc_otg.fiq_fix_enable=1 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait


I'll wait until weekend, before I try your change

My setup uses the USB-RS485-WE-1800-BT (http://www.ftdichip.com/Support/Documents/DataSheets/Cables/DS_USB_RS485_CABLES.pdf, RS485 to USB. It hits the adapter about 2-3/sec, so will be nice to try
Posts: 39
Joined: Sun Oct 21, 2012 8:19 am
by rspitz » Thu Mar 07, 2013 4:15 pm
Thanks M33P for your continuing work on the USB problems.

How much of your work is coordinated with gsh's efforts? There has been very little info about the official work he is doing with USB on behalf of the Foundation.

Regards, Richard
Posts: 49
Joined: Tue Jul 31, 2012 7:25 pm
by ski522 » Thu Mar 07, 2013 4:18 pm
[quote="azeam"]
Ok, thanks. The issue isn't that, it's that the sound is distorted (seems as if it can't push the data fast enough), so I'll wait a bit with the rpi-update. Keep up the good work! :)[/quote]
Have you tried using nrpacks in your modprobe config. I found I had to do that with my PCM2704 card (16bit). See http://alsa.opensrc.org/Usb-audio#Tunin ... _latencies. I needed to use nrpacks=1
[code]options snd-usb-audio index=0 nrpacks=1
[/code]
You might want to look at picking up a PCM2704 card too. I actually read a great article aound 24bit verses 16bit cards and the conlusion was you're better off with 16bit and this is a great little card! http://people.xiph.org/~xiphmont/demo/neil-young.html
Last edited by ski522 on Thu Mar 07, 2013 4:22 pm, edited 1 time in total.
Posts: 394
Joined: Sun Sep 30, 2012 2:22 pm
by gsh » Thu Mar 07, 2013 4:22 pm
We've been working on different things are are therefore only communicating through github...

But P33M's updates have integrated into my work on FIQ split transactions well so they fixes shouldn't be lost in future.

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 780
Joined: Sat Sep 10, 2011 11:43 am
by M33P » Thu Mar 07, 2013 4:47 pm
I have mainly been working on pure bugfixes on the existing Synopsys implementation - inefficient and spaghettified though it is.

gsh has been (for a while) implementing much of the "tricky" bits of a USB driver in an ARM FIQ. This in theory will prevent the timing issues associated with an entirely interrupt-based driver given the non-realtime behaviour of the Linux kernel.

My fixes will not significantly change the underlying coding method of the driver. Unfortunately I don't have time to rewrite portions of it - even finding some of these obscure bugs takes several days. Or several inspiration particles.*

I will have a crack at isoc next - unless a better implementation from gsh is imminent. One elephant already discovered is that on processing a completed set of isoc transactions, the driver will stay in an IRQ handler until the very_long_completion_function_cough_uvcvideo(); does whatever it does to complete the URB. This for some reason can take up to 700uS - an eternity for a processor to sit with interrupts disabled.

* Terry Pratchett.
Posts: 199
Joined: Sun Sep 02, 2012 1:14 pm
by kumme74 » Thu Mar 07, 2013 8:10 pm
Hi Terry,

my devices are now running for 24 hours under stress conditions without any problem. One of my CDC USB devices is connected to the RPi directly, the second one via a hub. Without your fix the system crashed in less than 10 minutes reliably. So far I can be sure this is FAR the best improvement I have seen within the last 4 month. Great Work!

For those like me who do not live in a perfect world and need a practical solution rather than a theoretical one this fix is great.

Klaus
Posts: 6
Joined: Thu Sep 27, 2012 6:40 pm
by azeam » Thu Mar 07, 2013 10:44 pm
ski522 wrote:Have you tried using nrpacks in your modprobe config. I found I had to do that with my PCM2704 card (16bit). See http://alsa.opensrc.org/Usb-audio#Tunin ... _latencies. I needed to use nrpacks=1
Code: Select all
options snd-usb-audio index=0 nrpacks=1

You might want to look at picking up a PCM2704 card too. I actually read a great article aound 24bit verses 16bit cards and the conlusion was you're better off with 16bit and this is a great little card! http://people.xiph.org/~xiphmont/demo/neil-young.html


Thanks. I've tried those settings and it doesn't do any difference, haven't heard of anyone who's been able to get 24 bit audio working properly on a RPi. The only solution that works is to limit the USB to 1.1 and you can get up to 24/96, but then the network becomes too slow to be usable for other stuff.

I've got a PCM2704 based DAC and while I do think it's absolutely great value for the money I still prefer the sound of my ODAC (http://nwavguy.blogspot.se/2012/04/odac-released.html). The audible difference between 16 and 24 bit is, as you know, a highly debatable question and that discussion probably belongs in a different forum. Personally I usually prefer listening to higher bit depths, even if the (perceived) difference is subtle. Whether it "actually" sounds better or it's just placebo doesn't really matter to me to be honest - placebo can be a great thing you know ;) There are also other benefits of high bit depth audio, such as being able to use software volume control without dropping the bit depth to very low levels (I'm using a DIY pre-amp without remote control so it can be handy sometimes). The article looks interesting though, I'll have a closer look at it later.
User avatar
Posts: 192
Joined: Fri Oct 26, 2012 11:13 pm
by paul42 » Fri Mar 15, 2013 10:44 am
@M33P - Your fix worked for me. Thank you so much, now back to my project!

For info i am now using 3.6.11+ #389 with a Nokia DKU-5 cable which loads a USB Serial PL2303 converter with a basic Nokia GSM phone.

The system has now been up continuously for 5 days happily sending & receiving sms's with no lockups or reboots (best before was 3 days).

For info note there are at least two (maybe more) DKU-5 cables around. I have tried the official Nokia one but that doesn't work,. The Pi recognised it but i was unable to make it work with Gnokii which i use to send/receive sms's. The one i have is i believe a copy cable & works well as it loads the PL2303 converter.

Thanks again, Paul
Posts: 22
Joined: Mon Nov 26, 2012 5:38 pm
by whocares_ido » Fri Mar 15, 2013 7:54 pm
Just to make sure that I understand how to apply this latest fix:

I just have to install and run rpi-update? That is it? Do I have to set any kernel args in cmdline.txt?

Thank you!
Posts: 22
Joined: Wed Sep 26, 2012 5:47 pm
by paul42 » Fri Mar 15, 2013 8:01 pm
whocares_ido wrote:Just to make sure that I understand how to apply this latest fix:

I just have to install and run rpi-update? That is it? Do I have to set any kernel args in cmdline.txt?

Thank you!

That's what I did. I use the standard cmdline.txt but with the AM0 bit removed as I use the serial port to drive a lcd. If you don't use the serial port leave it standard.
Posts: 22
Joined: Mon Nov 26, 2012 5:38 pm
by MastaG » Sat Mar 16, 2013 10:28 pm
Gordon, could you give us a small status update on your usb work?
I'm mostly interested in hispeed isochronous devices such as webcams/tv-tuners.
Most of them suffer badly from transfer issues.
Posts: 11
Joined: Fri Jun 08, 2012 8:14 am
by gsh » Sun Mar 17, 2013 7:27 am
I have a first version being played with at the moment which is pretty good, fixes the keyboards etc.

But it breaks isochronous !

This fix will probably not effect isochronous anyway, in general it looks like most of the reason it doesn't work is CPU maxed out, although haven't been able to look at it yet.

That's next. In future I'm going to use the @TeamRaspi for updates
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 780
Joined: Sat Sep 10, 2011 11:43 am
by pajko » Tue Mar 19, 2013 10:37 am
Hi!

I've seen in a couple of threads that some of you have been fighting with the driver of the dwc_otg controller to make it better and less resource hungry. Even writing a new driver from scratch popped up sometime, which was doomed by not having proper documentation. I think I have found something, which can help, if anybody is still interested in it. I could do the gory job myself, but unfortunately have no time to work on it, as I have a couple of more important things to work on at my company. Besides that I have only a little experience in writing USB drivers (have written a 'device' driver for a custom boot loader targeting Au1250 a couple of years ago, but not completely from scratch).

The Telechips TCC890x I'm working on also has this dwc_otg IP core. It's user manual has a _very_ detailed documentation of it. Including complete register description, use-case scenarios with diagrams, and complete programming model with pseudo code. All this both for 'host' and 'device' modes.
Just to ruffle any feathers - if I understood correctly - handling SOF interrupts is not necessary at all in 'host' mode. Neither for 'interrupt', nor for 'isochronous' transfers.

We got the documentation under NDA, so I cannot give it out, but with a bit of googling you _will_ find something. For eg. there's an anonymous FTP server somewhere in China with a big pile of documentation targetting Telechips SoCs.

Hope that helps.

Bye,
pajko
Posts: 1
Joined: Tue Mar 19, 2013 9:53 am
by gsh » Tue Mar 19, 2013 11:36 am
Yes you do need to handle SOF interrupts, otherwise you won't be sending the isoc and interrupt packets on the right frames. Which means the split transactions won't work properly

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 780
Joined: Sat Sep 10, 2011 11:43 am
by jjplano » Wed Mar 20, 2013 4:12 am
hi guys

thanks for all the good work

I have one question: the "isochronous" that everyone is referring means that still no usb video capture device can work, right?

thanks!
Posts: 11
Joined: Tue Mar 19, 2013 6:40 pm
by pluggy » Wed Mar 20, 2013 6:02 am
Is anything stable enough to make the main apt-get upgrade path ?. I've had rpi-update break stuff in the past so I avoid it now. Of course I'll probably shut up when the camera module arrives, because its imaging that's my bent. There's only a limited number of my USB webcams that can see past the Pi's USB.
Don't judge Linux by the Pi.......
User avatar
Posts: 2423
Joined: Thu May 31, 2012 3:52 pm
Location: Barnoldswick, Lancashire,UK