Messages in this thread | | | Date | Mon, 7 Nov 2005 20:20:15 +0100 | From | Pozsar Balazs <> | Subject | Re: 2.6.14, udev: unknown symbols for ehci_hcd |
| |
On Mon, Nov 07, 2005 at 11:12:14AM -0800, Greg KH wrote: > 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?
On my machine it happened while loading pcmcia modules. It was two modprobes running in parallel (invoked by udev), not 1 modprobe loading modules in parallel.
> > , 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.
That's what I thought too, but this is not the case it seems.
-- pozsy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |