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

> Date: Sat, 31 Jul 2004 17:51:42 +0300
> From: Maxim Sobolev <sobomax_at_portaone.com>
> Sender: owner-freebsd-current_at_freebsd.org
> 
> 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,

There is a known issue with DVD drives locking up like this in
current. I know that Nate Lawson and Søren are aware of the problem and
at least Nate has experienced it. (I'm not sure if Søren has seen it,
though.) It is happening with read access. I had not seen it on write,
but it is certainly possible. 

I don't think that this is related to DMA issues as it only appeared in
CURRENT earlier this year. I don't think STABLE has the problem.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman_at_es.net			Phone: +1 510 486-8634