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").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.
- Dave
------------------------------------------------------- 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
