Re: [Libcdio-devel] CD_MSF_FORMAT vs LBA on NetBSD

[Thomas Schmitt]

Hi,

Edd Barrett wrote:
> ++ WARN: ioctl CDIOREADMSADDR failed: Invalid argument

You should try to find out what get_last_session_netbsd() submits to
that ioctl. Regrettably i found not much of documentation for
CDIOREADMSADDR.
  https://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/sys/cdio.h
has:

  /* read LBA start of a given session; 0=last, others not yet supported */
  #define CDIOREADMSADDR _IOWR('c', 6, int)

It is obviously about multi-session data CDs, for which the convention is
to mount the superblock (Primary Volume Descriptor) of the first track in
the last session. In FreeBSD it can be overridden by mount(8) option -s.
With a Linux kernel its option -o "sbsector=".

But finding out where and how "_IOWR('c', 6, int)" is implemented goes
beyond my systek peeking capabilities.


> 405: Option not supported by drive

That's the missing implementation of .set_speed().


> cd0(umass0:0:0:0):  Check Condition on CDB: 0x28 00 00 00 00 00 00 00 01 00
>     SENSE KEY:  Illegal Request
>                 Incorrect Length Indicator Set
>      ASC/ASCQ:  Illegal Mode For This Track

The kernel (possibly ioctl SCIOCCOMMAND) complains about SCSI command 0x28
READ(10), which is for data sectors. Since your CD is CD-DA, this command
is supposed to fail with this KEY, ASC , ASCQ:
  5 64 00 ILLEGAL MODE FOR THIS TRACK

Only the message text "Incorrect Length Indicator Set" is unexpected to me.
One would have to search in the kernel code for its trigger.
(I found in read_audio_sectors_netbsd() a wrong
         req.cmdlen = 10;
 which should be 12. But there is no READ(10) command to see in netbsd.c.)


> cd0d: error reading fsbn 0 of 0-3 (cd0 bn 0; cn 0 tn 0 sn 0)

One would have to find out in the kernel code what this shall mean.


> cd0(umass0:0:0:0):  Check Condition on CDB: 0x35 00 00 00 00 00 00 00 00 00
>     SENSE KEY:  Media Error
>      ASC/ASCQ:  Medium Format Corrupted

Command 0x35 is SYNCHRONIZE CACHE. This is used to indicate to the drive
that a burn run is done. So this should not be emitted by libcdio, i guess.
Did you burn CDs on that machine ?


> So in summary, there are still some BSD issues,

At least the bug about the potentially wrong track number interpretation
in get_track_msf_netbsd() and get_track_format_netbsd() should be tackled.
See my message
  http://lists.gnu.org/archive/html/libcdio-devel/2018-10/msg00025.html


Have a nice day :)

Thomas