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