From: Greg KH <greg@kroah.com>
To: Pozsar Balazs <pozsy@uhulinux.hu>, rusty@rustcorp.com.au
Cc: "Marco d'Itri" <md@Linux.IT>,
linux-kernel@vger.kernel.org, Kay Sievers <kay.sievers@vrfy.org>
Subject: Re: 2.6.14, udev: unknown symbols for ehci_hcd
Date: Mon, 7 Nov 2005 11:12:14 -0800 [thread overview]
Message-ID: <20051107191214.GA20364@kroah.com> (raw)
In-Reply-To: <20051107190738.GC22737@ojjektum.uhulinux.hu>
On Mon, Nov 07, 2005 at 08:07:38PM +0100, Pozsar Balazs wrote:
> On Mon, Nov 07, 2005 at 09:31:57AM -0800, Greg KH wrote:
> > On Mon, Nov 07, 2005 at 12:33:29PM +0100, Marco d'Itri wrote:
> > > On Nov 06, Greg KH <greg@kroah.com> wrote:
> > >
> > > > This seems to be a Debian issue for some odd reason, I suggest filing a
> > > > bug against the udev package (or just tagging onto the existing bug for
> > > > this problem, I've seen it in there already...)
> > > The reason this is usually seen only on Debian systems is that I am the
> > > first one who shipped an udev package which runs many parallel modprobe
> > > commands, but this is a genuine kernel/modprobe bug.
> >
> > I'm pretty sure OpenSuSE 10.0 does the same thing, and I don't think
> > anyone has reported the same kind of bugs there. Makes me wonder what
> > is really happening here...
>
> If module A depends on module B, and "modprobe A" and "modprobe B" are
> run parallel
Why would they be run in parallel? modprobe doesn't do this, why would
you?
> , there is time window when module B is already listed in
> /proc/modules, but not completely loaded/initialized, it is in the state
> "Loading". At this point "modprobe A" checks /proc/modules if module B
> is already loaded, but it does not take into account that it is in the
> state "Loading" and not yet "Live". So it tries to load module A, but it
> fails, because there are missing symbols because module A did not
> register them yet.
Sounds like a locking issue within the module core. I thought we could
only load one at a time, otherwise we have other races within the
kernel.
thanks,
greg k-h
next prev parent reply other threads:[~2005-11-07 19:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-05 15:37 2.6.14, udev: unknown symbols for ehci_hcd Harald Dunkel
2005-11-05 16:25 ` Greg KH
2005-11-06 5:59 ` Harald Dunkel
2005-11-06 17:03 ` Gustavo Guillermo Pérez
2005-11-11 0:20 ` Rob Landley
2005-11-06 21:51 ` Greg KH
2005-11-07 11:33 ` Marco d'Itri
2005-11-07 17:31 ` Greg KH
2005-11-07 19:07 ` Pozsar Balazs
2005-11-07 19:12 ` Greg KH [this message]
2005-11-07 19:20 ` Pozsar Balazs
2005-11-07 19:27 ` Greg KH
[not found] ` <1131405438.21610.17.camel@localhost.localdomain>
2005-11-07 23:19 ` Marco d'Itri
2005-11-05 17:31 ` Kay Sievers
2005-11-05 18:48 ` Pozsar Balazs
2005-11-06 3:51 ` Rusty Russell
2005-11-06 6:22 ` Bug#333052: " Harald Dunkel
2005-11-06 14:50 ` Harald Dunkel
2005-11-06 15:29 ` Pozsar Balazs
2005-11-06 17:05 ` Harald Dunkel
2005-11-06 17:21 ` Marco d'Itri
2005-11-07 6:00 ` Harald Dunkel
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=20051107191214.GA20364@kroah.com \
--to=greg@kroah.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=md@Linux.IT \
--cc=pozsy@uhulinux.hu \
--cc=rusty@rustcorp.com.au \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.