Re: cdrecord and "get performance" scsi errors

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

> I confirm it can now write to the USB LG E10L.

:))


> Also, it correctly writes DVD-RWs on the USB LG 2166D where cdrecord
> fails (cdrecord is ok for DVD+RW on that).

I guess that is the command
>  # /tmp/cdrecord dev=$cddev -v -data blank=fast
you reported Thu, 17 May 2007.

> /tmp/cdrecord: Input/output error. read disk info: scsi sendcmd: no error
> CDB:  51 00 00 00 00 00 00 00 2C 00

This READ DISC INFO command limits the reply to up to
44 bytes. I assume that sg_io_hdr_t.dxfer_len for the
SG_IO driver is set to the same value.
The command requests Data Type 000b, which has a reply
length of >= 34 bytes, depending on the number of OPC
table entries. 
(See MMC-5, 6.22.3.1 Data Type 000b: Standard Disc Information)

So probably libburn's new approach to request only 34
bytes does the trick here. (If libburn would be interested
in the OPC entries then it would have to interpret 
Disc Information Length from the first reply and then
call again. But all it wants to know for now is within
the standardly promised first 34 bytes of reply.)

One has to note that this remedy will fail if some
drive decides to deliver less than 34 bytes. The
obvious demand of kernel 2.4 USB drivers to see
sg_io_hdr_t.dxfer_len reply bytes is cumbersome.

I still have to explore wether the dramatic difference
between cdrecord and libburn-0.3.6 comes from the
oversized i/o buffer in libburn-0.3.6.
I first repaired the stalling by the new reply size
restrictions for MMC commands. Only later i reduced
buffer size to enable record sizes != 2048.
Maybe libburn-0.3.6 would receive only harmless
protests from the drivers if it used 32 kiB buffer.


Have a nice day :)

Thomas