Date: Mon, 26 Jan 2004 17:26:48 -0800 (PST) From: Dan Strick <strick@covad.net> To: ken@FreeBSD.org Cc: scsi@FreeBSD.org Subject: Re: kern/15608: acd0 / cd0 give inconsistent errors on empty tray open() Message-ID: <200401270126.i0R1QmCW000463@mist.nodomain>
next in thread | raw e-mail | index | archive | help
>> > Synopsis: acd0 / cd0 give inconsistent errors on empty tray open() > > 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 >> ENXIO would be historically the correct error to return for nonexistant disk media, including an attempt to begin a read/write one or more sectors beyond the end of a disk. This should also be the error returned for an attempt to begin a read one or more sectors beyond the last written sector of a write-once medium (e.g. CD-R) though this might be difficult situation to recognize. It might be the correct error to return whenever a read produces a "blank check" though one might sometimes make a good argument for EIO in that situation. Of course, a read that begins at or before the end of the medium but extends past the end should simply result in a short read. I mention this because it works on FreeBSD with CD-ROM but not with CD-R. I don't think I have tested this on the most recent FreeBSD releases so it might have been fixed. (This glitch, present in both scsi and atapi cd drivers, also triggered a bug in ata/atapi dma code that the ata driver eventually resolved by timing out waiting for dma to complete and disabling dma for the device.) Dan Strick strick@covad.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401270126.i0R1QmCW000463>