From owner-freebsd-ppc@FreeBSD.ORG Sat Jan 29 23:08:51 2011 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 A2782106566B for ; Sat, 29 Jan 2011 23:08:51 +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 747648FC0A for ; Sat, 29 Jan 2011 23:08:51 +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 <0LFT00C024AROM00@smtpauth3.wiscmail.wisc.edu> for freebsd-ppc@freebsd.org; Sat, 29 Jan 2011 17:08:51 -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 <0LFT00C0H4APMV00@smtpauth3.wiscmail.wisc.edu> for freebsd-ppc@freebsd.org; Sat, 29 Jan 2011 17:08:50 -0600 (CST) Date: Sat, 29 Jan 2011 17:08:49 -0600 From: Nathan Whitehorn In-reply-to: <4D449D3B.5050008@freebsd.org> To: freebsd-ppc@freebsd.org Message-id: <4D449E01.5010107@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.208.68.88 X-Spam-PmxInfo: Server=avs-12, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.1.29.225715, 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 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:08:51 -0000 On 01/29/11 17:05, 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); > } > > Some things (e.g. USB) get interrupts before secondary CPUs come > online. Bind it to a potentially non-primary CPU before SMP is up > causes the interrupt to be lost, stalling boot. I had fixed this when > adding interrupt binding support with the smp_intr_init() callback, > which you have left. Since that's still there, deleting these two > lines shouldn't cause any problems and fixes booting on my xserve. > > 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. I should clarify this. "Breaks" in a future, theoretical sense. The PS3 firmware uses only IRQs 1-64. -Nathan