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

[Thomas Schmitt]

Hi,

> Here is a log I tested xorriso-1.4.5 with -scsi_log on.
> [...]
> +++ sense data = 70 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> +++ key=2  asc=00h  ascq=00h

In both cases it seems that the ASC,ASCQ info of expectable DRIVE NOT READY
states does not get to libburn or that drive or bus went mad.

Both commands are issued with Immed bit. A TEST UNIT READY loop is
supposed to wait until they are done.
The BLANK loop cycles endlessly whereas the SYNCHRONIZE CACHE loop ends
on the first unexpected error indication. The commands after SYNCHRONIZE
CACHE get further DRIVE NOT READY, if they inquire any media properties. 


> Blank process is not succeeded. 1.0% done about 4000 seconds passed,

Did the drive stop blinking at some time ?
Did it start blinking at all ? (Was the disc blank afterwards ?)


> and pressing Ctrl-C could not stop.

Did you see a message from the signal handler ?
Like
  xorriso : ABORT : Trying to shut down drive and library

We will have to examine this when the other issues are solved.


Well, currently the log points to the Immed bit of commands BLANK
and SYNCRONIZE CACHE. Both are long running commands which can even
cause problems with timeout in some kernels. So i prefer to have them
ending quickly and to actively wait for the drive to become ready again.

Only the Immed bit (bit 0 of byte 1) in this command caused no direct
problems:

  START/STOP UNIT
  1b 01 00 00 01 00
        511 us     [ 4386674 ]

The potentially long running operation of tray loading is done without
Immed bit, though:

  START/STOP UNIT
  1b 00 00 00 03 00
       1024 us     [ 3878909 ]


> Cdrecord-ProDVD-ProBD-Clone 3.00 (from ports collection) works good.

cdrecord has an option -immed, of which the description looks like what
libburn does.


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

It would be worth to test with disabled libburn Immed and with cdrecord
option -immed. The Immed bits of libburn are hardcoded, i fear.

The Immed bit of command BLANK is set in libburn/mmc.c, mmc_erase() :

        c->opcode[1] = 16;      /* IMMED set to 1 */

Set to 0 instead of 16.

With command SYNCHRONIZE CACHE it is in mmc_sync_cache():

        c->opcode[1] |= 2; /* ts A70918 : Immed */

Again, set to 0 or outcomment.

There is also mmc_close(), which would be called after successful sync:

        c->opcode[1] |= 1; /* ts A70918 : Immed */

(The timestamps A70918 indicate that i changed original libburn habits
 in september 2007. It lasted quite some time until the backlash.)


Vice versa to learn whether -immed spoils a cdrecord blanking run:

  cdrecord -v -V -immed dev=/dev/rcd0c blank=fast 2>&1 | tee -i cdrecord.log

Option -V should produce a log of SCSI commands and Sense replies.

With a write run, -immed would introduce another modification of behavior,
which in xorriso is called "modesty_on_drive". It keeps the drive buffer
hungry to cause quick replies to WRITE commands.
Normally it should not spoil a burn run ...


---------------------------------------------------------------------------
Just for completeness: There are more Immed bits in libburn.

The one in mmc_format_unit() will not be triggered by CD operation:
        c->page->data[1] = 0x02;                  /* Immed */

The one in libburn/sbc.c, sbc_start_unit_flag():

        c->opcode[1] |= (flag & 1); /* ts A70918 : Immed */

caused no direct problems in your test.

In sbc_load() i see an interesting remark
        /* ts A70921 : Had to revoke Immed because of LG GSA-4082B */
        /* c->opcode[1] |= 1; / * ts A70918 : Immed */

That was just three days after i immedizied the long running commands.

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


Have a nice day :)

Thomas