Date: Sat, 31 Jul 2004 15:42:32 -0700 From: "Kevin Oberman" <oberman@es.net> To: Maxim Sobolev <sobomax@portaone.com> Cc: =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@DeepCore.dk> Subject: Re: Is there still sufficient reason for hw.ata.atapi_dma being 0 by default? Message-ID: <20040731224232.07E4F5D08@ptavv.es.net> In-Reply-To: Your message of "Sat, 31 Jul 2004 17:51:42 %2B0300." <410BB1FE.7050804@portaone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Sat, 31 Jul 2004 17:51:42 +0300 > From: Maxim Sobolev <sobomax@portaone.com> > Sender: owner-freebsd-current@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@es.net Phone: +1 510 486-8634
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040731224232.07E4F5D08>