Bug 15608 - acd0 / cd0 give inconsistent errors on empty tray open()
Summary: acd0 / cd0 give inconsistent errors on empty tray open()
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 4.0-CURRENT
Hardware: Any Any
: Normal Affects Only Me
Assignee: Kenneth D. Merry
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 1999-12-21 15:50 UTC by Nick Sayer
Modified: 2004-01-26 20:02 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Sayer 1999-12-21 15:50:00 UTC
Opening an EIDE CDROM with no disk in the tray yields EIO.
Doing the same on a SCSI cdrom yields ENODEV.

Returning ENXIO instead of EIO breaks vmware and seems to me,
at least, to be the wrong error. There _is_ a device there.

Fix: 

IMHO, the two devices should be consistent, and EIO, at least,
doesn't break vmware.
Comment 1 Johan Karlsson freebsd_committer freebsd_triage 2002-08-22 20:40:51 UTC
State Changed
From-To: open->feedback

Is this still the case? 


Comment 2 Johan Karlsson freebsd_committer freebsd_triage 2002-08-22 20:40:51 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-scsi

Over to -scsi since the proposal is to change cd0.
Comment 3 ken 2002-08-22 22:09:31 UTC
On Thu, Aug 22, 2002 at 12:42:22 -0700, Johan Karlsson wrote:
> Responsible-Changed-From-To: freebsd-bugs->freebsd-scsi
> Responsible-Changed-By: johan
> Responsible-Changed-When: Thu Aug 22 12:40:51 PDT 2002
> Responsible-Changed-Why: 
> 	Over to -scsi since the proposal is to change cd0.

Let's see if there are any opinions on freebsd-standards.

The question is, what sort of error should we return from a peripheral
driver (cd(4), da(4), etc.) open() routine when there is no media in the
drive?

Currently all CAM drivers will return ENXIO, and although the PR says that
the acd(4) driver returns EIO, I can't tell from acdopen that it returns
any errors at all if media isn't present.

My guess is that EIO is getting returned sometime later in the acd(4)
driver.  (If that is still the case, this PR was filed in late 1999.)

So is there any opinion on -standards as to what sort of error we should
return on open if there is no media in a drive?

Ken
-- 
Kenneth Merry
ken@kdm.org
Comment 4 M. Warner Losh 2002-08-22 22:23:29 UTC
In message: <20020822150931.A10866@panzer.kdm.org>
            "Kenneth D. Merry" <ken@kdm.org> writes:
: The question is, what sort of error should we return from a peripheral
: driver (cd(4), da(4), etc.) open() routine when there is no media in the
: drive?
: 
: Currently all CAM drivers will return ENXIO, and although the PR says that
: the acd(4) driver returns EIO, I can't tell from acdopen that it returns
: any errors at all if media isn't present.
: 
: My guess is that EIO is getting returned sometime later in the acd(4)
: driver.  (If that is still the case, this PR was filed in late 1999.)
: 
: So is there any opinion on -standards as to what sort of error we should
: return on open if there is no media in a drive?

EIO means "The device is there, but the driver had problems
interacting with it" while ENXIO means "the device isn't there at
all."  As such, EIO is the more correct error to return in this case.

I don't know if the standards speak to this specific issue (no or bad
media in a device with removable media).

Warner
Comment 5 Bruce Evans 2002-08-23 03:41:28 UTC
On Thu, 22 Aug 2002, M. Warner Losh wrote:

> In message: <20020822150931.A10866@panzer.kdm.org>
>             "Kenneth D. Merry" <ken@kdm.org> writes:
> : So is there any opinion on -standards as to what sort of error we should
> : return on open if there is no media in a drive?
>
> EIO means "The device is there, but the driver had problems
> interacting with it" while ENXIO means "the device isn't there at
> all."  As such, EIO is the more correct error to return in this case.

No, EIO means that an input/output arror occurred.  open.2 only documents
EIO for creating files.  Otherwise open() normally doesn't do any i/o.
So ENXIO is the more correct error.

I think the bug is that the open doesn't succeed.  The device is
reported as being there at boot time, and there is enough of it there
to tell which parts of it aren't there, so why not open() it so that
you do things like ioctl() on it to close its door and make it there?

> I don't know if the standards speak to this specific issue (no or bad
> media in a device with removable media).

POSIX doesn't say anything much different from open.2 about this.

Bruce
Comment 6 ken 2002-08-23 05:32:04 UTC
On Fri, Aug 23, 2002 at 12:41:28 +1000, Bruce Evans wrote:
> On Thu, 22 Aug 2002, M. Warner Losh wrote:
> 
> > In message: <20020822150931.A10866@panzer.kdm.org>
> >             "Kenneth D. Merry" <ken@kdm.org> writes:
> > : So is there any opinion on -standards as to what sort of error we should
> > : return on open if there is no media in a drive?
> >
> > EIO means "The device is there, but the driver had problems
> > interacting with it" while ENXIO means "the device isn't there at
> > all."  As such, EIO is the more correct error to return in this case.
> 
> No, EIO means that an input/output arror occurred.  open.2 only documents
> EIO for creating files.  Otherwise open() normally doesn't do any i/o.
> So ENXIO is the more correct error.

Cool.

> I think the bug is that the open doesn't succeed.  The device is
> reported as being there at boot time, and there is enough of it there
> to tell which parts of it aren't there, so why not open() it so that
> you do things like ioctl() on it to close its door and make it there?

There is no ioctl in the interface for loading a CD.  None of the other
ioctls, I think, make much sense without media in the drive.

The reason we need to do a read capacity in the open() routine, which is
why the open fails when there is no media, is so we can fill in the
d_secsize and d_secperunit fields in the disklabel.

> > I don't know if the standards speak to this specific issue (no or bad
> > media in a device with removable media).
> 
> POSIX doesn't say anything much different from open.2 about this.
> 
> Bruce

Ken
-- 
Kenneth Merry
ken@kdm.org
Comment 7 Johan Karlsson freebsd_committer freebsd_triage 2002-08-25 03:03:27 UTC
Responsible Changed
From-To: freebsd-scsi->scsi

Use short names for mailing list to make searches    
using the web query form work with the shown responsible. 

This also makes open PR show up in the summery mail.
Comment 8 Bruce Evans 2002-08-25 08:07:32 UTC
On Thu, 22 Aug 2002, Kenneth D. Merry wrote:

> On Fri, Aug 23, 2002 at 12:41:28 +1000, Bruce Evans wrote:
> > I think the bug is that the open doesn't succeed.  The device is
> > reported as being there at boot time, and there is enough of it there
> > to tell which parts of it aren't there, so why not open() it so that
> > you do things like ioctl() on it to close its door and make it there?
>
> There is no ioctl in the interface for loading a CD.  None of the other
> ioctls, I think, make much sense without media in the drive.

There is a CDIOCCLOSE which seems to be supported by acd and by some
unmaintained cdrom drivers by not by the scsi cdrom driver.

> The reason we need to do a read capacity in the open() routine, which is
> why the open fails when there is no media, is so we can fill in the
> d_secsize and d_secperunit fields in the disklabel.

acdopen() calls acd_read_toc() which does similar things.  When there is
no media, acd_read_toc() fails with the not quite right error EBUSY, but
acdopen() ignores this error and the open succeeds and you can try
CDIOCCLOSE() to attempt to load media.  So it seems that acdopen() already
works like I want, and the EIO error reported earlier doesn't actually
occur for acdopen().

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.

Bruce
Comment 9 Kenneth D. Merry freebsd_committer freebsd_triage 2004-01-26 19:59:35 UTC
State Changed
From-To: feedback->closed

Bruce said that ENXIO was the correct error to return, and we do return 
that when media isn't present.  Also, I believe that the issues that Bruce 
brought up about the CDIOCCLOSE ioctl, etc., have been fixed. 


Comment 10 Kenneth D. Merry freebsd_committer freebsd_triage 2004-01-26 19:59:35 UTC
Responsible Changed
From-To: scsi->ken

Bruce said that ENXIO was the correct error to return, and we do return 
that when media isn't present.  Also, I believe that the issues that Bruce 
brought up about the CDIOCCLOSE ioctl, etc., have been fixed.