From nobody@FreeBSD.org  Thu May 15 03:40:45 2008
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id A17FD106567D
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 15 May 2008 03:40:45 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 939FA8FC19
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 15 May 2008 03:40:45 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m4F3dZkE077297
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 15 May 2008 03:39:35 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.2/8.14.1/Submit) id m4F3dZ7B077296;
	Thu, 15 May 2008 03:39:35 GMT
	(envelope-from nobody)
Message-Id: <200805150339.m4F3dZ7B077296@www.freebsd.org>
Date: Thu, 15 May 2008 03:39:35 GMT
From: Carlos Santos <unixmania@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Workaround for burncd: ioctl(CDIOCEJECT): Input/output error
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         123693
>Category:       bin
>Synopsis:       [patch] burncd(8): workaround for busy cd-writer while ejecting
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu May 15 03:50:02 UTC 2008
>Closed-Date:    
>Last-Modified:  Mon Nov 16 02:20:02 UTC 2009
>Originator:     Carlos Santos
>Release:        7.0-STABLE
>Organization:
-
>Environment:
FreeBSD casantos 7.0-STABLE FreeBSD 7.0-STABLE #1: Fri Apr 25 03:02:38 BRT 2008     root@casantos:/share/FreeBSD/src/sys/i386/compile/HP_NX6320  i386
>Description:
I get "burncd: ioctl(CDIOCEJECT): Input/output error" each time I attempt to blank a CDRW with

    burncd -f /dev/acd0 blank eject

I noticed that this does not happen when I write a data cd with

    burncd -f /dev/acd0 data cd-image.iso fixate eject

I have seen the same bahavior on 4 different computers that have DVD-RW units. It seems that it is necessary to give some time to the writer in order to let it stabilize before attempting to eject the disk.

>How-To-Repeat:
Run "burncd -f /dev/acd0 blank eject" on a Compaq nx6320 notebook with FreeBSD 7.0-STABLE installed. I have seen the same problem on 6.x releases.
>Fix:
Applying the attached patch to /usr/src/usr.sbin/burncd/burncd.c solves the problem. It makes burncd attempt to eject the CD five times, sleeping for one second after each unccessful try.

Patch attached with submission follows:

--- burncd.c.orig	2005-05-13 17:06:44.000000000 -0300
+++ burncd.c	2008-05-12 01:44:30.000000000 -0300
@@ -46,6 +46,7 @@
 #include <arpa/inet.h>
 
 #define BLOCKS	16
+#define EJECT_TRIES 5
 
 struct track_info {
 	int	file;
@@ -316,9 +317,13 @@
 		err(EX_IOERR, "ioctl(CDRIOCSETBLOCKSIZE)");
 	}
 
-	if (eject)
-		if (ioctl(fd, CDIOCEJECT) < 0)
+	if (eject) {
+		int status, i = 0;
+		while ((status = ioctl(fd, CDIOCEJECT)) < 0 && ++i <= EJECT_TRIES)
+			sleep(1);
+		if (status < 0)
 			err(EX_IOERR, "ioctl(CDIOCEJECT)");
+	}
 	close(fd);
 	exit(EX_OK);
 }


>Release-Note:
>Audit-Trail:

From: Volker <volker@vwsoft.com>
To: bug-followup@FreeBSD.org, unixmania@gmail.com
Cc:  
Subject: Re: bin/123693: Workaround for burncd: ioctl(CDIOCEJECT): Input/output
 error
Date: Sat, 17 May 2008 21:28:39 +0200

 Carlos,
 
 IMHO it's better to explicitly check for ioctl returning EBUSY and 5
 seconds may not fit every situation.
 
 Volker

From: "Carlos A. M. dos Santos" <unixmania@gmail.com>
To: Volker <volker@vwsoft.com>
Cc: bug-followup@freebsd.org
Subject: Re: bin/123693: Workaround for burncd: ioctl(CDIOCEJECT): Input/output error
Date: Mon, 19 May 2008 09:27:17 -0300

 On Sat, May 17, 2008 at 4:28 PM, Volker <volker@vwsoft.com> wrote:
 > Carlos,
 >
 > IMHO it's better to explicitly check for ioctl returning EBUSY and 5
 > seconds may not fit every situation.
 >
 > Volker
 
 Ok, I will attempt the approach of checking for EBUSY.
 
 -- 
 Carlos A. M. dos Santos

From: "Carlos A. M. dos Santos" <unixmania@gmail.com>
To: Volker <volker@vwsoft.com>
Cc: bug-followup@freebsd.org
Subject: Re: bin/123693: Workaround for burncd: ioctl(CDIOCEJECT): Input/output error
Date: Mon, 26 May 2008 01:21:28 -0300

 ------=_Part_13622_26553487.1211775688368
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline
 
 On Mon, May 19, 2008 at 9:27 AM, Carlos A. M. dos Santos
 <unixmania@gmail.com> wrote:
 > On Sat, May 17, 2008 at 4:28 PM, Volker <volker@vwsoft.com> wrote:
 >> Carlos,
 >>
 >> IMHO it's better to explicitly check for ioctl returning EBUSY and 5
 >> seconds may not fit every situation.
 >>
 >> Volker
 >
 > Ok, I will attempt the approach of checking for EBUSY.
 
 I found that ioctl(fd, CDIOCEJECT) returns EIO, not EBUSY, so it seems
 that there is no better solution. I was able to improve the delays,
 however (see attachmet). Now they grow exponentially, limited to 31
 seconds (1 + 2 + 4 + 8 + 16). This is better than flooding the CD
 drive with one eject request per second.
 
 -- 
 Carlos A. M. dos Santos
 
 ------=_Part_13622_26553487.1211775688368
 Content-Type: application/octet-stream; name=burncd_eject.patch
 Content-Transfer-Encoding: base64
 X-Attachment-Id: f_fgojrct30
 Content-Disposition: attachment; filename=burncd_eject.patch
 
 ZGlmZiAtZHVyUCBidXJuY2Qub3JpZy9idXJuY2QuYyBidXJuY2QvYnVybmNkLmMKLS0tIGJ1cm5j
 ZC5vcmlnL2J1cm5jZC5jCTIwMDUtMDUtMTMgMTc6MDY6NDQuMDAwMDAwMDAwIC0wMzAwCisrKyBi
 dXJuY2QvYnVybmNkLmMJMjAwOC0wNS0yNiAwMDo1MTozMS4wMDAwMDAwMDAgLTAzMDAKQEAgLTQ2
 LDYgKzQ2LDcgQEAKICNpbmNsdWRlIDxhcnBhL2luZXQuaD4KIAogI2RlZmluZSBCTE9DS1MJMTYK
 KyNkZWZpbmUgRUpFQ1RfVFJJRVMgNQogCiBzdHJ1Y3QgdHJhY2tfaW5mbyB7CiAJaW50CWZpbGU7
 CkBAIC0zMTYsOSArMzE3LDE1IEBACiAJCWVycihFWF9JT0VSUiwgImlvY3RsKENEUklPQ1NFVEJM
 T0NLU0laRSkiKTsKIAl9CiAKLQlpZiAoZWplY3QpCi0JCWlmIChpb2N0bChmZCwgQ0RJT0NFSkVD
 VCkgPCAwKQorCWlmIChlamVjdCkgeworCQlpbnQgc3RhdHVzLCB0cnkgPSBFSkVDVF9UUklFUywg
 ZGVsYXkgPSAxOworCQl3aGlsZSAoKHN0YXR1cyA9IGlvY3RsKGZkLCBDRElPQ0VKRUNUKSkgPCAw
 ICYmIC0tdHJ5ID4gMCkgeworCQkJc2xlZXAoZGVsYXkpOworCQkJZGVsYXkgKj0gMjsKKwkJfQor
 CQlpZiAoc3RhdHVzIDwgMCkKIAkJCWVycihFWF9JT0VSUiwgImlvY3RsKENESU9DRUpFQ1QpIik7
 CisJfQogCWNsb3NlKGZkKTsKIAlleGl0KEVYX09LKTsKIH0KT25seSBpbiBidXJuY2Qub3JpZzog
 YnVybmNkLmMub3JpZwo=
 ------=_Part_13622_26553487.1211775688368--

From: "Carlos A. M. dos Santos" <unixmania@gmail.com>
To: Volker <volker@vwsoft.com>
Cc: bug-followup@freebsd.org
Subject: Re: bin/123693: Workaround for burncd: ioctl(CDIOCEJECT): Input/output error
Date: Mon, 26 May 2008 10:01:13 -0300

 ------=_Part_14585_2359284.1211806873200
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline
 
 On Mon, May 26, 2008 at 1:21 AM, Carlos A. M. dos Santos
 <unixmania@gmail.com> wrote:
 > On Mon, May 19, 2008 at 9:27 AM, Carlos A. M. dos Santos
 > <unixmania@gmail.com> wrote:
 >> On Sat, May 17, 2008 at 4:28 PM, Volker <volker@vwsoft.com> wrote:
 >>> Carlos,
 >>>
 >>> IMHO it's better to explicitly check for ioctl returning EBUSY and 5
 >>> seconds may not fit every situation.
 >>>
 >>> Volker
 >>
 >> Ok, I will attempt the approach of checking for EBUSY.
 >
 > I found that ioctl(fd, CDIOCEJECT) returns EIO, not EBUSY, so it seems
 > that there is no better solution. I was able to improve the delays,
 > however (see attachmet). Now they grow exponentially, limited to 31
 > seconds (1 + 2 + 4 + 8 + 16). This is better than flooding the CD
 > drive with one eject request per second.
 
 Resending the patch, since bug-followup seems to expect an explicit
 ".txt" extension in order to display it correctly.
 
 -- 
 Carlos A. M. dos Santos
 
 ------=_Part_14585_2359284.1211806873200
 Content-Type: text/plain; name=patch_v2.txt
 Content-Transfer-Encoding: base64
 X-Attachment-Id: f_fgp2hzxh0
 Content-Disposition: attachment; filename=patch_v2.txt
 
 ZGlmZiAtZHVyUCBidXJuY2Qub3JpZy9idXJuY2QuYyBidXJuY2QvYnVybmNkLmMKLS0tIGJ1cm5j
 ZC5vcmlnL2J1cm5jZC5jCTIwMDUtMDUtMTMgMTc6MDY6NDQuMDAwMDAwMDAwIC0wMzAwCisrKyBi
 dXJuY2QvYnVybmNkLmMJMjAwOC0wNS0yNiAwMDo1MTozMS4wMDAwMDAwMDAgLTAzMDAKQEAgLTQ2
 LDYgKzQ2LDcgQEAKICNpbmNsdWRlIDxhcnBhL2luZXQuaD4KIAogI2RlZmluZSBCTE9DS1MJMTYK
 KyNkZWZpbmUgRUpFQ1RfVFJJRVMgNQogCiBzdHJ1Y3QgdHJhY2tfaW5mbyB7CiAJaW50CWZpbGU7
 CkBAIC0zMTYsOSArMzE3LDE1IEBACiAJCWVycihFWF9JT0VSUiwgImlvY3RsKENEUklPQ1NFVEJM
 T0NLU0laRSkiKTsKIAl9CiAKLQlpZiAoZWplY3QpCi0JCWlmIChpb2N0bChmZCwgQ0RJT0NFSkVD
 VCkgPCAwKQorCWlmIChlamVjdCkgeworCQlpbnQgc3RhdHVzLCB0cnkgPSBFSkVDVF9UUklFUywg
 ZGVsYXkgPSAxOworCQl3aGlsZSAoKHN0YXR1cyA9IGlvY3RsKGZkLCBDRElPQ0VKRUNUKSkgPCAw
 ICYmIC0tdHJ5ID4gMCkgeworCQkJc2xlZXAoZGVsYXkpOworCQkJZGVsYXkgKj0gMjsKKwkJfQor
 CQlpZiAoc3RhdHVzIDwgMCkKIAkJCWVycihFWF9JT0VSUiwgImlvY3RsKENESU9DRUpFQ1QpIik7
 CisJfQogCWNsb3NlKGZkKTsKIAlleGl0KEVYX09LKTsKIH0KT25seSBpbiBidXJuY2Qub3JpZzog
 YnVybmNkLmMub3JpZwo=
 ------=_Part_14585_2359284.1211806873200--

From: "Carlos A. M. dos Santos" <unixmania@gmail.com>
To: Volker <volker@vwsoft.com>
Cc: bug-followup@freebsd.org, "FreeBSD Stable" <freebsd-stable@freebsd.org>
Subject: Re: bin/123693: Workaround for burncd: ioctl(CDIOCEJECT): Input/output error
Date: Sat, 26 Jul 2008 19:04:05 -0300

 On Mon, May 26, 2008 at 1:21 AM, Carlos A. M. dos Santos
 <unixmania@gmail.com> wrote:
 > On Mon, May 19, 2008 at 9:27 AM, Carlos A. M. dos Santos
 > <unixmania@gmail.com> wrote:
 >> On Sat, May 17, 2008 at 4:28 PM, Volker <volker@vwsoft.com> wrote:
 >>> Carlos,
 >>>
 >>> IMHO it's better to explicitly check for ioctl returning EBUSY and 5
 >>> seconds may not fit every situation.
 >>>
 >>> Volker
 >>
 >> Ok, I will attempt the approach of checking for EBUSY.
 >
 > I found that ioctl(fd, CDIOCEJECT) returns EIO, not EBUSY, so it seems
 > that there is no better solution. I was able to improve the delays,
 > however (see attachmet). Now they grow exponentially, limited to 31
 > seconds (1 + 2 + 4 + 8 + 16). This is better than flooding the CD
 > drive with one eject request per second.
 
 Any update on this issue? I'd suggest you to at least close the PR if
 the proposed patch is not acceptable. I must admit that it is only a
 tricky workaround, not a masterpiece, so I will not feel offended. :-)
 
 -- 
 If you think things can't get worse it's probably only
 because you lack sufficient imagination.

From: Alexander Best <alexbestms@math.uni-muenster.de>
To: <bug-followup@FreeBSD.org>
Cc: "Carlos A. M. dos Santos" <unixmania@gmail.com>
Subject: Re: bin/123693: [patch] burncd(8): workaround for busy cd-writer
 while ejecting
Date: Sat, 10 Jan 2009 09:14:29 +0100 (CET)

   This is a MIME encoded multipart message.
 
 --+permail-200901100814296981cf3e00002fba-a_best01+
 Content-Type: text/plain; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 
 i adjusted your patch a bit. now the loop will break if the return value is
 EIO e.g.
 
 alex
 
 --+permail-200901100814296981cf3e00002fba-a_best01+
 Content-Type: text/plain
 Content-Transfer-Encoding: Base64
 Content-Disposition: attachment; filename="burncdeject.patch.txt"
 
 LS0tIHVzci5zYmluL2J1cm5jZC9idXJuY2QuYy5vcmlnCTIwMDktMDEtMDYgMDg6MDA6MzguMDAw
 MDAwMDAwICswMDAwCisrKyB1c3Iuc2Jpbi9idXJuY2QvYnVybmNkLmMJMjAwOS0wMS0xMCAwOTow
 NTo1OC4wMDAwMDAwMDAgKzAwMDAKQEAgLTMyMyw5ICszMjMsMTcgQEAKIAkJZXJyKEVYX0lPRVJS
 LCAiaW9jdGwoQ0RSSU9DU0VUQkxPQ0tTSVpFKSIpOwogCX0KIAotCWlmIChlamVjdCkKLQkJaWYg
 KGlvY3RsKGZkLCBDRElPQ0VKRUNUKSA8IDApCisJaWYgKGVqZWN0KSB7CisJCWludCBlcnJvciwg
 cmV0cmllcyA9IDYsIGRlbGF5ID0gMTsKKwkJd2hpbGUgKChlcnJvciA9IGlvY3RsKGZkLCBDRElP
 Q0VKRUNUKSkgPCAwICYmIHJldHJpZXMtLSA+IDApIHsKKwkJCWlmIChlcnJvciAhPSBFQlVTWSkK
 KwkJCQllcnIoRVhfSU9FUlIsICJpb2N0bChDRElPQ0VKRUNUKSIpOworCQkJc2xlZXAoZGVsYXkp
 OworCQkJZGVsYXkgKj0gMjsKKwkJfQorCQlpZihlcnJvciA8IDApCiAJCQllcnIoRVhfSU9FUlIs
 ICJpb2N0bChDRElPQ0VKRUNUKSIpOworCX0KIAogCXNpZ25hbChTSUdIVVAsIFNJR19ERkwpOwog
 CXNpZ25hbChTSUdJTlQsIFNJR19ERkwpOwo=
 
 --+permail-200901100814296981cf3e00002fba-a_best01+--

From: Jaakko Heinonen <jh@saunalahti.fi>
To: Alexander Best <alexbestms@math.uni-muenster.de>,
	"Carlos A. M. dos Santos" <unixmania@gmail.com>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/123693: [patch] burncd(8): workaround for busy cd-writer
	while ejecting
Date: Tue, 20 Jan 2009 22:00:39 +0200

 Hi,
 
 A similar problem exists if you combine blank and data commands:
 
 # burncd -s max blank data image.iso
 blanking CD - 100 % done     
 burncd: ioctl(CDIOCSTART): Device busy
 
 Thus in my opinion a more generic solution is desired. Possibly the
 correct solution would be to issue ATAPI_TEST_UNIT_READY command until
 the drive reports a ready state. This could be done in kernel or in user
 space.
 
 If done in user space there's the CDIOCRESET ioctl which issues the
 ATAPI_TEST_UNIT_READY command. Here is a patch which implements
 wait_for_ready() function in burncd using the CDIOCRESET ioctl:
 
 --- patch begins here ---
 Index: usr.sbin/burncd/burncd.c
 ===================================================================
 --- usr.sbin/burncd/burncd.c	(revision 187153)
 +++ usr.sbin/burncd/burncd.c	(working copy)
 @@ -65,6 +65,7 @@ void add_track(char *, int, int, int);
  void do_DAO(int fd, int, int);
  void do_TAO(int fd, int, int, int);
  void do_format(int, int, char *);
 +void wait_for_ready(int);
  int write_file(int fd, struct track_info *);
  int roundup_blocks(struct track_info *);
  void cue_ent(struct cdr_cue_entry *, int, int, int, int, int, int, int);
 @@ -219,6 +220,7 @@ main(int argc, char **argv)
  					break;
  				last = pct;
  			}
 +			wait_for_ready(fd);
  			if (!quiet)
  				printf("\n");
  			continue;
 @@ -323,6 +325,8 @@ main(int argc, char **argv)
  		err(EX_IOERR, "ioctl(CDRIOCSETBLOCKSIZE)");
  	}
  
 +	wait_for_ready(fd);
 +
  	if (eject)
  		if (ioctl(fd, CDIOCEJECT) < 0)
  			err(EX_IOERR, "ioctl(CDIOCEJECT)");
 @@ -600,6 +604,27 @@ do_format(int the_fd, int force, char *t
  		fprintf(stderr, "\n");
  }
  
 +void
 +wait_for_ready(int fd)
 +{
 +	int timeout = 10 * 1000;
 +
 +	while (timeout > 0) {
 +		/*
 +		 * CDIOCRESET issues ATAPI_TEST_UNIT_READY command.
 +		 */
 +		if (ioctl(fd, CDIOCRESET) == 0)
 +			return;
 +		else if (errno != EBUSY)
 +			err(EX_IOERR, "ioctl(CDIOCRESET)");
 +
 +		usleep(500 * 1000);
 +		timeout -= 500;
 +	}
 +
 +	errx(EX_IOERR, "timed out while waiting for the drive to become ready");
 +}
 +
  int
  write_file(int fd, struct track_info *track_info)
  {
 --- patch ends here ---
 
 There is apparently a bogus privilege check in atapi-cd.c for CDIOCRESET
 ioctl. It prevents CDIOCRESET to work for non-root users. (Remember that
 ioctls are restricted with device permissions.) So this change is needed
 for CDIOCRESET to work for non-root users:
 
 --- patch begins here ---
 Index: sys/dev/ata/atapi-cd.c
 ===================================================================
 --- sys/dev/ata/atapi-cd.c	(revision 187157)
 +++ sys/dev/ata/atapi-cd.c	(working copy)
 @@ -255,13 +255,7 @@ acd_geom_ioctl(struct g_provider *pp, u_
  	cdp->flags |= F_LOCKED;
  	break;
  
 -    /*
 -     * XXXRW: Why does this require privilege?
 -     */
      case CDIOCRESET:
 -	error = priv_check(td, PRIV_DRIVER);
 -	if (error)
 -	    break;
  	error = acd_test_ready(dev);
  	break;
  
 --- patch ends here ---
 
 Note that if you intend to test these patches on stable/7 (or older) you
 need to backport r187105 (a fix to ata-queue.c) from head. Otherwise the
 CDIOCRESET ioctl doesn't correctly report the busy state. (See
 http://www.freebsd.org/cgi/query-pr.cgi?pr=95979 for more information.)
 
 On 2009-01-10, Alexander Best wrote:
 >  i adjusted your patch a bit. now the loop will break if the return value is
 >  EIO e.g.
 
 > +		while ((error = ioctl(fd, CDIOCEJECT)) < 0 && retries-- > 0) {
 > +			if (error != EBUSY)
 > +				err(EX_IOERR, "ioctl(CDIOCEJECT)");
 
 Alexander: you can't test a value returned from ioctl(2) with EBUSY. You
 should use errno instead of error.
 
 -- 
 Jaakko

From: Alexander Best <alexbestms@wwu.de>
To: <bug-followup@FreeBSD.org>,
 <unixmania@gmail.com>
Cc:  
Subject: Re: bin/123693: [patch] burncd(8): workaround for busy cd-writer
 while ejecting
Date: Mon, 16 Nov 2009 03:18:04 +0100 (CET)

 here is a version of the patch which should apply cleanly to
 HEAD/8-stable/8.0-release:
 
 http://lists.freebsd.org/pipermail/freebsd-current/2009-November/013197.html
 
 alex
>Unformatted:
