Date: Thu, 3 Dec 1998 05:59:52 -0600 (CST) From: Kyle Mestery <mestery@winternet.com> To: "Kenneth D. Merry" <ken@plutotech.com> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Still errors stopping audio CDs in current Message-ID: <Pine.GSO.4.05.9812030551540.29436-100000@tundra.winternet.com> In-Reply-To: <199812030458.VAA00595@panzer.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
> 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
> 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.
> 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.
> 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.
> 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!
--
Kyle Mestery
StorageTek's Storage Networking Group
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?Pine.GSO.4.05.9812030551540.29436-100000>