David, this doesn't look like it's going to be easy.
I added the printk() statement, and recompiled the kernel using
make-kpkg. This tree is exactly the same as the earlier one, except
for the new printk() statement.
*Two seperate* compiles from this tree have failed to boot on our U30
(my test box - I don't want to reboot our production server with the
new kernel until I know it works).
The U30 loads SILO without a problem, and SILO can uncompress the
kernel. As soon as it gets to 'Loading Linux...', it simply stops.
Keyboard stops responding, nothing more on the screen, etc.
This is bizarre. I can't seem to figure out why these two compiles
fail to boot, while the first compile (with your original patch)
worked. No errors from what I can see during compilation.
Any ideas?
On Tue, Apr 19, 2005 at 12:45:04PM -0700, David S. Miller said:
> On Tue, 19 Apr 2005 15:40:27 -0400
> Mike Edwards <sauron-debian-sparc@psychology.rutgers.edu> wrote:
>
> > Erk. Can you give me a patch for that, or, at the very least, tell me
> > what to modify? My C is rusty.
>
> Make mm/page_alloc.c:__get_free_pages() do something like this:
>
> page = alloc_pages(gfp_mask, order);
> if (!page) {
> if (order > 0)
> printk("DEBUG: __get_free_pages() order %d failed "
> "called by %p\n",
> order, __builtin_return_address(0));
> return 0;
> }
>
> > As it is, I'm going to have to reboot this box in any case. Can you
> > think of a reason why an SMP kernel on a dual processor E450 only
> > started one processor at boot time? (Yes, openprom sees both
> > processors, and the old kernel had no problem with them, either).
>
> Make sure CONFIG_NR_CPUS is set large enough.
>
> It must be at least as large as the largest "physical cpu number"
> of all the cpus in your machine. The physical numbering is not
> necessarily linear, it can be "0 2 4 6" or similar for a 4-cpu
> machine, for example.
>
--
Mike Edwards <sauron-debian-sparc@psychology.rutgers.edu>
System Administrator
Psychology Department, Rutgers University, Newark campus