Kernel Panic booting cdrom

[Michael Ellerman]

On Fri, 2007-04-20 at 14:05 -0700, David Huffman wrote:
> Nathan,
> 
> I think I determined why I received a kernel panic and the numa=off 
> argument fixed the problem. When we boot from cdrom we specify maxcpus=1 
> as a kernel argument. A system with numa enabled fails.  I plan on 
> adding numa=off whenever I use maxcpus=1, but I wonder if you could 
> answer a question for me.
> 
> I originally was told that in the case where I am booting a basic system 
> into an initrd instead of in normal mode, I should use maxcpus=1 because 
> there may be power and cooling daemons that are not running and try to 
> limit the system resources by limiting the number of cpus. Does this 
> sound right? I can successfully boot a cdrom without the maxcpus flag on 
> an SMP system but maybe it is typically not a good idea?
> 
> I can prevent the kernel panics by removing maxcpus=1 and not adding 
> numa=off. I am a little more informed about numa (now), but I am fuzzy 
> as to all the implications with allowing more cpus for cdrom install 
> media. The maxcpus=1 argument was something we added to our install boot 
> media years ago and few here remember why it was such a great idea. The 
> power/resource management was the only thing we could come up with.

maxcpus=x is poorly tested, I would definitely NOT recommend it.

I don't think there's any issue with power etc. With maxcpus=1 all the
other CPUs are still running, they're just not used by the kernel - in
fact a cursory glance suggests they will do less power saving in that
situation than when they're in use but idle.

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/20070423/be2783b7/attachment.pgp>