Distribution: Debian Sarge, SuSE 9.3, Ubuntu Hoary Hedgehog so far Hardware Environment: ASUS A7V400-MX with Sempron 2500+ 512MB VIA Technologies, Inc. VT8378 [KM400] Chipset Host Bridge VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) VIA Technologies, Inc. USB 2.0 (rev 82) Software Environment: Any or N/A, take your pick. Problem Description: Installed standard USB external (front panel) plug in motherboard socket. Using kernels 2.4.30 & 31, it works fine for USB2 transfers. Using kernels 2.6.11 and above listed, only USB1.1 devices are recognized on the front panel plug; all USB2 devices fail with something resembling the following: usb 1-5: new high speed USB device using ehci_hcd and address 3 usb 1-5: device descriptor read/64, error -71 usb 1-5: new high speed USB device using ehci_hcd and address 4 usb 1-5: device descriptor read/64, error -71 ...etc ad nauseam. the read/64 can also be read/8, read/all. Steps to reproduce: So far have tried various USB2 mass storage devices, both flash and hard drive enclosures with identical results. Also fails with a Sony DSC-W5 camera. So basically, from my point of view, plug a USB2 mass storage device into the front panel. PLEASE NOTE: All these devices show up and work perfectly normally on the same system and USB port using kernel 2.4.30-31 (at least). The problem will not show up there. ALSO NOTE: Does not seem to be relevant whether Hotplug or HAL/UDEV is involved (my Sarge does not use them; SuSE and Ubuntu do). ALSO NOTE: USB 1.1 devices all work normally at all times on all ports, front or back panel.
try the "usbcore.old_scheme_first" kernel/module parameter to see if that makes any difference.
Aha, David. Thanks. That works for now. However, just after initializing eth0 I got (for the first time ever) a "spurious 8259A interrupt: IRQ7." Possibly related? Dave North
David, it appears I was premature in signaling success. In fact, it only worked once and I have not been able to reproduce the positive result. I have also been unable to confirm I'm even doing it right (I don't see a positive description of the syntax anywhere online). On my successful attempt I entered, at the GRUB prompt: usbcore.old_scheme_first ...just as you typed it. In attempting to get a module parameter entered on a build-as-module version, I used: options usbcore old_scheme_first=y (and alternately =1) in /etc/modprobe.conf In any event, I have seen only the first successful attempt, which makes me wonder if I somehow managed to start the wrong (2.4) kernel by accident somehow. All subsequent attempts have failed, sometimes with just the standard error message and other times with the "waiting to settle" lockup. Sorry for the spurious report. I did try building the kernel with verbose USB debug, but for some reason it stopped reporting the kernel command line in dmesg, which I found worrisome, so I backed it out. Confirmed 1.1 devices all still work on the front panel, and USB2 devices all work normally under 2.4 still. Dave North
First, my understanding was the new enumeration started in 2.6.10, so to test I built a 2.6.9 kernel using make oldconfig. The device still fails, so I suspect the problem lies elsewhere. It did make a slightly different report on failure, so here's an example (this is from 2.6.9): usb 1-6: new high speed USB device using address 3 usb 1-6: unable to read config index 0 descriptor/start usb 1-6: can't read configurations, error -71 ehci_hcd 0000:00:10.3: qh dfcba080 (#0) state 1 For comparison, the same device successfully initialized on a rear (builtin) USB plug:usb 1-4: new high speed USB device using address 17 scsi0 : SCSI emulation for USB Mass Storage devices Vendor: Genesys Model: SD USB Reader Rev: 9144 Type: Direct-Access ANSI SCSI revision: 02 Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0 Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0 USB Mass Storage device found at 17 SCSI device sda: 126912 512-byte hdwr sectors (65 MB) sda: assuming Write Enabled sda: assuming drive cache: write through SCSI device sda: 126912 512-byte hdwr sectors (65 MB) sda: assuming Write Enabled sda: assuming drive cache: write through sda: sda1 ...and a successful USB1.1 initialization on the problematic front plug: usb 4-2: new full speed USB device using address 2 scsi1 : SCSI emulation for USB Mass Storage devices Vendor: Model: Rev: Type: Direct-Access ANSI SCSI revision: 02 SCSI device sda: 125440 512-byte hdwr sectors (64 MB) sda: assuming Write Enabled sda: assuming drive cache: write through sda: sda1 Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0 Attached scsi generic sg0 at scsi1, channel 0, id 0, lun 0, type 0 USB Mass Storage device found at 2 I don't know if this helps at all, but I just can't seem to stop myself. I'm like a dog gnawing a bone. Dave North
Okay, just for completeness, a front-panel success on 2.4.31 looks like: hub.c: new USB device 00:10.2-2, assigned address 2 scsi1 : SCSI emulation for USB Mass Storage devices Vendor: Genesys Model: SD USB Reader Rev: 9144 Type: Direct-Access ANSI SCSI revision: 02 Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0 SCSI device sda: 126912 512-byte hdwr sectors (65 MB) sda: Write Protect is off sda: sda1 WARNING: USB Mass Storage data integrity not assured USB Mass Storage device found at 2 ... I'll shut up now. Promise! Dave North
Created attachment 5741 [details] longer enumeration delays Dave North reports that this suffices to make the enumeration problem go away. (This is a trimmed down version of the debug patch I sent to linux-usb-devel.) It'd likely be a good one to get into 2.6.13-final after learning which parts are the ones that are actually necessary. (I'll guess just the root hub powerup delay would suffice.) There seems to be a usb-storage issue later on, too.
This bug is probably invalid. It appears to be a flaky hardware issue. Reports of 2.4 kernel correctly operating the socket were incorrect because the idiot bug reporter (that would be me) failed to notice he never set ehci in the 2.4 kernel. Doing so caused failure there, too.