Date: Thu, 3 Dec 1998 16:17:55 -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: <199812032317.QAA04738@panzer.plutotech.com> In-Reply-To: <Pine.GSO.4.05.9812031643590.4715-100000@tundra.winternet.com> from Kyle Mestery at "Dec 3, 98 04:50:39 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
--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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812032317.QAA04738>