Date: Mon, 22 Sep 2008 15:13:03 -0700 From: Maxim Sobolev <sobomax@FreeBSD.org> To: Nathan Whitehorn <nwhitehorn@FreeBSD.org> Cc: freebsd-ppc@FreeBSD.org Subject: Re: Call for testers: Apple ATA DMA Message-ID: <48D8186F.4020308@FreeBSD.org> In-Reply-To: <48D80DDD.2080309@freebsd.org> References: "b9c23c9f0809100322n1659cb36oa05acf2f13f3c7e1@mail.gmail.com" <48D389EE.9000207@FreeBSD.org> <48D3AD50.8070505@freebsd.org> <48D69679.1080701@freebsd.org> <48D7F437.1040603@FreeBSD.org> <48D80DDD.2080309@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------040402000909040405080208 Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit 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 --------------040402000909040405080208--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48D8186F.4020308>