Date: Mon, 22 Sep 2008 12:38:31 -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: <48D7F437.1040603@FreeBSD.org> In-Reply-To: <48D69679.1080701@freebsd.org> References: "b9c23c9f0809100322n1659cb36oa05acf2f13f3c7e1@mail.gmail.com" <48D389EE.9000207@FreeBSD.org> <48D3AD50.8070505@freebsd.org> <48D69679.1080701@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------030600000004000407060205 Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit 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 --------------030600000004000407060205--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48D7F437.1040603>