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! -Maxim 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 > > > >Received on Sat Aug 28 2004 - 12:33:42 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:09 UTC