From nsayer@mailhost.kfu.com  Tue Dec 21 07:45:39 1999
Return-Path: <nsayer@mailhost.kfu.com>
Received: from quack.kfu.com (quack.kfu.com [170.1.70.2])
	by hub.freebsd.org (Postfix) with ESMTP id 46A67150FD
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 21 Dec 1999 07:45:39 -0800 (PST)
	(envelope-from nsayer@mailhost.kfu.com)
Received: from morpheus.kfu.com (morpheus.kfu.com [170.1.70.19])
	by quack.kfu.com (8.9.2/8.9.3) with ESMTP id HAA63223
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 21 Dec 1999 07:45:38 -0800 (PST)
	(envelope-from nsayer@mailhost.kfu.com)
Received: by morpheus.kfu.com 
        (8.9.3//ident-1.0) id HAA00571; Tue, 21 Dec 1999 07:45:38 -0800 (PST) 
Message-Id: <199912211545.HAA00571@morpheus.kfu.com>
Date: Tue, 21 Dec 1999 07:45:38 -0800 (PST)
From: nsayer@quack.kfu.com
Sender: nsayer@mailhost.kfu.com
Reply-To: nsayer@quack.kfu.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: acd0 / cd0 give inconsistent errors on empty tray open()
X-Send-Pr-Version: 3.2

>Number:         15608
>Category:       kern
>Synopsis:       acd0 / cd0 give inconsistent errors on empty tray open()
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    ken
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Dec 21 07:50:00 PST 1999
>Closed-Date:    Mon Jan 26 12:02:41 PST 2004
>Last-Modified:  Mon Jan 26 12:02:41 PST 2004
>Originator:     Nick Sayer
>Release:        FreeBSD 4.0-CURRENT i386
>Organization:
Just me
>Environment:

SCSI and EIDE CDROM drives, no disk in tray.

>Description:

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.

>How-To-Repeat:

>Fix:

IMHO, the two devices should be consistent, and EIO, at least,
doesn't break vmware.


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: johan 
State-Changed-When: Thu Aug 22 12:40:51 PDT 2002 
State-Changed-Why:  
Is this still the case? 


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. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=15608 

From: "Kenneth D. Merry" <ken@kdm.org>
To: Johan Karlsson <johan@FreeBSD.ORG>
Cc: nsayer@quack.kfu.com, freebsd-gnats-submit@FreeBSD.ORG,
	freebsd-scsi@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG,
	sos@FreeBSD.ORG
Subject: Re: kern/15608: acd0 / cd0 give inconsistent errors on empty tray open()
Date: Thu, 22 Aug 2002 15:09:31 -0600

 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

From: "M. Warner Losh" <imp@bsdimp.com>
To: ken@kdm.org
Cc: johan@FreeBSD.ORG, nsayer@quack.kfu.com,
	freebsd-gnats-submit@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG,
	freebsd-standards@FreeBSD.ORG, sos@FreeBSD.ORG
Subject: Re: kern/15608: acd0 / cd0 give inconsistent errors on empty tray
 open()
Date: Thu, 22 Aug 2002 15:23:29 -0600 (MDT)

 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

From: Bruce Evans <bde@zeta.org.au>
To: "M. Warner Losh" <imp@bsdimp.com>
Cc: ken@kdm.org, <johan@FreeBSD.ORG>, <nsayer@quack.kfu.com>,
	<freebsd-gnats-submit@FreeBSD.ORG>, <freebsd-scsi@FreeBSD.ORG>,
	<freebsd-standards@FreeBSD.ORG>, <sos@FreeBSD.ORG>
Subject: Re: kern/15608: acd0 / cd0 give inconsistent errors on empty tray
 open()
Date: Fri, 23 Aug 2002 12:41:28 +1000 (EST)

 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
 

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-gnats-submit@FreeBSD.ORG,
	freebsd-scsi@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG,
	sos@FreeBSD.ORG
Subject: Re: kern/15608: acd0 / cd0 give inconsistent errors on empty tray open()
Date: Thu, 22 Aug 2002 22:32:04 -0600

 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
Responsible-Changed-From-To: freebsd-scsi->scsi 
Responsible-Changed-By: johan 
Responsible-Changed-When: Sat Aug 24 19:03:27 PDT 2002 
Responsible-Changed-Why:  
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. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=15608 

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-gnats-submit@FreeBSD.ORG>,
	<freebsd-scsi@FreeBSD.ORG>, <freebsd-standards@FreeBSD.ORG>,
	<sos@FreeBSD.ORG>
Subject: Re: kern/15608: acd0 / cd0 give inconsistent errors on empty tray
 open()
Date: Sun, 25 Aug 2002 17:07:32 +1000 (EST)

 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
 
State-Changed-From-To: feedback->closed 
State-Changed-By: ken 
State-Changed-When: Mon Jan 26 11:59:35 PST 2004 
State-Changed-Why:  
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. 


Responsible-Changed-From-To: scsi->ken 
Responsible-Changed-By: ken 
Responsible-Changed-When: Mon Jan 26 11:59:35 PST 2004 
Responsible-Changed-Why:  
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. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=15608 
>Unformatted:
