From owner-freebsd-ppc@FreeBSD.ORG Mon Sep 22 19:38:33 2008 Return-Path: Delivered-To: freebsd-ppc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A5951065676; Mon, 22 Sep 2008 19:38:33 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 1EB3E8FC1E; Mon, 22 Sep 2008 19:38:32 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.61] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m8MJcUOk085099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 12:38:31 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <48D7F437.1040603@FreeBSD.org> Date: Mon, 22 Sep 2008 12:38:31 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Nathan Whitehorn References: "b9c23c9f0809100322n1659cb36oa05acf2f13f3c7e1@mail.gmail.com" <48D389EE.9000207@FreeBSD.org> <48D3AD50.8070505@freebsd.org> <48D69679.1080701@freebsd.org> In-Reply-To: <48D69679.1080701@freebsd.org> Content-Type: multipart/mixed; boundary="------------030600000004000407060205" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-ppc@FreeBSD.org Subject: Re: Call for testers: Apple ATA DMA X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2008 19:38:33 -0000 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: mem 0xf5004000-0xf5007fff irq 39,1 at device 13.0 on pci2 ata1: [ITHREAD] ad0: 38154MB at ata1-master UDMA100 acd0: DVDR 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: mem 0xf5004000-0xf5007fff irq 39,1 at device 13.0 on pci2 ata0: [ITHREAD] ad0: 38154MB at ata0-master UDMA100 acd0: DVDR 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--