RELENG_7: interrupt eating whole cpu core

Peter Jeremy peterjeremy at
Fri Feb 8 20:41:11 UTC 2008

On Fri, Feb 08, 2008 at 12:22:38AM -0200, Carlos A. M. dos Santos wrote:
>Wow, now I'm *really* surprised. I used to think that putting
>     hw.ata.ata_dma="1"
>     hw.ata.atapi_dma="1"

hw.ata.ata_dma has no effect on ATAPI devices.

>in /boot/loader.conf would be enough to enable DMA mode.

Looking at the code, atapi_dma will enable UDMA modes if the drive
supports at least UDMA2 them but ignores WDMA capabilities.  This was
part of the ATA mkIII update - which is in 6.x but was not MFC'd to
5.x.  If you do a verbose boot, you will get a probe line reporting
the drive capabilities.  Unfortunately, atacontrol only reports 'dma
[not] supported' - not what capabilities the drive has.

>1. Is this related to using atapicam?


>2. Should this be considered a bug?

Possibly.  The relevant commit message doesn't mention the ATAPI DMA
changes so it's not clear whether this is an oversight or deliberate.

I do recall that there have been problems in the past with ATAPI
drives that would advertise DMA capabilities but would misbehave if
you used DMA (atapi_dma was disabled by default in 5.x for this
reason).  I'm not sure if the current code is at effort to avoid this.

Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :

More information about the freebsd-stable mailing list