From: Andrew Morton <akpm@osdl.org>
To: Paul Jackson <pj@sgi.com>
Cc: greg@kroah.com, ebiederm@xmission.com,
linux-kernel@vger.kernel.org, yanmin.zhang@intel.com,
neilb@cse.unsw.edu.au, steiner@sgi.com, hawkes@sgi.com
Subject: Re: + proc-dont-lock-task_structs-indefinitely-cpuset-fix-2.patch added to -mm tree
Date: Thu, 2 Mar 2006 13:52:27 -0800 [thread overview]
Message-ID: <20060302135227.012134f9.akpm@osdl.org> (raw)
In-Reply-To: <20060302111201.cf61552f.pj@sgi.com>
Paul Jackson <pj@sgi.com> wrote:
>
> ...
>
> The initial failure is in the file:
>
> arch/ia64/kernel/topology.c
>
> function:
>
> topology_init
>
> line:
>
> sysfs_cpus = kzalloc(sizeof(struct ia64_cpu) * NR_CPUS, GFP_KERNEL);
>
> With our large NR_CPUS of 1024, and the additional cost of
> the CONFIG_DEBUG_SPINLOCK* debug stuff, and the little bit of
> additional data added by this patch, that kzalloc() fails.
>
Oh. Maybe we should put a big fat printk in slab for that.
> I should stare at the code between this point of initial failure and
> the point that the house of cards finally collapsed and see if
> something should have squeaked sooner.
Probably a panic() in your topology_init().
Also the below patch should have been done ages ago.
> I suspect that the short term solution is to proceed without
> prejudice to the patch that triggered this:
>
> gregkh-driver-allow-sysfs-attribute-files-to-be-pollable.patch
Well yeah, except I find that patch to be independently malodorous ;)
> while I look at some way, if just a stop gap measure, to complain
> earlier in the boot, closer to the scene of the original crime,
> so that others hitting this won't waste more time.
See below.
> Perhaps failing that first kzalloc should cause a complaint,
> if not a panic. It would seem that the system is beyond repair
> if that kzalloc fails. And since the system hasn't even finished
> booting yet, and is for sure trying to boot some larger than tried
> before configuration, might just as well announce ones death boldly.
Yeah, it's dead.
From: Andrew Morton <akpm@osdl.org>
We presently ignore the return values from initcalls. But that can carry
useful debugging information. So print it out if it's non-zero.
Also make that warning message more friendly by printing the name of the
initcall function.
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
init/main.c | 20 ++++++++++++++------
1 files changed, 14 insertions(+), 6 deletions(-)
diff -puN init/main.c~initcall-failure-reporting init/main.c
--- 25/init/main.c~initcall-failure-reporting Thu Mar 2 13:41:02 2006
+++ 25-akpm/init/main.c Thu Mar 2 13:50:53 2006
@@ -565,17 +565,23 @@ static void __init do_initcalls(void)
int count = preempt_count();
for (call = __initcall_start; call < __initcall_end; call++) {
- char *msg;
+ char *msg = NULL;
+ char msgbuf[40];
+ int result;
if (initcall_debug) {
printk(KERN_DEBUG "Calling initcall 0x%p", *call);
- print_fn_descriptor_symbol(": %s()", (unsigned long) *call);
+ print_fn_descriptor_symbol(": %s()",
+ (unsigned long) *call);
printk("\n");
}
- (*call)();
+ result = (*call)();
- msg = NULL;
+ if (result) {
+ sprintf(msgbuf, "error code %d", result);
+ msg = msgbuf;
+ }
if (preempt_count() != count) {
msg = "preemption imbalance";
preempt_count() = count;
@@ -585,8 +591,10 @@ static void __init do_initcalls(void)
local_irq_enable();
}
if (msg) {
- printk(KERN_WARNING "error in initcall at 0x%p: "
- "returned with %s\n", *call, msg);
+ printk(KERN_WARNING "initcall at 0x%p", *call);
+ print_fn_descriptor_symbol(": %s()",
+ (unsigned long) *call);
+ printk(": returned with %s\n", msg);
}
}
_
next prev parent reply other threads:[~2006-03-02 21:50 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200603010120.k211KqVP009559@shell0.pdx.osdl.net>
2006-03-01 2:18 ` + proc-dont-lock-task_structs-indefinitely-cpuset-fix-2.patch added to -mm tree Paul Jackson
2006-03-01 2:36 ` Andrew Morton
2006-03-01 3:45 ` Paul Jackson
2006-03-01 4:10 ` Paul Jackson
2006-03-01 5:05 ` Eric W. Biederman
2006-03-01 5:25 ` Paul Jackson
2006-03-01 6:11 ` Eric W. Biederman
2006-03-01 6:15 ` Eric W. Biederman
2006-03-01 7:20 ` [PATCH] proc: Reference couting fix Eric W. Biederman
2006-03-01 7:26 ` [PATCH] proc: task_mmu bug fix Eric W. Biederman
2006-03-01 7:46 ` Andrew Morton
2006-03-01 12:49 ` Eric W. Biederman
2006-03-01 13:14 ` Hugh Dickins
2006-03-01 13:15 ` Rafael J. Wysocki
2006-03-01 18:33 ` Paul Jackson
2006-03-01 7:48 ` + proc-dont-lock-task_structs-indefinitely-cpuset-fix-2.patch added to -mm tree Paul Jackson
2006-03-01 8:26 ` Andrew Morton
2006-03-01 8:39 ` Paul Jackson
2006-03-01 9:53 ` Paul Jackson
2006-03-01 10:02 ` Andrew Morton
2006-03-01 10:14 ` Paul Jackson
2006-03-01 10:11 ` Paul Jackson
2006-03-01 10:31 ` Paul Jackson
2006-03-01 19:21 ` Greg KH
2006-03-01 20:58 ` Paul Jackson
2006-03-01 21:30 ` Greg KH
2006-03-01 22:26 ` Andrew Morton
2006-03-01 22:50 ` Greg KH
2006-03-01 23:20 ` Paul Jackson
2006-03-01 23:40 ` Andrew Morton
2006-03-02 0:10 ` Paul Jackson
2006-03-02 0:35 ` Paul Jackson
2006-03-01 23:10 ` Paul Jackson
2006-03-01 23:40 ` Paul Jackson
2006-03-02 4:20 ` Andrew Morton
2006-03-02 6:14 ` Paul Jackson
2006-03-02 7:42 ` Andrew Morton
2006-03-02 19:12 ` Paul Jackson
2006-03-02 21:52 ` Andrew Morton [this message]
2006-03-03 6:33 ` Paul Jackson
2006-03-03 6:44 ` Andrew Morton
2006-03-01 4:31 ` Eric W. Biederman
2006-03-01 4:58 ` Paul Jackson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060302135227.012134f9.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=ebiederm@xmission.com \
--cc=greg@kroah.com \
--cc=hawkes@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
--cc=pj@sgi.com \
--cc=steiner@sgi.com \
--cc=yanmin.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox