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:

quoted

On Tue, 2007-03-06 at 19:27 +0530, Mohan Kumar M wrote:

quoted

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