Bug#333052: 2.6.14, udev: unknown symbols for ehci_hcd
On Sat, 2005-11-05 at 19:48 +0100, Pozsar Balazs wrote: > On Sat, Nov 05, 2005 at 06:31:04PM +0100, Kay Sievers wrote: > > I've got these messages several times on the experimental SUSE too, > > but can't reproduce it so far, even without Rusty's patch to modprobe > > they have disappeared. See here for the details: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333052 > > > Just to let you know, I've also met this problem (on another distro), > and did not know about this bugreport until now. > So I've done another workaround: modprobe already parses /proc/modules > to check whether the modules needed are already loaded, and this file > also shows us the state of the modules, being "Loading", "Live" or > "Unloading". > > With my patch, modprobe waits until the needed modules come out of the > "Loading" or "Unloading" state. Yes, this was going to be my solution. However, we only need to resort to this is locking fails (read-only root filesystem). Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333052: Bug#333522: possible problem cause: wait4(-1)
On Mon, 2005-10-31 at 19:53 +0100, Marco d'Itri wrote: > On Oct 29, Rusty Russell <[EMAIL PROTECTED]> wrote: > > > Please send complete log. > Here it is. I can reproduce the bug even with a script like: > > while read m; do > /sbin/modprobe.real $m & > done < LIST > > > (Each command was logged to different files which have been sorted by > PID and reassembled.) Unfortunately, this destroys the time sequence. But it looks very much like usbcore is slow to insmod, and the ehci-hcd.ko and uhci-hcd.ko modules are not waiting for it to be inserted. Hmm, if the root filesystem is read-only, then the locking will fail (you need to open a file read/write to get an exclusive fcntl lock). Perhaps this is happening to you? If not, please check again that you have the modified modprobe (strace of modprobe uhci-hcd after usbcore is already inserted should show it locking usbcore). We need to change locking strategy, I think. Yet there's no clear way to do this. Might have to lock each module in the kernel somehow. Fucking Unix, what a mess. Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333052: Bug#333522: possible problem cause: wait4(-1)
On Fri, 2005-10-28 at 15:08 +0200, Marco d'Itri wrote: > On Oct 28, Rusty Russell <[EMAIL PROTECTED]> wrote: > > > The latter is the simplest option. Please try this patch (it will be in > > the next release, too). If it seems to work, please ack. > No luck. Please send complete log. I might need to produce a debugging version of modprobe to track this down. Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333052: Bug#333522: possible problem cause: wait4(-1)
On Thu, 2005-10-27 at 10:10 +0200, Marco d'Itri wrote:
> And then it fails for ehci-hcd too (which is not loaded at all).
> Rusty, do you have other ideas for debugging?
I have reread the bug reports, and meditated on this issue some more.
This is a possibility I was aware of when I changed to code to drop the
module_mutex before calling mod->init(), years ago. Sorry it took so
long.
Module A depends on Module B. Module B is already being loaded, and
doing its init call (slowly). "modprobe A" sees B in the kernel and
calls insmod on B, but the kernel won't let A use B because it's not
ready.
There are two possible fixes:
(1) Queue in the kernel when a module isn't ready to be used
(non-trivial),
(2) modprobe can lock modules we depend on before checking whether
they're in the kernel.
The latter is the simplest option. Please try this patch (it will be in
the next release, too). If it seems to work, please ack.
Rusty.
--- modprobe.c.orig 2005-10-28 17:10:42.0 +1000
+++ modprobe.c 2005-10-28 17:23:32.0 +1000
@@ -814,20 +814,21 @@
strip_vermagic, strip_modversion, cmdline_opts);
}
+ /* Lock before we look, in case it's initializing. */
+ fd = lock_file(mod->filename);
+ if (fd < 0) {
+ error("Could not open '%s': %s\n",
+ mod->filename, strerror(errno));
+ goto out_optstring;
+ }
+
/* Don't do ANYTHING if already in kernel. */
if (!ignore_proc
&& module_in_kernel(newname ?: mod->modname, NULL) == 1) {
if (first_time)
error("Module %s already in kernel.\n",
newname ?: mod->modname);
- goto out_optstring;
- }
-
- fd = lock_file(mod->filename);
- if (fd < 0) {
- error("Could not open '%s': %s\n",
- mod->filename, strerror(errno));
- goto out_optstring;
+ goto out_unlock;
}
command = find_command(mod->modname, commands);
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333522: possible problem cause: wait4(-1)
On Tue, 2005-10-18 at 15:38 +0200, Martin Wilck wrote: > Rusty Russell wrote: > > > Martin Wilck <[EMAIL PROTECTED]> wrote: > > > >>0. the module loading tool runs during boot with PID 1. > > > > I do not understand how this can happen. request_module() cannot occur > > until usermodehelper_init() is called. This is only done once the init > > thread is spawned, which should take pid 1. > > The process I am talking about was running in init's context. It _was_ > the initrd's init process, actually. Right. It's not a modprobe bug then. Thanks, that makes sense. Cheers, Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333522: possible problem cause: wait4(-1)
On Thu, 2005-10-13 at 23:07 +0200, Marco d'Itri wrote: > Any comments? Martin Wilck <[EMAIL PROTECTED]> wrote: > 0. the module loading tool runs during boot with PID 1. I do not understand how this can happen. request_module() cannot occur until usermodehelper_init() is called. This is only done once the init thread is spawned, which should take pid 1. Also, reparenting should happen to the process in the kernel which is "child_reaper", even if another process were to have PID 1... Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
