ATAPI burners support - significant regression in 5.x

Maxim Sobolev sobomax at
Sat Aug 28 07:33:42 PDT 2004

Indeed, the problem appears to be finally fixed - I can't reproduce it 
anymore. At least I've been burning one of my 24x RWs in a loop during 
the past 2 hours without any problems.

Please don't forget to do MT5 after several days.

Thank you very much!


Søren Schmidt wrote:

> Maxim Sobolev wrote:
>> I've noticed that quality of support for ATAPI CD burners in 5.x has 
>> degraded significantly. Often when burning CD-RW (I have not 
>> experimented on CD-Rs for obvious reasons), burncd hangs in the 
>> middle, without any error messages. When it happens it doesn't respond 
>> to SIGKILL, eject button doesn't work and the only way to recover form 
>> this situation without reboot is to run atacontrol reinit. I've tested 
>> 3 different CD-RW devices on 3 different machines (2 runnning RELENG_5 
>> and one running RELENG_5_2), and the same problem exists on all of 
>> them. All machines were idle during my experiments.
>> The easy way to reproduce this problem is to create some dummy iso 
>> image (e.g. dd if=/dev/random of=/tmp/tmp.iso bs=1m count=650), put 
>> blank CD-RW medium into the burner and then run something along the 
>> lines:
>> while true; do time burncd -s max data /tmp/tmp.iso; burncd -s max 
>> fixate; burncd -s max blank; sleep 5; done
>> I've tried RW mediums with various speed ratings: 2x-4x, 4x-12x, 
>> 16x-24x the problem happens with all of them. It also makes no 
>> difference whether the medium is new or used.
>> Turning DMA on or off doesn't solve the problem either.
>> All is matter of time - sooner or later burncd hangs solidly, usually 
>> 30 minutes is enough to reproduce the problem.
>> IMHO it is quite significant problem that have to be addressed before 
>> the 5.3 is out. At least if I am not correct and the problem happens 
>> due to  problems with particular CD-RW devices, ata driver has to be 
>> "smarter" to recover from such situation gracefully, returning error 
>> code and leaving device in the useable position.
> Does this happen on an up to date -current ? I'm pretty sure I fixed 
> this some time ago, but I could be wrong as I was only able to reproduce 
> this ecactly once. The problem was a race in ata_start where it could 
> loose a request. The only way to get it back "online" was to get 
> ata_start called again by fx issueing a command though another channel 
> (ioctl, atapicam).
> -Søren

More information about the freebsd-current mailing list