Re: cdrecord 2.01 do READ_BUFFER and crashes drive.
Hin-Tak Leung <hintak_leung@yahoo.co.uk> wrote:
> Had a bit of conversation over at usb-storage mailing list below.
> cdrecord 2.00.3 works fine with USB freecom drive, but cdrecord 2.01
> crashes the firmware. Looks like there are two new READ_BUFFER
> scsi commands in 2.01, and the drive doesn't like the 2nd one
> with a large transfer length (0xfc00). Obviously this is a firmware
> bug, but since it is a USB enclosure to an ATAPI drive, neither would
> provide new firmware, so I wonder if there is any possibility of using
> cdrecord 2.01 but not having the offending scsi READ_BUFFER command
> at initialisation?
Are you sure that this is a firmware bug?
This may also be a bug in the kernel usb driver.
Cdrecord first asks for the size of the buffer in the drive and then
uses a number that is not bigger than the size accepted by the OS.
> May 3 02:15:05 localhost kernel: usb-storage: Command READ_BUFFER (10 bytes)
> May 3 02:15:05 localhost kernel: usb-storage: 3c 00 00 00 00 00 00 00 04 00 00 00
> May 3 02:15:05 localhost kernel: usb-storage: Bulk command S 0x43425355 T 0xd9
> Trg 0 LUN 0 L 4 F 128 CL 10
> May 3 02:15:05 localhost kernel: usb-storage: Bulk command transfer result=0
> May 3 02:15:05 localhost kernel: usb-storage: usb_stor_transfer_partial(): xfer
> 4 bytes
> May 3 02:15:05 localhost kernel: usb-storage: usb_stor_bulk_msg() returned 0
> xferred 4/4
> May 3 02:15:05 localhost kernel: usb-storage: usb_stor_transfer_partial():
> transfer complete
> May 3 02:15:05 localhost kernel: usb-storage: Bulk data transfer result 0x0
>
> May 3 02:15:05 localhost kernel: usb-storage: Attempting to get CSW...
> May 3 02:15:05 localhost kernel: usb-storage: Bulk status result = 0
> May 3 02:15:05 localhost kernel: usb-storage: Bulk status Sig 0x53425355 T 0xd9
> R 0 Stat 0x0
> May 3 02:15:05 localhost kernel: usb-storage: scsi cmd done, result=0x0
> May 3 02:15:05 localhost kernel: usb-storage: *** thread sleeping.
> May 3 02:15:05 localhost kernel: usb-storage: queuecommand() called
> May 3 02:15:05 localhost kernel: usb-storage: *** thread awakened.
The kernel here behaves different than above....
> May 3 02:15:05 localhost kernel: usb-storage: Command READ_BUFFER (10 bytes)
> May 3 02:15:05 localhost kernel: usb-storage: 3c 00 00 00 00 00 00 fc 00 00 b4 cc
> May 3 02:15:05 localhost kernel: usb-storage: Bulk command S 0x43425355 T 0xda
> Trg 0 LUN 0 L 64512 F 128 CL 10
> May 3 02:15:05 localhost kernel: usb-storage: Bulk command transfer result=0
> May 3 02:15:05 localhost kernel: usb-storage: usb_stor_transfer_partial(): xfer
> 32768 bytes
> May 3 02:15:05 localhost kernel: usb-storage: usb_stor_bulk_msg() returned 0
> xferred 0/32768
> May 3 02:15:05 localhost kernel: usb-storage: Bulk data transfer result 0x1
> May 3 02:15:05 localhost kernel: usb-storage: Attempting to get CSW...
> May 3 02:15:05 localhost kernel: usb-storage: clearing endpoint halt for pipe
> 0xc0012f80
> May 3 02:15:05 localhost kernel: usb-storage: usb_stor_clear_halt: result=0
> May 3 02:15:05 localhost kernel: usb-storage: Attempting to get CSW (2nd try)...
> May 3 02:15:05 localhost kernel: usb-storage: Bulk status result = 0
> May 3 02:15:05 localhost kernel: usb-storage: Bulk status Sig 0x53425355 T 0xda
> R 64512 Stat 0x2
> May 3 02:15:05 localhost kernel: usb-storage: -- transport indicates error,
> resetting
> May 3 02:15:05 localhost kernel: usb-storage: Bulk reset requested
> May 3 02:15:09 localhost kernel: usb-storage: Bulk soft reset failed -110
> May 3 02:15:09 localhost kernel: usb-storage: scsi cmd done, result=0x70000
> May 3 02:15:09 localhost kernel: usb-storage: *** thread sleeping.
> May 3 02:15:09 localhost kernel: usb-storage: queuecommand() called
BTW: if the kernel would return a _correct_ error indication to cdrecord,
cdrecord would stop to repeat this command....
My advise to you is to try Solaris 10.
It is free and it seems that USB on Solaris 10 is better than the implementation
on Linux. If you get similar problems with the same hardware, it makes sense
to discuss the problem to approach a workaround
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Reply to: