> usb-storage: usb_stor_bulk_transfer_sglist: xfer 524288 bytes, 128 entries
> usb-storage: Status code 0; transferred 524288/524288
> usb-storage: -- transfer complete
> usb-storage: Bulk data transfer result 0x0
That's two successive operations on the OUT endpoint
(two IRQs: request, then 128 pages) both of which
worked fine, followed by one on the IN endpoint:
> usb-storage: Attempting to get CSW...
> usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
> usb-storage: usb_storage_command_abort called
> usb-storage: usb_stor_stop_transport called
> usb-storage: -- cancelling URB
> usb-storage: Status code -104; transferred 0/13
> usb-storage: -- transfer cancelled
> usb-storage: Bulk status result = 3
> usb-storage: -- command was aborted
Interesting. So basically, the failure mode you saw
was that after all the data was (evidently) transferred
OK, usb-storage aborted (for some reason) its fetch
for the transfer status ... and then trouble.
Why did usb-storage abort that IN transfer? If we
knew that, we'd have a good clue as to what's going
> Load only got up to about 3-4 before it fell over.
> Apart from that, it seems the speed at which it falls over is depening
> on two factors: with/without debugging and speed at which data arrives
> for the drive.
Not unrelated. Turning on usb-storage debug slows down the
rate at which data is handed to the drive.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/