You are not logged in.
- Topics: Active | Unanswered
#1 2006-04-28 19:12:01
- Gullible Jones
- Member
- Registered: 2004-12-29
- Posts: 4,863
udev start times doubled after last update
After upgrading to udev 091-2, udev takes almost twice as long to start as before. Evidently the last update fixed a "weird timing issue in start_udev" - would that have something to do with this? If so, is there a workaround or am I stuck with it?
Offline
#2 2006-04-29 00:28:15
- stonecrest
- Member
- From: Boulder
- Registered: 2005-01-22
- Posts: 1,190
Re: udev start times doubled after last update
Why don't you ask the udev folks?
I am a gated community.
Offline
#3 2006-04-29 00:59:05
- Gullible Jones
- Member
- Registered: 2004-12-29
- Posts: 4,863
Re: udev start times doubled after last update
Because the update wasn't to udev proper, it was to Arch's udev package and involved patches from our package maintainers.
Offline
#4 2006-04-29 10:15:35
- brain0
- Developer
- From: Aachen - Germany
- Registered: 2005-01-03
- Posts: 1,382
Re: udev start times doubled after last update
Udev from 090-1 to 091-1 exited before all uevents had been processed.This lead to missing device nodes on many machines resulting in failing fs check and mounts. It now waits for what had been done in background before. It may be slower for you, but it is necessary.
Offline
#5 2006-04-29 16:32:02
- Gullible Jones
- Member
- Registered: 2004-12-29
- Posts: 4,863
Re: udev start times doubled after last update
... And why, pray tell, does loading the modules take so long in the first place, when they're loaded in parallel and the time it takes to load them is negligable? Judging from boot charts I made at one point, it looked like there was a lot of waiting going on in there, and I'm guessing that that's probably not necessary any more...
(Also... If a certain module is required for a device or filesystem that is mounted on boot, wouldn't it be better to just include it in the initrd?)
Offline
#6 2006-04-29 22:13:43
- brain0
- Developer
- From: Aachen - Germany
- Registered: 2005-01-03
- Posts: 1,382
Re: udev start times doubled after last update
(Also... If a certain module is required for a device or filesystem that is mounted on boot, wouldn't it be better to just include it in the initrd?)
No, absolutely not. Initrd only contains what is necessary to mount root and launch init. Besides, uevents is not only loading modules.
Offline
#7 2006-04-30 00:25:39
- iphitus
- Forum Fellow
- From: Melbourne, Australia
- Registered: 2004-10-09
- Posts: 4,927
Re: udev start times doubled after last update
... And why, pray tell, does loading the modules take so long in the first place, when they're loaded in parallel and the time it takes to load them is negligable? Judging from boot charts I made at one point, it looked like there was a lot of waiting going on in there, and I'm guessing that that's probably not necessary any more...
you'd be surprised. my wireless card modules, either ndiswrapper or ipw2100 can take over a second to load.
(Also... If a certain module is required for a device or filesystem that is mounted on boot, wouldn't it be better to just include it in the initrd?)
if its needed to mount /, then it is already in the initrd and is already loaded. if it werent in initrd, you would never have made it to udev as your root wouldnt have been mounted.
Offline
#8 2006-05-01 12:06:50
- vidal
- Member
- Registered: 2006-04-03
- Posts: 12
Re: udev start times doubled after last update
One of the reasons why module loading is slow is the way it's being done in /lib/udev/load-modules.sh. Modifying the script so that it just loads the modules without any checking cuts module loading time by 1/3. You lose the module blacklisting feature, though.
Offline