cdrecord 2.01 do READ_BUFFER and crashes drive.
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 <hintak_leung@yahoo.co.uk>
To: Alan Stern <stern@rowland.harvard.edu>
CC: usb-storage@lists.one-eyed-alien.net
References: <Pine.LNX.4.44L0.0505031043200.5654-100000@iolanthe.rowland.org>
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
Reply to: