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?
cdrecord dev=1,0,0 -atip Cdrecord 2.00.3 (i686-pc-linux-gnu) Copyright (C) 1995-2002 J�rg Schilling scsidev: '1,0,0' scsibus: 1 target: 0 lun: 0 Linux sg driver version: 3.1.25 Using libscg version 'schily-0.7' Device type : Removable CD-ROM Version : 2 Response Format: 1 Vendor_info : 'CD-R/RW ' Identifikation : 'CW088D CD-R/RW ' Revision : '11SF' Device seems to be: Generic mmc CD-RW. Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : MMC-2 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R ATIP info from disk: Indicated writing power: 5 Is not unrestricted Is not erasable Disk sub type: Medium Type A, high Beta category (A+) (3) ATIP start of lead in: -11634 (97:26/66) ATIP start of lead out: 359846 (79:59/71) Disk type: Short strategy type (Phthalocyanine or similar) Manuf. index: 3 Manufacturer: CMC Magnetics Corporation
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.
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
-------- Original Message -------- Subject: Re: [usb-storage] kernel 2.4.29: cdrecord 2.00.3 works, 2.01 breaks. Date: Tue, 03 May 2005 18:05:00 +0100 From: Hin-Tak Leung <[EMAIL PROTECTED]> To: Alan Stern <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] References: <[EMAIL PROTECTED]>
Alan Stern wrote: <snipped>
The problem occurred with the second READ BUFFER command, the one asking
to transfer 64512 bytes. The drive returned an error code and then died. It's not clear why, although most likely it's a bug in the firmware of the
drive.
Thanks! I did think the READ_BUFFER was new, but it was a fair bit down. The unsupported command message is in usb/storage/transport.c, around line 309, on vanilla kernel 2.4.29. The whole sequence has changed a fair bit between cdrecord 2.00.3 and 2.01.
So what I can do? I don't think a firmware update is an option (it is cyberdrive inside a freecom IDE->USB bridge box, which means neither of them support firmware updates, as far as I know). I suppose I could tell the Schilling guy... :-(.
Regards, Hin-Tak
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
