From owner-freebsd-alpha Thu Nov 9 15:13:54 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id BFBF337B479; Thu, 9 Nov 2000 15:13:48 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id QAA34228; Thu, 9 Nov 2000 16:13:38 -0700 (MST) (envelope-from ken) Date: Thu, 9 Nov 2000 16:13:38 -0700 From: "Kenneth D. Merry" To: Matthew Jacob Cc: Wilko Bulte , mjacob@FreeBSD.ORG, FreeBSD-alpha mailing list , 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> References: <20001109154911.A33812@panzer.kdm.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mjacob@feral.com on Thu, Nov 09, 2000 at 02:54:35PM -0800 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --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