Date: Fri, 30 Jul 2004 21:11:51 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@DeepCore.dk> To: Chuck Swiger <cswiger@mac.com> Cc: release@freebsd.org Subject: Re: Is there still sufficient reason for hw.ata.atapi_dma being 0 by default? Message-ID: <410A9D77.4030703@DeepCore.dk> In-Reply-To: <410A9B58.8000502@mac.com> References: <410A3833.7030502@portaone.com> <410A47C7.1080808@DeepCore.dk> <410A9B58.8000502@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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...
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?410A9D77.4030703>