You are not logged in.
Pages: 1
All of the sudden, the udev daemon is taking about 7 seconds to start... I'm pretty sure that version 0.78 took all of 1 second. What's happening here? Is udev also loading modules on startup now, or something?
Offline
I've got the same problem. It started when they dumped hotplug. I think it because udev takes over the things hotplug used to take care of.
Offline
I have the same issue except that I have one box where it takes about 3 secs to start and a second where it takes 55 secs.
Offline
It hadn't changed here.
Arch - It's something refreshing
Offline
All of the sudden, the udev daemon is taking about 7 seconds to start... I'm pretty sure that version 0.78 took all of 1 second. What's happening here? Is udev also loading modules on startup now, or something?
If you can't spare those 6 seconds you need to re-prioritize your life.
Offline
Offline
For the record, udev is now able to resend udev events for pre-existing devices when it is started. In essence, this mechanism will replace the running of hwdetect, while still respecting MOD_AUTOLOAD and MOD_BLACKLIST... it's in the works, and you may be hitting something odd with it in flux now.
Offline
It's seems like maybe my flash drives are taking a little longer to be recognized when I plug them in, too.
oz
Offline
Ugh... Udev is now taking longer to start than the coldplug script used to. :shock: And the new version (081-1) still can't load modules by itself... *Bangs head*
Offline
Ugh... Udev is now taking longer to start than the coldplug script used to. :shock: And the new version (081-1) still can't load modules by itself... *Bangs head*
Wait... what? Are you using MOD_AUTOLOAD="yes" ? If so, it should load modules just fine on boot. That is, of course, assuming this is the version I'm thinking of... do you think you could bootchart your system?
Mine here: http://phraktured.net/gallery/albums/sc … _boot2.png
Offline
I thought this new version was suppposed to be able to load modules without MOD_AUTOLOAD being enabled? Oh wait a minute, the "loading modules" message just flashes by instead of sticking around for a few seconds... I guess that MOD_AUTOLOAD now uses udev's capabilities rather than the hwdetect script?
At any rate, how do I make a boot chart?
Offline
Install bootchart from [community] and follow the post-install instructions ;-)
Offline
I've just noticed another weird thing... On first boot after a new install, udev starts *instantly*. After that, both the versions from Testing and Current take a while to start. No idea why this would be.
Anyway, a bootchart is coming right up...
Offline
Apparently (from posts I've seen on the ML) you need kernel 2.6.15 or later for udev modprobing to work... could that be the problem?
Offline
I'm using 2.6.15.1, and modprobing works fine.
My boot chart, like Phrak's, now shows start_udev taking a little under five seconds. The thing is, it differs between different filesystems... On ext3 it takes over twice as long as on JFS. Does the latest version (081) use scads of tiny little files or something?
Anyway, here is my bootchart.
Offline
Udev at boot is extra slow here (about 12 seconds...). Just hope in the new 082 version today released
Mortuus in anima, curam gero cutis
Offline
http://img27.imageshack.us/my.php?image … 1063hf.png
Here is my bootchart. udev takes indeed much time than on others distros, but I don't know why. It has always been like this on Arch for me (for 3 months) with 2.6.14 or 15 kernels.
Offline
hmm, it's normal that it takes longer because it does now a lot more then before. In the end my boot speed increased again over hwdetect.
I agree udev's performance could increase let's hope the udev devs will improve it, but here i have the fastest arch then ever.
greetings
tpowa
Offline
What I find odd in my boot chart is that start_udev continues to run long after udevd has started up and loaded all the modules. There a reason for this?
(BTW, I'm using Testing branch. Those not using Testing might not notice anything unusual...)
Offline
/ agrees with tpowa
My arch system takes 20 seconds to boot now. I'm running an Athlon XP 3200+ w/ 2GB of PC3200, but it works about the same with 512MB of PC2100 installed.
Offline
udev seems pretty fast to me -- less than 3 seconds on screen, though i guess it continues longer, as GJ asked? much better than hotplug, at least.
bootchart is cool little utility, i made one for comparison:
http://datalink.homelinux.com/~sero/gifs/bootchart.png
one question, does anyone know why reiserfsck is running, and not just once but twice? :?:
Offline
If you're not using Testing, it's because you don't have the relevent version of udev.
What I meant about it going on too long was that "Starting UDev Daemon" stays on the screen for a over 5 seconds, but the udev daemon has started up and loaded all the modules after a little over one second.
Your use of ReiserFS brings up something interesting though... ReiserFS (~3.5 seconds) is very good at dealing with lots of small files, JFS (~5.5 seconds) is almost as good at that, and ext3 (12 seconds, according to my watch) is pretty bad at dealing with lots of tiny files. Something of a pattern there... Maybe the read speed for the little files in /proc and /sys is involved? But that shouldn't matter, /proc and /sys are virtual filesystems!
(Re reiserfsck running twice, I don't know. It probably does that for the same reason that other things in bootcharts do... Unless you've got your ReiserFS partitions specified for fscking in /etc/fstab, which isn't necessary, as ReiserFS filesystems are (stupidly IMHO) fscked on mount.)
Offline
d'oh! that was it, thanks. a holdover from when i had some ext3. shaved 3 secs off my time, too.
Offline
If you're not using Testing, it's because you don't have the relevent version of udev.
What I meant about it going on too long was that "Starting UDev Daemon" stays on the screen for a over 5 seconds, but the udev daemon has started up and loaded all the modules after a little over one second.
You do have a point there - I'll have to profile that... check it out. There are some waits in there, specifically because most of the stuff after start_udev requires the device nodes to be there, and it's all async, so there's no real way to wait for it.
I'll look into that.
Offline
udev 082 is delayed, cd symlinking is broken until this is fixed 081 should be used. just for your information why no udev update happens atm.
Offline
Pages: 1