Call for testers: Apple ATA DMA

[Nathan Whitehorn]

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 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.
-Nathan