In 2.4.21 drivers/usb/usb.c line 2157 was: err = usb_get_string(dev, dev->string_langid, index, tbuf, 255);
Now in 2.6.0 drivers/usb/core/message.c line 1208: err = usb_get_string(dev, dev->string_langid, index, tbuf, len);
after setting to parameter len = 255 the device worked right away.
My scanner apparently reports the string descriptor length incorrectly, which leads to a global denial of the whole device.
I've noticed related problems with some other devices, especially "older" USB 1.x devices going through USB 2.0 hubs.
It's got me to thinking that usbcore probably needs smarter strategies for fetching descriptors (all kinds), retrying after certain kinds of errors:
- Some devices evidently choke on "read extra bytes", others
are like yours (choke on "read exact length"). So try
both, when we "know" a descriptor exists: device and
config descriptors, some string descriptors. - Firmware/silicon faults may stall the first read, and
work the second time ... even using the same strategy
("extra" vs "exact") to read the descriptor. Protocol
stall is sometimes not a "hard" error; so retry. - During early enumeration, sometimes devices get confused
after the initial "read 8 bytes to get ep0 maxpacket size".
Mostly an issue when ep0 maxpacket _is_ 8 bytes... :)
Retrying helps in some cases.When I've modified "lsusb" to retry, and understand both "extra" and "exact" descriptor read modes, it's started to work with a lot more devices. I think you're right that the kernel may need to pay more attention here.
- Dave
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
