[Bug 88746] Re: ehci_hcd module causes I/O errors in USB 2.0 devices
Troy James Sobotka
troy.sobotka at gmail.com
Thu Dec 11 04:15:45 UTC 2008
@zasq and Troy R.:
Chances are that there could be either the same underlying chip / hardware at the core of the Kingston. Alcor is just the identifier, and is certainly a vendor that will exhibit this bug. There are probably more. The key here is to locate the USB vendor so we can provide a list. I have seen the Kingston show up on someone's pendrive in this list, and as such, I'd say that so far it is consistent with our other findings.
The big boggle here is that David Becker's drive doesn't exhibit this
behavior. It is quite likely and probable that the underlying chip /
board in the drive is _different_ from the chip / board in your drives.
This is common and is also seen in wireless cards where in spite of an
identical model and brand, the chipset _may_ be different based on sub
I'd compile a list of the suspect boards if we can separate the bug into
those that are actually mounting but failing. For example, mine look
like this after an 'lsusb':
ID 058f:6366 Alcor Micro Corp.
ID 058f:6254 Alcor Micro Corp.
The above fix will work that is noted in the bug report. Locate your
drive location path and perform the 'echo "128" >' etc. line.
As for the mounting problem, I can't seem to find the appropriate bug
Hope this helps. For those with devices that _mount_ but gag out and
crash ehci_hcd after transferring, please state such and locate the
appropriate device ID in your lsusb output. Maybe that will help a dev
/ hacker locate the problem. I'll donate my card reader to the cause...
ehci_hcd module causes I/O errors in USB 2.0 devices
You received this bug notification because you are a member of Kernel
Bugs, which is subscribed to Linux.
More information about the kernel-bugs