Oct 26 23:53:09 titanic kernel: usb-storage: Bulk Command S 0x43425355 T 0x4d1a0 L 32768 F 128 Trg 0 LUN 0 CL 10
Oct 26 23:53:10 titanic kernel: usb-storage: Bulk Status S 0x53425355 T 0x4d1a0 R 0 Stat 0x1
Oct 26 23:53:10 titanic kernel: usb-storage: Bulk Command S 0x43425355 T 0x8004d1a0 L 18 F 128 Trg 0 LUN 0 CL 6
Oct 26 23:53:10 titanic kernel: usb-storage: Bulk Status S 0x53425355 T 0x8004d1a0 R 0 Stat 0x0
Yes this is a step forward, sorry it is not complete.
The theory I'm voting we test is whether the CDB, the CBW, or the relationship between the CDB and the CBW appears in any way consistent, from one observed failure to the next.
Here we have only CBW, labeled "Bulk Command", and CSW, labeled "Bulk Status", but no CDB. I'm used to seeing logs of Linux usb-storage print the "Bulk Command" message together with a print out of the CDB and the hex of the sense data. In this log we see only "Bulk Command". Is your /etc sending some lines to /var/log/messages and others to /var/log/debug? Can you easily turn that off? We want to see all the printk of usb-storage, in order, together, else we're losing significant evidence.
I like seeing the T correlate well: I imagine setting bit 31 is how Linux usb-storage decides the T of a "CL 6" "REQUEST SENSE" sent when a "CL 10" "READ (10)" failed.
I suppose by faith in Linux we can suppose the CDB is consistent with the CBW, but then we need a new theory to explain "Additional sense: Data phase error". We'd be supposing the "CL 10" CDB is fits the pattern x 28 00 xx:xx:xx:xx 00 00:40 00, and the "CL 6" CDB is x 06 00:00:00 12 00, and the xx:xx:xx:xx nybbles of the "CL 10" CDB are in the range of blockdev --getsize.
Note: I had to kill the pldd-prozess because accessing the first harddisk stopped after 30-60 mins but pldd neither finished nor displayed an error.No interesting dmesg near the kill? Or from your next shutdown?
No:
Curious. Well then, so long as we believe Linux isn't designed to give us useful information unless we wait for the ioctl SG_IO timeout to expire, we'd better patch pldd to substitute a short timeout, like 30s, else switch over to learning the command line syntax of another tool with a shorter default, like sg_dd.
Pat LaVarre
-------------------------------------------------------
This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
