Bug 30536

Summary:	burncd(8) doesn't wait long enough for CD-R's burning at high speed to spin down before trying to fixate the CD.
Product:	Base System	Reporter:	Farooq Mela <fmela0>
Component:	misc	Assignee:	Søren Schmidt <sos>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	Unspecified
Hardware:	Any
OS:	Any

Description Farooq Mela 2001-09-12 22:00:02 UTC

While burning a CD-R at a 10x or 12x, burncd(8) does not wait long
enough for the CD to spin down as soon as the burn is completed before
issuing a fixate command. For example:

# burncd -f /dev/acd1c -s 12 data file.iso fixate

will burn the ISO image to the CD just fine, but for whatever reason
(I believe it is because the CD is still spinning because this problem
never occurs while burning at lower speeds - however I'm no expert in
this matter), the CD-R is not yet ready to fixate the cd when burncd
issues the fixate command, and then burncd errors out and exits without
fixating the cd.

Fix: 

To fix the problem, I made a simple change to /usr/src/usr.bin/burncd.c
so that it tries 5 times to fixate the CD-R, with pauses in between.
This fixes the problem on my system, however there may be different
pause lengths or number of retries that are better for everybody else.

The patch is available at:
http://home.earthlink.net/~smela1/burncd.patch
How-To-Repeat: dmesg reports this for my Pacific Digital 12x CD-R

acd1: CD-RW <LITE-ON LTR-12102C> at ata1-slave using PIO4

Issue the following command:

# burncd -f /dev/acd1c -s 12 data file.iso fixate

where acd1c is your CD-R and file.iso is an ISO image. On my system it
usually happens that burncd will fail when trying to do an
ioctl(cd_fd, CDRIOCCLOSEDISK) with errno=EBUSY.

Comment 1 Søren Schmidt freebsd_committer

2001-09-13 12:22:23 UTC

Responsible Changed
From-To: freebsd-bugs->sos

The problem is not that burncd doesn't wait long enough (and no there is 
no need to wait for a spin down, on the contrary, the fixate part writes 
to the disk and needs it to spin), the problem is that some drives  
returns good status before actually being done with the command in 
progress. This has been dealt with in -current, but that part has 
not been MFC'd due to other implications.

Comment 2 Søren Schmidt freebsd_committer

2002-05-01 13:21:28 UTC

State Changed
From-To: open->closed

This is believed fixed in -stable