[Fastboot] [PATCH] Fix interrupt distribution in ppc970

Michael Ellerman michael at ellerman.id.au
Wed Mar 7 21:46:31 EST 2007


On Wed, 2007-03-07 at 11:36 +0530, Vivek Goyal wrote:
> On Tue, Mar 06, 2007 at 03:16:55PM +0100, Michael Ellerman wrote:
> > On Tue, 2007-03-06 at 19:27 +0530, Mohan Kumar M wrote:
> > > Hi,
> > > 
> > > Here comes the revised version of patch to fix the interrupt missing
> > > problem when a kdump kernel is booted with "maxcpus=1" kernel parameter.
> > > 
> > > In the xics initialization code a check is made to detemine whether
> > > maxcpus kernel parameter is present and if its present then
> > > default_distrib_server variable is initialized to the current boot cpu
> > > id (by default_server variable). So that when ever a kernel is booted
> > > with maxcpus kernel parameter all interrupts are routed to the boot cpu
> > > only.
> > > 
> > > Tested on POWER5 and JS20 systems.
> > 
> > First, I don't know why we keep telling people to use maxcpus=1 for
> > kexec/kdump - it's causing bugs, and I don't know of any that it fixes?
> > 
> 
> Logically speaking, there is no need to bring up all the cpus in the
> system to capture the dump. A single cpu can do the job, may be in
> relatively lesser memory. Just because we see bugs with maxcpus=1, does
> not mean we should try to bring up all the cpus in second kernel. I think
> we should try to clean maxcpus=1 path instead.

Sure it'd be nice. But in reality I think the memory reductions are
miniscule, it's still an SMP kernel, it still allocates per-cpu data for
every cpu, they're still spinning. The only thing that maxcpus does is
not bring them online ... and cause lots of bugs.

But the distros have made the call, so I'll just shutup now :)

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20070307/19f9b3f8/attachment.pgp>


More information about the Linuxppc-dev mailing list