Date: Thu, 29 Aug 2002 22:34:30 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: Bruce Evans <bde@zeta.org.au> Cc: "M. Warner Losh" <imp@bsdimp.com>, 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> In-Reply-To: <20020829210436.T3999-100000@gamplex.bde.org>; from bde@zeta.org.au on Thu, Aug 29, 2002 at 09:52:27PM %2B1000 References: <20020826221642.A39886@panzer.kdm.org> <20020829210436.T3999-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020829223429.A62384>