From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 06:21:59 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD55E16A4D4; Tue, 9 Dec 2003 06:21:59 -0800 (PST) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id E815243D4A; Tue, 9 Dec 2003 06:21:57 -0800 (PST) (envelope-from lefcha@hellug.gr) Received: from igloo.linux.gr (IDENT:1031@localhost [127.0.0.1]) hB9EYfkh019742; Tue, 9 Dec 2003 16:35:01 +0200 Received: (from lefcha@localhost) by igloo.linux.gr (8.12.10/8.12.10/Debian-2) id hB9EYQV7019721; Tue, 9 Dec 2003 16:34:26 +0200 X-Authentication-Warning: igloo.linux.gr: lefcha set sender to lefcha@hellug.gr using -f Date: Tue, 9 Dec 2003 16:34:26 +0200 From: Lefteris Chatzibarbas To: Scott Long Message-ID: <20031209143426.GA19683@igloo.linux.gr> References: <20031206174859.GA22714@igloo.linux.gr> <20031206175502.GB95786@cnd.mcgill.ca> <3FD230C3.1090205@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: <3FD230C3.1090205@freebsd.org> User-Agent: Mutt/1.5.4i cc: freebsd-current@freebsd.org Subject: Re: burncd(8) CD-RW blanking problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2003 14:22:00 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Dec 06, 2003 at 12:40:51PM -0700, Scott Long wrote: > Mathew Kanner wrote: > >On Dec 06, Lefteris Chatzibarbas wrote: > >>The pct variable is always 0, even after the blanking of the CD-RW is > >>finished (according to the device's LEDs), so the program falls into an > >>infinite loop. > > > > I have the exact same problem. It stays stuck in the loop > >because ioctl(fd, CDRIOGETPROGRESS, &pct) pct is always 0. > > I'm seeing this too. What's odd is that my cd drive is reporting back > incorrect sense information; the valid bit is not set, the asc/ascq is > suspect (4/8), and the sense key specific data is all 0. Since other > fields in the sense data are reasonable, it's not as if no sense data is > being returned at all. So it looks like the CDRIOGETPROGRESS ioctl > handler is doing the right thing, but the cd drive is not. Maybe the > driver is doing something wrong when it issues the erase command, but > I can't convince myself that that is likely. The attached patch seems to correct the problem (at least for me). It is similar to what was done in revision 1.137 of sys/dev/ata/atapi-cd.c (this has been changed since revision 1.138). --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-atapi-cd.c" --- sys/dev/ata/atapi-cd.c.orig Tue Dec 9 13:43:57 2003 +++ sys/dev/ata/atapi-cd.c Tue Dec 9 15:50:33 2003 @@ -1524,7 +1524,12 @@ struct atapi_sense sense; int8_t dummy[8]; - ata_atapicmd(cdp->device, ccb, dummy, sizeof(dummy), ATA_R_READ, 30); + if (ata_atapicmd(cdp->device, ccb, dummy, sizeof(dummy), ATA_R_READ, 30) + != EBUSY) { + *finished = 100; + return 0; + } + acd_request_sense(cdp->device, &sense); if (sense.sksv) --0OAP2g/MAC+5xKAE--