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

[Thomas Schmitt]

Hi,

it seems that Sense Data from the iHAS524-B get mangled with AHCI but not
with PCI-IDE.
Do i get it right that these are two driver approaches to the drive
while it is attached to the same SATA port ?
Are these hardware/firmware settings of the SATA port ?

I riddle how you switch between them in Linux. Me plugs in SATA drive
and boots. Then it works as /dev/srN. Actually me mostly plugs in USB
and hardly ever re-boots. :))

What caused the sudden end of pciide-cdrw-2.log ?
Did you wait due time and then abort manually ?
Did it abort on its own ?
The SCSI commands and replies look ok until the end.

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

Looking at openbsd/pciide-cdrw-2.log kills my theory about OpenBSD
generally mangling Sense Data.

There are lots of NOT READY replies with plausible ASC, ASCQ
when the drive is busy with writing Lead-in or when buffer is full:

  WRITE(10)
  2a 00 00 00 02 40 00 00 10 00
  +++ 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
      29358 us     [ 47950071 ]

which cause libburn to repeat the WRITE command until success is replied

  WRITE(10)
  2a 00 00 00 02 40 00 00 10 00 
      22759 us     [ 47972863 ]

The other drive did not issue NOT READY replies during write. Probably it
silently delays reply until the buffer has room for the next 32 or 64 KB.

Writing goes on (like it does in Linux too) until this command shall mark
the end of writing:

  SYNCHRONIZE CACHE
  35 00 00 00 00 00 00 00 00 00 

Linux is done after 42 seconds.
The OpenBSD pciide-cdrw-2.log ends suddenly after 7 seconds of waiting for
the reply to SYNCHRONIZE CACHE. I'd expect the reply would have come after
40+ seconds.

cdrecord in pciide-cdrecord-vv-2.log got the reply after 41.654 seconds

  Executing 'flush cache' command on Bus 2 Target 0, Lun 0 timeout 200s
  CDB:  35 00 00 00 00 00 00 00 00 00
  cmd finished after 41.654s timeout 200s

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

openbsd/ahci-cdrw-2.log on the other hand shows no expected NOT READY
replies but rather the mad NOT READY + ALL IS WELL one:

  WRITE(10)
  2a 00 ff ff ff ea 00 00 10 00 
  +++ 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
      28837 us     [ 2275409 ]

The negative block address 0xffffffea is normal for the start of a SAO
run.
With the run in openbsd/pciide-cdrw-2.log the reply was a digestible
NOT READY + LONG WRITE IN PROGRESS reply:

  WRITE(10)
  2a 00 ff ff ff ea 00 00 10 00
  +++ 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
      29383 us     [ 2267218 ]

So in ahci-cdrw-2.log we do see OpenBSD or the bus hardware interfering
with the reply by the drive which quite surely is the same in both cases.


cdrecord's failure in ahci-cdrecord-vv-2.log is at address 0xffffffe2
(because it writes 60 KB per WRITE whereas libburn writes 32):

  Executing 'write_g1' command on Bus 1 Target 4, Lun 0 timeout 200s
  CDB:  2A 00 FF FF FF E2 00 00 1E 00
  ...
  cdrecord: Input/output error. write_g1: scsi sendcmd: retryable error
  
It then aborted writing the Lead-in and began to write the payload at
block 0 which failed with the same symptoms:

  Executing 'write_g1' command on Bus 1 Target 4, Lun 0 timeout 200s
  CDB:  2A 00 00 00 00 00 00 00 1E 00
  ...
  cdrecord: Input/output error. write_g1: scsi sendcmd: retryable error
  ...
  CDB:  2A 00 00 00 00 00 00 00 1E 00
  ...
  write track data: error after 0 bytes
  cdrecord: A write error occured.

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

So if the xorriso run on PCI-IDE had completed, then id' say that AHCI
is the one which mangles SCSI Sense Data comming from the drive.
For some reason these mangled data persist in the transaction data
returned by the kernel even when the drive is supposed not to issue them
any more.

It stays a riddle, though, why with the other drive BH14NS48 we did
not see digestible NOT READY Sense Data on PCI-IDE. In the tests with that
drive we carefully had to avoid any NOT READY situation.

My best guess is that the drives behave differently at bus level and
that the BH14NS48 triggers the same bus-or-system problem on PCI-IDE
as both trigger on AHCI.

Well, the sudden end of pciide-cdrw-2.log puts this theory in question.


Have a nice day :)

Thomas