Bug 544815

Summary: udevd polls /dev/cdrom 10-20 times/second
Product: [Fedora] Fedora Reporter: Doncho Gunchev <dgunchev>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: harald, jugoslav.gacas
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-04-13 15:55:24 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Log file showing what udevd does none

Description Doncho Gunchev 2009-12-06 16:40:07 UTC 
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 Gunchev 2009-12-06 16:41:23 UTC 
...to see the difference 'killall udevd' - inotify starts reporting 1 open/close event every two seconds.
Comment 2 Doncho Gunchev 2009-12-11 02:28:46 UTC 
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 Gunchev 2009-12-11 02:31:51 UTC 
Created attachment 377651 [details]
Log file showing what udevd does
Comment 4 Jugoslav Gacas 2009-12-20 18:02:09 UTC 
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 12:43:55 UTC 
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 Gunchev 2009-12-26 01:48:14 UTC 
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 Gunchev 2010-02-04 17:17:46 UTC 
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 17:13:15 UTC 
(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 15:10:57 UTC 
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 Gunchev 2010-03-23 22:36:57 UTC 
I can not any longer reproduce the problem without touching anything (restored original udev rules)...