USB redux

[liz]

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!

[davidmam]

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

[abishur]

Thanks for the new thread!

[jamesh]

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).

[to-pse]

Hi everyone,

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...

[shuckle]

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.

Reproducible test:
1) Install gphoto2:

Code: Select all

sudo apt-get install gphoto2

2) Connect PTP capable camera in PTP mode to USB.
dmesg shows:

• [ 466.739090] usb 1-1.3: new high-speed USB device number 5 using dwc_otg
  [ 466.840621] usb 1-1.3: New USB device found, idVendor=04b0, idProduct=0414
  [ 466.840649] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
  [ 466.840666] usb 1-1.3: Product: NIKON DSC D40
  [ 466.840678] usb 1-1.3: Manufacturer: NIKON
  [ 466.840690] usb 1-1.3: SerialNumber: nnnnnnn

3) Take some photos with gphoto2.
First works fine:

Code: Select all

$ time gphoto2 --capture-image-and-download
real    0m5.238s
user    0m0.370s
sys     0m0.320s

but the second causes errors and delays:

Code: Select all

$ time gphoto2 --capture-image-and-download
An error occurred in the io-library ('Unspecified error'): No error description available
ERROR: Could not capture image.

After that every second works like the first and every second fails like the second example.

dmesg shows error:

• [ 500.990276] usb 1-1.3: usbfs: USBDEVFS_CONTROL failed cmd gphoto2 rqt 33 rq 102 len 0 ret -110

It is possible to avoid that error by resetting the usb file system for example
with the following program:

Code: Select all

#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <linux/usbdevice_fs.h>

void main(int argc, char **argv)
{
    const char *filename;
    int fd;

    if (argc < 2) {
        printf("Give USB device name as parameter\n");
        exit(1);
    }
    filename = argv[1];
    fd = open(filename, O_WRONLY);
    if (fd == -1) {
        perror("USB device open failed");
        exit(2);
    }
    if (ioctl(fd, USBDEVFS_RESET, 0) == -1) {
        perror("USBDEVFS_RESET device ioctl failed");
        exit(3);
    }
    close(fd);
}

for example:

Code: Select all

usbreset /dev/bus/usb/001/004

which is shown in dmesg as:

• [ 393.176417] usb 1-1.3: reset high-speed USB device number 4 using dwc_otg

lsusb -v shows:
Bus 001 Device 004: ID 04b0:0414 Nikon Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x04b0 Nikon Corp.
idProduct 0x0414
bcdDevice 1.00
iManufacturer 1 NIKON
iProduct 2 NIKON DSC D40
iSerial 3 nnnnnnn
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 2mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 6 Imaging
bInterfaceSubClass 1 Still Image Capture
bInterfaceProtocol 1 Picture Transfer Protocol (PIMA 15470)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 9
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered

I hope that helps?

[jamesh]

Hi everyone,

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.

[jamesh]

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.

Reproducible test:
1) Install gphoto2:

Code: Select all

sudo apt-get install gphoto2

2) Connect PTP capable camera in PTP mode to USB.
dmesg shows:

• [ 466.739090] usb 1-1.3: new high-speed USB device number 5 using dwc_otg
  [ 466.840621] usb 1-1.3: New USB device found, idVendor=04b0, idProduct=0414
  [ 466.840649] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
  [ 466.840666] usb 1-1.3: Product: NIKON DSC D40
  [ 466.840678] usb 1-1.3: Manufacturer: NIKON
  [ 466.840690] usb 1-1.3: SerialNumber: nnnnnnn

3) Take some photos with gphoto2.
First works fine:

Code: Select all

$ time gphoto2 --capture-image-and-download
real    0m5.238s
user    0m0.370s
sys     0m0.320s

but the second causes errors and delays:

Code: Select all

$ time gphoto2 --capture-image-and-download
An error occurred in the io-library ('Unspecified error'): No error description available
ERROR: Could not capture image.

After that every second works like the first and every second fails like the second example.

dmesg shows error:

• [ 500.990276] usb 1-1.3: usbfs: USBDEVFS_CONTROL failed cmd gphoto2 rqt 33 rq 102 len 0 ret -110

It is possible to avoid that error by resetting the usb file system for example
with the following program:

Code: Select all

#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <linux/usbdevice_fs.h>

void main(int argc, char **argv)
{
    const char *filename;
    int fd;

    if (argc < 2) {
        printf("Give USB device name as parameter\n");
        exit(1);
    }
    filename = argv[1];
    fd = open(filename, O_WRONLY);
    if (fd == -1) {
        perror("USB device open failed");
        exit(2);
    }
    if (ioctl(fd, USBDEVFS_RESET, 0) == -1) {
        perror("USBDEVFS_RESET device ioctl failed");
        exit(3);
    }
    close(fd);
}

for example:

Code: Select all

usbreset /dev/bus/usb/001/004

which is shown in dmesg as:

• [ 393.176417] usb 1-1.3: reset high-speed USB device number 4 using dwc_otg

lsusb -v shows:
Bus 001 Device 004: ID 04b0:0414 Nikon Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x04b0 Nikon Corp.
idProduct 0x0414
bcdDevice 1.00
iManufacturer 1 NIKON
iProduct 2 NIKON DSC D40
iSerial 3 nnnnnnn
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 2mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 6 Imaging
bInterfaceSubClass 1 Still Image Capture
bInterfaceProtocol 1 Picture Transfer Protocol (PIMA 15470)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 9
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered

I hope that helps?

Fantastic, thanks!

[stuporhero]

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...


More here: http://labs.opinsys.com/blog/2012/11/01 ... -in-linux/

[jamesh]

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...

More here: http://labs.opinsys.com/blog/2012/11/01 ... -in-linux/

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.

[bgirardot]

To that end, if you have a USB problem, please ensure you are using the very latest distro, ...

When you say very latest distro, does that mean just straight sudo apt-get update && sudo apt-get upgrade or do you mean install rpi-update and update via that tool?

Would including the uname -a output help with making these reports more useful?

[jamesh]

To that end, if you have a USB problem, please ensure you are using the very latest distro, ...

When you say very latest distro, does that mean just straight sudo apt-get update && sudo apt-get upgrade or do you mean install rpi-update and update via that tool?

Would including the uname -a output help with making these reports more useful?

Yes, knowing the version number would be very useful. Not sure of the answers to other Q's - must get more Raspi time.

[davidmam]

Here is a link to the previous post. If you need more details then please let me know and I'll do what I can to help.

http://www.raspberrypi.org/phpBB3/viewt ... 20#p213220

This is with a fully updated raspbian.

[rew]

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!).

[arcanon]

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.

I wanted to try "dwc_otg.speed=1", but on this stops any usb working (https://github.com/raspberrypi/linux/issues/66).

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?

[davidmam]

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.

[jamesh]

Some information on getting the latest firmware.

rpi-update gets the latest firmware from:
https://github.com/Hexxeh/rpi-firmware

This is a (slightly reorganised) copy of files from:
https://github.com/raspberrypi/firmware

(Dom updates both repos together)

[bgirardot]

Some information on getting the latest firmware.
rpi-update gets the latest firmware from:
https://github.com/Hexxeh/rpi-firmware
This is a (slightly reorganised) copy of files from:
https://github.com/raspberrypi/firmware
(Dom updates both repos together)

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

[michele.x]

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.

I'm using the kernel from the latest rpi-update (but the same problem happened with the kernel on the deb repository (http://mirrordirector.raspbian.org/raspbian/)

uname -a

Code: Select all

Linux raspberrypi 3.2.27+ #285 PREEMPT Tue Nov 20 17:49:40 GMT 2012 armv6l GNU/Linux

lsusb gives

Code: Select all

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. 
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. 
Bus 001 Device 004: ID 067b:2305 Prolific Technology, Inc. PL2305 Parallel Port
Bus 001 Device 005: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 006: ID 04d9:1503 Holtek Semiconductor, Inc. Shortboard Lefty
Bus 001 Device 007: ID 046d:c05a Logitech, Inc. Optical Mouse M90
Bus 001 Device 008: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 009: ID 0586:3410 ZyXEL Communications Corp. ZyAIR G-202 802.11bg

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.

Code: Select all

 usb 1-1.2: reset full-speed USB device number 4 using dwc_otg

The problem happens when the adapter is connected directly to the Pi and when is connected via the powered hub, and anyway it gets the power from pin 18 of the Centronics connectror.

If I have to make oter test to pinpoint the problem, please let me know.

[grantonstar]

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:

[48212.967078] usb 1-1.3.4.3: reset high-speed USB device number 8 using dwc_otg

The device is according to lssb a "Western Digital Technologies, Inc. Elements 2TB" external hard drive.

Anything I can do to further debug or resolve the issue?

[MaxK1]

Is it always the same drive? Can you reproduce the problem with just that drive plugged into the hub or into the pi (Assuming it is a separately powered drive)?

[grantonstar]

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).

[gsh]

Just to note what I'm working on at the moment...

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!

Gordon

[MaxK1]

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.

[rspitz]

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!

I'd be happy to send you a significant quantity of chocolate if it could help get my USB problems fixed. Just let me know the address where to ship to.

BTW: What is the latest raspbian kernel release that contains fixes for USB code?