From owner-freebsd-current Sun Oct 18 23:18:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA24136 for freebsd-current-outgoing; Sun, 18 Oct 1998 23:18:11 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA24127 for ; Sun, 18 Oct 1998 23:18:07 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id AAA21008; Mon, 19 Oct 1998 00:17:41 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810190617.AAA21008@panzer.plutotech.com> Subject: Re: 3.0-R, CAM, and audio tracks (more info) In-Reply-To: <19981018234428.A15396@binary.net> from Nathan Dorfman at "Oct 18, 98 11:44:28 pm" To: nathan@rtfm.net (Nathan Dorfman) Date: Mon, 19 Oct 1998 00:17:41 -0600 (MDT) Cc: freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nathan Dorfman wrote... > On Sun, Oct 18, 1998 at 11:17:04PM -0400, Nathan Dorfman wrote: > > At first I thought this was a bug in tosha, or its lack of support > > for my drive. It will read the TOC from an audio disc just fine, > > but upon trying to read the audio data itself: > > > > error returned from CD-DA read command: > > (pass1:ahc0:0:2:0): READ(10). CDB: 28 0 0 0 0 20 0 0 a 0 > > (pass1:ahc0:0:2:0): ILLEGAL REQUEST asc:64,0 > > (pass1:ahc0:0:2:0): Illegal mode for this track Your CDROM drive didn't like the command that tosha sent. > > tosha also seems to forget to reset the drive to a sane status > > because any subsequent CD audio attempts with cdcontrol(1) fail > > with cdcontrol: /dev/cd0c: Invalid argument. My guess is that the command that tosha did to set the density didn't get undone. It looks like there's a bug in the way error handling is done in the CAM version of tosha -- the density doesn't get set back to its original value before tosha exits if it exits abnormally. > > I tried this with > > both the tosha-0.5 port (most recent ports) and the > > tosha-0.05-cam.980916.tar.gz on ftp.kdm.org. Both fail the same > > way. Not surprising, since it's the same code in both places. > > This is a freshly installed 3.0-R system but the same > > behavior is seen on a 2 week old -current. Ditto. > > Anyway, what leads me > > to think that this is a CAM problem as opposed to a tosha bug is > > the following little quirk: I popped in the nearest data CD, which > > happened to be the 2.2.1 live FS, and ran tosha -v -- to my great > > am{az|us}ement it went right to work writing the pcm file. > > > > It was suggested to me that CAM might have a problem with passthrough > > for audio discs/tracks. Can anyone confirm/deny this? Anyone have > > any other ideas? > > After compiling the CAMDEBUG options into my kernel and running > camcontrol debug -Ic 0:2:0, I got the following: > > tosha attempting to read audio track and failing: > > (pass1:ahc0:0:2:0): INQUIRY. CDB: 12 0 0 0 40 0 > (pass1:ahc0:0:2:0): MODE SENSE(06). CDB: 1a 0 1 0 c 0 > (pass1:ahc0:0:2:0): MODE SELECT(06). CDB: 15 10 0 0 c 0 > (pass1:ahc0:0:2:0): READ TOC/PMA/ATIP {MMC Proposed}. CDB: 43 0 0 0 0 0 1 8 0 0 > > (pass1:ahc0:0:2:0): MODE SELECT(06). CDB: 15 10 0 0 c 0 > (pass1:ahc0:0:2:0): READ(10). CDB: 28 0 0 0 0 20 0 0 a 0 > > tosha attempting to read data track and succeeding: > > (pass1:ahc0:0:2:0): INQUIRY. CDB: 12 0 0 0 40 0 > (pass1:ahc0:0:2:0): MODE SENSE(06). CDB: 1a 0 1 0 c 0 > (pass1:ahc0:0:2:0): MODE SELECT(06). CDB: 15 10 0 0 c 0 > (pass1:ahc0:0:2:0): READ TOC/PMA/ATIP {MMC Proposed}. CDB: 43 0 0 0 0 0 1 8 0 0 > > (pass1:ahc0:0:2:0): MODE SELECT(06). CDB: 15 10 0 0 c 0 > (pass1:ahc0:0:2:0): READ(10). CDB: 28 0 0 0 0 0 0 0 a 0 > (pass1:ahc0:0:2:0): READ(10). CDB: 28 0 0 0 0 a 0 0 a 0 > (pass1:ahc0:0:2:0): READ(10). CDB: 28 0 0 0 0 14 0 0 a 0 > (pass1:ahc0:0:2:0): READ(10). CDB: 28 0 0 0 0 1e 0 0 a 0 > ...etc... > > Is CAM preventing tosha from reading audio data via passthrough? Yes. Justin and I were paid by the RIAA to make sure that FreeBSD users can't copy audio CDs. The FBI will contact you shortly to discuss whether or not your use of your CDs constitutes "fair use". It looks like your drive doesn't like it when you try to read audio tracks that way. You may want to talk to Oliver Fromme about it, and see if he's heard any other bug reports about Yamaha drives not working. IIRC, Daniel O'Conner had a similar problem with a Yamaha drive. I think he was able to get it to work with cdda2wav, but he ran into another problem with cdda2wav that looks like a vm problem related to shared memory. I'm not exactly sure what the problem is, but it's most likely related to tosha's interaction with your drive. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message