Slow bootup as "Loading UDev uevent" takes its time at bootup

Flying Saxman · 2008-03-13 15:20:22

Also got the same output.

fwojciec · 2008-03-13 16:00:29

Looking at the initscripts the only things that happens during "udev uevent" is the execution of these two commands:

    /sbin/udevadm trigger
    /sbin/udevadm settle

Which would mean, if I understand things correctly, that the problem you guys are experiencing is directly related to udev and not the initscripts themselves (in other words it is not specific to Arch). Perhaps udev bugtracker/mailing list would be the best place to ask question about this.

shining · 2008-03-13 16:03:34

fwojciec wrote:

Looking at the initscripts the only things that happens during "udev uevent" is the execution of these two commands:
    /sbin/udevadm trigger
    /sbin/udevadm settle
Which would mean, if I understand things correctly, that the problem you guys are experiencing is directly related to udev and not the initscripts themselves (in other words it is not specific to Arch). Perhaps udev bugtracker/mailing list would be the best place to ask question about this.

Arch has several specific rules in /etc/udev/rules.d/
With the previous udev package, the udev uevent step was awfully slow because of a bogus rule.
It has been removed now, and udev loading is fast again for many users.

fwojciec · 2008-03-13 16:03:44

Ibex wrote:

Can somebody (who's system don't has the problem) list the rules in the rules.d directory?

Sure thing:

$ ls -la /etc/udev/rules.d/
total 89K
drwxr-xr-x 2 root root  864 2008-03-12 10:36 ./
drwxr-xr-x 3 root root  144 2008-03-10 18:19 ../
-rw-r--r-- 1 root root  191 2008-03-10 15:42 05-udev-early.rules
-rw-r--r-- 1 root root  174 2008-03-10 15:42 40-pilot-links.rules
-rw-r--r-- 1 root root 5.1K 2008-03-10 15:42 50-udev-default.rules
-rw-r--r-- 1 root root 8.0K 2008-03-10 15:42 51-arch.rules
-rw-r--r-- 1 root root  206 2008-03-10 15:42 60-cdrom_id.rules
-rw-r--r-- 1 root root 1.1K 2008-03-12 07:23 60-pcmcia.rules
-rw-r--r-- 1 root root 1.5K 2008-03-10 15:42 60-persistent-input.rules
-rw-r--r-- 1 root root 1.3K 2008-03-10 15:42 60-persistent-storage-tape.rules
-rw-r--r-- 1 root root 3.6K 2008-03-10 15:42 60-persistent-storage.rules
-rw-r--r-- 1 root root  421 2008-03-10 15:42 61-persistent-storage-edd.rules
-rw-r--r-- 1 root root  107 2008-03-10 15:42 64-device-mapper.rules
-rw-r--r-- 1 root root  735 2008-03-10 15:42 64-md-raid.rules
-rw-r--r-- 1 root root  390 2008-03-10 15:42 75-cd-aliases-generator.rules.optional
-rw-r--r-- 1 root root 2.2K 2008-03-10 15:42 75-persistent-net-generator.rules.optional
-rw-r--r-- 1 root root  837 2008-03-10 15:42 80-drivers.rules
-rw-r--r-- 1 root root  194 2008-02-20 19:32 85-bithead.rules
-rw-r--r-- 1 root root   82 2007-10-28 16:43 90-hal.rules
-rw-r--r-- 1 root root  233 2008-03-10 15:42 95-udev-late.rules
-rw-r--r-- 1 root root   28 2008-03-04 16:23 99-fuse.rules
-rw-r--r-- 1 root root  201 2008-01-07 10:15 device-mapper.rules

The only customization is the 85-bithead.rules file, but it shouldn't change anything -- it just runs some scripts when I connect my USB soundcard.

shining wrote:

Arch has several specific rules in /etc/udev/rules.d/
With the previous udev package, the udev uevent step was awfully slow because of a bogus rule.
It has been removed now, and udev loading is fast again for many users.

So I guess this problem could very well qualify as something to be reported on the Arch bug tracker -- perhaps some further refinements to the rules are possible.

Last edited by fwojciec (2008-03-13 16:07:01)

Ibex · 2008-03-14 08:03:15

The contents of my /etc/udev/rules.d/

05-udev-early.rules
10-own.rules
40-pilot-links.rules
50-udev-default.rules
51-arch.rules
60-cdrom_id.rules
60-pcmcia.rules
60-persistent-input.rules
60-persistent-storage-tape.rules
60-persistent-storage.rules
61-persistent-storage-edd.rules
64-device-mapper.rules
64-md-raid.rules
75-cd-aliases-generator.rules.optional
75-persistent-net-generator.rules.optional
80-drivers.rules
95-udev-late.rules
99-btnx.rules
99-fuse.rules
bluetooth.rules
device-mapper.rules
udev.rules.pacsave

I noticed that when I do "udevadm trigger" it does that instantly. But "udevadm settle" takes half a minute! Second time i do that command, it is done withing a part of a second. But when I do it after the "udevadm trigger", its taking a long time.

Maybe if there is a bogus rule in the above directory, I can try to remove them all, reinstall udev so it fills the directory with new files?

=========================

Edit: I tried the above myself. Removed the whole /etc/udev-directory and reinstall udev. Directory was created with a bunch of new files. I rebooted and the udev events where as fast as used to be. A second or two. Unfortunately, My computer was not be able to find a valid filesystem on /dev/mapper/root (I'm using encrypted disks by LUKS) so I had to restore my backuped "old" rules to start up again.
So, the problem is in the rules. I'm now going to reinstall udev again and check the new rule-files with my old one to find the missing rule that makes my system boot.

=========================

Second edit: It seems like my own 10-own.rules is making it all slow.

They let my system know which networkcard needs what name:

SUBSYSTEM=="net", ATTRS{address}=="00:1c:23:2f:d5:28", NAME="lan0"
SUBSYSTEM=="net", ATTRS{address}=="00:1d:e0:36:a6:21", NAME="wlan0"

Without them, the names of my networkcards are not wlan0 and lan0, so my network isn't working. How do I fix that? (I'd realy like to use the names lan0 and wlan0)

Last edited by Ibex (2008-03-14 09:40:30)

attila · 2008-03-14 13:52:01

@ibex Have you ever tried the rule from http://reactivated.net/writing_udev_rul … mple-netif as a test instead of the suggestion of the readme? Do you have alias lines in the /etc/modprobe.conf for lan0 and wlan0? Perhaps this can speed up something but sorry, i don't know it exactly.

schivmeister · 2008-03-14 14:25:53

Shining: so it was that loop?

"Sorry but we're doing this til we find a better way"

ST.x · 2008-03-14 14:45:01

This is mine:

$ ls -la /etc/udev/rules.d/
total 140
drwxr-xr-x 2 root root  4096 2008-03-13 20:05 .
drwxr-xr-x 3 root root  4096 2008-03-13 18:50 ..
-rw-r--r-- 1 root root   191 2008-03-11 06:42 05-udev-early.rules
-rw-r--r-- 1 root root   174 2008-03-11 06:42 40-pilot-links.rules
-rw-r--r-- 1 root root  5165 2008-03-11 06:42 50-udev-default.rules
-rw-r--r-- 1 root root  8129 2008-03-11 06:42 51-arch.rules
-rw-r--r-- 1 root root   206 2008-03-11 06:42 60-cdrom_id.rules
-rw-r--r-- 1 root root  1098 2007-11-16 06:53 60-pcmcia.rules
-rw-r--r-- 1 root root  1434 2008-03-11 06:42 60-persistent-input.rules
-rw-r--r-- 1 root root  1255 2008-03-11 06:42 60-persistent-storage-tape.rules
-rw-r--r-- 1 root root  3592 2008-03-11 06:42 60-persistent-storage.rules
-rw-r--r-- 1 root root   421 2008-03-11 06:42 61-persistent-storage-edd.rules
-rw-r--r-- 1 root root   107 2008-03-11 06:42 64-device-mapper.rules
-rw-r--r-- 1 root root   735 2008-03-11 06:42 64-md-raid.rules
-rw-r--r-- 1 root root   390 2008-03-11 06:42 75-cd-aliases-generator.rules.optional
-rw-r--r-- 1 root root  2251 2008-03-11 06:42 75-persistent-net-generator.rules.optional
-rw-r--r-- 1 root root   837 2008-03-11 06:42 80-drivers.rules
-rw-r--r-- 1 root root    82 2007-10-29 06:55 90-hal.rules
-rw-r--r-- 1 root root   233 2008-03-11 06:42 95-udev-late.rules
-rw-r--r-- 1 root root    28 2008-01-08 03:16 99-fuse.rules
-rw-r--r-- 1 root root   201 2008-01-08 02:15 device-mapper.rules
-rw-r--r-- 1 root root 21362 2008-03-13 20:05 udev.rules
-rw-r--r-- 1 root root 21362 2008-02-16 17:36 udev.rules.pacsave

Hmm I saved udev.rules.pacsave as udev.rules and my system still boots fine, I also read the readme that came with this udev update and found that I didnt require any real modifications of the current rules, I also cleared modprobe.conf like it said. Just wondering if theres supposed to be a udev.rules file there since the others who posted dont have it there.

shining · 2008-03-14 17:01:55

schivmeister wrote:

Shining: so it was that loop?
"Sorry but we're doing this til we find a better way"

Not sure what you mean, but here it is :
http://www.archlinux.org/pipermail/arch … 04913.html

shining · 2008-03-14 17:02:44

ST.x wrote:

Hmm I saved udev.rules.pacsave as udev.rules and my system still boots fine, I also read the readme that came with this udev update and found that I didnt require any real modifications of the current rules, I also cleared modprobe.conf like it said. Just wondering if theres supposed to be a udev.rules file there since the others who posted dont have it there.

Remove it, it is covered by the other files, mostly by 51-arch.rules

schivmeister · 2008-03-15 06:08:09

Ahh, not what i thought.

Ibex · 2008-03-15 15:30:05

attila wrote:

@ibex Have you ever tried the rule from http://reactivated.net/writing_udev_rul … mple-netif as a test instead of the suggestion of the readme? Do you have alias lines in the /etc/modprobe.conf for lan0 and wlan0? Perhaps this can speed up something but sorry, i don't know it exactly.

I don't understand what you mean. The methods in the link and in the readme are the same as I use in the bad-working rule I posted above?

attila · 2008-03-15 17:40:15

Ibex wrote:

don't understand what you mean. The methods in the link and in the readme are the same as I use in the bad-working rule I posted above?

You use this line
SUBSYSTEM=="net", ATTRS{address}=="00:1c:23:2f:d5:28", NAME="lan0"
and the link use this
KERNEL=="eth*", ATTR{address}=="00:1c:23:2f:d5:28", NAME="lan0"
I don't thay this will works better but perhaps yes.

praka123 · 2008-03-15 18:22:07

yes,I can also confirm this problem in a latest archlinux ftp install.
for me,udev shows busy status for around 10-12 seconds
I was actually searching for any posts regarding this problem
I am having a nvidia 7300GT card(pcie) using module "nvidia" else my pc is p4 prescott 2.8Ghz 915GV based with 384MB RAM
below is my /etc/rc.conf:

# Scan hardware and load required modules at bootup
MOD_AUTOLOAD="yes"
# Module Blacklist - modules in this list will never be loaded by udev
MOD_BLACKLIST=(intel_agp)
MODULES=(8139cp 8139too it87 mii slhc ppp_generic ac97_bus snd-mixer-oss snd-pcm-oss snd-page-alloc snd-pcm snd-timer snd snd-ac97-codec snd-intel8x0 soundcore)
DAEMONS=(syslog-ng hal iptables network !ppp !netfs crond)

@Ibex:

[root@myhost ~]# cat /etc/udev/
readme-udev-arch.txt  rules.d/              udev.conf
[root@myhost ~]# cat /etc/udev/rules.d/
05-udev-early.rules
40-pilot-links.rules
50-udev-default.rules
51-arch.rules
60-cdrom_id.rules
60-pcmcia.rules
60-persistent-input.rules
60-persistent-storage-tape.rules
60-persistent-storage.rules
61-persistent-storage-edd.rules
64-device-mapper.rules
64-md-raid.rules
75-cd-aliases-generator.rules.optional
75-persistent-net-generator.rules.optional
80-drivers.rules
90-hal.rules
95-udev-late.rules
99-fuse.rules
device-mapper.rules
microcode.rules
udev.rules.pacsave

attila · 2008-03-15 19:32:17

@praka123 Only a little hint about your rc.conf: MOD_BLACKLIST is no longer used so you have to append "!intel_agp" to your MODULES array.

MoonSwan · 2008-03-15 22:23:58

@attila, From the readme file accompanying the latest updates to udev:

* Blacklisting:
---------------
- means udev will never try to load the module, even if MOD_AUTOLOAD="yes"
is set.

You can do this in 2 ways:
- MOD_BLACKLIST=(moduleA moduleB)
- MODULES=(!moduleA !moduleB)

praka123 · 2008-03-16 03:55:22

^which is true? :?
anyways,intel_agp is not loading,that I am sure of! (I have a nvidia card and disabled onboard intel graphix)

attila · 2008-03-16 07:16:20

@MoonSwan and praka123 See this http://bugs.archlinux.org/task/8920 why i say my warning but it seems that the devs let MOD_BLACKLIST survice. Sorry, this was my my mistake.

shining · 2008-03-16 09:48:37

attila wrote:

@MoonSwan and praka123 See this http://bugs.archlinux.org/task/8920 why i say my warning but it seems that the devs let MOD_BLACKLIST survice. Sorry, this was my my mistake.

It's deprecated, which means it lets the users the time to switch before the next release where it will be removed.
Even though MOD_BLACKLIST still works now, users should still stop using it.

shining · 2008-03-16 09:49:31

praka123 wrote:

^which is true? :?
anyways,intel_agp is not loading,that I am sure of! (I have a nvidia card and disabled onboard intel graphix)

You can't use intel agp with nvidia card?

praka123 · 2008-03-16 14:40:49

^huh?intel_agp is loaded earlier.after blacklisting ,intel_agp is not loading.
actually I dont want onboard gfx,hence disabled.

schivmeister · 2008-03-16 15:21:18

maybe you could try triple-head

Ibex · 2008-03-18 08:28:40

attila wrote:

Ibex wrote:
don't understand what you mean. The methods in the link and in the readme are the same as I use in the bad-working rule I posted above?
You use this line
SUBSYSTEM=="net", ATTRS{address}=="00:1c:23:2f:d5:28", NAME="lan0"
and the link use this
KERNEL=="eth*", ATTR{address}=="00:1c:23:2f:d5:28", NAME="lan0"
I don't thay this will works better but perhaps yes.

Does not work.

And the two lines are still making my boot slow. Does anyone else has an idea how to fix this issue? I want my wired networkcard called lan0 and my wireless wlan0. but rules like those I posted before and the suggestion above makes no difference.

Flying Saxman · 2008-03-20 16:23:27

I found the problem by trying around: It is the file "/etc/udev/rules.d/99-btnx.rules". If you have got an actual version of btnx installed, you do not need it anymore but unfortunately it did not get removed during the update, where it got deleted out of btnx (newer versions of btnx, like the current one in AUR) do not have this file anymore, so can safely delete it (I did it and my btnx still works but UDev uevent is now amazingly fast, from almost 1minute 20seconds to only about 5 (five!) seconds!)!

Edit: I already posted it in the bugtracker!

Last edited by Flying Saxman (2008-03-20 16:23:58)

_clark_ · 2008-05-06 05:20:44

Hello,

First, please excuse my poor english language but it is not my native language

I desagree with the last suggestions because I don't have the 99-btnx.rules file and the problem occurs yet on my system. It is very strange because it occurs randomly. And when it occurs, kde starts and run very slowly.

So I submit you two bootchart pictures. The first one shows a normal boot sequence (about 1 min boot time) and the second a bogus boot sequence (more than 2 min boot time).
The main difference is around the 22th second : in the bogus sequence, we can see a short udevd process, just after hwclock, but it's not normal : the "real" udevd process is few process down, just before the first load-modules.sh, and run up to end of the boot sequence.
In a good and quick boot sequence, this short and first udevd process dos not appear. During all the tests that I have realised, I have observed this two differents behaviors :
- only one and long udevd process => normal and quick boot sequence
- two udevd processes : the first is very short and does not seem to launch any other process => very long boot sequence with long and repetitives load-modules.sh processes.

So prehaps the problem is with udev, but I think that initscripts could be in cause too.

Clean and quick boot sequence :

Bogus and long boot sequence :

Arch Linux

#26 2008-03-13 15:20:22

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#27 2008-03-13 16:00:29

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#28 2008-03-13 16:03:34

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#29 2008-03-13 16:03:44

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#30 2008-03-14 08:03:15

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#31 2008-03-14 13:52:01

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#32 2008-03-14 14:25:53

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#33 2008-03-14 14:45:01

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#34 2008-03-14 17:01:55

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#35 2008-03-14 17:02:44

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#36 2008-03-15 06:08:09

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#37 2008-03-15 15:30:05

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#38 2008-03-15 17:40:15

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#39 2008-03-15 18:22:07

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#40 2008-03-15 19:32:17

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#41 2008-03-15 22:23:58

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#42 2008-03-16 03:55:22

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#43 2008-03-16 07:16:20

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#44 2008-03-16 09:48:37

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#45 2008-03-16 09:49:31

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#46 2008-03-16 14:40:49

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#47 2008-03-16 15:21:18

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#48 2008-03-18 08:28:40

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#49 2008-03-20 16:23:27

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

#50 2008-05-06 05:20:44

Re: Slow bootup as "Loading UDev uevent" takes its time at bootup

Board footer