That's what a clean unlink looks like under EHCI? Okay, then.... 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.
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
>
>
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
Oh great modem, why hast thou forsaken me?
-- Dust Puppy
User Friendly, 3/2/1998
msg07791/pgp00000.pgp
Description: PGP signature
