From owner-freebsd-ppc@FreeBSD.ORG Sat Jan 29 23:27:46 2011 Return-Path: Delivered-To: powerpc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04E1E106564A for ; Sat, 29 Jan 2011 23:27:46 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id CA0CE8FC13 for ; Sat, 29 Jan 2011 23:27:45 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LFT00E005699H00@smtpauth3.wiscmail.wisc.edu> for powerpc@freebsd.org; Sat, 29 Jan 2011 17:27:45 -0600 (CST) Received: from comporellon.tachypleus.net (adsl-76-208-68-88.dsl.mdsnwi.sbcglobal.net [76.208.68.88]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LFT00CKO567MV00@smtpauth3.wiscmail.wisc.edu>; Sat, 29 Jan 2011 17:27:44 -0600 (CST) Date: Sat, 29 Jan 2011 17:27:43 -0600 From: Nathan Whitehorn In-reply-to: To: Marcel Moolenaar Message-id: <4D44A26F.1070701@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.208.68.88 X-Spam-PmxInfo: Server=avs-11, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.1.29.231515, SenderIP=76.208.68.88 References: <550814DC-3E80-401C-B725-BFCB391726DF@mac.com> <4D449504.7030209@freebsd.org> <5C0CFF6E-94C9-43F5-A22F-5A0F6ECC0448@mac.com> <4D4498FF.9050808@freebsd.org> <4D449D3B.5050008@freebsd.org> User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101214 Thunderbird/3.1.7 Cc: powerpc@freebsd.org Subject: Re: Beware of revision 218075 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: Sat, 29 Jan 2011 23:27:46 -0000 On 01/29/11 17:18, Marcel Moolenaar wrote: > On Jan 29, 2011, at 3:05 PM, Nathan Whitehorn wrote: > >> On 01/29/11 16:58, Marcel Moolenaar wrote: >>> On Jan 29, 2011, at 2:47 PM, Nathan Whitehorn wrote: >>> >>>> On 01/29/11 16:38, Marcel Moolenaar wrote: >>>>> On Jan 29, 2011, at 2:30 PM, Nathan Whitehorn wrote: >>>>> >>>>>>> I'll be causing some more churn in the coming weeks, but that >>>>>>> should be mostly related to the FDT support and as such should not >>>>>>> impact any powerpc platforms other than mpc85xx. >>>>>>> >>>>>> I would really have appreciated a heads up and a chance to test this before it went into the tree. I would also note that you appear well on your way to duplicating all the PCI logic in /sys/powerpc/ofw, and that unifying OFW/FDT, since they are the same thing, would probably save a lot of pain down the road. >>>>> Yes, unification between FDT and OFW is on my mind. However, I first >>>>> need FDT to work well before I can unify. Unifying powerpc with arm >>>>> is the first step. >>>> Understood. Also, G5 machines are totally broken by your commit. >>> Ok. What exactly is broken? >> It's actually not G5 machines, but SMP machines. The problem is this part of the commit: >> >> Index: intr_machdep.c >> =================================================================== >> --- intr_machdep.c (revision 218074) >> +++ intr_machdep.c (revision 218075) >> @@ -373,6 +426,9 @@ >> i->pol != INTR_POLARITY_CONFORM) >> PIC_CONFIG(i->pic, i->intline, i->trig, i->pol); >> >> + if (i != NULL&& i->pic == root_pic) >> + PIC_BIND(i->pic, i->intline, i->cpu); >> + >> if (i->event != NULL) >> PIC_ENABLE(i->pic, i->intline, vector); >> } > > That can be reverted without harm AFAICT. One of my earlier > changes removed the SYSINIT to do the binding and instead do > it here. I partially reverted that (i.e. the SYSINIT is > still there, but the change above remained), because I didn't > know the consequence of such a change. I've reverted it in r218081. Everything seems OK now. >> The "max IRQ = 128" thing also likely breaks Cell systems, like the PS3, where the PIC has 256 interrupts, but I haven't looked into that in detail yet. > This is where we need to implement multiple passes. I tried to > do that in the same commit, but ended up with a lot more > churn than I was comfortable handling. But ideally, we probe > busses and interrupt controllers first, so that we don't have > this problem -- all interrupt controllers will have registered > before we need to map from PIC+pin to IRQ. > > There's probably a quick fix in case it's broken. If the pin > is higher than the number of IRQs we have recorded for the PIC, > we can simply bump the number of irqs the PIC has (i.e. extend > the IRQ range assigned to the PIC). Unless we have other PICs > recorded this can always be done -- since the PS3 only has 1 > PIC, this should be a quick kluge to get it working again. Ah, OK. My PS3 seems to boot fine, so don't worry about it. Good luck navigating through the rest of this minefield! -Nathan