Date: Fri, 27 Aug 2004 23:46:08 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@DeepCore.dk> To: Maxim Sobolev <sobomax@portaone.com> Cc: sos@FreeBSD.ORG Subject: Re: ATAPI burners support - significant regression in 5.x Message-ID: <412FABA0.3020104@DeepCore.dk> In-Reply-To: <412F85E9.1050004@portaone.com> References: <412F85E9.1050004@portaone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?412FABA0.3020104>