Date: Sat, 29 Jan 2011 17:05:31 -0600 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Marcel Moolenaar <xcllnt@mac.com> Cc: powerpc@freebsd.org Subject: Re: Beware of revision 218075 Message-ID: <4D449D3B.5050008@freebsd.org> In-Reply-To: <F60BB9A4-E8D8-4DA9-A179-C395B0BFA568@mac.com> References: <550814DC-3E80-401C-B725-BFCB391726DF@mac.com> <4D449504.7030209@freebsd.org> <5C0CFF6E-94C9-43F5-A22F-5A0F6ECC0448@mac.com> <4D4498FF.9050808@freebsd.org> <F60BB9A4-E8D8-4DA9-A179-C395B0BFA568@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
-Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D449D3B.5050008>