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);
> +
> #define GET_DESCRIPTOR_BUFSIZE 64
> buf = kmalloc(GET_DESCRIPTOR_BUFSIZE, GFP_NOIO);
> if (!buf) {
>
> 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.
> I tried a patch which simply skips all this insanity and goes right to
> the address setting and reading of descriptors. It seems to work with all
> my devices. See appended.
Isn't this pretty much the same as what you get if you set the
old_scheme_first module parameter?
> At bare minimum, I need the delay in, but please consider the bigger patch
> (it will conflict with the current tree because of retry loop added
> recently for the 64-byte descriptor read, but I only want a general
> opinion).
I have no objection to increasing the default port-reset delays. And
refactoring the code to split out the portion of hub_port_init that
determines ep0maxpacket is a good idea, so long as the functionality
doesn't change. Would you like me to write a patch against the current
tree to do those things?
Alan Stern
-------------------------------------------------------
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
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
