Date: Thu, 9 Nov 2000 16:13:38 -0700 From: "Kenneth D. Merry" <ken@kdm.org> To: Matthew Jacob <mjacob@feral.com> Cc: Wilko Bulte <wkb@freebie.demon.nl>, mjacob@FreeBSD.ORG, FreeBSD-alpha mailing list <freebsd-alpha@FreeBSD.ORG>, justin@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG Subject: Re: alpha/22650: SCSI cdrom attach problems on 4-stable Message-ID: <20001109161338.A34112@panzer.kdm.org> In-Reply-To: <Pine.BSF.4.21.0011091450300.46819-100000@beppo.feral.com>; from mjacob@feral.com on Thu, Nov 09, 2000 at 02:54:35PM -0800 References: <20001109154911.A33812@panzer.kdm.org> <Pine.BSF.4.21.0011091450300.46819-100000@beppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--qMm9M+Fa2AknHoGS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Thu, Nov 09, 2000 at 14:54:35 -0800, Matthew Jacob wrote:
> On Thu, 9 Nov 2000, Kenneth D. Merry wrote:
> > On Thu, Nov 09, 2000 at 14:34:19 -0800, Matthew Jacob wrote:
> > > What's particularly obnoxious here is that the CD in question doesn't
> > > actually completely detach- that is, it's pass instance stays, but
> > > the cd instance won't attach- and this, for some reason, makes it
> > > impossible to rescan it later.
> >
> > The reason the device isn't gone is because the pass(4) driver actually
> > attached successfully. The problem is that when there is no CD in the
> > drive, any CDROM drive will return an error in response to a READ CAPACITY
> > command.
> >
> > Since autosense is failing, the cd(4) driver can't tell what sort of error
> > is getting returned (and therefore whether the drive is really accessible),
> > so it won't attach.
>
> An AUTOSENSE failing means that a check condition occurred, but no sense data
> is available. That should, in fact, be treated identically to READ CAPACITY
> failing because there's no media.
Right.
> > The pass(4) driver doesn't issue any commands to check the device (it
> > doesn't have any requirements for device functionality beyond the basic
> > probe code), so it attaches without problems.
> >
> > Both drivers are doing the right thing from what I can see.
>
> But a later rescan should see it but it doesm't. And see above.
That's how the rescan semantics work. The device only gets announced to
the peripheral drivers if it is a new device, or if it has gone away.
In this case the device is still there, and still attached to the pass(4)
driver. So from the transport layer's perspective, all the peripheral
drivers have already seen the device and had a chance to attach or not.
> But the high order bit is that the autosense is failing. All other stuff in
> scsi_cd is is secondary.
>
> What's more important is that cam_periph_error or the periph should send a
> REQUEST SENSE if AUTOSENSE fails- the sim should not be the one doing this.
I agree. It would be interesting to find out what the SCSI status byte is
here. I've attached a patch that should print it out.
Ken
--
Kenneth Merry
ken@kdm.org
--qMm9M+Fa2AknHoGS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="scsi_cd.c.scsi_status.20001109"
==== //depot/FreeBSD-ken/src/sys/cam/scsi/scsi_cd.c#13 - /c/ken/perforce/FreeBSD-ken/src/sys/cam/scsi/scsi_cd.c ====
*** /tmp/tmp.34213.0 Thu Nov 9 16:12:46 2000
--- /c/ken/perforce/FreeBSD-ken/src/sys/cam/scsi/scsi_cd.c Thu Nov 9 16:12:33 2000
***************
*** 1728,1733 ****
--- 1728,1735 ----
xpt_print_path(periph->path);
printf("got CAM status %#x\n",
done_ccb->ccb_h.status);
+ printf("got SCSI status %#x\n",
+ done_ccb->csio.scsi_status);
}
xpt_print_path(periph->path);
printf("fatal error, failed"
--qMm9M+Fa2AknHoGS--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001109161338.A34112>