On Sat, 31 May 2003, Frederick Bruckman wrote:

: I wish I knew what that meant. Does the CD-ROM drive work under NetBSD
: generally; can you rip audio with cdparanoia, or burn with cdrdao? How
: about "mplayer cdda://" (with an audio CD)?

Of all the stuff below that's third party, it's a newly compiled package
from pkgsrc as of this morning (just to be sure 8-).

"/usr/bin/eject [-l|-L|-u]" works.
"cdrecord dev=/dev/rcd0d" works (also with -dummy).
"cdrecord dev=/dev/rcd0d -dao" works (also with -dummy).
"cdrdao write --driver=generic-mmc[-raw]" works (also with --simulate).
"cdrdao read-cd --driver=generic-mmc[-raw]" works.[*]
"[g]mplayer cdda://" works on an audio CD.
"cdparanoia" works, but not on [S]VCDs.[**]
"cdd" works (protocol 0), but not on [S]VCDs (not even with -noed).

Does cdparanoia or cdd work on [S]VCDs for you?  I can start to read the
first track (ISO9660 mode 2 form 1) of a [S]VCD with cdd, and then it craps
out at exactly 300 2k-sectors.

[*] This doesn't produce the kernel message, either.  Obviously cdrdao has a
    richer set of SCSI/ATAPI commands that it uses.

[**] This, I now discover, is the supplier of SCSI routines to [g]mplayer.

: This is what you normally get, by the way, any time you access the
: CDROM under NetBSD:
:
:     cd0(pciide0:1:0): illegal request, data = 00 00 00 00 21 00 00 00 00 00
:     cd0: dos partition I/O error

I get the following when cdrecord does its work, and a similar message for
cdrdao and "mplayer cdda://":

cd0(pciide0:1:0):  Check Condition on CDB: 0x28 00 00 00 00 00 00 00 01 00
    SENSE KEY:  Illegal Request
     ASC/ASCQ:  ASC 0x64 ASCQ 0x04

cd0: dos partition I/O error

which is the same thing with SCSIVERBOSE turned on.  (My original klog dump
from gmplayer should have included the dos partition message at the end;
perhaps I cut that off by accident.)

That message comes from scsipi_base.c:1.75.2.1:924, where the errno returned
to the caller is EINVAL (22, Invalid argument, the precise error cdd reports
when trying to read a [S]VCD raw track).

: Are you still getting the "ioctl dif1:" message with "rcd0d", as below
: (from your first post)...

No.  That's missing now, using rcd0d:

Playing VCD track 1
track 01:  adr=1  ctrl=4  format=2  00:02:00
track 02:  adr=1  ctrl=4  format=2  00:21:15
scsi command failed: status 3 error 0
scsi command failed: status 3 error 0
...

I've also just attached another drive (a DVD-ROM), and it works the same way
with all the programs listed above.  Its dmesg:

cd1 at atapibus0 drive 1: <RAITE RDR-108H DVDROM   V1.7, RDR-108H, VER 1.7> type 5 cdrom removable
cd1: 32-bit data port
cd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 2 (Ultra/33)
pciide0: secondary channel interrupting at irq 15
cd1(pciide0:1:1): using PIO mode 4, Ultra-DMA mode 2 (Ultra/33) (using DMA data transfers)

Given the cdd/cdparanoia behavior above, and the fact that the same behavior
exists on my DVD-ROM drive, I'm starting to wonder if there might be a
kernel-in-the-way problem going on, or that cdparanoia/libscsi is not nearly
as robust as it should be wrt errors.

Both these drives have been used successfully (for some time) with M$
operating systems, reading and writing all kinds of data.  I've used
cdrecord and cdrdao for Cygwin on them without troubles.

-- 
-- Todd Vierling <tv@pobox.com>