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

From: Maxim Sobolev (sobomax_at_portaone.com)
Date: 07/31/04

  • Next message: Mike Makonnen: "Re: RFC: Alternate patch to have true new-style rc.d scripts in ports (without touching localpkg)" 
    Date: Sat, 31 Jul 2004 17:51:42 +0300
To: Søren Schmidt <sos@DeepCore.dk>

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

    _______________________________________________
    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: Mike Makonnen: "Re: RFC: Alternate patch to have true new-style rc.d scripts in ports (without touching localpkg)"

    Relevant Pages