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

[Thomas Schmitt]

Hi,

SASANO Takayoshi wrote:
> UEFI setup switches operation mode.

The UEFI of my workstation i see once per year.
My test machine is BIOS-only (but might be smart enough to switch).


> The drive's firmware is updated with the current version.

Currently the drives pose only the riddle why BH14NS48 did not yield
the ASC,ASCQ info whereas iHAS524 did when used with PCI-IDE.
This riddle would be solved if the BH14NS48 was only tested with AHCI.

Then there stays the riddle why the log of xorriso on PCI-IDE ends
after 7 seconds of SYNCHRONIZE CACHE (which should last 42 seconds and
be followed by more SCSI transactions).

If BH14NS48 was only tested on AHCI and if the burn run of xorriso
on iHAS524 PCI-IDE was aborted by mistake, then the theory holds,
that AHCI is bad and PCI-IDE is good.

We need to explore this theory.


> I wonder if Linux ignores above setting, always work as AHCI mode.

If i only knew how to inquire the SATA mode of my two built-in drives
without rebooting. The log messages do not reach back to last reboot.

I can do

  # lspci -vv
  ...
  00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset
  Family 6-port SATA Controller 1 [AHCI mode] (rev 05) (prog-if 01 [AHCI 1.0])
  ...
          Kernel driver in use: ahci

but this tells nothing about single ports and drives.


> The log is enabled wdc driver's message, but it makes hard to read
> xorriso's SCSI log.
> [...]
> I tried these commands, but both hanged up with "wdc_atapi_intr:
> warning: reading only 1 of 2 bytes" message.
> 
>   xorriso -scsi_log on -outdev /dev/rcd0c -blank deformat
>   xorriso -scsi_log on -outdev /dev/rcd0c -format as_needed

The GET CONFIGURATION transactions name 0x000a as Current Profile.
That's CD-RW.

Both xorriso runs are not really applicable to CD-RW media by xorriso.
CD-RW can be formatted, but libburn does not do, because the performance
aftwerwards is awful and capacity shrinks to less than 600 MB.
xorriso should have finally reported:
  xorriso : NOTE : -format as_needed: no need for action detected

On Linux the xorriso command -blank deformat triggers a normal run of
full blanking the CD-RW. If yours was already blank, then xorriso should
have ended gracefully by reporting
  xorriso : NOTE : Blank medium detected. Will leave it untouched


Whatever, it seems that the wdc message mode is not helpful.
At least it makes the log nearly unreadable and the xorriso runs
abort prematurely or get their message output truncated.

The warning in deformat.log appears after an INQUIRY command, which is
supposed to be absolutely harmless. The drive seems to have answered
to the command. Sense Data are not supposed to have been issued. 

The warning in asneed.log appears during half performed transaction
READ TOC/PMA/ATIP. The answer to the command is missing.
Nevertheless the preview transaction succeeded which inquired the
number of available reply bytes of READ TOC/PMA/ATIP.
So it is totally unexpected that the same SCSI command fails when
repeated just with a different number of requested bytes.


> do I have to modify kernel to show ASC/ASCQ response from deivce?

I have no idea about OpenBSD's kernel. The SCSI commands at the end
of both logs are not supposed to have caused Sense Data.

Actually none of the commands which i can spot in the logs should
have caused Sense Data. You may provoke such a situation by running

  xorriso -scsi_log on -outdev /dev/rcd0c

while the drive tray is open.

xorriso should then experience NOT READY replies from the drive while
the medium is automatically inspected by the drive.

This command loads the tray:

  START/STOP UNIT
  1b 00 00 00 03 00 
    1244075 us     [ 3102819 ]

Several TEST UNIT READY commands are then issued to learn when it is done:

  TEST UNIT READY
  00 00 00 00 00 00 
  +++ sense data = 71 00 02 00 00 00 00 0A 00 00 00 00 04 01 00 00 00 00
  +++ key=2  asc=04h  ascq=01h
      21214 us     [ 3632894 ]

  ...

  TEST UNIT READY
  00 00 00 00 00 00 
        517 us     [ 11424607 ]

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

We should for now concentrate on verifying whether IDE-PCI is ok for both
drives.

Any failure with IDE-PCI must be analyzed whether it was caused by
misleading Sense Data replies or by other causes.

For example pciide-cdrw-2.log from August 13 does not look like
problems with Sense Data but rather like an externally caused abort.
This run should be re-tried and if it aborts again, then the following
should be examined:
- Is the medium fully readable afterwards ?
  (I.e. did the drive go on with finishing it ?)
- Does the second abort happen again a few seconds after the SCSI
  command SYNCHRONIZE CACHE ?


Have a nice day :)

Thomas