Is there still sufficient reason for hw.ata.atapi_dma being 0 by default?

[Maxim Sobolev]

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
> 
> 
>