From owner-freebsd-scsi Thu Aug 29 21:34:47 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9377937B400; Thu, 29 Aug 2002 21:34:41 -0700 (PDT) Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E55F43E4A; Thu, 29 Aug 2002 21:34:40 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: from panzer.kdm.org (localhost [127.0.0.1]) by panzer.kdm.org (8.12.5/8.12.5) with ESMTP id g7U4YUKD062456; Thu, 29 Aug 2002 22:34:30 -0600 (MDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.12.5/8.12.5/Submit) id g7U4YUU0062455; Thu, 29 Aug 2002 22:34:30 -0600 (MDT) (envelope-from ken) Date: Thu, 29 Aug 2002 22:34:30 -0600 From: "Kenneth D. Merry" To: Bruce Evans Cc: "M. Warner Losh" , johan@FreeBSD.ORG, nsayer@quack.kfu.com, freebsd-scsi@FreeBSD.ORG, sos@FreeBSD.ORG Subject: Re: kern/15608: acd0 / cd0 give inconsistent errors on empty tray open() Message-ID: <20020829223429.A62384@panzer.kdm.org> References: <20020826221642.A39886@panzer.kdm.org> <20020829210436.T3999-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020829210436.T3999-100000@gamplex.bde.org>; from bde@zeta.org.au on Thu, Aug 29, 2002 at 09:52:27PM +1000 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Aug 29, 2002 at 21:52:27 +1000, Bruce Evans wrote: > On Mon, 26 Aug 2002, Kenneth D. Merry wrote: > > > [ freebsd-gnats-submit taken out for now, so we don't clutter up the PR > > database too much with in-progress patches ] > > I took out freebsd-standards too. > > > On Sun, Aug 25, 2002 at 17:07:32 +1000, Bruce Evans wrote: > > > > [...] > > > There is a CDIOCCLOSE which seems to be supported by acd and by some > > > unmaintained cdrom drivers by not by the scsi cdrom driver. > > > > Ahh, I missed that. > > > [...] > > Well, here is a first pass at it. Let me know what you think. > > > > > dsopen() has similar issues. It attempts to read MBRs and disk labels > > > and can probably return EIO for read errors when there is no media or > > > bad media. One reason why the fd driver doesn't use the slice layer > > > is that I never got this working well enough for floppies. It is hard > > > to issue formatting ioctls when the open fails because the MBR is > > > unreadable. > > > > FWIW, if the slice code is setup to attempt to read labels off the disk, but > > there is no media in the drive (i.e. sector size and sectors per unit are > > 0, or it could be because p_size for the first partition is 0), it panics. > > (DSO_COMPATLABEL is set, and DSO_NOLABELS is cleared) > > > > If the slice code is setup not to attempt to read labels off the disk, it > > doesn't panic at least. > > Hmm. I never committed the patch that makes dsopen() return EINVAL > if the sector size is 0. (We added an early return if the sector size > is not a multiple of DEV_BSIZE some time ago.) But these early returns > of an error are not quite right, since they cause the whole open() to > fail, but dsopen() is really only about the slice+label parts of opening > disks. Ahh. > > Behavior of things like dd(1) is different, obviously, because it no longer > > fails in open() with an empty drive. e.g., new behavior is: > > > > ================ > > {nargothrond:/usr/home/ken:2:0} dd if=/dev/cd0c of=/dev/null bs=2k > > dd: /dev/cd0c: Device not configured > > 0+0 records in > > 0+0 records out > > 0 bytes transferred in 0.004522 secs (0 bytes/sec) > > ================ > > Shouldn't the error be EIO now? Hmm, POSIX just made ENXIO standard for > read(). From POSIX.1-2001-draft7: > > % 36723 [ENXIO] A request was made of a nonexistent device, or the request was outside the > % 36724 capabilities of the device. > % ... > % 36845 * The [ENXIO] optional error condition is added. > > Similarly for write(). ENXIO is very reasonable for i/o an open device that > went away. Cool. The error returned will be whatever the error recovery code decides is appropriate. In the case of "medium not present" errors, that means ENXIO. (see asc_table[] in sys/cam/scsi/scsi_all.c ) > > current behavior is: > > [...] > > > > cdcontrol seems to get a better idea of what is going on when open() fails: > > > > ================ > > {gondolin:/usr/home/ken:7:1} cdcontrol > > cdcontrol: no CD device name specified, defaulting to /dev/cd0c > > Compact Disc Control utility, version 2.0 > > Type `?' for command list > > > > cdcontrol> info > > cdcontrol: no disc in drive /dev/cd0c > > cdcontrol> quit > > ================ > > It also prints this if there is no cd0 device but there is a cd0c inode :-). > The comment before it prints this says that ENXIO is overloaded, but here > it is too overloaded to work. Ahh. > > When the ioctl fails instead of the open, it isn't quite as clear about > > what is going on: > > > > ================ > > {nargothrond:/usr/home/ken:3:1} cdcontrol > > cdcontrol: no CD device name specified, defaulting to /dev/cd0c > > Compact Disc Control utility, version 2.0 > > Type `?' for command list > > > > cdcontrol> info > > cdcontrol: getting toc header: Device not configured > > cdcontrol: Device not configured > > cdcontrol> quit > > ================ > > Here it could more reasonably say that there is no disc in the drive, since > there must at least have been a drive to get that far. Similarly for ENXIO > in read(). Does the acd(4) driver produce the same behavior? > I didn't try the patch or look closely at it. My only SCSI cdrom is 8 years > old hasn't been able to read disks for 2-3 years. Bummer. I think you should be able to try it out with an ATAPI CDROM drive if you turn on options ATAPICAM. (FWIW, I don't have any ATA or ATAPI peripherals at home, except for two disk drives that are mostly dead and haven't been turned on in 7 or 8 years. :) I still need to make sure this doesn't break any of the disklabel behavior for randomly writeable drives, e.g. DVD-RAM. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message