Bug 544815 - udevd polls /dev/cdrom 10-20 times/second
udevd polls /dev/cdrom 10-20 times/second
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-06 11:40 EST by Doncho N. Gunchev
Modified: 2010-04-13 11:55 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-04-13 11:55:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Log file showing what udevd does (8.20 KB, application/x-gzip)
2009-12-10 21:31 EST, Doncho N. Gunchev
no flags Details

  None (edit)
Description Doncho N. Gunchev 2009-12-06 11:40:07 EST
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.
Comment 1 Doncho N. Gunchev 2009-12-06 11:41:23 EST
...to see the difference 'killall udevd' - inotify starts reporting 1 open/close event every two seconds.
Comment 2 Doncho N. Gunchev 2009-12-10 21:28:46 EST
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?
Comment 3 Doncho N. Gunchev 2009-12-10 21:31:51 EST
Created attachment 377651 [details]
Log file showing what udevd does
Comment 4 Jugoslav Gacas 2009-12-20 13:02:09 EST
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.
Comment 5 Harald Hoyer 2009-12-23 07:43:55 EST
Seems like s.th. is frequently opening the cdrom with the write flag, which causes a udev change event, which causes udev to rescan.
Comment 6 Doncho N. Gunchev 2009-12-25 20:48:14 EST
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).
Comment 7 Doncho N. Gunchev 2010-02-04 12:17:46 EST
I have no idea from which version, but I have not observed the problem lately (removed the udev rule disabling the CD).
Comment 8 Jugoslav Gacas 2010-02-05 12:13:15 EST
(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.
Comment 9 Harald Hoyer 2010-02-12 10:10:57 EST
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"
Comment 10 Doncho N. Gunchev 2010-03-23 18:36:57 EDT
I can not any longer reproduce the problem without touching anything (restored original udev rules)...

Note You need to log in before you can comment on or make changes to this bug.