From owner-freebsd-scsi Thu Aug 29 5:36: 9 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 75BFA37B400; Thu, 29 Aug 2002 05:36:04 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFC8B43E84; Thu, 29 Aug 2002 05:36:01 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id LAA24107; Thu, 29 Aug 2002 11:45:26 GMT Date: Thu, 29 Aug 2002 21:52:27 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "Kenneth D. Merry" Cc: "M. Warner Losh" , , , , Subject: Re: kern/15608: acd0 / cd0 give inconsistent errors on empty tray open() In-Reply-To: <20020826221642.A39886@panzer.kdm.org> Message-ID: <20020829210436.T3999-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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. > 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. > 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. > 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(). 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. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message