Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 30 Jul 2004 15:46:45 -0400
From:      Chuck Swiger <cswiger@mac.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:  <410AA5A5.4000001@mac.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:
[ ... ]
>> 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...

You're right that truly modern fast burners ought to implement "justlink" or 
"burn proof".  However, I don't think it's a good idea to depend on the burner 
to be able to handle underruns; I'd rather run CD/DVD burners using UDMA.

[ FWIW, I've got a 16/10/40x Yamaha burner which just predates the first 
generation of burners with underrun protection-- this affects me directly. ]

[ ... ]
>> ...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...

Oh.  Ewww.  Could chipsets which do that be added to a "quirks" table similar 
to the way USB devices are being handled?  Or is it not just the chipset, but 
some more complex interaction between ATAPI DMA and other devices in the 
system which want to do DMA which causes the lockup?

-- 
-Chuck



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?410AA5A5.4000001>