From owner-freebsd-ppc@FreeBSD.ORG Mon Sep 22 23:06:07 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 DBB09106566C for ; Mon, 22 Sep 2008 23:06:07 +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 89BA48FC16 for ; Mon, 22 Sep 2008 23:06:07 +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 m8MN65ba095453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 16:06:06 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <48D824E1.1030109@FreeBSD.org> Date: Mon, 22 Sep 2008 16:06:09 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Marco Trillo References: <48D389EE.9000207@FreeBSD.org> <48D3AD50.8070505@freebsd.org> <48D69679.1080701@freebsd.org> <48D7F437.1040603@FreeBSD.org> <48D80DDD.2080309@freebsd.org> <48D8186F.4020308@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 23:06:07 -0000 Marco Trillo wrote: > Hi, > > On Tue, Sep 23, 2008 at 12:13 AM, Maxim Sobolev wrote: >>>> 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. > > Try deleting the USE_DBDMA_IRQ definition line from ata_macio.c > instead of just defining it to 0, so the "ifdef USE_DBDMA_IRQ" stuff > is not compiled. Yes, you are right. There are few unused variables in such case, though: cc1: warnings being treated as errors ../../../powerpc/powermac/ata_macio.c: In function 'ata_macio_attach': ../../../powerpc/powermac/ata_macio.c:206: warning: unused variable 'cookie' ../../../powerpc/powermac/ata_macio.c:205: warning: unused variable 'dbdma_irq' ../../../powerpc/powermac/ata_macio.c:204: warning: unused variable 'dbdma_irq_rid' *** Error code 1 If I ifdef them the kernel compiles and when booted there interrupt storm no longer happens. ata0 mem 0x20000-0x20fff,0x8800-0x88ff irq 24,12 on macio0 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 Just curious, what's the purpose of that ata0? Is it real device or some compatibility shim? -Maxim