Comment 422 for bug 88746
Revision history for this message
| Troy James Sobotka (troy-sobotka) wrote | #422 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
@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 versions.
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 report.
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...