Duncan Sands wrote:
>>>Question: why did the first urb complete with -EILSEQ when
>>>the other device was plugged in?
>>
>>And also, why did it _keep_ doing that afterwards?
>
>
> This is presumably the same question.
Likely so, but not necessarily.
>>Can you tweak the "return -EILSEQ" to be more like
>>
>> { info ("status bits %08x", status); return -EILSEQ; }
>>
>>and see if perhaps some other status bit is more suggestive
>>of the real problem. Maybe the data toggle got trashed, or
>>something similar.
>
>
> This always gives "status bits 00440000".
Translates to stall and a crc/timeout, I think...
I'm still not quite clear what's making that happen,
but it does suggest that it might be important for
the driver to clear the stall before expecting anything
else. That's usb_clear_halt(), and I presume there's
some "libusb" call you can make to get at that through
the USBDEVFS_CLEAR_HALT ioctl.
If that makes your driver behave again, then it'd seem to
me there's a bug in the UHCI status processing ... neither
UHCI driver looks like it'll flag endpoints as halted
unless a stall is the _only_ error reported.
Of course there might be some other bug lurking too, since
it's not clear why that first error should ever happen, but
discarding stall status doesn't seem correct.
- Dave
p.s. This failure mode is about what you'd expect to
happen when a driver doesn't clear a stall on
an endpoint ... the device would completely
refuse to talk using that endpoint.
-------------------------------------------------------
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
