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

From: Chuck Swiger (cswiger_at_mac.com)
Date: 07/30/04

  • Next message: Michael Nottebrock: "Funky compile error with new gcc" 
    Date: Fri, 30 Jul 2004 15:46:45 -0400
To: Søren Schmidt <sos@DeepCore.dk>

    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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
  • Next message: Michael Nottebrock: "Funky compile error with new gcc"

    Relevant Pages