Comment 21 for bug 24238

On Fri, Oct 21, 2005 at 04:54:35PM +0200, Marco d'Itri wrote:
> On Oct 21, Horms <email address hidden> wrote:
>
> > I did a bit of a poke around this symbols problem.
> > I puzzeled over it for a while. I began to wonder
> > if it might be caused byudevsynthesize[1] which seems
> > to be the major change between -2 and -4, and I completely
> > failed in all my attempts to reproduce the problem.
> It's *exposed* by udevsynthesize because it makes udevd try to load in
> parallel a big number of modules at the same time. I expect that you
> should be able to reproduce the bug with:
>
> for m in $MODULES; do /sbin/modprobe $m &; done

Just to clarify, udevd gets a bunch of events and tries to
serialise them into modprobe calls, right? Do you think there
is any chance it might be calling modprobe out of order
for some reason.

> > I then chatted it over with some people, and they suggested
> > that it might actually be a problem with a bogus depmod run.
> No, it's not. I checked my modules.dep and it's correct, and anyway if
> it were broken loading the same modules with modprobe from the command
> line would not work.

True

> > Alternateively, its seems there is a high correlation between
> > this problem and loading uhci_hcd. Providing lspci -vv might help a bit.
> Also 8250, but I can't see how this could be related to the hardware at
> all... All of this happens before the drivers are even initialised.
> Do not forget that the bug is not reliably reproducible, some days on my
> system may fail one of 8250, 8250_pnp, uhci_hcd or nothing at all.

What I am wondering is, perhaps there are some modules that cause
udevd to generate events in the wrong order. This would line up
with your theory that the bug is probably in the kernel, though
as I can't reproduce it, it is somewhat tricky to debug.

--
Horms