Call for testers: Apple ATA DMA
Maxim Sobolev
sobomax at FreeBSD.org
Mon Sep 22 22:13:02 UTC 2008
Nathan Whitehorn wrote:
> Maxim Sobolev wrote:
>>>
>>> I now have UDMA modes working on my Shasta controller -- there was a
>>> stupid bug where I forgot to set the device to accept transfers in
>>> the selected mode. Please give this patch a test: I expect that UDMA
>>> modes now work everywhere.
>>>
>>> http://people.freebsd.org/~nwhitehorn/apple-ata-dma.patch
>>
>> Nathan,
>>
>> The patch works here (G4 Mac Mini, 1.25GHz), however, I see some weird
>> things happening in the interrupt domain. Particularly, according to
>> the vmstat(8) ata0 device, which has no disks attached to it,
>> generates large number of interrupts, about 1,500 in the idle state
>> when no disk activity is in progress, and more than 100K (sic!) when I
>> am running buildworld. At the same time, ata1 doesn't generate any
>> interrupts at all. As a result, the system spends half of its time
>> servicing those interrupts, so that UDMA mode is not very usable yet.
>> See 341.png screenshot. Dmesg is below:
> Thanks for testing! So ata1 generates no interrupts? Or does it just
> generate a number << ata0?
I have looked at the vmstat output closely and it appears that ata1
actually generates interrupts, just much less number of them than ata0.
In fact I think that number if interrupts generated by ata1 during
buildworld is roughly the same with or without ata_macio enabled.
>> I was able to "fix" the problem by making ata_macio probe function
>> returning ENXIO always. My guess is that ATA chipset on this machine
>> is somehow accessible through two different buses (macio and pci),
>> which creates some weird conflicts, but I might be wrong. Hopefully
>> you will have better idea, I can provide any assistance needed to fix
>> the issue properly. See 342.png screenshot. Dmesg with hacked
>> ata_macio is as follows:
> Interesting -- it looks like all the interrupts are arriving on the
> second (DBDMA) IRQ. Could you try setting USE_DBDMA_IRQ to 0 in
> ata_macio.c and re-enabling ata_macio? There is something funny with how
> these interrupts are triggered currently and they can set off interrupt
> storms like this.
I've done that, but it has not changed anything. I still see interrupt
storm on irq 12.
Please let me know if you want me to make any other changes and re-test.
-Maxim
More information about the freebsd-ppc
mailing list