Re: ATAPI burners support - significant regression in 5.x

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