Re: [Bug-xorriso] building libisofs-1.4.4, libburn-1.4.4, libisoburn-1.4.4 on OpenBSD

[Thomas Schmitt]

Hi,

> Here is the log of cdrecord -VV.

The DAO burn run dies at about the same point as did the one of xorriso:

> CDB:  2A 00 00 00 00 10 00 00 10 00
> ...
> cdrecord: Input/output error. write_g1: scsi sendcmd: retryable error

Again the second WRITE command yielded an error. cdrecord does not show
the Sense reply, but the text "retryable error" indicates that it was
a NOT READY key.
(Rolling eyes to heaven: What does one have to do in order to see the
 cdrecord Sense replies ?)

cdrecord retries the WRITE command at the same address two times until
it gives up and reports:

> write track data: error after 32768 bytes
> cdrecord: A write error occured.

The message "... retryable error" shows up after each of the following
SCSI commands.
This matches my impression that the reply 2,0,0 persists much longer than
the NOT READY state of the drive.


> > - Try whether -as cdrecord option -tao brings better results
> >    xorriso -scsi_log on -as cdrecord -v -tao dev=/dev/rcd0c 
> > /home/uaa/install
> > [...]
> > - Try whether xorriso writes on formatted DVD-RW
> >    xorriso -outdev /dev/rcd0c -format as_needed
> >    xorriso -scsi_log on -as cdrecord -v dev=/dev/rcd0c /home/uaa/install

> They seems to be working. The log is very large.

The "-tao" run on sequential DVD-RW does not use command RESERVE TRACK,
which i suspect to be the reason for a temporary NOT READY state of the
drive.
The subsequent WRITE commands get no NOT READY reply. Their execution
time indicates about 2x DVD write speed (~ 2.7 MB/s).

The write run on the formatted DVD-RW does not issue RESERVE TRACK either.
Burn speed again was about 2x DVD.


The whole SCSI log of the successful xorriso runs does not show a single
Sense data reply.
So it cannot be outruled that the whole Sensa data forwarding mechanism
of OpenBSD is flawed.

-------------------------------------------------------------------------

In summary it seems that one currently has to avoid any drive operation
which would it make respond NOT READY to subsequent SCSI commands.

Not only the Immed Bit with commands like BLANK, FORMAT, CLOSE SESSION
but also the effects of command RESERVE TRACK seem to cause a NOT READY
state.
This all is in the normal range of drive behavior. Not normal is Sense
code 2,0,0 and the impression that this reply persists longer than the
drive stays in NOT READY state.


We need to find out what component is to blame:

Do you see a chance to test the drive on a system with Linux kernel ?
(A successful run of xorriso blanking run on CD-RW, or a successful
 cdrecord burn run on a fast blanked DVD-RW would prove that the drive
 is ok.)

Do you have a possibility to try a different drive with OpenBSD ?

If Linux works ok and the drive cannot be blamed:
Do you know an expert for the OpenBSD SCSI passthrough mechanism who could
investigate why libburn gets to see Sense code 2,0,0 and why this info
seems to emitted over and over again ?


Have a nice day :)

Thomas