Matthew Dharm wrote:
> That's what a clean unlink looks like under EHCI? Okay, then....

According to the spec for usb_unlink_urb(), that's what an async
unlink should look like for *all* host controllers.  (Modulo the
fact that -ECONNRESET may have different values on different
versions of Linux.)

Looking at the usb_stor_transfer_partial() code, it looks to me
like it expected to know it was in the middle of an abort, but
didn't ... and so it gave a catch-all message and bypassed the
abort processing, rather than knowing that the only reason it'd
ever see async unlinks is because the request was aborted.

This particular usb-storage abort problem has been seen before.

I suspect maybe there's just a race in the error/abort logic,
which gets lost more often with higher speed transfers.


> The only reason command_abort() gets called is that the command has been
> out for over 20 seconds.  For that to occur during the data phase (and
> combined with the 'hang' at the CSW stage) means that the HCD thinks that
> the device is NAKing.
> 
> My -guess- is that the data toggle has been screwed up somewhere.  If it's
> not an EHCI problem, then the device is basically refusing to transfer
> anything in.  We should get status or data or _something_, but never
> silence from the device.

Yeah, data toggle problems in USB have really rude failure modes.

The toggle bit is maintained by hardware (except for UHCI :), and
the HCD never modifies that bit in the QH unless a device driver
resets the toggle with usb_clear_halt(), usb_set_interface(), or
usb_settoggle().

- Dave



> Matt
> 
> On Mon, Jul 15, 2002 at 11:23:18PM -0700, David Brownell wrote:
> 
>>>>(lots of successfull xfer 4096 bytes; xferred 4096/4096; transfer complete)
>>>>
>>>>usb-storage: usb_stor_bulk_msg() returned 0 xferred 4096/4096
>>>>usb-storage: usb_stor_transfer_partial(): transfer complete
>>>>usb-storage: usb_stor_transfer_partial(): xfer 4096 bytes
>>>>usb-storage: command_abort() called
>>>>hcd/ehci-hcd.c: 00:13.2 urb_dequeue 8151be60 qh state 1
>>>>hcd.c: giveback urb 8151be60 status -131 len 0
>>>>usb-storage: usb_stor_bulk_msg() returned -131 xferred 0/4096
>>>>usb-storage: usb_stor_transfer_partial(): unknown error
>>>>usb-storage: Bulk data transfer result 0x2
>>>>usb-storage: Attempting to get CSW...
>>>
>>>
>>>This is clearly from your MIPS system, which shows that the EHCI driver for
>>>your 2.0 card is complaining about something.  Likely the EHCI driver is
>>>experiencing some problems on this platform.
>>
>>In this case, the question is why usb-storage aborted the
>>command and unlinked the urb ... everything after that
>>command_abort() is exactly what one would expect when a
>>driver unlinks an urb (asynchronously).
>>
>>As for why usb_stor_transfer_partial() doesn't know to handle
>>the async unlink that it requested, I have no idea.
>>
>>- Dave
>>
>>
> 
> 





-------------------------------------------------------
This sf.net email is sponsored by: Jabber - The world's fastest growing 
real-time communications platform! Don't just IM. Build it in! 
http://www.jabber.com/osdn/xim
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to