Hi, Edd Barrett wrote: > I'm super-happy that someone can help with this! As you can > tell, I'm no expert.
I have few knowledge about NetBSD and cdparanoia's internals. But as developer of libburn, i am hopefully able to recognize problems with SCSI/MMC command parameters if i get to see them. The messages reported by Greg look much like a mess-up with parameters of SCSI commands or of the functions which compose the SCSI commands. Sector 169348352 and track 255 are obvious nonsense on CD. Please give me the URL of your cdparanoia branch. Google finds me only https://github.com/rocky/libcdio-paranoia/branches ------------------------------------------------------------------------- The messages about SCIOCCOMMAND probably stem from libcdio's lib/driver/netbsd.c function read_audio_sectors_netbsd(). It composes a SCSI command 0xbe from parameters "lsn" and "nblocks". In case of error indication from the drive (or synthetic sense data from the kernel): if (req.retsts != SCCMD_OK) { fprintf(stderr, "SCIOCCOMMAND cmd 0xbe sts %d\n", req.retsts); return 1; } libcdio could print some extra info before "return 1": lsn, nblocks, req.cmd[0...11] (byte-wise as hex), req.sense[0...13] (byte-wise as hex) A run by Greg would then tell more about the failed command. -------------------------------------------------------------------------- I wonder why libcdio sets in read_audio_sectors_netbsd() req.cmdlen = 10; It should be 12 for command BEh. That's documented already in MMC-1. libcdio function mmc_get_cmd_len() in lib/driver/mmc/mmc.c computes from command code 0xBE the length scsi_cdblen[5] == 12. Regrettably i do not know NetBSD enough to tell whether this short command length causes a problem in communications of kernel and drive. It is well possible that the kernel knows how long READ CD is supposed to be and uses length 12. -------------------------------------------------------------------------- Have a nice day :) Thomas
