"13 bytes not 512" is rather suspicious if we have bInterfaceClass ...Protocol = x 08
50. In that context, 13 just happens to be the length of a CSW. How sure are we that
the packet here is data? Do we know if its first four bytes are "USBS", as we would
expect in a CSW?
When working with perfect devices, a host thinking that CSW In is Data In is a host
that dropped a Data In packet.
Curiously yours, Pat LaVarre
-----Original Message-----
From: Greg KH [mailto:[EMAIL PROTECTED]]
Sent: Tue 12/10/2002 2:34 PM
To: David Brownell; USB Developers; USB Storage List
Cc:
Subject: Re: [usb-storage] Re: [linux-usb-devel] Re: PATCH: usb-storage: make
internal structs more consistent
On Mon, Dec 09, 2002 at 06:11:32PM -0800, Matthew Dharm wrote:
> On Mon, Dec 09, 2002 at 05:34:11PM -0800, Greg KH wrote:
> > On Mon, Dec 09, 2002 at 05:32:02PM -0800, David Brownell wrote:
> > > >>...
> > > >>Dec 9 15:22:26 soap kernel: usb-storage:
> > > >>usb_stor_bulk_transfer_sglist(): xfer 65536 bytes, 16 entries
> > > >>Dec 9 15:22:26 soap kernel: usb-storage: Status code -121;
transferred
> > > >>65037/65536
> > > >>Dec 9 15:22:26 soap kernel: usb-storage: -- unknown error
> > >
> > > That's not a timeout, "-EREMOTEIO" means it got a short read.
> > > In this case, that last packet included only 13 bytes not 512.
> > > (Assuming this was at high speed, otherwise it wasn't the last
> > > one, and that was likely 13 bytes out of 64.)
> >
> > Yeah, that suggests that either usb-storage needs to handle this
> > somehow, right?
>
> No. That's a bogus thing for a drive to do. It _should_ just NAK when
> there is no data until data becomes available.
>
> A short packet indicates the end of the data phase.
So the device is buggy when pushed as fast as we now are?
> > > Given there's only one place in the EHCI driver where EREMOTEIO
> > > shows up, I'm tempted to believe that the hardware really did
> > > return a short read in that last packet.
> > >
> > > As for why it did so, no ideas just now. Though I wonder if
> > > maybe retrying short reads wouldn't help, on the premise that
> > > the disk had a temporary "can't keep up" problem, since using
> > > those scatterlist operations drives that hardware much faster
> > > than it was ever driven by earlier kernels.
>
> Ack! No! No retrying short reads. We need to be able to see them!
>
> > But does that deserve the long "reset the endpoint" delay that happens
> > because of this? I'd rather have a bit slower throughput and no long
> > delays, than shorter bursts of data, with long delays, cutting the end
> > throughput way down.
>
> Well, the reset logic is slow because some devices need that much time.
> You shouldn't be resetting, because you shouldn't be getting short reads.
> We need to fix the root cause, not the symptoms.
I agree, any ideas?
greg k-h
_______________________________________________
usb-storage mailing list
[EMAIL PROTECTED]
http://www2.one-eyed-alien.net/mailman/listinfo/usb-storage
�+,~w�zf��+,��좷�o%���y�O��
���j�j�^��'�&�+r-櫞�.�쨺�h��ڴ�6��ޭ�+���x*&��b� �jyޖm����^��Z�w���?�)���u�ޖX���(�� ~��zw�N�����r��z� ��j�_�����]j�m��?�X���(�� ~��zw��X�����b��?�)���u��
