Date: Tue, 1 Oct 2002 15:06:21 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: "Kenneth D. Merry" <ken@kdm.org> 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: <20021001142616.M354-100000@gamplex.bde.org> In-Reply-To: <20020829223429.A62384@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[Lot's quoted since this is a reply to old mail]
Long ago, on Thu, 29 Aug 2002, Kenneth D. Merry wrote:
> On Thu, Aug 29, 2002 at 21:52:27 +1000, Bruce Evans wrote:
> > On Mon, 26 Aug 2002, Kenneth D. Merry wrote:
> > > 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.
I finally configured atapicam so that I could test this, but I seem to have
deleted the mail with the patch. Please resend the patch.
> > > > 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.
This is now "fixed" in diskopen() by dividing by the sector size before
dsopen() can validate it. When the drive tray is open, division by 0
only happens if there have been no previous successful opens, so something
is apparently remembering the label for too long. These are some of the
bugs introduced in subr_disk.c rev.1.59 (the others are lossage of passing
the d_type, d_typename, d_packname and d_flags fields from the driver).
> > > 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 )
So this thread is now about errors in read(): acd gives EIO but cd will give
ENXIO. (cd still gives ENXIO in open() in -current.)
> > > 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?
acd gives almost the second behaviour: a read error "getting toc header".
The read error is EIO instead of ENXIO.
> > 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. :)
Thanks for the hint. BTW, atapicam has the interesting property of living
alongside atapi. I get devices afd0/da0, cd0/acd0 and cd1/acd1 here. They
all work, at least non-concurrently. I haven't tried concurrent opens and
expect they would cause problems, especially for writable devices.
Bruce
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?20021001142616.M354-100000>