Applied the diagnostic patch to 2.6.1-rc1 _without_ the recommended workaround from Alan. Is the attached log what you expected to see?
Yes, see below. Exactly the sort of failure seen before; looks like a problem in the device.
It'd be good if someone who can reproduce this would post a CATC trace log too, but I'd expect that would just say the same thing.
- Dave
Jan 5 11:57:19 eraser kernel: usb-storage: *** thread sleeping. Jan 5 11:57:19 eraser kernel: usb-storage: queuecommand called Jan 5 11:57:19 eraser kernel: usb-storage: *** thread awakened. Jan 5 11:57:19 eraser kernel: usb-storage: Command WRITE_10 (10 bytes) Jan 5 11:57:19 eraser kernel: usb-storage: 2a 00 00 01 22 30 00 00 10 00 Jan 5 11:57:19 eraser kernel: usb-storage: Bulk Command S 0x43425355 T 0x135d L 32768 F 0 Trg 0 LUN 0 CL 10 Jan 5 11:57:19 eraser kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes Jan 5 11:57:19 eraser kernel: usb-storage: Status code 0; transferred 31/31 Jan 5 11:57:19 eraser kernel: usb-storage: -- transfer complete Jan 5 11:57:19 eraser kernel: usb-storage: Bulk command transfer result=0 Jan 5 11:57:19 eraser kernel: usb-storage: usb_stor_bulk_transfer_sglist: xfer 32768 bytes, 8 entries Jan 5 11:57:19 eraser kernel: ehci_hcd 0000:00:1d.7: cancel qh c275b100 n0275b002 info 42002202 40000000 qtd 275a1e0 Jan 5 11:57:19 eraser kernel: ehci_hcd 0000:00:1d.7: overlay td c275b110 n0275a240 00000007 t0c000c41 p0=7c8f2400 Jan 5 11:57:19 eraser kernel: ehci_hcd 0000:00:1d.7: cancel td c275a240 n0275a2a0 00000001 t10000c80 p0=7c56b000
That's the QH with its overlay TD (sharing memory), followed by the QH that's now at the head of the list. The hardware's list is a bit ahead of the software's list, since the software is now cleaning up the transfer queue after a HALT.
In this case the overlay TD token (t0c000c41) has status bits (41) saying the QH is HALTed and the last transaction to the device was a PING. And that the buffer had 0c00 bytes to go (3072).
So the device returned a STALL in response to the PING it was sent, after transferring about 1 KByte from this TD. There were likely two TDs preceding this: 4KB each, plus 1KB from this, adds up to the 9KB reported transfer.
What we've seen previously with such devices is that the device stops responding after two or three full speed OUT packets, just like this did. As if there's some bug in the device when the FIFO fills up; FIFOs usually won't hold more than a handful of high speed packets.
The only thing different here is that the STALL seems to have come in response to a PING. I don't recall noticing that before. It supports the theory that the FIFO filled just before this hardware started flaking out. (It might also support theories about broken PING support in that GeneSys hardware.)
Jan 5 11:57:19 eraser kernel: ehci_hcd 0000:00:1d.7: cancel td c275a2a0 n0275a300 00000001 t10000c80 p0=7c56a000 Jan 5 11:57:19 eraser kernel: ehci_hcd 0000:00:1d.7: cancel td c275a300 n0275a360 00000001 t10000c80 p0=7c569000 Jan 5 11:57:19 eraser kernel: ehci_hcd 0000:00:1d.7: cancel td c275a360 n0275a3c0 00000001 t10000c80 p0=7c568000 Jan 5 11:57:19 eraser kernel: ehci_hcd 0000:00:1d.7: cancel td c275a3c0 n0275a420 00000001 t10008c80 p0=7bc87000 Jan 5 11:57:19 eraser kernel: usb-storage: Status code -32; transferred 9216/32768 Jan 5 11:57:19 eraser kernel: usb-storage: clearing endpoint halt for pipe 0xc0010200 Jan 5 11:57:19 eraser kernel: usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value=0000 index=02 len=0 Jan 5 11:57:19 eraser kernel: usb-storage: usb_stor_clear_halt: result = 0 Jan 5 11:57:19 eraser kernel: usb-storage: Bulk data transfer result 0x2 Jan 5 11:57:19 eraser kernel: usb-storage: Attempting to get CSW... Jan 5 11:57:19 eraser kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes Jan 5 11:57:19 eraser kernel: usb-storage: Status code -32; transferred 0/13 Jan 5 11:57:19 eraser kernel: usb-storage: clearing endpoint halt for pipe 0xc0008280 Jan 5 11:57:19 eraser kernel: usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value=0000 index=81 len=0 Jan 5 11:57:19 eraser kernel: usb-storage: usb_stor_clear_halt: result = 0
OK, this much is good -- the halt cleared, so the device isn't completely locked up.
Although I suspect it's sitting there waiting to read more data, rather than waiting to transmit the CSW, which would explain the timeout below.
Jan 5 11:57:19 eraser kernel: usb-storage: Attempting to get CSW (2nd try)... Jan 5 11:57:19 eraser kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes Jan 5 11:58:19 eraser kernel: usb-storage: command_abort called Jan 5 11:58:19 eraser kernel: usb-storage: usb_stor_stop_transport called Jan 5 11:58:19 eraser kernel: usb-storage: -- cancelling URB Jan 5 11:58:19 eraser kernel: ehci_hcd 0000:00:1d.7: cancel qh c275b180 n0275b002 info 42002102 40000000 qtd 275a060 Jan 5 11:58:19 eraser kernel: ehci_hcd 0000:00:1d.7: overlay td c275b190 n0275a120 00000001 t000d8d80 p0=3709f000 Jan 5 11:58:19 eraser kernel: ehci_hcd 0000:00:1d.7: cancel td c275a060 n0275a120 00000001 t000d8d80 p0=3709f000
This was a normal timeout/unlink. Token in the overlay (t000d8d80) is the same as the in-memory one, and the QH didn't advance past the software's record of the list head (qtd 275a060) ... everything's still live, but the device just isn't responding.
Jan 5 11:58:19 eraser kernel: usb-storage: Status code -104; transferred 0/13 Jan 5 11:58:19 eraser kernel: usb-storage: -- transfer cancelled Jan 5 11:58:19 eraser kernel: usb-storage: Bulk status result = 4 Jan 5 11:58:19 eraser kernel: usb-storage: -- command was aborted Jan 5 11:58:19 eraser kernel: usb-storage: usb_stor_Bulk_reset called
------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
