RELENG_7: interrupt eating whole cpu core
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 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.
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
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