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