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
