On Thursday 06 January 2005 10:46 am, Alan Stern wrote:
>
> The best answer may be to make use_both_schemes=1 the default.
That'd likely reduce the number of problem reports, but I suspect
it'd still be masking some fixable problems.
> I'm sure
> I've seen log reports of devices that failed when initially asked for 18
> bytes worth of the device descriptor and worked when asked for 64 bytes,
> even though they only returned 18.
I don't recall any such reports, but then the developers of
firmware bugs can be rather creative ... ;)
> > > Anyway, the intent of the scheme was to duplicate the
> > > Windows packet sequence, which always requests 64 bytes. The real
> > > question is: If a device works under Windows, why doesn't it work under
> > > Linux with the same sequence of packets?
> >
> > That's one question. You may recall that I submitted a patch a
> > while back to retry the read in that case, rather than failing...
> > you changed it to check much later, instead of retrying right away.
>
> It's not _that_ much later. Only a port reset intervenes.
But it was late enough to make a critical difference: between
being able to enumerate, and failing completely. When that
reset/read sequence failed, it was repeatable; but the simpler
reset/read/retry sequence worked.
> And the
> current code in gregkh-2.6 does retry immediately on length-0 reply or
> STALL. Would you like to see it retry also if the second byte of the
> reply is not equal to USB_DT_DEVICE? How does the patch below look?
That patch looked OK, but I might prefer one that also validated
the ep0 maxpacket size too. (The patch I sent _only_ validated
that field.) How about something more like
if (r < 8 || buf->bDescriptorType != USB_DT_DEVICE) {
r = -EPROTO;
continue;
}
switch (buf->bMaxPacketSize0) {
case 8: case 16: case 32: case 64: break;
default:
r = -EPROTO;
continue;
}
No real point in accepting a read of 3 bytes and then relying
on the non-existent 8th byte ... or relying on obviously borked
data in that byte!
> > That's because I saw devices that failed without early retry;
> > the short read confused the hardware (or firmware), and the
> > data landing in that buffer needed more checks. The normal
> > code for usb_get_descriptor() retries when it gets garbage;
> > but in that code path, you don't retry.
>
> The code _does_ retry, following a port reset. Anyway, if a short read
> confuses the device, how does immediately repeating the short read manage
> to unconfuse it?
In some cases, the root of the problem has been that the
endpoint zero FIFO state doesn't get fully cleared on receipt
of the SETUP packet, or after reset ... so the next read gets
the data left over from some previous request. In other cases
I've seen strangeness related to marginal signal levels.
That can happen with hardware bugs, firmware bugs, or even
combinations of the two.
> > Another question is whether those devices will work better
> > under Linux when not forcing short reads ... :)
>
> That's why I think we should always use both schemes.
Yes, I think that'd be a less troublesome default.
But I also think we need to make all the control transfers
during the init sequence be more robust.
- Dave
> Alan Stern
>
>
>
> ===== drivers/usb/core/hub.c 1.222 vs edited =====
> --- 1.222/drivers/usb/core/hub.c 2004-12-20 20:14:32 -05:00
> +++ edited/drivers/usb/core/hub.c 2005-01-06 13:43:42 -05:00
> @@ -2197,6 +2197,11 @@
> (i ? HZ * USB_CTRL_GET_TIMEOUT : HZ));
> if (r == 0 || r == -EPIPE)
> continue;
> + if (r >= 2 && buf->bDescriptorType !=
> + USB_DT_DEVICE) {
> + r = -EPROTO;
> + continue;
> + }
> if (r < 0)
> break;
> }
>
>
-------------------------------------------------------
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
