Bug#333522: udev: modules randomly aren't loaded at startup - "Unknown symbol"
Jan Taegert
Version: 0.070-4
Severity: grave
Hello,
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).
Unfortunately this misbehaviour is hard to reproduce because sometimes
it works sometimes not, and the concerning modules are changing on every
startup (I tried at least 10 times).
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)
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.
I wonder if other users have similar problems, but maybe it has to do
with some special kernel/chipset combination.
With prior udev (hotplug) - versions module loading always went fine, so
I assume this has to do with the new integrated coldplug/hotplug method,
which I really like because bootup is a lot faster now. But it is a
little bit annoying if after every bootup I have first to look which
devices are missing now and modprobe the modules manually.
Please tell me if you need more information (more logs, kernel-config,
etc.),
thanks,
jan.
-- Package-specific info:
-- /etc/udev/rules.d/:
/etc/udev/rules.d/:
insgesamt 0
lrwxrwxrwx 1 root root 20 2005-10-11 23:49 020_permissions.rules ->
../permissions.rules
lrwxrwxrwx 1 root root 23 2005-09-30 00:46 025_libsane-extras.rules ->
../libsane-extras.rules
lrwxrwxrwx 1 root root 16 2005-09-30 00:46 025_libsane.rules ->
../libsane.rules
lrwxrwxrwx 1 root root 12 2005-10-11 23:49 050_hal-plugdev.rules ->
../hal.rules
lrwxrwxrwx 1 root root 19 2005-10-11 23:49 cd-aliases.rules ->
../cd-aliases.rules
lrwxrwxrwx 1 root root 13 2005-10-11 23:49 udev.rules -> ../udev.rules
lrwxrwxrwx 1 root root 19 2005-10-11 23:49 z20_persistent.rules ->
../persistent.rules
lrwxrwxrwx 1 root root 12 2005-10-11 23:49 z50_run.rules -> ../run.rules
lrwxrwxrwx 1 root root 16 2005-10-12 10:51 z55_hotplug.rules ->
../hotplug.rules
lrwxrwxrwx 1 root root 19 2005-08-03 00:40 z60_alsa-utils.rules ->
../alsa-utils.rules
lrwxrwxrwx 1 root root 15 2005-09-20 13:37 z60_hdparm.rules ->
../hdparm.rules
lrwxrwxrwx 1 root root 17 2005-10-11 23:49 z70_hotplugd.rules ->
../hotplugd.rules
-- /sys/:
/sys/block/fd0/dev
/sys/block/hda/dev
/sys/block/hda/hda1/dev
/sys/block/hda/hda2/dev
/sys/block/hda/hda3/dev
/sys/block/hda/hda4/dev
/sys/block/hda/hda5/dev
/sys/block/hda/hda6/dev
/sys/block/hda/hda7/dev
/sys/block/hda/hda8/dev
/sys/block/hdc/dev
/sys/block/hdd/dev
/sys/block/ram0/dev
/sys/block/ram10/dev
/sys/block/ram11/dev
/sys/block/ram12/dev
/sys/block/ram13/dev
/sys/block/ram14/dev
/sys/block/ram15/dev
/sys/block/ram1/dev
/sys/block/ram2/dev
/sys/block/ram3/dev
/sys/block/ram4/dev
/sys/block/ram5/dev
/sys/block/ram6/dev
/sys/block/ram7/dev
/sys/block/ram8/dev
/sys/block/ram9/dev
/sys/class/drm/card0/dev
/sys/class/input/event0/dev
/sys/class/input/event1/dev
/sys/class/input/event2/dev
/sys/class/input/mice/dev
/sys/class/input/mouse0/dev
/sys/class/misc/agpgart/dev
/sys/class/misc/hpet/dev
/sys/class/misc/psaux/dev
/sys/class/misc/rtc/dev
/sys/class/sound/controlC0/dev
/sys/class/sound/controlC1/dev
/sys/class/sound/dmmidi1/dev
/sys/class/sound/midi1/dev
/sys/class/sound/midiC1D0/dev
/sys/class/sound/pcmC0D0c/dev
/sys/class/sound/pcmC0D0p/dev
/sys/class/sound/pcmC0D1c/dev
/sys/class/sound/pcmC0D1p/dev
/sys/class/sound/pcmC1D0c/dev
/sys/class/sound/pcmC1D0p/dev
/sys/class/sound/seq/dev
/sys/class/sound/timer/dev
/sys/class/usb/lp0/dev
-- Kernel configuration:
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (100, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13debmv1
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Versions of packages udev depends on:
ii initscripts 2.86.ds1-4 Standard scripts needed for
bootin
ii libc6 2.3.5-6 GNU C Library: Shared
libraries an
ii libselinux1 1.26-1 SELinux shared libraries
ii lsb-base 3.0-9 Linux Standard Base 3.0
init scrip
ii makedev 2.3.1-78 creates device files in /dev
ii sed 4.1.4-4 The GNU sed stream editor
udev recommends no packages.
-- debconf information:
udev/devfs-warning:
udev/reboot-warning:
Jonas Smedegaard
Hash: SHA1
On Wed, 12 Oct 2005 13:06:18 +0200
m...@Linux.IT (Marco d'Itri) wrote:
> On Oct 12, Jan Taegert <j...@cosmopilot.net> 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.
You could also test with a yaird-baked initramfs instead of one made
using initramfs-tools.
No, this is not meant as advertising for yaird (it has its own set of
problems!), but initramfs-tools includes udev on the ramdisk (I
believe), and yaird does not. So for debugging this yaird sounds
relevant.
Oh - and now I think about it: If I am right that udev gets included on
initramfs-tools-based ramdisks, have you tried regenerating the ramdisk
(with initramfs-tools) after the udev update?
Kind regards,
- Jonas
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
- Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDTPRFn7DbMsAkQLgRAhE7AJ9xLegkRHoZPR6xOoMAaEYpIkJoBACgkPva
xqu6eX/ioftBhFFsqPnjAcQ=
=Ay+M
-----END PGP SIGNATURE-----
Marco d'Itri
> You could also test with a yaird-baked initramfs instead of one made
> using initramfs-tools.
The point is that bug can be reproduced only *without* the initramfs.
--
ciao,
Marco
Jan Taegert
> 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?
Sorry, but I'm afraid I'm not skilled enough to do that.
>>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.
Recompiled my kernel with debian 2.6.13 source (same config), but there
is no difference.
Actually the bootup process seems to be less problematic, but this can
be by accident: Tried 5 times, 3 of them without any errors(!), the
other the usual "snd_*/*hcd/8250* ... Unknown symbol" error.
jan.
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Marco d'Itri
> 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
Harald Dunkel
>
> 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
> 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
> 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