Date: Tue, 22 Feb 2000 21:40:03 -0800 (PST) From: "Kenneth D. Merry" <ken@kdm.org> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/16920: cdcontrol fails (and xmcd) Message-ID: <200002230540.VAA60262@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/16920; it has been noted by GNATS. From: "Kenneth D. Merry" <ken@kdm.org> To: Jon Dugan <jdugan@ncsa.uiuc.edu> Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: bin/16920: cdcontrol fails (and xmcd) Date: Tue, 22 Feb 2000 22:33:22 -0700 On Tue, Feb 22, 2000 at 23:15:20 -0600, Jon Dugan wrote: > On Tue, Feb 22, 2000 at 09:31:28PM -0700, Kenneth D. Merry wrote: > > Okay, I'll need some information to try to solve your problem: > > > > - has this drive ever worked correctly with cdcontrol or xmcd? > > Yes, it has, as recently as 3.4-STABLE. (not sure what date) Any idea whether it worked with that particular cd when you type 'cdcontrol play'? > > - what exactly did you type in cdcontrol? > > play, I did it again and got: > > (cd0:ahc0:0:6:0): PLAY AUDIO(12). CDB: a5 0 0 0 0 0 0 3 86 46 0 0 > (cd0:ahc0:0:6:0): ILLEGAL REQUEST asc:24,0 > (cd0:ahc0:0:6:0): Invalid field in CDB What happens when you do this is cdcontrol tries to play starting at block 0, for the entire length of the CD. What is wrong is the CDROM drive either doesn't like the starting address, or it doesn't like the number of blocks. What happens if you use another CD? > > - what does 'cdcontrol info' return? > > > > - does 'cdcontrol play 1' work? > > DOH! Yes, cdcontrol works that way... Is it a bug that it doesn't work the > other way? I feel pretty dumb right about now... It may be a bug, but it may just be a bug in your CDROM drive's firmware. It works on a Plextor CDROM and a Panasonic DVD-RAM drive I've got here. It might be interesting to see if we can figure out what is causing it to fail. Try something like this: cdcontrol play "#0" 230980 230980 == 0x38646 - 2 0x38646 is the length from the command above. The idea is that the TOC on the CD may be wrong somehow, and may be going past the end of the CD or something. If that doesn't work, just try something like this: cdcontrol play "#0" 2048 > > - does camcontrol work? e.g.: > > > > camcontrol devlist > > camcontrol tur cd0 -v > > camcontrol inquiry cd0 -v > > [ that will return bogus inquiry data, don't worry about it ] > > rivendell# camcontrol devlist > <QUANTUM ATLAS 10K 9WLS UCH0> at scbus0 target 0 lun 0 (pass0,da0) > <IOMEGA ZIP 100 J.03> at scbus0 target 5 lun 0 (pass1,da1) > <MATSHITA CD-R CW-7502 4.10> at scbus0 target 6 lun 0 (pass2,cd0) > rivendell# camcontrol tur cd0 -v > Unit is ready > rivendell# camcontrol inquiry cd0 -v > pass2: < > Fixed Direct Access SCSI-0 device > pass2: Serial Number > pass2: 10.000MB/s transfers (10.000MHz, offset 8) That looks fine. I fixed the camcontrol inquiry problem on Saturday, FWIW. > > - I also need the output from xmcd -debug > > I've attached it, but I don't think you'll need it, the comment from the > HEAD of xmcd Makefile says it all: > > Upgrade to latest release (xmcd-2.6). > > This still fails to build correctly on -current since the /usr/libexec/cpp > fiasco -- old versions of imake still use /usr/libexec/cpp instead of > gcc -E. If you don't have a fixed version of imake, a quick fix to get > around this is to set IMAKECPP=/usr/bin/cpp in your environment before > make'ing this port. > > Note that the port builds without errors if you don't have the correct > version of imake, but FREEBSD_CAM will not be defined and xmcd will use > the ioctl method which hasn't worked since 3.0. > > So it looks like I got an old port. Which makes sense since the commit time > for the above comment is Wed Feb 23 3:40:29 2000 UTC. > > When I build from the latest version of the port with IMAKECPP set as > instructed above xmcd builds and can interact with the cd but it doesn't > actually seem to work, it sorta fast forwards through the tracks. That is, > it goes in 3-7 second hops through the time elapsed counter in xmcd and > doesn't actually output any audio. I've included a second xmcd -debug > called xmcd.debug-cam which is a script of a session with this behavior. > cdcontrol still works after I've seen xmcd in this state. I just tried > again after exiting cdcontrol in the "stop" state and now xmcd works fine. > Probably just a fluke. Hmm, maybe the drive was set in a bogus mode or something. One thing I have found is that you generally don't want to have two CD-type programs active on the device at the same time, even if they're paused. Sometimes they put the drive in different modes, and get screwed up if things aren't in the state they expect. I had trouble compiling the previous version of xmcd a couple weeks ago, and I "solved" the problem by doing the following in /usr/X11R6/lib/X11/config/Imake.cf: #define __FreeBSD__ <----- this line #ifdef __FreeBSD__ # define MacroIncludeFile <FreeBSD.cf> # define MacroFile FreeBSD.cf # undef __FreeBSD__ It's a kludge, but works permanantly. Another alternative is to recompile and reinstall XFree86, assuming they've fixed it to point to the "right" cpp, or you can run a binary editor on cpp. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200002230540.VAA60262>