Date: Wed, 2 Dec 1998 21:58:12 -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: <199812030458.VAA00595@panzer.plutotech.com> In-Reply-To: <Pine.GSO.4.05.9812022142200.27248-100000@tundra.winternet.com> from Kyle Mestery at "Dec 2, 98 09:52:47 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Kyle Mestery wrote... > > Greetings, > > I am still seeing the same problems trying to stop audio CDs in my SCSI CD-ROM > drive. I am now running a 3.0 kernel from about 6:30AM CST. The machine is a > dual Pentium machine, with a Buslogic BT-946c SCSI controller, one 1GB HP > SCSI-2 disk, and a Sony 4x SCSI CD-ROM attached. It also has an IDE disk in > it. Here is dmesg info for the controller, disk, and cd-rom: > > bt0: <Buslogic Multi-Master SCSI Host Adapter> rev 0x00 int a irq 16 on pci0.20.0 > bt0: BT-946C FW Rev. 4.25J Narrow SCSI Host Adapter, SCSI ID 7, 100 CCBs > da0 at bt0 bus 0 target 0 lun 0 > da0: <HP C2247-300 0BA4> Fixed Direct Access SCSI2 device > da0: 10.0MB/s transfers (10.0MHz, offset 8), Tagged Queueing Enabled > da0: 1003MB (2054864 512 byte sectors: 64H 32S/T 1003C) > cd0 at bt0 bus 0 target 4 lun 0 > cd0: <SONY CD-ROM CDU-76S 1.1c> Removable CD-ROM SCSI2 device > cd0: 5.0MB/s transfers (5.0MHz, offset 15) > cd0: cd present [316932 x 2048 byte records] > > I have now verified the problem persists with cdcontrol and cdplay from the > ports collection. What happens is, when the drive is issued a stop command > from one of those programs, the program hangs in cbwait. Looking into the > cdcontrol code, when stop is issued, a CDIOCSTOP is sent to the drive. Is that > correct? That's correct. > Also, cdplay managed to get this out through syslog, which cdcontrol > had never previously done: > > (cd0:bt0:0:4:0): PLAY AUDIO MSF. CDB: 47 0 0 0 0 0 42 f 19 0 > (cd0:bt0:0:4:0): ILLEGAL REQUEST asc:24,0 > (cd0:bt0:0:4:0): Invalid field in CDB > > I tried issuing some camcontrol commands to the drive, but they all return > the above illegal request. I never had these problems with rev 1.7 of > /sys/cam/scsi/scsi_cd.c. Is there anything else I can do to debug this > problem? 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 or camcontrol tur -v -n cd -u 0 One question I have is which command is hanging. It could be that one of the commands in the CD driver's open routine is hanging. Try enabling CDB debugging: - put 'options CAMDEBUG' in your kernel - before you try playing anything on your CDROM drive, use the following camcontrol command to enable debugging for that device: camcontrol debug -c 0:4:0 (this assumes that your BusLogic controller is the only controller in the system. If not, you'll need to type 'camcontrol devlist' to get the proper bus number.) You should get a kernel printf for each SCSI command that is issued. I'd also like to see the exact sequence of commands you give to cdcontrol. cut-and-paste will be fine. 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'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. 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. 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?199812030458.VAA00595>