race in the modules loader?

[Debian Bug Importer]

Automatically imported from Debian bug report #333052 http://bugs.debian.org/333052

[Marco d'Itri (md)]

reassign 333052 linux-2.6
retitle 333052 race in the modules loader?
thanks

On Oct 10, "C.Y.M" <email address hidden> wrote:

> When using udev with linux kernel 2.6.14-rc3, I get the following error during
> system boot. Plug and Play ACPI support in the kernel is loading uhci_hcd just
> fine, but it appears udev is attempting to load it prior to ACPI causing the
> unknown symbol errors.
This randomly happens for other modules too. Looks like some race is hit
when you try to modprobe a lot of modules at the same time.

(BTW, can you clarify how ACPI is related to autoloading hcds?)

--
ciao,
Marco

[C.Y.M. (syphir)]

Marco d'Itri wrote:
> reassign 333052 linux-2.6
> retitle 333052 race in the modules loader?
> thanks
>
> On Oct 10, "C.Y.M" <email address hidden> wrote:
>
>
>>When using udev with linux kernel 2.6.14-rc3, I get the following error during
>>system boot. Plug and Play ACPI support in the kernel is loading uhci_hcd just
>>fine, but it appears udev is attempting to load it prior to ACPI causing the
>>unknown symbol errors.
>
> This randomly happens for other modules too. Looks like some race is hit
> when you try to modprobe a lot of modules at the same time.
>
> (BTW, can you clarify how ACPI is related to autoloading hcds?)
>

The "Plug and Play ACPI" kernel config option allows the kernel to autodetect
built-in mainboard resources (including usb and parallel port). When I
blacklist uhci_hcd in udev, the module is then loaded by the plug and play option.

Best Regards.

[Rusty Russell (rusty-rustcorp)]

On Sun, 2005-10-09 at 16:26 +0200, Kay Sievers wrote:
> On Sun, Oct 09, 2005 at 10:56:15AM +0200, Marco d'Itri wrote:
> > What do you think about this? It happens when udevd tries to load a
> > dozen of modules at boot time. Is there a race in modules loading?
> > It happens less frequently with other modules too (which as far as I can
> > see are always loaded by one of the other instances).
> >
> > Oct 9 10:36:51 wonderland kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
> > Oct 9 10:36:51 wonderland kernel: 8250_pnp: Unknown symbol serial8250_unregister_port
> > Oct 9 10:36:51 wonderland kernel: 8250_pnp: Unknown symbol serial8250_register_port
> > Oct 9 10:36:51 wonderland kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> > Oct 9 10:36:51 wonderland kernel: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
>
> I'm seeing this too for all sort of modules when using heavy parallel
> modprobe calls like the experimental udev coldplug is doing now...

Weird. Be interesting to replace modprobe with a script that logged who
its parent was and what the args were. The above can happen, of course,
if someone is *removing* modules. It should not really happen with mere
module insertion.

If log doesn't show anything interesting, try adding -v and logging
that...

Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman

[Marco d'Itri (md)]

reassign 333522 linux-2.6
severity 333052 grave
merge 333522 333052
thanks

On Oct 12, Jan Taegert <email address hidden> wrote:

> after upgrading udev from 0.070-2 to 0.070-4 modprobe is giving out
> error messages to console output on system startup. Normally the
> concerning modules seem to work correctly, but from time to time they
> aren't loaded at all. I attached the last dmesg-output to document this
> (this time ehci_hcd was'n loaded).
This is probably a kernel bug, the module-init-tool author provided some
advice to debug it in #333052 but I had no time yet to try. Can you?

> Anotation #1: Until now, the "bad" modules always are out of the
> categories usb (uhci/ehci-hcd), serial (8250/8250_pnp?) and alsa
> (snd_...), all attached to onboard devices (via chipset)
On my system it usually happens to the the hcd and 8250 modules.

> Anotation #2: I'am using a home-backed vanilla-kernel 2.6.13 without
> initrd. For testing purposes I tried the experimental 2.6.13
> kernel-package and ... all mentioned problems are gone! I dont't think
> that this a nice solution, but maybe my problems have someting to do
> with this difference.
Interesting... I use a vanilla 2.6.13 myself as well.
I think it would be useful to try with the debian 2.6.13 source and a
custom kernel without the initramfs.

--
ciao,
Marco

[Marco d'Itri (md)]

# Automatically generated email from bts, devscripts version 2.9.7
tags 333522 upstream help

[Marco d'Itri (md)]

# Automatically generated email from bts, devscripts version 2.9.7
reassign 333522 module-init-tools

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #333052 http://bugs.debian.org/333052

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 09 Oct 2005 19:14:54 -0700
From: "C.Y.M" <email address hidden>
To: Submit Debian Bugs <email address hidden>
Subject: uhci_hcd unknown symbol errors

Package: udev
Version: 0.070-3
Severity: important

When using udev with linux kernel 2.6.14-rc3, I get the following error during
system boot. Plug and Play ACPI support in the kernel is loading uhci_hcd just
fine, but it appears udev is attempting to load it prior to ACPI causing the
unknown symbol errors. If I add "uhci_hcd" to the udev blacklist file, then the
errors go away and uhci_hcd loads fine via ACPI. I have all my usb kernel code
compiled as modules. This error does not occur with the previous version of
udev. A quick hack to fix the errors with the current version of udev is:

--SNIP--

--- modprobe.d/blacklist.orig 2005-10-09 19:02:15.000000000 -0700
+++ modprobe.d/blacklist 2005-10-09 19:01:49.000000000 -0700
@@ -2,6 +2,9 @@
 # the hotplug subsystem. It does not affect autoloading of modules by the
 # kernel. This file is provided by the udev package.

+# dont load usb
+blacklist uhci_hcd
+
 # usbcore is loaded as a dependency, ignore it otherwise
 blacklist usbcore

--SNIP--

Oct 9 04:55:44 sid kernel: parport0: PC-style at 0x378, irq 7 [PCSPP(,...)]
Oct 9 04:55:44 sid kernel: Linux agpgart interface v0.101 (c) Dave Jones
Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_pci_suspend
Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_resume_root_hub
Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_pci_probe
Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_check_bandwidth
Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_disabled
Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_release_bandwidth
Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_claim_bandwidth
Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_pci_resume
Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_giveback_urb
Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_poll_rh_status
Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_pci_remove
Oct 9 04:55:44 sid kernel: usbcore: registered new driver usbfs
Oct 9 04:55:44 sid kernel: usbcore: registered new driver hub
Oct 9 04:55:44 sid kernel: nvidia: module license 'NVIDIA' taints kernel.
Oct 9 04:55:44 sid kernel: ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA]
-> GSI 11 (level, low) -> IRQ 11
Oct 9 04:55:44 sid kernel: NVRM: loading NVIDIA Linux x86 NVIDIA Kernel Module
 1.0-7676 Fri Jul 29 12:58:54 PDT 2005
Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_pci_suspend
Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_resume_root_hub
Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_pci_probe
Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_check_bandwidth
Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_disabled
Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_release_bandwidth
Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_claim_bandwidth
Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_pci_resu...

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 10 Oct 2005 09:22:42 +0200
From: <email address hidden> (Marco d'Itri)
To: <email address hidden>, <email address hidden>,
 <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#333052: uhci_hcd unknown symbol errors

--XWOWbaMNXpFDWE00
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

reassign 333052 linux-2.6
retitle 333052 race in the modules loader?
thanks

On Oct 10, "C.Y.M" <email address hidden> wrote:

> When using udev with linux kernel 2.6.14-rc3, I get the following error d=
uring
> system boot. Plug and Play ACPI support in the kernel is loading uhci_hc=
d just
> fine, but it appears udev is attempting to load it prior to ACPI causing =
the
> unknown symbol errors.
This randomly happens for other modules too. Looks like some race is hit
when you try to modprobe a lot of modules at the same time.

(BTW, can you clarify how ACPI is related to autoloading hcds?)

--=20
ciao,
Marco

--XWOWbaMNXpFDWE00
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDShbCFGfw2OHuP7ERAuCaAJ4hI1m7ZRlXlriUEQ6YiuZbdDPkJgCgk6Bb
cshz0gqojLERfyw4fXcFA3g=
=vlIX
-----END PGP SIGNATURE-----

--XWOWbaMNXpFDWE00--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 10 Oct 2005 02:10:47 -0700
From: "C.Y.M" <email address hidden>
To: <email address hidden>
CC: <email address hidden>, <email address hidden>
Subject: Re: Bug#333052: uhci_hcd unknown symbol errors

Marco d'Itri wrote:
> reassign 333052 linux-2.6
> retitle 333052 race in the modules loader?
> thanks
>
> On Oct 10, "C.Y.M" <email address hidden> wrote:
>
>
>>When using udev with linux kernel 2.6.14-rc3, I get the following error during
>>system boot. Plug and Play ACPI support in the kernel is loading uhci_hcd just
>>fine, but it appears udev is attempting to load it prior to ACPI causing the
>>unknown symbol errors.
>
> This randomly happens for other modules too. Looks like some race is hit
> when you try to modprobe a lot of modules at the same time.
>
> (BTW, can you clarify how ACPI is related to autoloading hcds?)
>

The "Plug and Play ACPI" kernel config option allows the kernel to autodetect
built-in mainboard resources (including usb and parallel port). When I
blacklist uhci_hcd in udev, the module is then loaded by the plug and play option.

Best Regards.

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Tue, 11 Oct 2005 05:46:13 +1000
From: Rusty Russell <email address hidden>
To: Kay Sievers <email address hidden>
Cc: Marco d'Itri <email address hidden>
Subject: Re: insmod race?

On Sun, 2005-10-09 at 16:26 +0200, Kay Sievers wrote:
> On Sun, Oct 09, 2005 at 10:56:15AM +0200, Marco d'Itri wrote:
> > What do you think about this? It happens when udevd tries to load a
> > dozen of modules at boot time. Is there a race in modules loading?
> > It happens less frequently with other modules too (which as far as I can
> > see are always loaded by one of the other instances).
> >
> > Oct 9 10:36:51 wonderland kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
> > Oct 9 10:36:51 wonderland kernel: 8250_pnp: Unknown symbol serial8250_unregister_port
> > Oct 9 10:36:51 wonderland kernel: 8250_pnp: Unknown symbol serial8250_register_port
> > Oct 9 10:36:51 wonderland kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> > Oct 9 10:36:51 wonderland kernel: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
>
> I'm seeing this too for all sort of modules when using heavy parallel
> modprobe calls like the experimental udev coldplug is doing now...

Weird. Be interesting to replace modprobe with a script that logged who
its parent was and what the args were. The above can happen, of course,
if someone is *removing* modules. It should not really happen with mere
module insertion.

If log doesn't show anything interesting, try adding -v and logging
that...

Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 12 Oct 2005 13:06:18 +0200
From: <email address hidden> (Marco d'Itri)
To: Jan Taegert <email address hidden>, <email address hidden>,
 <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#333522: udev: modules randomly aren't loaded at startup - "Unknown symbol"

--8t9RHnE3ZwKMSgU+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

reassign 333522 linux-2.6
severity 333052 grave
merge 333522 333052
thanks

On Oct 12, Jan Taegert <email address hidden> wrote:

> after upgrading udev from 0.070-2 to 0.070-4 modprobe is giving out
> error messages to console output on system startup. Normally the
> concerning modules seem to work correctly, but from time to time they
> aren't loaded at all. I attached the last dmesg-output to document this
> (this time ehci_hcd was'n loaded).
This is probably a kernel bug, the module-init-tool author provided some
advice to debug it in #333052 but I had no time yet to try. Can you?

> Anotation #1: Until now, the "bad" modules always are out of the
> categories usb (uhci/ehci-hcd), serial (8250/8250_pnp?) and alsa
> (snd_...), all attached to onboard devices (via chipset)
On my system it usually happens to the the hcd and 8250 modules.

> Anotation #2: I'am using a home-backed vanilla-kernel 2.6.13 without
> initrd. For testing purposes I tried the experimental 2.6.13
> kernel-package and ... all mentioned problems are gone! I dont't think
> that this a nice solution, but maybe my problems have someting to do
> with this difference.
Interesting... I use a vanilla 2.6.13 myself as well.
I think it would be useful to try with the debian 2.6.13 source and a
custom kernel without the initramfs.

--=20
ciao,
Marco

--8t9RHnE3ZwKMSgU+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDTO4qFGfw2OHuP7ERAkAhAJ9YvEojEbh+yFdrCMFFQL1N4MnigwCghgun
aKMoRQwWKXrLkAdSs9tL1nQ=
=k1uT
-----END PGP SIGNATURE-----

--8t9RHnE3ZwKMSgU+--

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Wed, 12 Oct 2005 13:08:05 +0200
From: Marco d'Itri <email address hidden>
To: <email address hidden>
Subject: tagging 333522

# Automatically generated email from bts, devscripts version 2.9.7
tags 333522 upstream help

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Wed, 19 Oct 2005 09:08:06 +0200
From: Marco d'Itri <email address hidden>
To: <email address hidden>
Subject: reassign 333522 to module-init-tools

# Automatically generated email from bts, devscripts version 2.9.7
reassign 333522 module-init-tools

[Marco d'Itri (md)]

reassign 333522 linux-2.6
thank

On Oct 19, Rusty Russell <email address hidden> wrote:

> Right. It's not a modprobe bug then. Thanks, that makes sense.
Oops... I did not read correctly Rusty's answer.
If it's not a modprobe bug and not an udev bug (I checked udevd and it
looks fine to me) then looks like it is a kernel bug.

--
ciao,
Marco

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 19 Oct 2005 15:14:53 +0200
From: <email address hidden> (Marco d'Itri)
To: <email address hidden>, <email address hidden>,
 <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#333522: possible problem cause: wait4(-1)

--azLHFNyN32YCQGCU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

reassign 333522 linux-2.6
thank

On Oct 19, Rusty Russell <email address hidden> wrote:

> Right. It's not a modprobe bug then. Thanks, that makes sense.
Oops... I did not read correctly Rusty's answer.
If it's not a modprobe bug and not an udev bug (I checked udevd and it
looks fine to me) then looks like it is a kernel bug.

--=20
ciao,
Marco

--azLHFNyN32YCQGCU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDVkbNFGfw2OHuP7ERAjELAKCgoOCGp6DVsN3rbZ5O1t++o01uxACfQnBI
/Pb5NW66vibjKKuox0xnqE8=
=lBNG
-----END PGP SIGNATURE-----

--azLHFNyN32YCQGCU--

[Simon Horman (horms)]

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.

[1] http://marc.theaimsgroup.com/?t=112482472200005&r=1&w=2

I then chatted it over with some people, and they suggested
that it might actually be a problem with a bogus depmod run.
Can people who are seeing this run depmod manually and
see if the problem goes away?

Alternateively, its seems there is a high correlation between
this problem and loading uhci_hcd. Providing lspci -vv might help a bit.
Also, what kind of usb devices do the people who are seeing this have
plugged in. I tried with a few I found lying around the office,
but to no avail.

--
Horms

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 21 Oct 2005 18:26:16 +0900
From: Horms <email address hidden>
To: <email address hidden>, <email address hidden>, <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: Re: Bug#333522: possible problem cause: wait4(-1)

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.

[1] http://marc.theaimsgroup.com/?t=112482472200005&r=1&w=2

I then chatted it over with some people, and they suggested
that it might actually be a problem with a bogus depmod run.
Can people who are seeing this run depmod manually and
see if the problem goes away?

Alternateively, its seems there is a high correlation between
this problem and loading uhci_hcd. Providing lspci -vv might help a bit.
Also, what kind of usb devices do the people who are seeing this have
plugged in. I tried with a few I found lying around the office,
but to no avail.

--
Horms

[Marco d'Itri (md)]

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

> 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.

> 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.

--
ciao,
Marco

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 21 Oct 2005 16:54:35 +0200
From: <email address hidden> (Marco d'Itri)
To: Horms <email address hidden>, <email address hidden>
Cc: <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: Re: Bug#333522: possible problem cause: wait4(-1)

--ZPt4rx8FFjLCG7dd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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

> 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.

> 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.

--=20
ciao,
Marco

--ZPt4rx8FFjLCG7dd
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDWQErFGfw2OHuP7ERAhStAJkBxwbLUAMsZNDDaxCLAIeqk7xlEgCfTSnB
6S+MaAw9u5BhyFfsLa9EcLE=
=D7Vp
-----END PGP SIGNATURE-----

--ZPt4rx8FFjLCG7dd--

[Simon Horman (horms)]

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 26 Oct 2005 13:23:39 +0900
From: Horms <email address hidden>
To: Marco d'Itri <email address hidden>, <email address hidden>
Subject: Re: Bug#333052: Bug#333522: possible problem cause: wait4(-1)

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

[Marco d'Itri (md)]

On Oct 26, Horms <email address hidden> wrote:

> Just to clarify, udevd gets a bunch of events and tries to
> serialise them into modprobe calls, right? Do you think there
There is no serialization, only some throttling (IIRC it tries to run up
to 10 child processes in parallel).

> is any chance it might be calling modprobe out of order
> for some reason.
The point is the dependencies are handled by modprobe, so the order in
which udevd loads the modules at the top of the dependency tree is not
relevant.

As Rusty suggested I wrapped /sbin/modprobe in a logger script, but so
far I have not been able to reproduce the bug again (which may or may
not be related, I need a few more reboots).

--
ciao,
Marco

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 26 Oct 2005 09:37:54 +0200
From: <email address hidden> (Marco d'Itri)
To: Horms <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#333052: Bug#333522: possible problem cause: wait4(-1)

--ADZbWkCsHQ7r3kzd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Oct 26, Horms <email address hidden> wrote:

> Just to clarify, udevd gets a bunch of events and tries to
> serialise them into modprobe calls, right? Do you think there
There is no serialization, only some throttling (IIRC it tries to run up
to 10 child processes in parallel).

> is any chance it might be calling modprobe out of order
> for some reason.
The point is the dependencies are handled by modprobe, so the order in
which udevd loads the modules at the top of the dependency tree is not
relevant.

As Rusty suggested I wrapped /sbin/modprobe in a logger script, but so
far I have not been able to reproduce the bug again (which may or may
not be related, I need a few more reboots).

--=20
ciao,
Marco

--ADZbWkCsHQ7r3kzd
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDXzJSFGfw2OHuP7ERAgEGAJ9BU/AYZ++3OG6z852WDcVNOf0eSQCeK8pm
YuYlDzlo2A3GRZt/c5+deH8=
=zDCv
-----END PGP SIGNATURE-----

--ADZbWkCsHQ7r3kzd--

[Simon Horman (horms)]

On Wed, Oct 26, 2005 at 09:37:54AM +0200, Marco d'Itri wrote:
> On Oct 26, Horms <email address hidden> wrote:
>
> > Just to clarify, udevd gets a bunch of events and tries to
> > serialise them into modprobe calls, right? Do you think there
> There is no serialization, only some throttling (IIRC it tries to run up
> to 10 child processes in parallel).

Ok, but it runs modprobe, not ismod, right?

> > is any chance it might be calling modprobe out of order
> > for some reason.
> The point is the dependencies are handled by modprobe, so the order in
> which udevd loads the modules at the top of the dependency tree is not
> relevant.

True.

> As Rusty suggested I wrapped /sbin/modprobe in a logger script, but so
> far I have not been able to reproduce the bug again (which may or may
> not be related, I need a few more reboots).

Thanks. I'm not having any luck reproducing the problem at all.

--
Horms

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 27 Oct 2005 12:58:32 +0900
From: Horms <email address hidden>
To: Marco d'Itri <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#333052: Bug#333522: possible problem cause: wait4(-1)

On Wed, Oct 26, 2005 at 09:37:54AM +0200, Marco d'Itri wrote:
> On Oct 26, Horms <email address hidden> wrote:
>
> > Just to clarify, udevd gets a bunch of events and tries to
> > serialise them into modprobe calls, right? Do you think there
> There is no serialization, only some throttling (IIRC it tries to run up
> to 10 child processes in parallel).

Ok, but it runs modprobe, not ismod, right?

> > is any chance it might be calling modprobe out of order
> > for some reason.
> The point is the dependencies are handled by modprobe, so the order in
> which udevd loads the modules at the top of the dependency tree is not
> relevant.

True.

> As Rusty suggested I wrapped /sbin/modprobe in a logger script, but so
> far I have not been able to reproduce the bug again (which may or may
> not be related, I need a few more reboots).

Thanks. I'm not having any luck reproducing the problem at all.

--
Horms

[Marco d'Itri (md)]

On Oct 27, Horms <email address hidden> wrote:

> > There is no serialization, only some throttling (IIRC it tries to run up
> > to 10 child processes in parallel).
> Ok, but it runs modprobe, not ismod, right?
Yes.

> > As Rusty suggested I wrapped /sbin/modprobe in a logger script, but so
> > far I have not been able to reproduce the bug again (which may or may
> > not be related, I need a few more reboots).
This time it happened again. I could not find anything really
interesting in the log, insmod just fails two times out of three:

insmod /lib/modules/2.6.13/kernel/drivers/usb/host/uhci-hcd.ko
FATAL: Error inserting uhci_hcd (/lib/modules/2.6.13/kernel/drivers/usb/host/uhci-hcd.ko): Unknown symbol in module, or unknown parameter (see dmesg)

And then it fails for ehci-hcd too (which is not loaded at all).
Rusty, do you have other ideas for debugging?

Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_pci_suspend
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_resume_root_hub
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_pci_probe
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_check_bandwidth
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_disabled
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_release_bandwidth
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_claim_bandwidth
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_pci_resume
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_giveback_urb
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_poll_rh_status
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_pci_remove
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_pci_suspend
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_resume_root_hub
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_pci_probe
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_check_bandwidth
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_disabled
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_release_bandwidth
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_claim_bandwidth
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_pci_resume
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_giveback_urb
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_poll_rh_status
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_pci_remove
Oct 27 09:13:51 wonderland kernel: ehci_hcd: Unknown symbol usb_hcd_pci_suspend
Oct 27 09:13:51 wonderland kernel: ehci_hcd: Unknown symbol usb_free_urb
Oct 27 09:13:51 wonderland kernel: ehci_hcd: Unknown symbol usb_hub_tt_clear_buffer
Oct 27 09:13:51 wonderland kernel: ehci_hcd: Unknown symbol usb_hcd_pci_probe
Oct 27 09:13:51 wonderland kernel: ehci_hcd: Unknown symbol usb_disabled
Oct 27 09:13:51 wonderland kernel: ehci_hcd: Unknown symbol usb_unlock_device
Oct 27 09:13:51 wonderland kernel: ehci_hcd: Unknown symbol usb_put_dev
Oct 27 09:13:51 wonderland kernel: ehc...

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 27 Oct 2005 10:10:08 +0200
From: <email address hidden> (Marco d'Itri)
To: Horms <email address hidden>, <email address hidden>
Cc: Rusty Russell <email address hidden>
Subject: Re: Bug#333052: Bug#333522: possible problem cause: wait4(-1)

--2oS5YaxWCcQjTEyO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Oct 27, Horms <email address hidden> wrote:

> > There is no serialization, only some throttling (IIRC it tries to run up
> > to 10 child processes in parallel).
> Ok, but it runs modprobe, not ismod, right?
Yes.

> > As Rusty suggested I wrapped /sbin/modprobe in a logger script, but so
> > far I have not been able to reproduce the bug again (which may or may
> > not be related, I need a few more reboots).
This time it happened again. I could not find anything really
interesting in the log, insmod just fails two times out of three:

insmod /lib/modules/2.6.13/kernel/drivers/usb/host/uhci-hcd.ko=20
FATAL: Error inserting uhci_hcd (/lib/modules/2.6.13/kernel/drivers/usb/hos=
t/uhci-hcd.ko): Unknown symbol in module, or unknown parameter (see dmesg)

And then it fails for ehci-hcd too (which is not loaded at all).
Rusty, do you have other ideas for debugging?

Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_pci_sus=
pend
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_resume_=
root_hub
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_pci_pro=
be
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_check_bandw=
idth
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_disabled
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_release_ban=
dwidth
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_claim_bandw=
idth
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_pci_res=
ume
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_givebac=
k_urb
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_poll_rh=
_status
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_pci_rem=
ove
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_pci_sus=
pend
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_resume_=
root_hub
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_pci_pro=
be
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_check_bandw=
idth
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_disabled
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_release_ban=
dwidth
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_claim_bandw=
idth
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_pci_res=
ume
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_givebac=
k_urb
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_poll_rh=
_status
Oct 27 09:13:51 wonderland kernel: uhci_hcd: Unknown symbol usb_hcd_pci_rem=
ove
Oct 27 09:13:51 wonderland kernel: ehci_hcd: Unknown symbol usb_hcd_pci_sus=
pend
Oct 27 09:13:51 wonde...

[Rusty Russell (rusty-rustcorp)]

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.000000000 +1000
+++ modprobe.c 2005-10-28 17:23:32.000000000 +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

[Simon Horman (horms)]

On Fri, Oct 28, 2005 at 05:24:44PM +1000, Rusty Russell wrote:
> 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.

Thanks, very much appreciated. Hopefully this solves our woes.

--
Horms

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Fri, 28 Oct 2005 17:24:44 +1000
From: Rusty Russell <email address hidden>
To: Marco d'Itri <email address hidden>
Cc: Horms <email address hidden>, <email address hidden>
Subject: Re: 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.000000000 +1000
+++ modprobe.c 2005-10-28 17:23:32.000000000 +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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 28 Oct 2005 16:52:44 +0900
From: Horms <email address hidden>
To: Rusty Russell <email address hidden>
Cc: Marco d'Itri <email address hidden>, <email address hidden>
Subject: Re: Bug#333052: Bug#333522: possible problem cause: wait4(-1)

On Fri, Oct 28, 2005 at 05:24:44PM +1000, Rusty Russell wrote:
> 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.

Thanks, very much appreciated. Hopefully this solves our woes.

--
Horms

[Marco d'Itri (md)]

On Oct 28, Rusty Russell <email address hidden> 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.

--
ciao,
Marco

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 28 Oct 2005 15:08:33 +0200
From: <email address hidden> (Marco d'Itri)
To: Rusty Russell <email address hidden>, <email address hidden>
Cc: Horms <email address hidden>
Subject: Re: Bug#333052: Bug#333522: possible problem cause: wait4(-1)

--xgyAXRrhYN0wYx8y
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Oct 28, Rusty Russell <email address hidden> 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.

--=20
ciao,
Marco

--xgyAXRrhYN0wYx8y
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDYiLRFGfw2OHuP7ERAkSpAJ9/+w4v3NHHaJf5AnJYzeSM3OoYRQCdGMfd
xkgjaEJ6PGn8BpE+RViFC38=
=C4sE
-----END PGP SIGNATURE-----

--xgyAXRrhYN0wYx8y--

[Rusty Russell (rusty-rustcorp)]

On Fri, 2005-10-28 at 15:08 +0200, Marco d'Itri wrote:
> On Oct 28, Rusty Russell <email address hidden> 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

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sat, 29 Oct 2005 11:25:26 +1000
From: Rusty Russell <email address hidden>
To: Marco d'Itri <email address hidden>
Cc: <email address hidden>, Horms <email address hidden>
Subject: Re: 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 address hidden> 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

[Simon Horman (horms)]

On Sun, Oct 30, 2005 at 09:32:42PM +0100, Sven Luther wrote:
> On Sun, Oct 30, 2005 at 05:23:42PM +0100, Elimar Riesebieter wrote:
> > Hi all,
> >
> > I am running 2.6.14 from Debian sources on my PB5,6. Booting gives
> > some Unknown issuses:
> > $ dmesg | grep Unk
> > ohci_hcd: Unknown symbol usb_hcd_pci_suspend
> > ohci_hcd: Unknown symbol usb_hcd_pci_probe
> > ohci_hcd: Unknown symbol usb_trylock_device
> > ohci_hcd: Unknown symbol usb_disabled
> > ohci_hcd: Unknown symbol usb_unlock_device
> > ohci_hcd: Unknown symbol usb_lock_device
> > ohci_hcd: Unknown symbol usb_calc_bus_time
> > ohci_hcd: Unknown symbol usb_hcd_pci_resume
> > ohci_hcd: Unknown symbol usb_hcd_giveback_urb
> > ohci_hcd: Unknown symbol usb_set_device_state
> > ohci_hcd: Unknown symbol usb_hcd_pci_remove
> > ohci_hcd: Unknown symbol usb_hcd_pci_suspend
> > ohci_hcd: Unknown symbol usb_hcd_pci_probe
> > ohci_hcd: Unknown symbol usb_trylock_device
> > ohci_hcd: Unknown symbol usb_disabled
> > ohci_hcd: Unknown symbol usb_unlock_device
> > ohci_hcd: Unknown symbol usb_lock_device
> > ohci_hcd: Unknown symbol usb_calc_bus_time
> > ohci_hcd: Unknown symbol usb_hcd_pci_resume
> > ohci_hcd: Unknown symbol usb_hcd_giveback_urb
> > ohci_hcd: Unknown symbol usb_set_device_state
> > ohci_hcd: Unknown symbol usb_hcd_pci_remove
> >
> > The usb2 iface seems to work properly.
> > Suggestions?
>
> This is a strange bug in the 2.6.12+ kernel packages.
>
> For some obscure reason, neither at postinst time nor at boot time the depmod
> get's regenerated properly, so simply run depmod yourself and it goes away.
>
> If you have time to investigate this, it would be really appreciated.

Actually, I believe it is #333052 for which a solution still alludes us.
Although it does seem to be a modprobe problem tickled by recent changes
to udev.

http://bugs.debian.org/cgi-bin/333052

--
Horms

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 31 Oct 2005 14:49:58 +0900
From: Horms <email address hidden>
To: Sven Luther <email address hidden>
Cc: debian-powerpc <email address hidden>,
 <email address hidden>, <email address hidden>
Subject: Re: udev issue

On Sun, Oct 30, 2005 at 09:32:42PM +0100, Sven Luther wrote:
> On Sun, Oct 30, 2005 at 05:23:42PM +0100, Elimar Riesebieter wrote:
> > Hi all,
> >
> > I am running 2.6.14 from Debian sources on my PB5,6. Booting gives
> > some Unknown issuses:
> > $ dmesg | grep Unk
> > ohci_hcd: Unknown symbol usb_hcd_pci_suspend
> > ohci_hcd: Unknown symbol usb_hcd_pci_probe
> > ohci_hcd: Unknown symbol usb_trylock_device
> > ohci_hcd: Unknown symbol usb_disabled
> > ohci_hcd: Unknown symbol usb_unlock_device
> > ohci_hcd: Unknown symbol usb_lock_device
> > ohci_hcd: Unknown symbol usb_calc_bus_time
> > ohci_hcd: Unknown symbol usb_hcd_pci_resume
> > ohci_hcd: Unknown symbol usb_hcd_giveback_urb
> > ohci_hcd: Unknown symbol usb_set_device_state
> > ohci_hcd: Unknown symbol usb_hcd_pci_remove
> > ohci_hcd: Unknown symbol usb_hcd_pci_suspend
> > ohci_hcd: Unknown symbol usb_hcd_pci_probe
> > ohci_hcd: Unknown symbol usb_trylock_device
> > ohci_hcd: Unknown symbol usb_disabled
> > ohci_hcd: Unknown symbol usb_unlock_device
> > ohci_hcd: Unknown symbol usb_lock_device
> > ohci_hcd: Unknown symbol usb_calc_bus_time
> > ohci_hcd: Unknown symbol usb_hcd_pci_resume
> > ohci_hcd: Unknown symbol usb_hcd_giveback_urb
> > ohci_hcd: Unknown symbol usb_set_device_state
> > ohci_hcd: Unknown symbol usb_hcd_pci_remove
> >
> > The usb2 iface seems to work properly.
> > Suggestions?
>
> This is a strange bug in the 2.6.12+ kernel packages.
>
> For some obscure reason, neither at postinst time nor at boot time the depmod
> get's regenerated properly, so simply run depmod yourself and it goes away.
>
> If you have time to investigate this, it would be really appreciated.

Actually, I believe it is #333052 for which a solution still alludes us.
Although it does seem to be a modprobe problem tickled by recent changes
to udev.

http://bugs.debian.org/cgi-bin/333052

--
Horms

[Marco d'Itri (md)]

On Oct 29, Rusty Russell <email address hidden> 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.)

=[ pid:00490 parent:00282 ] ===================================================
/sbin/modprobe -q mousedev

=[ pid:00672 parent:00282 ] ===================================================
/sbin/modprobe -q evdev
insmod /lib/modules/2.6.14/kernel/drivers/input/evdev.ko

=[ pid:00825 parent:00819 ] ===================================================
/sbin/modprobe -s -q ide-cd
insmod /lib/modules/2.6.14/kernel/drivers/cdrom/cdrom.ko
insmod /lib/modules/2.6.14/kernel/drivers/ide/ide-cd.ko

=[ pid:00844 parent:00826 ] ===================================================
/sbin/modprobe -s -q ide-cd

=[ pid:00884 parent:00872 ] ===================================================
/sbin/modprobe serio:ty01pr00id00ex00
insmod /lib/modules/2.6.14/kernel/drivers/input/serio/serio_raw.ko
insmod /lib/modules/2.6.14/kernel/drivers/input/mouse/psmouse.ko

=[ pid:00910 parent:00909 ] ===================================================
/sbin/modprobe pnp:dPNP0200
FATAL: Module pnp:dPNP0200 not found.

=[ pid:00925 parent:00924 ] ===================================================
/sbin/modprobe pnp:dPNP0800
FATAL: Module pnp:dPNP0800 not found.

=[ pid:00934 parent:00933 ] ===================================================
/sbin/modprobe pnp:dPNP0c04
FATAL: Module pnp:dPNP0c04 not found.

=[ pid:00941 parent:00940 ] ===================================================
/sbin/modprobe pnp:dPNP0401
insmod /lib/modules/2.6.14/kernel/drivers/parport/parport.ko
insmod /lib/modules/2.6.14/kernel/drivers/parport/parport_pc.ko

=[ pid:00954 parent:00953 ] ===================================================
/sbin/modprobe pnp:dPNP0501
insmod /lib/modules/2.6.14/kernel/drivers/serial/serial_core.ko
insmod /lib/modules/2.6.14/kernel/drivers/serial/8250.ko
insmod /lib/modules/2.6.14/kernel/drivers/serial/8250_pnp.ko

=[ pid:00988 parent:00987 ] ===================================================
/sbin/modprobe pnp:dPNP0b00
FATAL: Module pnp:dPNP0b00 not found.

=[ pid:00997 parent:00996 ] ===================================================
/sbin/modprobe pnp:dPNPb02f
FATAL: Module pnp:dPNPb02f not found.

=[ pid:01013 parent:01012 ] ===================================================
/sbin/modprobe pnp:dPNPb006
FATAL: Module pnp:dPNPb006 not found.

=[ pid:01017 parent:01016 ] ===================================================
/sbin/modprobe pnp:dPNP0501
insmod /lib/modules/2.6.14/kernel/drivers/serial/8250_pnp.ko
FATAL: Error inserting 8250_pnp (/lib/modules/2.6.14/kernel/drivers/serial/8250_pnp.ko): Unknown symbol in module, or unknown parameter (see dmesg)

=[ pid:01025 parent:01009 ] ===================================================
/sbin/modprobe pci:v00001106d0000B198sv00000000sd00000000bc06sc04i00
FATAL: Module pci:v00001106d0000B198sv00000000sd00000000bc06sc04i00 not found.

=[ pid:01031 parent:01011 ] ===================================================
/sbin...

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 31 Oct 2005 19:53:12 +0100
From: <email address hidden> (Marco d'Itri)
To: Rusty Russell <email address hidden>, <email address hidden>
Cc: Horms <email address hidden>
Subject: Re: Bug#333052: Bug#333522: possible problem cause: wait4(-1)

On Oct 29, Rusty Russell <email address hidden> 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.)

=[ pid:00490 parent:00282 ] ===================================================
/sbin/modprobe -q mousedev

=[ pid:00672 parent:00282 ] ===================================================
/sbin/modprobe -q evdev
insmod /lib/modules/2.6.14/kernel/drivers/input/evdev.ko

=[ pid:00825 parent:00819 ] ===================================================
/sbin/modprobe -s -q ide-cd
insmod /lib/modules/2.6.14/kernel/drivers/cdrom/cdrom.ko
insmod /lib/modules/2.6.14/kernel/drivers/ide/ide-cd.ko

=[ pid:00844 parent:00826 ] ===================================================
/sbin/modprobe -s -q ide-cd

=[ pid:00884 parent:00872 ] ===================================================
/sbin/modprobe serio:ty01pr00id00ex00
insmod /lib/modules/2.6.14/kernel/drivers/input/serio/serio_raw.ko
insmod /lib/modules/2.6.14/kernel/drivers/input/mouse/psmouse.ko

=[ pid:00910 parent:00909 ] ===================================================
/sbin/modprobe pnp:dPNP0200
FATAL: Module pnp:dPNP0200 not found.

=[ pid:00925 parent:00924 ] ===================================================
/sbin/modprobe pnp:dPNP0800
FATAL: Module pnp:dPNP0800 not found.

=[ pid:00934 parent:00933 ] ===================================================
/sbin/modprobe pnp:dPNP0c04
FATAL: Module pnp:dPNP0c04 not found.

=[ pid:00941 parent:00940 ] ===================================================
/sbin/modprobe pnp:dPNP0401
insmod /lib/modules/2.6.14/kernel/drivers/parport/parport.ko
insmod /lib/modules/2.6.14/kernel/drivers/parport/parport_pc.ko

=[ pid:00954 parent:00953 ] ===================================================
/sbin/modprobe pnp:dPNP0501
insmod /lib/modules/2.6.14/kernel/drivers/serial/serial_core.ko
insmod /lib/modules/2.6.14/kernel/drivers/serial/8250.ko
insmod /lib/modules/2.6.14/kernel/drivers/serial/8250_pnp.ko

=[ pid:00988 parent:00987 ] ===================================================
/sbin/modprobe pnp:dPNP0b00
FATAL: Module pnp:dPNP0b00 not found.

=[ pid:00997 parent:00996 ] ===================================================
/sbin/modprobe pnp:dPNPb02f
FATAL: Module pnp:dPNPb02f not found.

=[ pid:01013 parent:01012 ] ===================================================
/sbin/modprobe pnp:dPNPb006
FATAL: Module pnp:dPNPb006 not found.

=[ pid:01017 parent:01016 ] ===================================================
/sbin/modprobe pnp:dPNP0501
insmod /lib/modules/2.6.14/kernel/drivers/serial/8250_pnp.ko
FATAL: Error inserting 8250_pnp (/lib/modules/2.6.14/kernel/drivers/serial/8250_pnp.ko): Unknown symbol in module, or unknown parameter (see dmesg)

=[ pid:01025 parent:...

[Rusty Russell (rusty-rustcorp)]

On Mon, 2005-10-31 at 19:53 +0100, Marco d'Itri wrote:
> On Oct 29, Rusty Russell <email address hidden> 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

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Tue, 01 Nov 2005 15:23:14 +1100
From: Rusty Russell <email address hidden>
To: Marco d'Itri <email address hidden>
Cc: <email address hidden>, Horms <email address hidden>
Subject: Re: 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 address hidden> 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

[Marco d'Itri (md)]

On Nov 01, Rusty Russell <email address hidden> wrote:

> 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
Sure, all of this happens when / is read only.

--
ciao,
Marco

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 1 Nov 2005 09:35:35 +0100
From: <email address hidden> (Marco d'Itri)
To: Rusty Russell <email address hidden>
Cc: <email address hidden>, Horms <email address hidden>
Subject: Re: Bug#333052: Bug#333522: possible problem cause: wait4(-1)

--0F1p//8PRICkK4MW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Nov 01, Rusty Russell <email address hidden> wrote:

> 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
Sure, all of this happens when / is read only.

--=20
ciao,
Marco

--0F1p//8PRICkK4MW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD4DBQFDZyjXFGfw2OHuP7ERAi1hAJQK/x9tm+iuC+301YZCOqtQMlTcAJ9swQVN
osLNa13kxHush83CLewWCQ==
=qxOz
-----END PGP SIGNATURE-----

--0F1p//8PRICkK4MW--

[Simon Horman (horms)]

On Tue, Nov 01, 2005 at 09:35:35AM +0100, Marco d'Itri wrote:
> On Nov 01, Rusty Russell <email address hidden> wrote:
>
> > 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
> Sure, all of this happens when / is read only.

Perhaps a rw tmpfs could save the day.
Just an idea.

--
Horms

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 1 Nov 2005 18:15:18 +0900
From: Horms <email address hidden>
To: Marco d'Itri <email address hidden>
Cc: Rusty Russell <email address hidden>, <email address hidden>
Subject: Re: Bug#333052: Bug#333522: possible problem cause: wait4(-1)

On Tue, Nov 01, 2005 at 09:35:35AM +0100, Marco d'Itri wrote:
> On Nov 01, Rusty Russell <email address hidden> wrote:
>
> > 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
> Sure, all of this happens when / is read only.

Perhaps a rw tmpfs could save the day.
Just an idea.

--
Horms

[Paul Traina (pst-pst)]

I tried Rusty's suggested patch to modprobe.c (moving the lock forward).
Works like a charm with stock 2.6.14-2 with an initramfs based upon
initramfs-tools.

Please ignore my comments about manual modprobes and the intel sound stuff
screwing up with unknown symbols, I realized that that is a DIFFERENT bug
(invalid command line parameter passed in from udev to the snd module).

Paul

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Wed, 2 Nov 2005 15:15:00 -0800 (PST)
From: <email address hidden> (Paul Traina)
To: <email address hidden>
Subject: confirmation of rusty's fix

I tried Rusty's suggested patch to modprobe.c (moving the lock forward).
Works like a charm with stock 2.6.14-2 with an initramfs based upon
initramfs-tools.

Please ignore my comments about manual modprobes and the intel sound stuff
screwing up with unknown symbols, I realized that that is a DIFFERENT bug
(invalid command line parameter passed in from udev to the snd module).

Paul

[Pozsár Balázs (pozsy)]

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.

--
pozsy

--- module-init-tools-3.2-pre4.orig/modprobe.c 2005-05-08 09:38:52.000000000 +0200
+++ module-init-tools-3.2-pre4/modprobe.c 2005-10-24 13:19:39.000000000 +0200
@@ -363,6 +363,7 @@
  FILE *proc_modules;
  char *line;

+start:
  /* Might not be mounted yet. Don't fail. */
  proc_modules = fopen("/proc/modules", "r");
  if (!proc_modules)
@@ -373,12 +374,31 @@

   if (entry && strcmp(entry, modname) == 0) {
    /* If it exists, usecount is the third entry. */
- if (usecount) {
- entry = strtok(NULL, " \n");
- if (entry
- && (entry = strtok(NULL, " \n")) != NULL)
+ if (!(entry = strtok(NULL, " \n")))
+ goto out;
+
+ if (!(entry = strtok(NULL, " \n"))) /* usecount */
+ goto out;
+ else
+ if (usecount)
      *usecount = atoi(entry);
+
+ if (!(entry = strtok(NULL, " \n"))) /* "-" */
+ goto out;
+
+ if (!(entry = strtok(NULL, " \n"))) /* status */
+ goto out;
+ else {
+ if (!strcmp(entry, "Loading") || !strcmp(entry, "Unloading")) {
+ usleep(100000);
+ free(line);
+ fclose(proc_modules);
+ goto start;
+ }
+ goto out;
    }
+
+ out:
    free(line);
    fclose(proc_modules);
    return 1;

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 5 Nov 2005 19:48:02 +0100
From: Pozsar Balazs <email address hidden>
To: Kay Sievers <email address hidden>, Rusty Russell <email address hidden>, <email address hidden>
Cc: Harald Dunkel <email address hidden>,
 <email address hidden>
Subject: Re: 2.6.14, udev: unknown symbols for ehci_hcd

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.

--
pozsy

--- module-init-tools-3.2-pre4.orig/modprobe.c 2005-05-08 09:38:52.000000000 +0200
+++ module-init-tools-3.2-pre4/modprobe.c 2005-10-24 13:19:39.000000000 +0200
@@ -363,6 +363,7 @@
  FILE *proc_modules;
  char *line;

+start:
  /* Might not be mounted yet. Don't fail. */
  proc_modules = fopen("/proc/modules", "r");
  if (!proc_modules)
@@ -373,12 +374,31 @@

   if (entry && strcmp(entry, modname) == 0) {
    /* If it exists, usecount is the third entry. */
- if (usecount) {
- entry = strtok(NULL, " \n");
- if (entry
- && (entry = strtok(NULL, " \n")) != NULL)
+ if (!(entry = strtok(NULL, " \n")))
+ goto out;
+
+ if (!(entry = strtok(NULL, " \n"))) /* usecount */
+ goto out;
+ else
+ if (usecount)
      *usecount = atoi(entry);
+
+ if (!(entry = strtok(NULL, " \n"))) /* "-" */
+ goto out;
+
+ if (!(entry = strtok(NULL, " \n"))) /* status */
+ goto out;
+ else {
+ if (!strcmp(entry, "Loading") || !strcmp(entry, "Unloading")) {
+ usleep(100000);
+ free(line);
+ fclose(proc_modules);
+ goto start;
+ }
+ goto out;
    }
+
+ out:
    free(line);
    fclose(proc_modules);
    return 1;

[Rusty Russell (rusty-rustcorp)]

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

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sun, 06 Nov 2005 14:51:36 +1100
From: Rusty Russell <email address hidden>
To: Pozsar Balazs <email address hidden>
Cc: Kay Sievers <email address hidden>, <email address hidden>,
 Harald Dunkel <email address hidden>, <email address hidden>
Subject: Re: 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

[Harri (harald-dunkel)]

Pozsar Balazs wrote:
> On Sat, Nov 05, 2005 at 06:31:04PM +0100, Kay Sievers wrote:
>
>
> With my patch, modprobe waits until the needed modules come out of the
> "Loading" or "Unloading" state.
>
>

For testing I have added it to Debian's
module-init-tools 3.2-pre9. Works for me.

Regards

Harri

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 06 Nov 2005 07:22:24 +0100
From: Harald Dunkel <email address hidden>
To: Pozsar Balazs <email address hidden>, <email address hidden>
CC: Kay Sievers <email address hidden>, Rusty Russell <email address hidden>,
 <email address hidden>
Subject: Re: Bug#333052: 2.6.14, udev: unknown symbols for ehci_hcd

--------------enigBC6388C1C342D217BB25EDFB
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Pozsar Balazs wrote:
> On Sat, Nov 05, 2005 at 06:31:04PM +0100, Kay Sievers wrote:
>
>
> With my patch, modprobe waits until the needed modules come out of the
> "Loading" or "Unloading" state.
>
>

For testing I have added it to Debian's
module-init-tools 3.2-pre9. Works for me.

Regards

Harri

--------------enigBC6388C1C342D217BB25EDFB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDbaEnUTlbRTxpHjcRAjjKAKCS9GuDXdUv0nxfdX5BNS/f9KwERACgkjqj
tPL4IvtkZYumJ6Q1fUkTvhs=
=Wgs6
-----END PGP SIGNATURE-----

--------------enigBC6388C1C342D217BB25EDFB--

[Marco d'Itri (md)]

On Nov 05, Pozsar Balazs <email address hidden> wrote:

> With my patch, modprobe waits until the needed modules come out of the
> "Loading" or "Unloading" state.
Looks like it works, I will upload a new package today.

--
ciao,
Marco

[Marco d'Itri (md)]

# Automatically generated email from bts, devscripts version 2.9.8
reassign 333052 module-init-tools

[Marco d'Itri (md)]

Source: module-init-tools
Source-Version: 3.2-pre9-4

We believe that the bug you reported is fixed in the latest version of
module-init-tools, which is due to be installed in the Debian FTP archive:

module-init-tools-udeb_3.2-pre9-4_i386.udeb
  to pool/main/m/module-init-tools/module-init-tools-udeb_3.2-pre9-4_i386.udeb
module-init-tools_3.2-pre9-4.diff.gz
  to pool/main/m/module-init-tools/module-init-tools_3.2-pre9-4.diff.gz
module-init-tools_3.2-pre9-4.dsc
  to pool/main/m/module-init-tools/module-init-tools_3.2-pre9-4.dsc
module-init-tools_3.2-pre9-4_i386.deb
  to pool/main/m/module-init-tools/module-init-tools_3.2-pre9-4_i386.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Marco d'Itri <email address hidden> (supplier of updated module-init-tools package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sun, 6 Nov 2005 12:14:39 +0100
Source: module-init-tools
Binary: module-init-tools-udeb module-init-tools
Architecture: source i386
Version: 3.2-pre9-4
Distribution: unstable
Urgency: high
Maintainer: Marco d'Itri <email address hidden>
Changed-By: Marco d'Itri <email address hidden>
Description:
 module-init-tools - tools for managing Linux kernel modules
 module-init-tools-udeb - tools for managing Linux kernel modules (udeb)
Closes: 333522
Changes:
 module-init-tools (3.2-pre9-4) unstable; urgency=high
 .
   * Added two patches to prevent errors when concurrently loading modules.
     (Closes: #333522)
   * Removed the diversions for kallsyms(8) and ksyms(8).
Files:
 6cd790a08b2ae9903f502db83c9ce126 635 admin important module-init-tools_3.2-pre9-4.dsc
 75567c1c0a9f88e2dc34df1c0564d0e6 20294 admin important module-init-tools_3.2-pre9-4.diff.gz
 9dfbc63b235d7e34fe04368a16838b54 74258 admin important module-init-tools_3.2-pre9-4_i386.deb
 618623e058f7d971ed8e54dc9d8465db 25040 debian-installer extra module-init-tools-udeb_3.2-pre9-4_i386.udeb
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDbe+pFGfw2OHuP7ERArsLAJ4hIT67Yacjk+7jRMx6osDyBxRz+wCePjGz
lTmgNKKuHvsL4IZrsVETHlA=
=7Qnq
-----END PGP SIGNATURE-----

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 6 Nov 2005 11:59:01 +0100
From: <email address hidden> (Marco d'Itri)
To: Pozsar Balazs <email address hidden>, <email address hidden>
Cc: Kay Sievers <email address hidden>, Rusty Russell <email address hidden>,
 <email address hidden>
Subject: Re: Bug#333052: 2.6.14, udev: unknown symbols for ehci_hcd

--ibTvN161/egqYuK8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Nov 05, Pozsar Balazs <email address hidden> wrote:

> With my patch, modprobe waits until the needed modules come out of the=20
> "Loading" or "Unloading" state.
Looks like it works, I will upload a new package today.

--=20
ciao,
Marco

--ibTvN161/egqYuK8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDbeH1FGfw2OHuP7ERAlYIAKCcrjWVYslt1ozNDtb2XnKg8DxCyACfcT8v
vRZpA/Ry8RC6Aae+gfli7OY=
=HY/1
-----END PGP SIGNATURE-----

--ibTvN161/egqYuK8--

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sun, 6 Nov 2005 11:53:46 +0100
From: Marco d'Itri <email address hidden>
To: <email address hidden>
Subject: reassign 333052 to module-init-tools

# Automatically generated email from bts, devscripts version 2.9.8
reassign 333052 module-init-tools

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sun, 06 Nov 2005 04:02:17 -0800
From: Marco d'Itri <email address hidden>
To: <email address hidden>
Subject: Bug#333522: fixed in module-init-tools 3.2-pre9-4

Source: module-init-tools
Source-Version: 3.2-pre9-4

We believe that the bug you reported is fixed in the latest version of
module-init-tools, which is due to be installed in the Debian FTP archive:

module-init-tools-udeb_3.2-pre9-4_i386.udeb
  to pool/main/m/module-init-tools/module-init-tools-udeb_3.2-pre9-4_i386.udeb
module-init-tools_3.2-pre9-4.diff.gz
  to pool/main/m/module-init-tools/module-init-tools_3.2-pre9-4.diff.gz
module-init-tools_3.2-pre9-4.dsc
  to pool/main/m/module-init-tools/module-init-tools_3.2-pre9-4.dsc
module-init-tools_3.2-pre9-4_i386.deb
  to pool/main/m/module-init-tools/module-init-tools_3.2-pre9-4_i386.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Marco d'Itri <email address hidden> (supplier of updated module-init-tools package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sun, 6 Nov 2005 12:14:39 +0100
Source: module-init-tools
Binary: module-init-tools-udeb module-init-tools
Architecture: source i386
Version: 3.2-pre9-4
Distribution: unstable
Urgency: high
Maintainer: Marco d'Itri <email address hidden>
Changed-By: Marco d'Itri <email address hidden>
Description:
 module-init-tools - tools for managing Linux kernel modules
 module-init-tools-udeb - tools for managing Linux kernel modules (udeb)
Closes: 333522
Changes:
 module-init-tools (3.2-pre9-4) unstable; urgency=high
 .
   * Added two patches to prevent errors when concurrently loading modules.
     (Closes: #333522)
   * Removed the diversions for kallsyms(8) and ksyms(8).
Files:
 6cd790a08b2ae9903f502db83c9ce126 635 admin important module-init-tools_3.2-pre9-4.dsc
 75567c1c0a9f88e2dc34df1c0564d0e6 20294 admin important module-init-tools_3.2-pre9-4.diff.gz
 9dfbc63b235d7e34fe04368a16838b54 74258 admin important module-init-tools_3.2-pre9-4_i386.deb
 618623e058f7d971ed8e54dc9d8465db 25040 debian-installer extra module-init-tools-udeb_3.2-pre9-4_i386.udeb
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDbe+pFGfw2OHuP7ERArsLAJ4hIT67Yacjk+7jRMx6osDyBxRz+wCePjGz
lTmgNKKuHvsL4IZrsVETHlA=
=7Qnq
-----END PGP SIGNATURE-----

[Harri (harald-dunkel)]

Harald Dunkel wrote:
>
> For testing I have added it to Debian's
> module-init-tools 3.2-pre9. Works for me.
>

No, it doesn't. After the 3rd reboot the
problem was back.

Regards

Harri

[Pozsár Balázs (pozsy)]

On Sun, Nov 06, 2005 at 03:50:05PM +0100, Harald Dunkel wrote:
> Harald Dunkel wrote:
> >
> > For testing I have added it to Debian's
> > module-init-tools 3.2-pre9. Works for me.
> >
>
> No, it doesn't. After the 3rd reboot the
> problem was back.

Well, that's really wierd, It Should Work(tm) :)
Did you apply both patches (Rusty's + mine), or only the latter?

Could you send me debug output please? The first time I met the problem,
I used a modprobe wrapper which dumped /proc/modules and modprobe
stdout/stderr to a temp file.

I would like to also mention, that my patch leaves a very little time
window open, but that's only a problem if module unloading is also
happening: after parsing /proc/modules, but before actually loading the
module, it is possible that an rmmod unloads (starts to unload) a
dependant module. But this does not affect booting.

--
pozsy

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 06 Nov 2005 15:50:05 +0100
From: Harald Dunkel <email address hidden>
To: Harald Dunkel <email address hidden>, <email address hidden>
CC: Pozsar Balazs <email address hidden>, Kay Sievers <email address hidden>,
 Rusty Russell <email address hidden>, <email address hidden>
Subject: Re: Bug#333052: 2.6.14, udev: unknown symbols for ehci_hcd

--------------enigD725E6A9BDA190D84892FB01
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Harald Dunkel wrote:
>
> For testing I have added it to Debian's
> module-init-tools 3.2-pre9. Works for me.
>

No, it doesn't. After the 3rd reboot the
problem was back.

Regards

Harri

--------------enigD725E6A9BDA190D84892FB01
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDbhgmUTlbRTxpHjcRAnJ4AJ9th+WX7Gd/3z+kwixvK8dM0pgKGACfSZdD
1tecYJSB10ht+DC8hjefnWQ=
=Yzid
-----END PGP SIGNATURE-----

--------------enigD725E6A9BDA190D84892FB01--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 6 Nov 2005 16:29:24 +0100
From: Pozsar Balazs <email address hidden>
To: Harald Dunkel <email address hidden>
Cc: <email address hidden>, Kay Sievers <email address hidden>,
 Rusty Russell <email address hidden>, <email address hidden>
Subject: Re: Bug#333052: 2.6.14, udev: unknown symbols for ehci_hcd

On Sun, Nov 06, 2005 at 03:50:05PM +0100, Harald Dunkel wrote:
> Harald Dunkel wrote:
> >
> > For testing I have added it to Debian's
> > module-init-tools 3.2-pre9. Works for me.
> >
>
> No, it doesn't. After the 3rd reboot the
> problem was back.

Well, that's really wierd, It Should Work(tm) :)
Did you apply both patches (Rusty's + mine), or only the latter?

Could you send me debug output please? The first time I met the problem,
I used a modprobe wrapper which dumped /proc/modules and modprobe
stdout/stderr to a temp file.

I would like to also mention, that my patch leaves a very little time
window open, but that's only a problem if module unloading is also
happening: after parsing /proc/modules, but before actually loading the
module, it is possible that an rmmod unloads (starts to unload) a
dependant module. But this does not affect booting.

--
pozsy

[Harri (harald-dunkel)]

Pozsar Balazs wrote:
>
> Well, that's really wierd, It Should Work(tm) :)
> Did you apply both patches (Rusty's + mine), or only the latter?
>

I hadn't seen Rusty's patch on Debian's bts, until you mentioned
it. I have applied both patches now, and rebooted twice: By now
it worked. But that's what I thought before.

> Could you send me debug output please? The first time I met the problem,
> I used a modprobe wrapper which dumped /proc/modules and modprobe
> stdout/stderr to a temp file.
>
If the problem comes back then I will do.

> I would like to also mention, that my patch leaves a very little time
> window open, but that's only a problem if module unloading is also
> happening: after parsing /proc/modules, but before actually loading the
> module, it is possible that an rmmod unloads (starts to unload) a
> dependant module. But this does not affect booting.
>
>

Are there several modprobe's running in parallel? Or does modprobe
return SUCCESS while the kernel is still busy "making the module
usable somehow"?

Regards

Harri

[Marco d'Itri (md)]

On Nov 06, Harald Dunkel <email address hidden> wrote:

> I hadn't seen Rusty's patch on Debian's bts, until you mentioned
> it. I have applied both patches now, and rebooted twice: By now
> it worked. But that's what I thought before.
It cannot be relevant, because when the bug is triggered / is still
read-only.

> Are there several modprobe's running in parallel? Or does modprobe
Yes.

--
ciao,
Marco

[Marco d'Itri (md)]

# Automatically generated email from bts, devscripts version 2.9.8
reopen 333052

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 06 Nov 2005 18:05:44 +0100
From: Harald Dunkel <email address hidden>
To: Pozsar Balazs <email address hidden>
CC: <email address hidden>, Kay Sievers <email address hidden>,
 Rusty Russell <email address hidden>, <email address hidden>
Subject: Re: Bug#333052: 2.6.14, udev: unknown symbols for ehci_hcd

--------------enigAFEA4EF0EA532F22C33CAFDC
Content-Type: multipart/mixed;
 boundary="------------050900040809070701040700"

This is a multi-part message in MIME format.
--------------050900040809070701040700
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Pozsar Balazs wrote:
>
> Well, that's really wierd, It Should Work(tm) :)
> Did you apply both patches (Rusty's + mine), or only the latter?
>

I hadn't seen Rusty's patch on Debian's bts, until you mentioned
it. I have applied both patches now, and rebooted twice: By now
it worked. But that's what I thought before.

> Could you send me debug output please? The first time I met the problem,
> I used a modprobe wrapper which dumped /proc/modules and modprobe
> stdout/stderr to a temp file.
>
If the problem comes back then I will do.

> I would like to also mention, that my patch leaves a very little time
> window open, but that's only a problem if module unloading is also
> happening: after parsing /proc/modules, but before actually loading the
> module, it is possible that an rmmod unloads (starts to unload) a
> dependant module. But this does not affect booting.
>
>

Are there several modprobe's running in parallel? Or does modprobe
return SUCCESS while the kernel is still busy "making the module
usable somehow"?

Regards

Harri

--------------050900040809070701040700
Content-Type: application/x-tar;
 name="modprobe.patch.gz"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="modprobe.patch.gz"

H4sICLEubkMAA21vZHByb2JlLnBhdGNoAJVUbW/TMBD+nP6KWyRY0sZt025sdBSGeJ1U9gk+
ICFFIXE6a6ld2Q5jvPx37uykrHtjWGlSn893z3NvjDFYqbKpORNSWGaVqg2bDidsrfneUGmx
HOH5WquvfFgEk/F4n9FzCOOns+nhbH8yHHcLBmM87w0Gg3tM3rCWjtlkD9LpLEWDT29YOz4G
Nn0yTZ7AgD4HcHzcg+DtyeIN9NFOkXlX5gilxVmuoV8LyXHXGxibaztD+agPH8TyzIJUFr5y
RNdIy0u45HYI8FrJXQtVLuoh9EeoftUszKFSay6jcETiUSsOEwh1GJNTUUG0c/VK7DEfTJN0
gqAP9pJp6lCjstPm0upLePwYjNXFau33CcVM5isew3wO4xh+kjpBP6lAWODfhbEmgcbwguCD
MGDPOP6ELsGZcPBZ4J10emSIZIH3OienVp1Hp58WCyQBXyTRcBobbH4LuBBkdM/FGHbmQIK4
N2gN7Nyr7/WCpbIKVGOPeoOHXgSMxIY78rxuhxjWhnv5VgBcHIOgv7k9h9wq4d3F/wkhZOFt
3v/HBJalbcw9HDBjGxY72zUSLlReCrkMY/j1C64ffpJ1dxx3RoLG1Jyvo9Q1VXzUSivNeUSd
8ldS1MrwaKuSuzOH0bVTK/l9HTt4IYlxP3P7qz7gTg90orlttIT0yLXOYbqXTLD/3de1ji9G
XEhYrLNvXK/ypSiSdo/GUGSEkgkUq5JcZmptyTqCwklAbbRQxTk2f6U0hwsOtVLnCQgJRY4R
F3bXAE0rkdfiB0Zw6PNTlZjJGm9mlah5hI7Yc/rnGpViQTlCpWe+Y5E911rpKHylmrp084am
B+w+MrszeGSwChLS8my2zDky/ja+pYp99LsQO0LIVi5JTKEmUn52lQpenn7++P7k9B0goLzW
PC8vidw515L7uebLSSwlBiCjHPS6Dve5yITMvHok+QUhghczD7GdTIlvdZpPKbH1FVoJbWxm
BQakF2z4f3A2kfEtaFwQgi4IdzjzQ+k29gzZM3z/IzfsWm7Yg3LDHpybO9BdTVkjCV5bhEGh
VqtcEuhKyDJrt9F2hFsplW63/gDRsBheowcAAA==
--------------050900040809070701040700--

--------------enigAFEA4EF0EA532F22C33CAFDC
Content-Type: application/pgp-signature; name="signature.asc"
Content-De...

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 6 Nov 2005 18:21:28 +0100
From: <email address hidden> (Marco d'Itri)
To: Harald Dunkel <email address hidden>, <email address hidden>
Cc: Pozsar Balazs <email address hidden>, Kay Sievers <email address hidden>,
 Rusty Russell <email address hidden>, <email address hidden>
Subject: Re: Bug#333052: 2.6.14, udev: unknown symbols for ehci_hcd

--T4sUOijqQbZv57TR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Nov 06, Harald Dunkel <email address hidden> wrote:

> I hadn't seen Rusty's patch on Debian's bts, until you mentioned
> it. I have applied both patches now, and rebooted twice: By now
> it worked. But that's what I thought before.
It cannot be relevant, because when the bug is triggered / is still
read-only.

> Are there several modprobe's running in parallel? Or does modprobe
Yes.

--=20
ciao,
Marco

--T4sUOijqQbZv57TR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDbjuYFGfw2OHuP7ERAiEcAJ9GpF9Fr3ylZvPzkZXgt695dDoqYQCfa8ix
CqGrKFXmRSQ33LiVcQ+QIhA=
=+Noo
-----END PGP SIGNATURE-----

--T4sUOijqQbZv57TR--

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sun, 6 Nov 2005 18:25:15 +0100
From: Marco d'Itri <email address hidden>
To: <email address hidden>
Subject: reopening 333052

# Automatically generated email from bts, devscripts version 2.9.8
reopen 333052

[Harri (harald-dunkel)]

Marco d'Itri wrote:
>
>>Are there several modprobe's running in parallel? Or does modprobe
>
> Yes.
>
Is this supposed to be synchronized in user space, or in the
kernel?

Regards

Harri

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 07 Nov 2005 07:00:50 +0100
From: Harald Dunkel <email address hidden>
To: Marco d'Itri <email address hidden>
CC: <email address hidden>, Pozsar Balazs <email address hidden>, Kay Sievers <email address hidden>,
 Rusty Russell <email address hidden>, <email address hidden>
Subject: Re: Bug#333052: 2.6.14, udev: unknown symbols for ehci_hcd

--------------enigF1F7641E97792797838F7F4D
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Marco d'Itri wrote:
>
>>Are there several modprobe's running in parallel? Or does modprobe
>
> Yes.
>
Is this supposed to be synchronized in user space, or in the
kernel?

Regards

Harri

--------------enigF1F7641E97792797838F7F4D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDbu2YUTlbRTxpHjcRApjJAKCD776lSH/Mal8sS2IyYcDpfkB9awCgi01H
r4zA+W+cuvgctDMfqi6lXvE=
=m00t
-----END PGP SIGNATURE-----

--------------enigF1F7641E97792797838F7F4D--

[Marco d'Itri (md)]

On Nov 08, Rusty Russell <email address hidden> wrote:

> The current simple fix for that (thanks Pozsar!) is to poll while a
> module we rely on is still loading as indicated in /proc/modules. This
> fix will be needed to cover existing kernels, even if we were to get
> fancy in new kernels.
I have *not* been able to verify this, but at least two people still
reported problems after using this patch.

--
ciao,
Marco

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 8 Nov 2005 00:19:57 +0100
From: <email address hidden> (Marco d'Itri)
To: Rusty Russell <email address hidden>
Cc: Greg KH <email address hidden>, Pozsar Balazs <email address hidden>,
 <email address hidden>, Kay Sievers <email address hidden>, <email address hidden>
Subject: Re: 2.6.14, udev: unknown symbols for ehci_hcd

--mYCpIKhGyMATD0i+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Nov 08, Rusty Russell <email address hidden> wrote:

> The current simple fix for that (thanks Pozsar!) is to poll while a
> module we rely on is still loading as indicated in /proc/modules. This
> fix will be needed to cover existing kernels, even if we were to get
> fancy in new kernels.
I have *not* been able to verify this, but at least two people still
reported problems after using this patch.

--=20
ciao,
Marco

--mYCpIKhGyMATD0i+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDb+EdFGfw2OHuP7ERAuHBAKCc56u2WPFTCV745647Q4BrqJJlHwCfaadV
hH+XjeGzfjrM1UFkM7WjJBk=
=Mlm+
-----END PGP SIGNATURE-----

--mYCpIKhGyMATD0i+--

[Marco d'Itri (md)]

# Automatically generated email from bts, devscripts version 2.9.8
found 333052 0-1

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Tue, 8 Nov 2005 17:49:46 +0100
From: Marco d'Itri <email address hidden>
To: <email address hidden>
Subject: found 333052 in 0-1

# Automatically generated email from bts, devscripts version 2.9.8
found 333052 0-1

[Marco d'Itri (md)]

# Automatically generated email from bts, devscripts version 2.9.8
notfound 333552 0-1
close 333052 3.2-pre9-4

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sun, 13 Nov 2005 00:57:56 +0100
From: Marco d'Itri <email address hidden>
To: <email address hidden>
Subject: notfound 333552 in 0-1, closing 333052

# Automatically generated email from bts, devscripts version 2.9.8
notfound 333552 0-1
close 333052 3.2-pre9-4

[Ben Collins (ben-collins)]

This seems to be fixed with newer module-init-tools, which was merged for dapper.

[Marco d'Itri (md)]

notfound 333052 3.2.2-2
thanks

On Feb 26, Dionisio Martínez Soler <email address hidden> wrote:

> Package: module-init-tools
> Version: 3.2.2-2
> Severity: grave
Get real. Look at the log kernel log, you or some package probably
configured a bad parameter:

> FATAL: Error inserting snd
> (/lib/modules/2.6.15-1-686/kernel/sound/core/snd.ko): Unknown symbol in
> module, or unknown parameter (see dmesg)

--
ciao,
Marco

[Dionisio Martínez Soler (dmsoler)]

Package: module-init-tools
Version: 3.2.2-2
Severity: grave

I don't know for sure if this is probably related to this bug, but it
seems very similar. Using linux-image-2.6.15-1-686 (v. 2.6.15-7) I get
this while loading snd_intel8x0 (both at boot time and manually with
modprobe):

------------------------------------------------
FATAL: Error inserting snd
(/lib/modules/2.6.15-1-686/kernel/sound/core/snd.ko): Unknown symbol in
module, or unknown parameter (see dmesg)
WARNING: Error running install command for snd
WARNING: Error inserting snd_timer
(/lib/modules/2.6.15-1-686/kernel/sound/core/snd-timer.ko): Unknown
symbol in module, or unknown parameter (see dmesg)
FATAL: Error inserting snd
(/lib/modules/2.6.15-1-686/kernel/sound/core/snd.ko): Unknown symbol in
module, or unknown parameter (see dmesg)
WARNING: Error running install command for snd
WARNING: Error inserting snd_timer
(/lib/modules/2.6.15-1-686/kernel/sound/core/snd-timer.ko): Unknown
symbol in module, or unknown parameter (see dmesg)
FATAL: Error inserting snd_pcm
(/lib/modules/2.6.15-1-686/kernel/sound/core/snd-pcm.ko): Unknown symbol
in module, or unknown parameter (see dmesg)
WARNING: Error running install command for snd_pcm
WARNING: Error inserting snd_ac97_codec
(/lib/modules/2.6.15-1-686/kernel/sound/pci/ac97/snd-ac97-codec.ko):
Unknown symbol in module, or unknown parameter (see dmesg)
FATAL: Error inserting snd
(/lib/modules/2.6.15-1-686/kernel/sound/core/snd.ko): Unknown symbol in
module, or unknown parameter (see dmesg)
WARNING: Error running install command for snd
WARNING: Error inserting snd_timer
(/lib/modules/2.6.15-1-686/kernel/sound/core/snd-timer.ko): Unknown
symbol in module, or unknown parameter (see dmesg)
FATAL: Error inserting snd
(/lib/modules/2.6.15-1-686/kernel/sound/core/snd.ko): Unknown symbol in
module, or unknown parameter (see dmesg)
WARNING: Error running install command for snd
WARNING: Error inserting snd_timer
(/lib/modules/2.6.15-1-686/kernel/sound/core/snd-timer.ko): Unknown
symbol in module, or unknown parameter (see dmesg)
FATAL: Error inserting snd_pcm
(/lib/modules/2.6.15-1-686/kernel/sound/core/snd-pcm.ko): Unknown symbol
in module, or unknown parameter (see dmesg)
WARNING: Error running install command for snd_pcm
WARNING: Error inserting snd_ac97_codec
(/lib/modules/2.6.15-1-686/kernel/sound/pci/ac97/snd-ac97-codec.ko):
Unknown symbol in module, or unknown parameter (see dmesg)
FATAL: Error inserting snd_intel8x0
(/lib/modules/2.6.15-1-686/kernel/sound/pci/snd-intel8x0.ko): Unknown
symbol in module, or unknown parameter (see dmesg)
FATAL: Error running install command for snd_intel8x0
-----------------------------------------------------

But using linux-image-2.6.12-1-686 (v. 2.6.12-10), the module
snd_intel8x0 loads correctly and the soundcard is working fine.

Version of udev installed in my system is 0.085-1.

Hope this could be useful. If you need further information, please ask.

Ciao,

Dionisio

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686
Locale: LANG=pt_PT...

[C.Y.M. (syphir)]

I dont think the problem you are observing is related to module-init-tools. I
am using the same version and do not see these errors. IMHO, there is something
wrong with the kernel image you are using. The best way to solve symbol
problems like that is to use the kernel-package tool and build your own
kernel-image from source.

Another suggestion would be to blacklist the alsa modules (using
/etc/modprobe.d/blacklist) that you are trying to load before you attempt to
manuall insert them. This way udev/hotplug will not be part of the problem.

[Steve Langasek (vorlon)]

# Automatically generated email from bts, devscripts version 2.9.15
severity 333052 normal

[Marco d'Itri (md)]

# Automatically generated email from bts, devscripts version 2.9.15
notfound 333052 3.2.2-2

[Marco d'Itri (md)]

# Automatically generated email from bts, devscripts version 2.9.15
severity 333052 grave

[Jan De Luyck (jan-bugs)]

Package: module-init-tools
Version: 3.2.2-3
Followup-For: Bug #333052

Hello,

I'm also being bitten by this bug, where ohci_hcd or ehci_hcd
randomly fails to load at bootup. Doing a manual modprobe afterwards
works like a charm.

The errors that I get are:

kernel: ohci_hcd: Unknown symbol usb_hcd_pci_suspend
kernel: ohci_hcd: Unknown symbol usb_hcd_resume_root_hub
kernel: ohci_hcd: Unknown symbol usb_hcd_pci_probe
kernel: ohci_hcd: Unknown symbol usb_disabled
kernel: ohci_hcd: Unknown symbol usb_calc_bus_time
kernel: ohci_hcd: Unknown symbol usb_hcd_pci_resume
kernel: ohci_hcd: Unknown symbol usb_hcd_giveback_urb
kernel: ohci_hcd: Unknown symbol usb_hcd_suspend_root_hub
kernel: ohci_hcd: Unknown symbol usb_hcd_pci_remove
kernel: ohci_hcd: Unknown symbol usb_root_hub_lost_power

Jan

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.13
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages module-init-tools depends on:
ii libc6 2.3.6.ds1-4 GNU C Library: Shared libraries
ii lsb-base 3.1-15 Linux Standard Base 3.1 init scrip

module-init-tools recommends no packages.

-- no debconf information

[Steve Langasek (vorlon)]

# Automatically generated email from bts, devscripts version 2.9.21
# non-existent version
notfound 333052 0-1
found 333052 3.2-pre1-2

[Steve Langasek (vorlon)]

# Automatically generated email from bts, devscripts version 2.9.21
reassign 333052 module-init-tools
found 333052 3.2-pre1-2
# bug does not exist in current version, work around bts v-t bug
close 333052 3.2-pre9-4

[Steve Langasek (vorlon)]

# Automatically generated email from bts, devscripts version 2.9.21
# hmm, maybe found here after all
found 333052 3.2.2-3

[Steve Langasek (vorlon)]

severity 333052 important
thanks

Ok, there's been precisely one report of this problem by a user in the last
9 months. While it's possible that there is still a race condition in
module-init-tools, it seems unlikely that a real bug of this nature would
have been hit by so few people when m-i-t is a package used by so many.

In any case, even if there is still a real bug here, it does not appear to
make the package unusable, so I don't see any reason to treat this as RC.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

[Marco d'Itri (md)]

# Automatically generated email from bts, devscripts version 2.9.27
notfound 333052 3.2.2-3