Call for testers: Apple ATA DMA

[Maxim Sobolev]

Nathan Whitehorn wrote:
> Nathan Whitehorn wrote:
>> Maxim Sobolev wrote:
>>> Nathan,
>>>
>>> Do you have any news regarding the patch in question? I hope you did 
>>> not give up, the lack of ATA DMA support is IMHO probably the biggest 
>>> issue for the FreeBSD on PowerMacs now. The hardware is very 
>>> attractive for SOHO applications, so that having this feature is 
>>> important.
>> Right now, modes up to WDMA2 work. The UDMA modes cause hangs for 
>> reasons not entirely clear. I'm investigating it, but am in the 
>> Netherlands at the moment and it will have to wait until I get back.
> 
> 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:

ata0 mem 0x20000-0x20fff,0x8800-0x88ff irq 24,12 on macio0
ata0: [ITHREAD]
ata0: [ITHREAD]
ata1: <Intrepid Kauai ATA Controller> mem 0xf5004000-0xf5007fff irq 39,1 
at device 13.0 on pci2
ata1: [ITHREAD]
ad0: 38154MB <TOSHIBA MK4025GAS KA100P> at ata1-master UDMA100
acd0: DVDR <MATSHITACD-RW CW-8123/CAD4> at ata1-slave UDMA33

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:

ata0: <Intrepid Kauai ATA Controller> mem 0xf5004000-0xf5007fff irq 39,1 
at device 13.0 on pci2
ata0: [ITHREAD]
ad0: 38154MB <TOSHIBA MK4025GAS KA100P> at ata0-master UDMA100
acd0: DVDR <MATSHITACD-RW CW-8123/CAD4> at ata0-slave UDMA33

I should also mention that second boot of 8.0 kernel has fixed that time 
offset issue. Therefore, it seems that the 7.1 kernel doesn't sync RTC 
timer to current time correctly.

Thanks, please keep doing. I look forward to seeing your work going to 
the main tree.

-Maxim