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

[Thomas Schmitt]

Hi,

SASANO Takayoshi wrote:
> Please change to "I" because I am not SCSI expert.

I rather meant whether you want to submit the report yourself.
In any case we will both have to appear. You as witness, me as expert.

> address@hidden is suitable.

It seems that they only discuss proposed code changes.
address@hidden seems to be for user problems. Ours is very deep in
the kernel, but nevertheless still a user problem.


So how about this ?
Please agree or make corrections.

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

To:      address@hidden
Cc:      address@hidden,address@hidden
Subject: CD drive, SCIOCCOMMAND, scsireq_t.sense, AHCI versus PCI-IDE

What in the OpenBSD kernel might mangle scsireq_t.sense before it
is made available during an ioctl(SCIOCCOMMAND) that acts on an AHCI
connected CD drive ?

SASANO Takayoshi as user of OpenBSD and me as upstream of libburn are
testing libburn operation of optical drives via that ioctl.
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.
It nearly (*) always appears when provoked on AHCI.

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 and kills it from outside.

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 until successful end.

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.
With cdrecord option -immed it is possible to cause the same failures
as happen with libburn when it uses the Immed bit.

libburn 1.4.5 has for now been modified not to use Immed bit by default
on OpenBSD.
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 a 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

(*)
I have to write "nearly always when provoked" because the cdrecord -immed
blanking run succeeded on iHAS524, when SASANO Takayoshi tried to provoke
it after BH14NS48 nicely got stuck with the same cdrecord options.

It is a riddle to me why iHAS524 worked on that occasion. I could not get
cdrecord to showing the sense data of TEST UNIT READY. But after some due
time such a command reported no sense data and cdrecord went on.
With BH14NS48 the TEST UNIT READY commands yielded sense data until finally
cdrecord was killed from outside.

-------------------------------------------------------------------
End of problem report draft.
-------------------------------------------------------------------

Have a nice day :)

Thomas