Date: Thu, 3 Dec 1998 11:19:38 -0700 (MST) From: "Kenneth D. Merry" <ken@plutotech.com> To: mestery@winternet.com (Kyle Mestery) Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Still errors stopping audio CDs in current Message-ID: <199812031819.LAA03245@panzer.plutotech.com> In-Reply-To: <Pine.GSO.4.05.9812030551540.29436-100000@tundra.winternet.com> from Kyle Mestery at "Dec 3, 98 05:59:52 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Kyle Mestery wrote...
> Hi,
> Here are some answers to some of the questions you posed. I am limited for
> time this morning (I have to go to work), but will answer the rest tonite.
> Thanks!
>
> On Wed, 2 Dec 1998, Kenneth D. Merry wrote:
>
> >
> > That's rather odd. Could you show me some of the errors? For instance,
> > what happens when you type:
> >
> > camcontrol inquiry -v -n cd -u 0
> >
> su-2.00# camcontrol inquiry -v -n cd -u 0
> <SONY CD-ROM CDU-76S 1.1c> Removable CD-ROM SCSI2 device
> (pass1:bt0:0:4:0): INQUIRY. CDB: 12 1 80 0 ff 0
> (pass1:bt0:0:4:0): ILLEGAL REQUEST asc:24,0
> (pass1:bt0:0:4:0): Invalid field in CDB
> Serial Number 5.0MB/s transfers (5.0MHz, offset 15)
That's a normal error. Your CDROM drive doesn't support the serial number
inquiry. There's a bug in camcontrol that I haven't bothered to fix,
though -- it prints out "Serial Number" even when the serial number request
failed.
> > or
> >
> > camcontrol tur -v -n cd -u 0
> >
> su-2.00# camcontrol tur -v -n cd -u 0
> Unit is not ready
> (pass1:bt0:0:4:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
> (pass1:bt0:0:4:0): NOT READY asc:3a,0
> (pass1:bt0:0:4:0): Medium not present
Looks fine to me. You don't have a CD in the drive. What happens when you
have a CD in the drive?
> > I'd also like to see the exact sequence of commands you give to cdcontrol.
> > cut-and-paste will be fine.
> >
> su-2.00# cdcontrol
> cdcontrol: no CD device name specified, defaulting to /dev/cd0c
> Compact Disc Control utility, version 2.0
> Type `?' for command list
>
> cdcontrol> p 6
> cdcontrol> stop
>
> It hangs at that point. Here is debugging info once I enabled debugging on
> the drive. It looks like the kernel is continually trying to send a STOP
> command to the drive:
>
> (cd0:bt0:0:4:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0
> (cd0:bt0:0:4:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0
> (cd0:bt0:0:4:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0
> (cd0:bt0:0:4:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0
> (cd0:bt0:0:4:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0
> (cd0:bt0:0:4:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0
> (cd0:bt0:0:4:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0
> (cd0:bt0:0:4:0): READ TOC/PMA/ATIP {MMC Proposed}. CDB: 43 0 0 0 0 0 0 0 4 0
> (cd0:bt0:0:4:0): READ TOC/PMA/ATIP {MMC Proposed}. CDB: 43 0 0 0 0 0 0 0 4 0
> (cd0:bt0:0:4:0): READ TOC/PMA/ATIP {MMC Proposed}. CDB: 43 2 0 0 0 0 1 0 94 0
> (cd0:bt0:0:4:0): READ TOC/PMA/ATIP {MMC Proposed}. CDB: 43 2 0 0 0 0 aa 0 c 0
> (cd0:bt0:0:4:0): MODE SENSE(06). CDB: 1a 0 e 0 1c 0
> (cd0:bt0:0:4:0): MODE SELECT(06). CDB: 15 10 0 0 1c 0
> (cd0:bt0:0:4:0): PLAY AUDIO TRACK INDEX. CDB: 48 0 0 0 6 1 0 12 1 0
> (cd0:bt0:0:4:0): STOP START UNIT. CDB: 1b 0 0 0 0 0
> (cd0:bt0:0:4:0): STOP START UNIT. CDB: 1b 0 0 0 0 0
> (cd0:bt0:0:4:0): STOP START UNIT. CDB: 1b 0 0 0 0 0
> (cd0:bt0:0:4:0): STOP START UNIT. CDB: 1b 0 0 0 0 0
> (cd0:bt0:0:4:0): STOP START UNIT. CDB: 1b 0 0 0 0 0
>
> Those continue until I turn debugging off.
That's quite interesting. Something is causing the stop unit command to be
retried indefinitely. There are two possibilities:
- There is an error returned by the drive that is retried indefinitely by
the kernel error recovery code.
- There is an error returned by the drive, but the kernel does not retry
indefinitely. It returns an error to the client program, which retries
indefinitely.
> > Do you have the same trouble when you use xmcd? If you don't have motif,
> > you can download a precompiled version of xmcd 2.3 from the 3.0 packages
> > tree. You can also download a precompiled version of xmcd 2.4 from:
> >
> > http://metalab.unc.edu/tkan/xmcd/downloads.html
> >
> > It also includes a command line cd playing utility, cda, that is quite
> > nice.
> >
> I'll try xmcd tonite after work, and see what happens.
It may work better than the CD driver + cdcontrol. The reason it may work
better is because it uses SCSI passthrough, and does some things in
vendor-specific ways.
> > I'm not sure why revision 1.7 wouldn't cause any problems, but revision
> > 1.9 would. Revision 1.8 mainly concerned probe code fixes, which wouldn't
> > affect you. Revision 1.9 moved some spl() protection around in the open
> > routine. But it wouldn't have caused the driver to get hung in the cbwait
> > state.
> >
> You're right, 1.7 didn't matter. I tried that last nite. The kernel that ran
> fine was from about the beginning of October, if that helps.
Hmm. I'd have to look back and see what has changed since then.
> > The 'cbwait' state indicates that the kernel is waiting for a transaction
> > to complete. So it almost sounds like the request isn't coming back.
> > That's why I'd like to see *which* request isn't coming back. The
> > debugging printf code will print out the SCSI CDB of the request before it
> > is sent to the drive, so we'll be able to see just what is hanging.
> >
> This would be consistent with the debugging messages it appears. So the
> device is never returning a command? I'll try xmcd tonite, let me know if
> you need more debugging info. Thanks!
Well, it looks like that the command is coming back, but it's getting
retried infinitely for some reason.
Here's something to try:
- go into cdcontrol, and play a track
- quit cdcontrol without stopping the CD
- type something like this:
camcontrol stop -v -n cd -u 0
That should do the same thing as the CD driver's stop ioctl, but the
command will not be retried it it fails. The -v switch will cause
camcontrol to print out SCSI sense information if the command fails.
Hopefully that'll show us what the error is, and we can figure out whether
the kernel would retry it indefinitely.
Ken
--
Kenneth Merry
ken@plutotech.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812031819.LAA03245>