At 12:46 PM 1/16/2005 -0500, Alan Stern wrote: On Sun, 16 Jan 2005, Pete Zaitcev wrote:
Hi, Alan:
I have received a USB stick which refuses to return the descriptor upon the first 64 byte read (HC returns with code -71). The following patchlet fixes the problem:
@@ -2162,6 +2162,8 @@ hub_port_init (struct usb_device *hdev, if (USE_NEW_SCHEME(retry_counter)) {
struct usb_device_descriptor *buf;
+ msleep(10); + Apparently, the device does not like to return descriptors immediately after a port reset.
The descriptor fetch doesn't occur immediately after the port reset; there's a delay in between (see hub_port_wait_reset). What happens if you
increase HUB_SHORT_RESET_TIME and HUB_ROOT_RESET_TIME each by 10 ms
instead of adding the extra msleep?
Also note that the line above the first line shown in your patch already includes a 100 ms delay between loop iterations. If your device refuses to return the descriptor the first time through that loop, does it work the second time?
HOWEVER, I question the wisdom of going through these hoops for high-speed devices. Their MaxPacketSize is fixed, isn't it?
Yes it is.
I found a message at the following URL: http://marc.theaimsgroup.com/?l=linux-usb-devel&m=109595376619962&w=2
If you really want to imitate Windows, you should issue the 64-byte Get-Descriptor request to every device regardless of its speed. Then skip the existing 8-byte request, as it would no longer be needed.
What is up with that? Does Windows do it? Which one (98, XP)?
I haven't tested Win 98, but I believe that NT, 2000, and XP all do it. It's true that for high-speed and low-speed devices, none of this nonsense is needed because the maxpacket size is fixed. But I have seen reports of devices (can't remember what speed they ran at) which would not work unless this initialization sequence was used. I figure it's safest just to imitate Windows as best we can; for devices that don't need it the extra overhead shouldn't hurt.
Perhaps the main weakness in the approach is that the delays might not be long enough (as you found). While there may be USB traces of Windows device initialization with accurate, high-precision timestamps somewhere in the email archives, I can't locate them. Maybe you or someone else can.
Hi Alan, I am finally getting my Linux compatible hardware USB analyzer finished. I have posted two traces on my web site which may help (go to the very end of the page for samples).
The shorter, easier to understand one is win98SE enumerating a VERY SLOW ZOOM ACM modem. The longer one is winXP enumerating the same modem. I did not filter out the huge number of NAKs issued by the device so you saw a pure view of the process. Every SOF is shown in the displays. The SETUP commands are not decoded in these traces) Bus reset on both is more then 10ms and less than 20ms of SEO. You can count the number of frames after detection by counting the number of SOFs after device detection (The start of the trace win98=138 frames winXP=28 frames). You can count the number of ms after reset by counting the SOF after the SEO reset device 0 and got ready to set an address (win98=44 frames winXP=17 frames).
Regards ^Steve
web site: http://myspot.neteze.com/~calfee/
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
