Date: Mon, 22 Sep 2008 23:27:57 +0200 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: freebsd-ppc@FreeBSD.org Subject: Re: Call for testers: Apple ATA DMA Message-ID: <48D80DDD.2080309@freebsd.org> In-Reply-To: <48D7F437.1040603@FreeBSD.org> References: "b9c23c9f0809100322n1659cb36oa05acf2f13f3c7e1@mail.gmail.com" <48D389EE.9000207@FreeBSD.org> <48D3AD50.8070505@freebsd.org> <48D69679.1080701@freebsd.org> <48D7F437.1040603@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48D80DDD.2080309>