From owner-freebsd-current@FreeBSD.ORG Sat Jul 31 14:52:44 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 1993C16A4CE for ; Sat, 31 Jul 2004 14:52:44 +0000 (GMT) Received: from web.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3344A43D67 for ; Sat, 31 Jul 2004 14:52:43 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.20] (portacare.portaone.com [195.140.247.242]) (authenticated bits=0) by web.portaone.com (8.12.8p2/8.12.8) with ESMTP id i6VEq5Wq020084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jul 2004 16:52:06 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <410BB1FE.7050804@portaone.com> Date: Sat, 31 Jul 2004 17:51:42 +0300 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <410A3833.7030502@portaone.com> <410A47C7.1080808@DeepCore.dk> <410A9B58.8000502@mac.com> <410A9D77.4030703@DeepCore.dk> In-Reply-To: <410A9D77.4030703@DeepCore.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: Chuck Swiger cc: current@freebsd.org Subject: Re: Is there still sufficient reason for hw.ata.atapi_dma being 0 by default? 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: Sat, 31 Jul 2004 14:52:44 -0000 Søren Schmidt wrote: > Chuck Swiger wrote: > >> Søren Schmidt wrote: >> >>> Maxim Sobolev wrote: >>> >>>> Since high-speed CD-RW/DVD-RW recorders (32x - 52x) are commodity >>>> now IMO it makes sense to review hw.ata.atapi_dma default of 0, >>>> since apparently PIO mode can't support necessary sustained data >>>> transfer rates anymore. For example I had had problems burning RWs >>>> on 16-24x with several drives in PIO mode, which gone when I've >>>> switched to DMA. >> >> >> >> Before CD burners became common, having this sysctl default to zero >> was almost entirely harmless: people would simply read from CD-ROM >> drives slower than optimal. If we change the default to one, people >> with fast burners will no longer generate coasters by default too. In >> other words, Maxim has provided a pretty good reason for changing the >> default of atapi_dma, I think. :-) > > > Actually not, most if not all modern fast burners implements some sort > of "burn proof" ie no coasters at all due to buffer underruns... Actually it was not looking like underruns. I had weird problems burning RWs at 24x in PIO with three different burners - the burncd process just hanged solidly at random position, only atacontrol reinit helped. Machine was 100% idle (Celeron 2.4GHz). Switching to DMA33 solved the problem. -Maxim > >>> Hmm, things are still messy, but most drives that support UDMA33 can >>> do ATAPI dma. However, that is only part of the equation, the chipset >>> has its hands in there as well, and unfortunatly there seems to be no >>> good way to detect when it works and when it doesnt. >> >> >> >> If the chipset is broken, why doesn't it default to using PIO4 rather >> than UDMA? :-) Anyway, doesn't there exist fallback code in >> dev/ata/ata-disk.c: >> >> /* if this is a UDMA CRC error, reinject request */ >> [ ... ] >> printf(" falling back to PIO mode\n"); >> >> ...which will switch a device generating errors from UDMA mode to >> PIO? Can this check also turn off using atapi_dma (if using PIO >> doesn't already imply not using DMA)? > > > Not really, the problem with ATAPI dma is that if it fails it most > likely locks up the machine, so there is no way to back pedal... > > -Søren > > >