From owner-freebsd-scsi Thu Dec 3 04:00:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA01807 for freebsd-scsi-outgoing; Thu, 3 Dec 1998 04:00:30 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from icicle.winternet.com (icicle.winternet.com [198.174.169.13]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA01802 for ; Thu, 3 Dec 1998 04:00:28 -0800 (PST) (envelope-from mestery@mail.winternet.com) Received: (from adm@localhost) by icicle.winternet.com (8.8.8/8.8.8) id GAA03106; Thu, 3 Dec 1998 06:00:10 -0600 (CST) Received: from tundra.winternet.com(198.174.169.11) by icicle.winternet.com via smap (V2.0) id xma003064; Thu, 3 Dec 98 05:59:54 -0600 Received: from localhost (mestery@localhost) by tundra.winternet.com (8.8.7/8.8.4) with ESMTP id FAA29442; Thu, 3 Dec 1998 05:59:52 -0600 (CST) X-Authentication-Warning: tundra.winternet.com: mestery owned process doing -bs Date: Thu, 3 Dec 1998 05:59:52 -0600 (CST) From: Kyle Mestery To: "Kenneth D. Merry" cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Still errors stopping audio CDs in current In-Reply-To: <199812030458.VAA00595@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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 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