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

[Thomas Schmitt]

Hi,

> 20160909/ahci-bh14ns48.log:
> ^Ccdrecord: Caught interrupt.

Do i get it right that you waited a due time before you killed cdrecord ?

In this case we can use cdrecord as demo program and prove that
the problem is not because of libburn and its NetBSD/OpenBSD adapter.


> I tried with iHASB524, but there is no probmlem.
> 20160909/ahci-ihas524.log:
> Executing 'blank unit' command on Bus 1 Target 4, Lun 0 timeout 9600s
> ...
> Executing 'test unit ready' command on Bus 1 Target 4, Lun 0 timeout 40s
> CDB:  00 00 00 00 00 00
> cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error
> ...
> Executing 'test unit ready' command on Bus 1 Target 4, Lun 0 timeout 40s
> CDB:  00 00 00 00 00 00
> cmd finished after 0.000s timeout 40s

This is indeed a blow to my theory. It should have gone stuck.
So the complete trigger for KEY,ASC,ASCQ = (2,0,0) is not found yet.
AHCI helps much to achieve failure, but is not really reliable.

We had a failure with iHAS524 during writing on AHCI, when it tried
to tell (2,4,8) "Not ready, Long write in progress".


> 20160909/dmesg-bh14ns48.log:
> ahci0: port 4: 1.5Gb/s
> cd0 at scsibus1 targ 4 lun 0: <HL-DT-ST, BD-RE BH14NS48, 1.02> ATAPI 5/cdrom 
> removable

> 20160909/dmesg-ihas524.log:
> ahci0: port 4: 1.5Gb/s
> cd0 at scsibus1 targ 4 lun 0: <ATAPI, iHAS524 B, AL2A> ATAPI 5/cdrom removable

Looks quite equal. Slow speed is good. But how come ?
(My test machine has eSATA which works with an external drive only if
 curbed from 3.0 Gb/s to 1.5 Gb/s. Linux slows down after the first
 glitches spoiled a burn run. FreeBSD 8 stays at high speed until
 it crashes during a burn run, unless i switch to 1.5 Gb/s manually.)


Whatever, i don't think we will learn more from self-invented experiments.
It is about time we look for OpenBSD SCSI kernel code experts.

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

If you like you may change "SASANO Takayoshi" to "I" and report yourself
while pointing to me as source of theory and SCSI/MMC knowledge.

Where shall we post this request for help ?
As problem report ?
On address@hidden ?


Have a nice day :)

Thomas