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

[Thomas Schmitt]

Hi,

SASANO Takayoshi wrote:
> http://www.uaa.org.uk/temp/xorriso/pciide-xorriso-cdrw.log.gz

Looks ok. But did not challenge the transport mechanism for Sense Data.

That's because xorriso has on OpenBSD -use_immed_bit off by default
and because the BH14NS48 does not have the habit of the iHAS524 to
send intermediate NOT READY replies during writing when its buffer is
running full.

Please try the same hardware setup with

  ./xorriso -use_immed_bit on ...other.program.arguments...

in order to provoke NOT READY replies. Then we will see whether they
bear plausible ASC, ASCQ when Key is 2.


> http://www.uaa.org.uk/temp/xorriso/pciide-cdrecord-vv-cdrw.log.gz

Looks ok too.
With cdrecord, you could provoke NOT READY replies by option -immed.
This is only of interest, if xorriso with -use_immed_bit "on" succeeds.

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

To re-summarize (mainly for myself because the time intervals of our
conversation are quite demanding for my old brain):

We look for the reason why the NOT READY replies of iHAS524 with PCI-IDE
came with plausible ASC,ASCQ.

The fact that NOT READY was issued despite -use_immed_bit off is drive
firmware dependent. But the fact that ASC,ASCQ of BH14NS48 and of iHAS524
on AHCI are 0,0 must be due to bus hardware or kernel drivers ...
or else this BH14NS48 would be individually damaged.
Healthy LG drives issue plausible ASC,ASCQ.

Did you already check BH14NS48 with Linux and xorriso ?
(Forgive me if i don't remember.)
Success would indicate that this BH14NS48 is ok.

If the BH14NS48 nevertheless yields unplausible ASC,ASCQ on PCI-IDE of
OpenBSD then the alteration of ASC,ASCQ would not only depend on SATA
mode (which it does with iHAS524) but also on other specifics of the
drive's hardware or firmware.
This would make it harder to point to a particular stage of OpenBSD kernel
processing as the probable culprit.


And we still look for the reason why the burn run of iHAS524 with PCI-IDE
aborted suddenly near its normal end, although it looked very promising
up to that moment.
If the failure is reproducible, then it is most probably not due to the
problem about unplausible ASC, ASQ replies with Key 2.
That would mean we have a second problem. (Please not. :))


Have a nice day :)

Thomas