From owner-freebsd-scsi Thu Dec 3 15:18:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA10947 for freebsd-scsi-outgoing; Thu, 3 Dec 1998 15:18:16 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA10933 for ; Thu, 3 Dec 1998 15:18:13 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id QAA04738; Thu, 3 Dec 1998 16:17:56 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199812032317.QAA04738@panzer.plutotech.com> Subject: Re: Still errors stopping audio CDs in current In-Reply-To: from Kyle Mestery at "Dec 3, 98 04:50:39 pm" To: mestery@winternet.com (Kyle Mestery) Date: Thu, 3 Dec 1998 16:17:55 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM912727075-4685-0_ Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --ELM912727075-4685-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Kyle Mestery wrote... > On Thu, 3 Dec 1998, Kenneth D. Merry wrote: > > Kyle Mestery wrote... > > > On Wed, 2 Dec 1998, Kenneth D. Merry wrote: > > > Looks fine to me. You don't have a CD in the drive. What happens when you > > have a CD in the drive? > > > hope.winternet.com$ sudo camcontrol tur -v -n cd -u 0 > Unit is ready > > Looks like that completes okay. Yep. > > 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. > > > It looks like it's the program doing this, because if I run cdcontrol, play > a song, exit it without stopping, then stop the cdrom using camcontrol, it > stops fine, and prints this error message: > > hope.winternet.com$ 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> ^C > hope.winternet.com$ sudo camcontrol stop -v -n cd -u 0 > Error received from stop unit command > (pass1:bt0:0:4:0): STOP START UNIT. CDB: 1b 0 0 0 0 0 > (pass1:bt0:0:4:0): error code 0 > hope.winternet.com$ Heh. Well, it isn't what you think. In this case, the kernel is retrying the command over and over again. If I had to guess, I'd say that the drive is returning busy status. In that case, we wouldn't get any sense information. I've attached a patch for camcontrol.c. Can you try the above stop command using this patch? > > 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. > > > Still downloading xmcd to try it. Looks like I need an elf X11, which I am > also doing as we speak.:) Ahh. Well, I could have probably given you an a.out version of it, but I guess you need to upgrade to ELF sometime or another. > > 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. > > > See above, it looks like it's the program that isn't handling the error > returned, correct? I will try xmcd as soon as XFree builds for me, and xmcd > is installed. Until then, I can just use camcontrol to stop the drive, as it > lets me get by. Thanks! Good deal. And, as I said above, the problem is that the kernel is retrying the command indefinitely. The patch to camcontrol that I've attached will tell us exactly what error is returned. Once I know that, we can try to decide what to do. Ken -- Kenneth Merry ken@plutotech.com --ELM912727075-4685-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=camcontrol.c.startstop.120398 Content-Description: camcontrol.c.startstop.120398 Content-Transfer-Encoding: 7bit ==== //depot/cam/sbin/camcontrol/camcontrol.c#29 - /usr/home/ken/perforce/cam/sbin/camcontrol/camcontrol.c ==== *** /tmp/tmp.7426.0 Thu Dec 3 16:11:59 1998 --- /usr/home/ken/perforce/cam/sbin/camcontrol/camcontrol.c Thu Dec 3 16:10:58 1998 *************** *** 505,524 **** } else { error = 1; ! if (startstop) ! fprintf(stdout, ! "Error received from start unit command\n"); ! else ! fprintf(stdout, ! "Error received from stop unit command\n"); if (arglist & CAM_ARG_VERBOSE) { ! if ((ccb->ccb_h.status & CAM_STATUS_MASK) == CAM_SCSI_STATUS_ERROR) scsi_sense_print(device, &ccb->csio, stderr); else ! fprintf(stderr, "CAM status is %#x\n", ! ccb->ccb_h.status); } } --- 505,523 ---- } else { error = 1; ! fprintf(stdout, ! "Error received from %s unit command\n", ! startstop ? "start" : "stop"); if (arglist & CAM_ARG_VERBOSE) { ! if (((ccb->ccb_h.status & CAM_STATUS_MASK) == CAM_SCSI_STATUS_ERROR) + && (ccb->csio.scsi_status == SCSI_STATUS_CHECK_COND)) scsi_sense_print(device, &ccb->csio, stderr); else ! fprintf(stderr, "CAM status is %#x, SCSI " ! "status is %#x\n", ccb->ccb_h.status, ! ccb->csio.scsi_status); } } --ELM912727075-4685-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message