[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ac3eb2510812051810x8cf4256lf9fd31b15b9e0552@mail.gmail.com>
Date: Sat, 6 Dec 2008 03:10:33 +0100
From: "Kay Sievers" <kay.sievers@...y.org>
To: "Evgeniy Polyakov" <zbr@...emap.net>
Cc: "Alan Cox" <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org
Subject: Re: Runaway loop with the current git.
On Fri, Dec 5, 2008 at 22:24, Evgeniy Polyakov <zbr@...emap.net> wrote:
> On Fri, Dec 05, 2008 at 10:17:01PM +0100, Kay Sievers (kay.sievers@...y.org) wrote:
>> > And what's with tty drivers? If kernel freezes there even if suddenly
>> > faulty userspace started to load them, where this can happen? Apparently
>> > it is not sleeping userspace since console does not respond to input.
>>
>> 5-1 dev_t request looks like something in initramfs accesses
>> /dev/console, but the driver for it is not properly
>> initialized/registered that time, and the kernel module loader tries
>> to load a module? The forked process might also try to access
>> /dev/console again, and hence the loop?
>
> But why system freezes? Is this init linking/__init calling order
> changes?
Can you add something like:
+++ b/kernel/kmod.c
@@ -108,6 +108,7 @@ int request_module(const char *fmt, ...)
return -ENOMEM;
}
+ printk("XXX call modprobe %s %s[%u]\n", module_name,
current->comm, task_pid_nr(current));
It may show which process is looking for /dev/console and causes
modprobe to run, and maybe we get an idea what's going on. It may at
least show if it's a /dev/console problem.
Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists