From owner-freebsd-stable@FreeBSD.ORG Wed Dec 27 01:33:22 2006 Return-Path: X-Original-To: stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1AD9316A403; Wed, 27 Dec 2006 01:33:22 +0000 (UTC) (envelope-from sos@deepcore.dk) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.freebsd.org (Postfix) with ESMTP id 8C72C13C474; Wed, 27 Dec 2006 01:33:21 +0000 (UTC) (envelope-from sos@deepcore.dk) Received: from [194.192.25.137] (ws.deepcore.dk [194.192.25.137]) by spider.deepcore.dk (8.13.8/8.13.8) with ESMTP id kBR1XGAu025263; Wed, 27 Dec 2006 02:33:20 +0100 (CET) (envelope-from sos@deepcore.dk) Message-ID: <4591CD5B.4090005@deepcore.dk> Date: Wed, 27 Dec 2006 02:33:15 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Luigi Rizzo References: <20061221092717.A6431@xorpc.icir.org> <20061222073857.GA10704@tmn.ru> <20061225165735.M22401@atlantis.atlantis.dp.ua> <20061225084704.A23448@xorpc.icir.org> <4590066B.8050604@samsco.org> <20061226064831.B48751@xorpc.icir.org> In-Reply-To: <20061226064831.B48751@xorpc.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: stable@FreeBSD.ORG, sos@FreeBSD.ORG Subject: Re: [summary] Re: burncd 'blank' not terminating ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2006 01:33:22 -0000 Luigi Rizzo wrote: > summary: there was some discussion on how to > fix the problem, in 6.x, with "burncd -f /dev/acd0 -v blank" getting > stuck with this message > > blanking CD, please wait.. > > This used to work on 4.x. > > 6.x changes in two places: > > * the ioctl handler, acd_get_progress() in /sys/dev/ata/atapi-cd.c > does a much stricter error checking, expecting the ATA_SENSE_VALID > bit set in response to the ATAPI_READ_CAPACITY call. > None of my DVD drives do that: > > acd0: DVDR at ata1-master UDMA33 > acd0: DVDR at ata0-slave UDMA33 > > even though they do report a valid progress status if you disable > the check for ATA_SENSE_VALID, and in fact they do work under 4.x > > * usr.sbin/burncd/burncd.c waits for a transition of CDRIOCGETPROGRESS > from 90..99 to 0, which fails to be detected because the ioctl() > always returns 0 when ATA_SENSE_VALID is not set. > > In private mail, Soren mentioned that the spec (whatever it is called) > says that the ATA_SENSE_VALID 'shall be set' when returning a valid value, > so he is slightly dubious on removing the check in atapi-cd.c > > Also, it seems that the proper way to check for completion is to issue > the TEST UNIT READY command, which is accessible through the CDIOCRESET > ioct. > > I suggest the following two fixes: > 1. change burncd.c as below, so that if CDRIOCGETPROGRESS does not return > anything good, it calls CDIOCRESET to determine when the command > is complete. > This can be improved by calling CDIOCRESET unconditionally as a > termination test > FWIW just checking with TEST UNIT READY in general for progress will fail for lots of devices, but it might be that those have prober progress reporting so the sum of doing both is of benefit. > 2. change atapi-cd.c to return something even if ATA_SENSE_VALID is > unset. Apparently there is a lot of non-complying hardware around > so restricting to what the spec says is like shooting ourselves > in the foot. > As I mentioned lots of devices does return garbage there so its more a question on which pool of devices you want to have working and which you wont, so its not a solution, rather a decision on which devices to support properly, I chose those that follow specs. > Again, if burncd.c uses CDIOCRESET to determine the completion > of the 'blank' operation, we don't care if the return value from > CDRIOCGETPROGRESS is incorrect, because we don't rely on it. > Right, but that will leave out reporting of progress which has been asked for lots of times since some of this takes time. As usual there is no easy solution, its a question on which devices work and which wont, and that unfortunatly changes over time... -Søren