On Thu, 20 Nov 2003, David Brownell wrote:
> > Nov 10 19:59:25 shaun kernel: usb-storage: Command WRITE_10 (10 bytes)
> > Nov 10 19:59:25 shaun kernel: usb-storage: 2a 00 00 01 4f 6e 00 00 1f 00
> > Nov 10 19:59:25 shaun kernel: usb-storage: Bulk Command S 0x43425355 T 0x131f L
> > 63488 F 0 Trg 0 LUN 0 CL 10
> > Nov 10 19:59:25 shaun kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31
> > bytes
> > Nov 10 19:59:25 shaun kernel: usb-storage: Status code 0; transferred 31/31
> > Nov 10 19:59:25 shaun kernel: usb-storage: -- transfer complete
> > Nov 10 19:59:25 shaun kernel: usb-storage: Bulk command transfer result=0
> > Nov 10 19:59:25 shaun kernel: usb-storage: usb_stor_bulk_transfer_sglist: xfer
> > 63488 bytes, 2 entries
> > Nov 10 19:59:25 shaun kernel: usb 1-1: sg_complete, unlink --> -19
>
> That is, the sg_complete() code was cleaning up after an error and
> it ran into a problem ... like maybe it was trying to unlink an urb
> that hadn't yet been submitted. That particular error is nothing to
> worry about AFAICT, unless perhaps it's masking something else.
> (The diagnostic suggests _something_ unexpected.)
>
> The other thing that looks potentially interesting is that you managed
> to get more than the usual amount of contiguous memory. Normally I'd
> expect about fifteen sglist entries. A few things come to mind then:
>
> - Individual bulk transfers over about four "pages" (16K) will kick in
> a mechanism in the EHCI driver that should work fine, but which
> doesn't get used much at all. A bug could be lurking there
> (qtd_fill at the top of ehci-q.c), but none jumps out at me.
>
> - If "dvdrecord" is using the SG driver, it's also possible there's
> an issue with alignment. In this case, the buffers must all be
> aligned on 512 byte boundaries -- and have lengths that are all
> multiples of 512 bytes -- if the SG code is doing anything that
> verges on zerocopy I/O ("O_DIRECT").
I don't know anything about how dvdrecord works, but alignment could well
be the source of the problem. Try applying this patch and see if it
changes anything:
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=106943859421845&w=2
> Maybe you can play with "dvdrecord" options (or system load) to see
> if you can make it deliver smaller sglist entries, to rule out that
> first factor.
>
>
> > Nov 10 20:01:05 shaun kernel: usb-storage: command_abort called
> > Nov 10 20:01:05 shaun kernel: usb-storage: usb_stor_stop_transport called
> > Nov 10 20:01:05 shaun kernel: usb-storage: -- cancelling sg request
>
> Also it seems like usb-storage decided to abort after ten seconds.
> That's short for the usual timeouts (maybe dvdrecord chose it), but
> long for recovery from the fault noted above. But it didn't say a
> thing about _why_ it chose to cancel ... so it's not clear to me
> whether the fault was reported (and if so, what was it?) but mis-handled,
> or whether it was instead just never reported.
The abort was a simple timeout, and almost certainly the time limit was
chosen by dvdrecord. Whatever the problem was, it prevented the
usb_sg_wait() routine from returning; hence the timeout.
Alan Stern
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
