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