On Thu, 19 May 2005, Garnet Ulrich wrote: > Alan, sorry for the delay. Busy lately. Anyway, I finally got the > debug output to syslog. > So I notice that the OS (gnome/nautilus?) is constantly checking the > drive before I start cdrecord. I'd worry that it is interfering except > that even if I use the the Gnome CDrecording app, I think it just calls > cdrecord and of course has the same problem.
It looks like your drive has problems with the READ BUFFER command. That explains why things started breaking when you upgraded; the older version of cdrecord doesn't use READ BUFFER. The initial attempt to transfer only 4 bytes succeeds: > May 19 11:23:33 garnetd600 kernel: usb-storage: Command READ_BUFFER (10 > bytes) > May 19 11:23:33 garnetd600 kernel: usb-storage: 3c 00 00 00 00 00 00 00 > 04 00 > May 19 11:23:33 garnetd600 kernel: usb-storage: Bulk Command S > 0x43425355 T 0x1ed L 4 F 128 Trg 0 LUN 0 CL 10 ... > May 19 11:23:33 garnetd600 kernel: usb-storage: > usb_stor_bulk_transfer_sglist: xfer 4 bytes, 1 entries > May 19 11:23:33 garnetd600 kernel: usb-storage: Status code 0; > transferred 4/4 ... > May 19 11:23:33 garnetd600 kernel: usb-storage: Bulk status result = 0 > May 19 11:23:33 garnetd600 kernel: usb-storage: Bulk Status S 0x53425355 > T 0x1ed R 0 Stat 0x0 But then the following attempt to transfer 64512 bytes only manages to read 64510 bytes. Then the device violates the transport protocol: > May 19 11:23:33 garnetd600 kernel: usb-storage: Command READ_BUFFER (10 > bytes) > May 19 11:23:33 garnetd600 kernel: usb-storage: 3c 00 00 00 00 00 00 fc > 00 00 > May 19 11:23:33 garnetd600 kernel: usb-storage: Bulk Command S > 0x43425355 T 0x1ee L 64512 F 128 Trg 0 LUN 0 CL 10 ... > May 19 11:23:33 garnetd600 kernel: usb-storage: > usb_stor_bulk_transfer_sglist: xfer 64512 bytes, 14 entries > May 19 11:23:33 garnetd600 kernel: usb-storage: Status code -121; > transferred 64510/64512 > May 19 11:23:33 garnetd600 kernel: usb-storage: -- short read transfer > May 19 11:23:33 garnetd600 kernel: usb-storage: Bulk data transfer > result 0x1 > May 19 11:23:33 garnetd600 kernel: usb-storage: Attempting to get CSW... > May 19 11:23:33 garnetd600 kernel: usb-storage: > usb_stor_bulk_transfer_buf: xfer 13 bytes > May 19 11:23:33 garnetd600 kernel: usb-storage: Status code -75; > transferred 0/13 > May 19 11:23:33 garnetd600 kernel: usb-storage: -- babble > May 19 11:23:33 garnetd600 kernel: usb-storage: Bulk status result = 3 > May 19 11:23:33 garnetd600 kernel: usb-storage: -- transport indicates > error, resetting Several attempts at resets and retries succeeded only in confusing the drive even more. Was this running at high speed? If it was, you might want to try running at full speed instead (rmmod ehci-hcd) just to see if it makes any difference. If you would like to do a more in-depth experiment, try this. Download the plscsi package from <http://members.aol.com/plscsi/linux/>. Build the plscsi program, and then issue this command line (as root): plscsi -v -x '3c 0 0 0 0 0 0 0 4 0' -i 4 -X time 5,0 /dev/sg0 The results from that should prove informative. Then just for kicks, do this: plscsi -v -x '3c 0 0 0 0 0 0 fb fe 0' -i 64510 -t /dev/null \ -X time 5,0 /dev/sg0 In each case you should replace "/dev/sg0" with the actual "/dev/sg*" device name for your drive. And it might be a good idea to capture the usb-storage debugging log while these tests are running. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
