Description of problem: udevd polls /dev/cdrom 10-20 times/second Version-Release number of selected component (if applicable): udev-145-14.fc12.x86_64 How reproducible: Always Steps to Reproduce: 1. Boot fedora 12 2. sudo inotifywait -m /dev/cdrom Actual results: 10-20 attrib, open, close events per second Expected results: 0.5 events per second (hal is polling every 2 seconds, right?) Additional info: At times I get udev eating 45-50% CPU time. No idea what's causing it but killing udevd and starting it again fixes the problem temporary.
...to see the difference 'killall udevd' - inotify starts reporting 1 open/close event every two seconds.
I tried 'udevd --debug' and it really constantly tries to re-add my DVD-RW device. I'm also adding a compressed log file obtained by running 'udevd --debug-trace --debug > udev-cdrom.log 2>&1' for аbout two seconds. Is there temporary workaround I can use to stop udev re-adding the device?
Created attachment 377651 [details] Log file showing what udevd does
I have exactly the same problem on Lenovo N 500 notebook. Inner workings of udev and HAL are beyond my knowledge at the moment, but there is simple solution I used to temporarily bypass this problem. I disabled HAL polling for dvd-rom device: hal-disable-polling --device /dev/sr0 (put it in rc.local). Hope this solution will help you solve this irritating problem. If someone knows a better way to resolve this problem, please be kind and share your knowledge with us.
Seems like s.th. is frequently opening the cdrom with the write flag, which causes a udev change event, which causes udev to rescan.
hal-disable-polling did not help in my case (it's possible I did it wrong, I can try again if that would help). I created the following file: --- /etc/udev/rules.d/10-my.rules --- KERNEL=="sr0", GROUP="disk", OPTIONS+="ignore_device,last_rule" Now I really can't get udevd to show in htop (sorted by CPU).
I have no idea from which version, but I have not observed the problem lately (removed the udev rule disabling the CD).
(In reply to comment #7) > I have no idea from which version, but I have not observed the problem lately > (removed the udev rule disabling the CD). I can confirm that sympomes also disapired on my Lenovo N500 laptop. I suspect that one of the updates solved the problem.
ok, one thing to try: comment out line 7 in /lib/udev/rules.d/60-persistent-storage.rules, which will look like this: # forward scsi device event to corresponding block device # ACTION=="change", SUBSYSTEM=="scsi", ENV{DEVTYPE}=="scsi_device", TEST=="block", ATTR{block/*/uevent}="change"
I can not any longer reproduce the problem without touching anything (restored original udev rules)...