That report wasn't very helpful. I recommend reviewing the "How do I report a bug?" FAQ at www.linux-usb.org next time, and for now forward:
Sorry for that, someone on usb-users told me he already reported the bug, so I basically wanted to say "Hey, got the same problem".
Well, "reported" to who knows where. Not the right place, for sure.
- /proc/bus/usb/devices content showing your host controllers and the "problem" device.
... T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 6 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS= 8 #Cfgs= 1 P: Vendor=0000 ProdID=0000 Rev= 2.04 S: Manufacturer=Linux 2.4.21-ow2 ehci-hcd S: Product=PCI device 10de:0068 (nVidia Corporation) S: SerialNumber=00:02.2 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=256ms
Drive is connected to "PCI device 10de:0068 (nVidia Corporation)"
Doesn't look like it. There was no storage device in what you sent. And I don't know this "ow2" patch ... are you sure it's a superset of 2.4.22-rc1? Doesn't look like one...
00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev a3) (prog-if 20
[EHCI])
Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer: Unknown device f541
An SN41G2? :)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 (750ns min, 250ns max) Interrupt: pin C routed to IRQ 3 Region 0: Memory at ee085000 (32-bit, non-prefetchable) [size=256] Capabilities: [44] #0a [2080] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
- dmesg output including all EHCI messages, with the usb code compiled with CONFIG_USB_DEBUG. The most important bits will be any problems it reports, near when the scsi layer gets unhappy.
According to Alan, the output didn't contain anything useful. Here's the log, it starts shortly before the drive goes wild:
Right, that's useless. You're certain that had CONFIG_USB_DEBUG enabled? Those messages would be much earlier in /var/log/kernel (or wherever you keep your KERN_DEBUG output). Try running with the attached patch; it just spits out information about things that get unlinked due to timeouts.
- Results of using the same drivers on 2.6.0-test3, which has much better code in the layers over the ehci driver.
Would love to, but 2.6.0 doesn't work too well for me.
Curious. You should report the problems to LKML. Works fine for me, on hardware that seems to be almost identical to yours.
Would also have been great to get bug report before we reached 2.4.22-rc1 of course.
I reported this twice to LKML (pre5 and pre8 IIRC) and once to usb-users (-pre5).
Never got a reply on any of my posts, this is my fourth try and the first one with a response.
Hint: This is the first one you sent to linux-usb-devel ... :)
If you need anything else, just let me know. :)
Seems like this diagnostic patch should turn up anything that's to be turned up, if it's a real issue in the EHCI code.
- Dave
--- 1.16/drivers/usb/host/ehci-q.c Thu Jun 19 06:51:52 2003
+++ edited/ehci-q.c Sun Aug 10 12:06:53 2003
@@ -267,6 +267,7 @@
unsigned count = 0;
int do_status = 0;
u8 state;
+ u8 dumped = 0;
if (unlikely (list_empty (&qh->qtd_list)))
return count;
@@ -347,6 +348,19 @@
do_status = 0;
continue;
}
+#if 1
+ switch (urb->status) {
+ default:
+ break;
+ case -ECONNRESET: /* canceled */
+ case -ENOENT:
+ if (!dumped) {
+ dumped = 1;
+ dbg_qh ("cancel", ehci, qh);
+ }
+ dbg_qtd ("cancel", ehci, qtd);
+ }
+#endif
/* token in overlay may be most current */
if (state == QH_STATE_IDLE
