Here's a new USB thread, free of all of the unpleasant baggage (and unpleasant baggages) of the old one. I've been chatting to Gordon (and am about to meet him in the pub, so you won't see any updates here immediately); I've asked him to put any new updates here.

The old thread was getting seriously off-topic, and very unwieldy by virtue of its length. Please try to stay on topic in this one, and be polite!

There is a reported and reproducible issue with USB where repeated device acquisition can hang the USB system. This is exemplified by libgphoto2 among others where one command executes perfectly but a subsequent one causes the system to hang. I can reproduce this at will with libusb-1.0 calls to a device (tl500 temperature logger).

Am I correct in assuming that this is an issue with the dwc_otg module and will not be addressed until the dwc_otg module is replaced with one which is EHCI compliant?
Or am I missing something and even more incompetent a programmer than I thought?

davidmam wrote:There is a reported and reproducible issue with USB where repeated device acquisition can hang the USB system. This is exemplified by libgphoto2 among others where one command executes perfectly but a subsequent one causes the system to hang. I can reproduce this at will with libusb-1.0 calls to a device (tl500 temperature logger).

Am I correct in assuming that this is an issue with the dwc_otg module and will not be addressed until the dwc_otg module is replaced with one which is EHCI compliant?
Or am I missing something and even more incompetent a programmer than I thought?

..d

Can you post exact steps to reproduce the problem please (unless you've already done so on github or similar, in which case can you link them).

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

I have followed the various threads on USB-issues. It is nice to see that some topics
which existed due to power-supply issues have now been resolved due to the new
hardware-revision and usage of proper power-adapters.

Still issues remain that seem to be caused by the actual hardware-implementation
of the USB-controller in the Broadcom-chip.

I also see that some work has been done to improve the driver and circumvent
those hardware-limitiations of the controller.

Unfortunately from all those prior threads I have the impression that not all of the
USB-issues may actually be fixed via software.

I have seen references that USB-packets still get dropped, causing for example
network-packets to be dropped as well since the RPis ethernet-port is connected
to the USB-subsystem.

Though this might not be a huge problem for applications using TCP-network-
connections which can retransmitted such dropped packets, for UDP-based
applications this can be a real pain in the backside - think about realtime
multimedia applications like TV-streaming, VoIP etc. where packetloss would
cause artifacts in either video or audio...

But network-stability is only one part of the issue. If there are sufficient amounts
of USB-devices which work with almost all "normal PCs" and most ARM-based
boxes that implement a "real" EHCI-USB-controller, the reputation of the RPi
will suffer quite a bit...

So I really think the main current focus of the foundation should be to put enough
man-power into solving this issue to make sure the success-story of the RPi
continues and is not tainted by this flaw...

Best regards,
Tobias

PS.: I have seen somewhere that interrupt-latency of the linux-kernel may hinder
the successful solution of this issue - has anyone thought about trying to get
the "config_preempt_rt" (http://rt.wiki.kernel.org/index.php/Main_Page)
patches running on the RPi? Perhaps this will help the USB-driver to achieve
the needed timing to service the USB-hardware properly...

davidmam wrote:There is a reported and reproducible issue with USB where repeated device acquisition can hang the USB system. This is exemplified by libgphoto2 among others where one command executes perfectly but a subsequent one causes the system to hang. I can reproduce this at will with libusb-1.0 calls to a device (tl500 temperature logger).

Am I correct in assuming that this is an issue with the dwc_otg module and will not be addressed until the dwc_otg module is replaced with one which is EHCI compliant?
Or am I missing something and even more incompetent a programmer than I thought?

..d

Can you post exact steps to reproduce the problem please (unless you've already done so on github or similar, in which case can you link them).

I was not able to reproduce the full hang anymore with gphoto2 using the latest
kernel and firmware version. But there is something wrong still. I am not sure
if this is a bug in gphoto2, but it seems to work with other linux systems.

I have followed the various threads on USB-issues. It is nice to see that some topics
which existed due to power-supply issues have now been resolved due to the new
hardware-revision and usage of proper power-adapters.

Still issues remain that seem to be caused by the actual hardware-implementation
of the USB-controller in the Broadcom-chip.

I also see that some work has been done to improve the driver and circumvent
those hardware-limitiations of the controller.

Unfortunately from all those prior threads I have the impression that not all of the
USB-issues may actually be fixed via software.

I have seen references that USB-packets still get dropped, causing for example
network-packets to be dropped as well since the RPis ethernet-port is connected
to the USB-subsystem.

Though this might not be a huge problem for applications using TCP-network-
connections which can retransmitted such dropped packets, for UDP-based
applications this can be a real pain in the backside - think about realtime
multimedia applications like TV-streaming, VoIP etc. where packetloss would
cause artifacts in either video or audio...

But network-stability is only one part of the issue. If there are sufficient amounts
of USB-devices which work with almost all "normal PCs" and most ARM-based
boxes that implement a "real" EHCI-USB-controller, the reputation of the RPi
will suffer quite a bit...

So I really think the main current focus of the foundation should be to put enough
man-power into solving this issue to make sure the success-story of the RPi
continues and is not tainted by this flaw...

Best regards,
Tobias

PS.: I have seen somewhere that interrupt-latency of the linux-kernel may hinder
the successful solution of this issue - has anyone thought about trying to get
the "config_preempt_rt" (http://rt.wiki.kernel.org/index.php/Main_Page)
patches running on the RPi? Perhaps this will help the USB-driver to achieve
the needed timing to service the USB-hardware properly...

I guess the elephant thread was a bit long to read end to end, but we are aware there are still some remaining issues, although Gordon hasn't been seeing any on his equipment, and many people are using the device with no problems. We are actively working on fixing any remaining issues. We do expect the vast majority of people will be able to use the USB system without issue, once some remaining issues are fixed. Gordon has some ideas already, and believe we will be able to improve by a significant factor the number of devices that work without issue.

On a side note, this thread is really for passing on information about fixes that go in, and for reporting particular issues if people see them. I'll be deleting any further posts that just go over old ground. I don't want to see complaints, or concerns about a possible faulty USB system - they don't help anyone since the Foundation IS aware of ongoing issues, and IS working on them, no reminder is necessary. I want to see valid reports, or help with fixes. To that end, if you have a USB problem, please ensure you are using the very latest distro, and if you still see problems, please document what HW you are using and what your problem actually is. We do not need lots more missing keyboard press reports though!

I'll try and get a full 'current status' from Gordon - so people can cross reference any problems they may have against that to see if a report is needed.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

davidmam wrote:There is a reported and reproducible issue with USB where repeated device acquisition can hang the USB system. This is exemplified by libgphoto2 among others where one command executes perfectly but a subsequent one causes the system to hang. I can reproduce this at will with libusb-1.0 calls to a device (tl500 temperature logger).

Am I correct in assuming that this is an issue with the dwc_otg module and will not be addressed until the dwc_otg module is replaced with one which is EHCI compliant?
Or am I missing something and even more incompetent a programmer than I thought?

..d

Can you post exact steps to reproduce the problem please (unless you've already done so on github or similar, in which case can you link them).

I was not able to reproduce the full hang anymore with gphoto2 using the latest
kernel and firmware version. But there is something wrong still. I am not sure
if this is a bug in gphoto2, but it seems to work with other linux systems.

stuporhero wrote:I wanted to drop this link, because the issue in the second comment sounds remarkably familiar. Please ignore me if I'm wrong, but this sounds like a recent bug in the Linux kernel that was fixed...

Thanks Stuporhero - that article is a MUST READ for anyone commenting that Raspi MUST support every single USB device out of the box without fail and will hopefully give them a better idea of the idiosyncrasies of USB and associated drivers, and the difficulties of fixing some of the more obscure issues.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

jamesh wrote:Can you post exact steps to reproduce the problem please (unless you've already done so on github or similar, in which case can you link them).

Try the following. Connect your camera. Then try gphoto2 -L . And then again.
If that works, we need some cooperation from your camera: try gphoto2 --capture-image . Twice. It seems the second one hangs.
(I haven't tried this myself: I'm just on the gphoto mailing list. But this is supposed to be a surefire way to trigger it!).

We should start a wiki with some debug info use when looking at these issues. The forums are a bit complicated to traverse. That said, I don't know if the "gphoto" issue is related to what i see with motion and trying HD resolutions.

I see an error on the usb packets (-63)
ENOSR During an OUT transfer, the host controller
could not retrieve data from system memory fast
enough to keep up with the USB data rate.

I tried to bypass this in the uvcvideo module and hopefully just give me garbage in the buffer, but something else fails in the drivers somewhere.

What would be the best way to approach debugging the USB traffic and finding out what "system memory is not fast enough" really means? I have not yet looked into the module that returns ENOSR because there could be a few by the looks of things. How would I find out that?

If I strip the code down to the bare minimum for talking to the USB device then the problem appears to disappear. Likewise if I call the usbreset code (which does a USBDEVFS_RESET call on the device) before initialising. That is an acceptable workround for now (I just have to wrap the lsusb/usbreset calls in each script)

But the main mutlithreaded code still hangs. However, I now have a functioning workaround so I am happy.

The libgphoto issue is a pain as it takes so long to reinitialise the camera after a reset. There a fix would be nice.

Perfect. Thank you very much, that is exactly what I needed to know. And again, to anyone submitting reports, please include the output of uname -a, which for me, on a fully updated RPi currently outputs:
Linux raspberrypi 3.2.27+ #285 PREEMPT Tue Nov 20 17:49:40 GMT 2012 armv6l GNU/Linux

I think I've found another problematic device. It's a USB to Centronics parallel interface with a Prolific PL2305 Parallel Port IC. It's marketed as "Vivanco Parallel Port Adapter" but I think its a standard item.

04d9:1503 is a keyboard
05e3:0608 is a Belkin 7 port-hub
0586:3410 is the wi fi adapter
I'm using an HP Deskjet 400 printer that has a Centronics, actually IEEE 1284, interface.
I've installed cups and hplip packages and installed the printed. Every time I try to print the test page from the CUPS web interface, the printing starts, then after about 30 seconds, the printer stops and in kenr.log I find this message alone.

Running latest Raspbian full updated and kernel Linux raspberrypi 3.2.27+ #285. Mainly use pi as a NAS and have experienced serious problems with file copy operations stalling and then resuming or streaming video dying (via SMB, DLNA and NFS). Have adjusted a few settings (see http://www.raspberrypi.org/phpBB3/viewt ... 29&t=23910) and now it's quite a bit better though still present. At the time of the stoppage/drop in transfer, I get this in syslog:

I'm pretty sure it's always that drive but may also be because most of the content I play is from that drive. Also worth pointing out there is no other disk activity on the other drives while that drive is being used. All drives and the hub are also powered.

I haven't tried it with only that one drive connected but will do so this evening. Generally speaking, is this indicative of an issue with the drive or the hub? (the hub I'm using is a couple of years old and was picked up in SE Asia, not the cheapest but not on the list of working hubs either).

1) Lockup / crash with CDC/ACM device (may be similar to many other lockups with latest hardware)
2) Keydropping (split transaction scheduling) is ongoing, I don't think I'm going to be able to make it significantly better for a while, but if you have a keyboard and Pi combination that seems to drop keys very badly I'd be interested in knowing what the combination is and whether it happens all the time or only occasionally, I'm currently working on an interesting hypothesis for why keyboards sometimes drop keys a lot and at other times not so much...

Just to note, I'm giving some priority to 1) because Klaus sent me chocolate along with his hardware and I was able to reproduce the problem within minutes! Chocolate is good bribery!

grantonstar wrote:I'm pretty sure it's always that drive but may also be because most of the content I play is from that drive. Also worth pointing out there is no other disk activity on the other drives while that drive is being used. All drives and the hub are also powered.

I haven't tried it with only that one drive connected but will do so this evening. Generally speaking, is this indicative of an issue with the drive or the hub? (the hub I'm using is a couple of years old and was picked up in SE Asia, not the cheapest but not on the list of working hubs either).

Not sure - What I've seen in the past is the system goes to lunch if it's the hub (One of those evil back-powering hubs-not in use anymore. Next stop is the trash...) and a "drive" (Either the SATA/PATA bridge or drive itself) may get just one "burp" and it recovers. The same thing happened to me yesterday, but everything was out of its case and I may have jostled a cable. Recovered right away and no problems since. So far, I've had no problems copying files between external drives or a drive and thumb drive. Haven't attempted to copy files over the network from the Pi to another system, though. Best guess right now would be the drive.

You are in a maze of twisty little passages, all alike.
When General Failure and Major Disaster get together, Private Parts usually suffers.