From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 17:12:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B63EE16A4CE; Sun, 5 Sep 2004 17:12:34 +0000 (GMT) Received: from web.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08D7E43D2D; Sun, 5 Sep 2004 17:12:34 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.20] (xDSL-2-2.united.net.ua [193.111.9.226]) (authenticated bits=0) by web.portaone.com (8.12.8p2/8.12.8) with ESMTP id i85HCNmE047267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Sep 2004 19:12:26 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <413B48E7.3060403@portaone.com> Date: Sun, 05 Sep 2004 20:12:07 +0300 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <412F85E9.1050004@portaone.com> <412FABA0.3020104@DeepCore.dk> <413097B2.7060802@portaone.com> In-Reply-To: <413097B2.7060802@portaone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: re@FreeBSD.ORG cc: current@FreeBSD.ORG cc: sos@FreeBSD.ORG Subject: Re: ATAPI burners support - significant regression in 5.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2004 17:12:34 -0000 Maxim Sobolev wrote: > 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. Soren, Can you please MFC the change in question? Thanks! -Maxim > > 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 >> >> >> >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > >