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

[Thomas Schmitt]

Hi,

i am preparing a statement towards OpenBSD kernel programmers.

Do we have a log where cdrecord fails to blank on BH14NS48 with AHCI ?
I believe that the following run should demonstrate the AHCI problem
with about any drive (not only with iHAS524):

  cdrecord -immed dev=/dev/rcd0c:2,0,0 blank=fast

If you do not have such a log (i obviously only have PCI-IDE with -immed)
then please try whether we can use this as part of the problem report.

-------------------------------------------------------------------
Problem report draft:
-------------------------------------------------------------------

SASANO Takayoshi is testing libburn operation of optical drives via
ioctl SCIOCCOMMAND. The largest part of the adapter code is already
in use with NetBSD.
  http://libburnia-project.org/browser/libburn/trunk/libburn/sg-netbsd.c
Only small adaptions were necessary to make it run #ifdef __OpenBSD__.

Nevertheless, there is a problem with SATA attached drives if AHCI is
used. It not only appears with libburn but also with program cdrecord
if the necessary conditions are met.
The problem does not appear if PCI-IDE is used.

The problem is that scsireq_t.sense does not contain plausible ASC, ASCQ
values when KEY 2 "NOT READY" is indicated by the drive.
E.g. when one of the tested drives (iHAS524) indicates that its write
buffer currently does not accept more data.
libburn's log tells that it sends (for CD SAO beginning at LBA -150):

  WRITE(10)
  2a 00 ff ff ff ea 00 00 10 00

and gets indicated by (scsireq_t.retsts == SCCMD_SENSE) that scsireq_t.sense
is valid with this content:

  +++ 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

For a burn program this means: Drive is not ready and no info is available
why. The program may then either end or wait for the condition to go away.
But if the program is willing to wait until TEST UNIT READY indicates
readiness, then it gets to see always the same sense data 2,0,0 until
the user runs out of patience.

With PCI-IDE (and on another operating system with AHCI) the reply is

  +++ sense data = 70 00 02 00 00 00 00 0A 00 00 00 00 04 08 00 00 00 00
  +++ key=2  asc=04h  ascq=08h

which according to MMC-5 means: Not ready, Long write in progress.
A burn program knows that it shall wait and then resend the same WRITE
command with the same LBA.
After some re-tries, writing goes on on PCI-IDE.

Another drive (BH14NS48) does not reply sense data during normal burning
or blanking runs, unless the Immed bit is used with commands like
START/STOP UNIT, SYNCHRONIZE CACHE, or BLANK.
cdrecord does not use this bit by default. So with AHCI on OpenBSD it
does burn and blank properly, unless unexpected things like media error
happen.
libburn 1.4.5 has been modified not to use Immed bit by default on
OpenBSD.
With cdrecord option -immed it is possible to cause the same failures
as happen with libburn when it uses the Immed bit.

In general this bit is beneficial because it lets commands end swiftly
and thus cannot clog a bus or driver as much as a command that runs
dozens of seconds or even minutes.

In the context of this problem report it can serve as easy way to
reproduce the problem with drives like the BH14NS48 which elsewise
work well in many cases.
E.g. with a CD-RW which contains some data:

  cdrecord -immed dev=/dev/rcd0c:2,0,0 blank=fast

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

Have a nice day :)

Thomas