You are not logged in.
I updated udev recently, and now for some reason I get 100 udevd instances:
$ ps -A | grep udevd | wc -l
100
What is wrong here? This is annoying since these processes combined are eating up a good portion of CPU.
Last edited by wakkadojo (2009-08-27 12:52:35)
Offline
Same issue here, I have 79 udevd, waste 25% CPU, 150 MB Ram
Offline
Same Problem here. At the moment i limit the cpu usage with `cpulimit -e /sbin/udevd -l 1`. Its not the best solution, but it helps.
Offline
Similar, but I only have two instances. Doesn't seem to be a bug in Arch, though - I've seen it on the Ubuntu Jaunty bugtracker too. Rolling back to an older kernel version seemed to help there. Now if I only could find the corresponding flyspray entry...
<edit>Does anyone of you possibly have an integrated Intel GM45 chipset? I do. This thread might cover the same issue.
<edit 2>Now it's 108 instances. Highscore!
Last edited by Runiq (2009-08-28 08:26:11)
Offline
Similar, but I only have two instances.
That's my problem. High cpu usage, two udevd instances. Rolling-back udev solved the problem, but also had to roll back a number of dependencies.
Jay
Offline
Hi,
I've got the same problem after update, two udev process eating a lot of CPU time.
But in my case the boot took also realy longer, "Waiting for udev uevent" took more than 3min at each boot!
So I downgraded it too...
Offline
I just downgraded as well. There was a dependency conflict (the new gstreamer needed the new udev), but I ignored it. I doubt it's anything serious.
EDIT
Intel GM45 chipset here
Last edited by wakkadojo (2009-08-30 03:01:53)
Offline
No problems here ... 3 udevd instances at it behaves. AMD Turion X2 with Ati RS690 chipset here.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Runiq wrote:Similar, but I only have two instances.
That's my problem. High cpu usage, two udevd instances. Rolling-back udev solved the problem, but also had to roll back a number of dependencies.
Jay
Same here. It seems to happen just after resuming, not after a clean start.
All your base are belong to us
Offline
Problem persists with the new udev-146 version
Offline
Do people having this problem know if it is the same or related to the one described here?
Basically, if you have a G45 chipset and in a terminal you type (as root): "udevadm monitor" and get lots of messages (when the problem starts), it's probably the same. Otherwise it might be completely unrelated.
If it is the same bug, it is not related to udev, it is a kernel bug introduced in 2.6.30. It is already reported and it's being investigated.
Offline
Do people having this problem know if it is the same or related to the one described here?
Basically, if you have a G45 chipset and in a terminal you type (as root): "udevadm monitor" and get lots of messages (when the problem starts), it's probably the same. Otherwise it might be completely unrelated.
If it is the same bug, it is not related to udev, it is a kernel bug introduced in 2.6.30. It is already reported and it's being investigated.
I doubt it is the same problem. There were no excess udevd processes or excess cpu usage by udevd, using kernel 2.6.30, until udev was upgraded to 145-1, and reverting to udev 141-5 alleviates the problem.
Jay
Offline
No problem here, running linux kernel 2.6.31 with intel 945gm video.
udev only has 3 instances
Offline
3 instances here... running 2.6.30 - bfs kernel
Offline
Running udevadm monitor gives me thousands of messages
I have Intel PM45 chipset and Nvidia 9600M GT video card.
As jt512 said, I think is an udev related bug because downgrading it solves the problem.
All your base are belong to us
Offline
MartinZ, I also have an Intel PM45 with NVIDIA 9600M GT, and I also get thousands of messages when running udavadm. I wonder if this will ever be fixed. If not, it will only be a matter of time before many programs will be incompatible with similar systems since so many depend on udev.
Last edited by wakkadojo (2009-09-26 01:55:29)
Offline
New kernel/NVIDIA drivers did not resolve the problem
Offline
Arch bug report, upstream bug report.
Seems to have something to do with the optical drive (as udevadm monitor --property suggests). If you can add anything valuable to the upstream report, please do
Offline
I just installed udev-stable from AUR and am happy now, though that's not a real solution...
Great, Gnome 2.28 doesnt work with udev 141.
Last edited by MartinZ (2009-10-14 00:59:57)
All your base are belong to us
Offline
Hi! I just tried Ubuntu 9.10 beta and I did not have problems with udev, that I found here on Arch with udev 146 (high CPU, lots of udev instances, etc)
I don't like Ubuntu too much (xD) so I tried to port ubuntu's udev to Arch
The result is this PKGBUILD: http://aur.archlinux.org/packages.php?ID=31373
Everything works correctly: no high cpu, only 3 udev instances, GNOME 2.28 works right... try it if you have problems, it may help you
Also now udevadm monitor does not show any message regarding the optical drive...
UDev processing takes 13 seconds though, but it's better than infinite XD
Last edited by Gianfrix (2009-10-21 20:07:34)
~ Gianfrix
There's no place like 127.0.0.1
Offline
Hi! I just tried Ubuntu 9.10 beta and I did not have problems with udev, that I found here on Arch with udev 146 (high CPU, lots of udev instances, etc)
I don't like Ubuntu too much (xD) so I tried to port ubuntu's udev to ArchThe result is this PKGBUILD: http://aur.archlinux.org/packages.php?ID=31373
This indeed fixed my udev high cpu usage problem. So, thanks for the good work. There was one small problem, though: udev now loads the heinous pcspkr module, which I have blacklisted in rc.conf. I tried to prevent udev from loading it by putting "alias pcspkr off" in modules.conf, but that didn't work; but I was able to unload it using "modprobe -r pcspkr" in rc.local.
Anybody know a cleaner fix?
Jay
Offline
Hi! I just tried Ubuntu 9.10 beta and I did not have problems with udev, that I found here on Arch with udev 146 (high CPU, lots of udev instances, etc)
I don't like Ubuntu too much (xD) so I tried to port ubuntu's udev to ArchThe result is this PKGBUILD: http://aur.archlinux.org/packages.php?ID=31373
Everything works correctly: no high cpu, only 3 udev instances, GNOME 2.28 works right... try it if you have problems, it may help you
Also now udevadm monitor does not show any message regarding the optical drive...
UDev processing takes 13 seconds though, but it's better than infinite XD
Thanks, it works fine
All your base are belong to us
Offline
Hi! I just tried Ubuntu 9.10 beta and I did not have problems with udev, that I found here on Arch with udev 146 (high CPU, lots of udev instances, etc)
I don't like Ubuntu too much (xD) so I tried to port ubuntu's udev to ArchThe result is this PKGBUILD: http://aur.archlinux.org/packages.php?ID=31373
Everything works correctly: no high cpu, only 3 udev instances, GNOME 2.28 works right... try it if you have problems, it may help you
Also now udevadm monitor does not show any message regarding the optical drive...
UDev processing takes 13 seconds though, but it's better than infinite XD
hi!
when i try to install the package with yaourt i get following compile-error.
can you help me with this issue?
.
.
.
.
CCLD extras/edd_id/edd_id
CC extras/floppy/create_floppy_devices.o
CCLD extras/floppy/create_floppy_devices
CC extras/path_id/path_id.o
CCLD extras/path_id/path_id
CC extras/fstab_import/fstab_import.o
CCLD extras/fstab_import/fstab_import
CC extras/scsi_id/scsi_id.o
CC extras/scsi_id/scsi_serial.o
In file included from extras/scsi_id/scsi_serial.c:28:
/usr/include/scsi/scsi.h:145: error: expected specifier-qualifier-list before 'u8'
/usr/include/scsi/scsi.h: In function 'scsi_varlen_cdb_length':
/usr/include/scsi/scsi.h:156: error: 'struct scsi_varlen_cdb_hdr' has no member named 'additional_cdb_length'
make[2]: *** [extras/scsi_id/scsi_serial.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
==> ERROR: Build Failed.
Aborting...
Error: Makepkg was unable to build udev-ubuntu package.
thx in advance
Offline
udev 147-1 in testing seems to (finally) have solved the problem
All your base are belong to us
Offline
udev 147-1 in testing seems to (finally) have solved the problem
how to get it from testing??
Also, can more people confirm this...
Regards
Mukul
Offline