On Mon, 25 Feb 2008, Jan Gutter wrote: > Hi, I have a Cooler Master X-Craft hard drive enclosure with > USB ID ed06:8000. (Manufacturer ID according to lsusb is DATAST0R) > > I've had no problems in using the drive on 2.6.23, but on vanilla 2.6.24 > I get a "device not accepting address" error in dmesg. I've done a > bisect, and found out that if I revert the patch series, (from > linus-git) > > 4d2f110c51eec853c50f68cf068888a77551c8d3 to > e015268d2fcfcaef70a1ec535e6381f75aafbf81 > > (i.e. the "get rid of urb->lock" and "urb->status" series) > > it works again in 2.6.24. (A more verbose description is listed in the > bug report below.) > > At first glance, it *looks* like a timing issue. Since a lot of > spinlocks have been eliminated, the device might just go a little funny > if it gets responses too fast on init.
Actually the spinlocks weren't eliminated; they were just moved around. Any difference in speed should be minuscule. > I've found a similar bug at: > > http://bugzilla.kernel.org/show_bug.cgi?id=8639 > > I'm NOT sure that the enclosure has the same chipsets, but it seems very > likely. I get the exact same kernel messages, tough. I've logged all my > experiences there, if you need anything else, I would be happy to > provide! > > My question now is: what would be the best way to add a quirk for this > to the kernel, and who would best be able to help me with this? Does the > kernel even know the USB id at the stage that this error occurs? Last question first: The kernel does not know the USB IDs at the "device descriptor read/64" or "device not accepting address" stage. You can try adding an explicit delay to see if it helps. In drivers/usb/core/hub.c:hub_port_init(), add a call to msleep just before the line: for (i = 0; i < GET_DESCRIPTOR_TRIES; (++i, msleep(100))) { I don't know how large an argument to msleep you'll need. 100? 5000? Note that there's already a 50-ms delay before the loop begins. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
