what in the OpenBSD kernel might mangle scsireq_t.sense before it
is made available to a caller of 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.
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):
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
With cdrecord option -immed it is possible to cause the same failures
as happen with libburn when it uses the Immed bit.
Freshly released libburn 1.4.6 by default does not to use the Immed bit
when it runs on OpenBSD. So it is supposed to work as good or bad as
But in in general the Immed 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
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
With BH14NS48 the TEST UNIT READY commands yielded sense data until
finally cdrecord was killed from outside.
Have a nice day :)