RELENG_7: interrupt eating whole cpu core

Peter Jeremy peterjeremy at optushome.com.au
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?

No.

>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 : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080208/1676944a/attachment.pgp


More information about the freebsd-stable mailing list