(originally filed as https://bugzilla.redhat.com/show_bug.cgi?id=528312) When resuming computer from suspend-to-RAM after a brief pause udevd takes 100% CPU and it won't let computer work for couple of seconds. Then computer works as it is supposed to. When I do a clean boot, everything works just fine, but when I suspend to ram, and then resume, I have normal behaviour for maybe 5-10 seconds, then everything locks up, 'top' shows X is eating cpu. After 10-30 seconds I can use the laptop for maybe 2-3 seconds, and things lock up again. This continues for about 1-2 minutes (or less). Then everything works as normal. This is 100% reproducable. Observed in all times on Lenovo Thinkpad T400, Intel Corporation Mobile 4 Series, i915 with KMS (ie. I don't have nomodeset in grub). $ xrandr Screen 0: minimum 320 x 200, current 1440 x 900, maximum 8192 x 8192 LVDS1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 304mm x 190mm 1440x900 60.2*+ 50.0 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 VGA1 disconnected (normal left inverted right x axis y axis) DVI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) DVI2 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) DP3 disconnected (normal left inverted right x axis y axis) My current versions: libgudev1-145-14.fc12.x86_64 libudev-145-14.fc12.i686 udev-145-14.fc12.x86_64 xorg-x11-drv-intel-2.9.1-1.fc12.x86_64 xorg-x11-server-Xorg-1.7.1-7.fc12.x86_64 udev-debuginfo-145-14.fc12.x86_64
Created attachment 31444 [details] output of udevadm monitor --env
The background here is that our build of the Intel driver listens for uevents from drm and turns them into RANDR events. The patch is (mentioned) here: http://lists.freedesktop.org/archives/intel-gfx/2009-October/004440.html The problem, if I had to guess, is that the act of re-probing connection status from the drm clears the existing connection sense bits. Sometime later the detection hardware re-asserts those bits, more interrupts happen, the X server hears them and turns them into RANDR events, the client asks for connection status again, and around we go.
*** Bug 25327 has been marked as a duplicate of this bug. ***
I see this on a fully updated Fedora 12 i386 desktop, without suspend to ram happening. My bug report is at https://bugzilla.redhat.com/show_bug.cgi?id=538196. Using: xorg-x11-server-common-1.7.1-7.fc12.i686 X.Org X Server 1.7.1 Release Date: 2009-10-23 X Protocol Version 11, Revision 0 Build Date: 05 November 2009 07:43:20PM Build ID: xorg-x11-server 1.7.1-7.fc12 kernel-2.6.31.6-162.fc12.i686 udev-145-14.fc12.i686
Same problem here on a fully updated Ubuntu x64 server 9.10, with identical output from "udevadm monitor --env". The problem seems to appear at some random time after startup with no clear correlation I can see (and no need to hibernate to get the problem to occur). 100% reproducible. udevd eats up >25% of processor capacity (on a quad core). Is any workaround possible?
I should note that Bug 25327 (noted as a duplicate above) contains a working kernel patch for this issue.
I have Fedora 12 (i686), fully updated as of yesterday, plus the kernel patch from this defect, and I am still seeing this problem - without resuming from suspend. udevdadm gives output as per existing attachment, causing Xorg to constantly use 25 - 80% CPU. The problem does not reliably occur - my system ran for 7 hours yesterday with no problems, but it happened within 10 mins of boot today. System is an HP EliteBook 6930p, Intel GM45 - currently with docking station. Booting with "nomodeset". Using i915 (with proposed patch).
Matthew, if you look at the patch, I turned off two out of three bits in the "if" block. My system is hooked up to HDMI, but your laptop probably isn't. If I were to guess, you probably have to change the patch to mask off two other bits. But that's just guess. If you reach a solution, that would be valuable input for how to compose the final patch.
Oops... sorry. The patch I was talking about is the one in the other bug on this subject: Bug 25327.
Actually it's me who was being misleading - I was also referring to your patch on bug 25327. You are correct - I'm not using HDMI. In fact I have it explicitly disabled in Xorg.conf (in the hope that would help). Thanks for your suggestion - I will have a go at tweaking the patch as you recommend and let you know how I get on. Having run your original patch now for most of two days, I have only experienced the problem once, so it is a noticeable improvement. I should be able to report back in a couple of days once I've been able to build it and give it a decent run in.
I've been running my system now for 2 days, with a variation on Todd's patch in bug 25327, and the udev problem has not occurred, so it fixes it for me. I actually unset HDMIC_HOTPLUG_INT_STATUS and TV_HOTPLUG_INT_STATUS (as well as HDMIB_HOTPLUG_INT_STATUS and HDMID_HOTPLUG_INT_STATUS). As I said before, I'm using VGA, not HDMI. I'm happy to run a different variation of the patch if that might be useful.
I was getting this behavior in a desktop computer with onboard Intel GMA 4500 video card. I never hibernate or suspend -- it just periodically happens and does not stop, resulting in high resource usage by Xorg and udev and continuous appending of the text below to the Xorg log file /var/log/Xorg.0.log. The Fedora 12 system did not have an xorg.conf file, so I made one and included this as an attempt to stop probes where there are no displays and the bad behavior seems to have stopped: Section "Monitor" Identifier "Monitor0" Option "DPMS" Option "monitor-DP1" "DP1" Option "monitor-DVI1" "DVI1" Option "monitor-HDMI-1" "HDMI-1" Option "monitor-HDMI-2" "HDMI-2" EndSection Section "Monitor" Identifier "HDMI-1" Option "Ignore" "True" EndSection Section "Monitor" Identifier "HDMI-2" Option "Ignore" "True" EndSection Section "Monitor" Identifier "DP1" Option "Ignore" "True" EndSection Section "Monitor" Identifier "DVI1" Option "Ignore" "True" EndSection Here are the bits that repeatedly get logged in Xorg.0.log (I noticed a 700 MiB log file after the box had been sitting for a while!!). I am using the vga output only. The computer has a Lenovo "DisplayPort" for a DVI head but I am not using that: (II) intel(0): EDID for output DVI1 (II) intel(0): EDID for output DP1 (II) intel(0): EDID for output VGA1 (II) intel(0): Manufacturer: SNY Model: 1d70 Serial#: 16843009 (II) intel(0): Year: 2002 Week: 29 (II) intel(0): EDID Version: 1.3 (II) intel(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) intel(0): Sync: Separate Composite SyncOnGreen (II) intel(0): Max Image Size [cm]: horiz.: 34 vert.: 27 (II) intel(0): Gamma: 2.20 (II) intel(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display (II) intel(0): First detailed timing is preferred mode (II) intel(0): redX: 0.640 redY: 0.340 greenX: 0.290 greenY: 0.610 (II) intel(0): blueX: 0.140 blueY: 0.070 whiteX: 0.283 whiteY: 0.298 (II) intel(0): Supported established timings: (II) intel(0): 720x400@70Hz (II) intel(0): 640x480@60Hz (II) intel(0): 800x600@60Hz (II) intel(0): 1024x768@60Hz (II) intel(0): Manufacturer's mask: 0 (II) intel(0): Supported standard timings: (II) intel(0): #0: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) intel(0): Supported detailed timing: (II) intel(0): clock: 108.0 MHz Image Size: 338 x 270 mm (II) intel(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 h_border: 0 (II) intel(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 v_border: 0 (II) intel(0): Ranges: V min: 57 V max: 63 Hz, H min: 28 H max: 65 kHz, PixClock max 110 MHz (II) intel(0): Monitor name: SDM-X72 (II) intel(0): Serial No: 4001893 (II) intel(0): EDID (in hex): (II) intel(0): 00ffffffffffff004dd9701d01010101 (II) intel(0): 1d0c01030e221b78eac5c9a3574a9c23 (II) intel(0): 12484ca1080081800101010101010101 (II) intel(0): 010101010101302a009851002a403070 (II) intel(0): 1300520e1100001e000000fd00393f1c (II) intel(0): 410b000a202020202020000000fc0053 (II) intel(0): 444d2d5837320a2020202020000000ff (II) intel(0): 00343030313839330a20202020200066 (II) intel(0): EDID vendor "SNY", prod id 7536 (II) intel(0): Using hsync ranges from config file (II) intel(0): Using vrefresh ranges from config file (II) intel(0): Printing DDC gathered Modelines: (II) intel(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) intel(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) intel(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) intel(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) intel(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) intel(0): Printing probed modes for output VGA1 (II) intel(0): Modeline "1280x1024"x60.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) intel(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) intel(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) intel(0): Modeline "640x480"x60.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) intel(0): Modeline "720x400"x70.1 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz)
(In reply to comment #12) > ... and the bad behavior seems to have stopped: Never mind -- it's still happening. However, the repeating text in the xorg.conf now only shows a VGA1 probe (and there is a monitor attached).
Gary - have you tried Todd's patch from bug 25327? I had exactly the same problem as you. I was only using VGA output, so I disabled all other outputs in xorg.conf, as you did, and the problem still occurred. After using a modified form of Todd's patch - with all 3 HDMI bits unset - I've run my system for over a week now without seeing the problem.
(In reply to comment #14) > Gary - have you tried Todd's patch from bug 25327? I'm trying that now, thanks. > I had exactly the same problem as you. I was only using VGA output, so I > disabled all other outputs in xorg.conf, as you did, and the problem still > occurred. After using a modified form of Todd's patch - with all 3 HDMI bits > unset - I've run my system for over a week now without seeing the problem. Did you keep your xorg.conf as you had it? I suppose one can probably ditch the xorg.conf file as is the default in Fedora 12.
I'm running with the patch with all 3 HDMI bits unset and with no xorg.conf and I am no longer having the problem. Thanks.
(In reply to comment #15) > Did you keep your xorg.conf as you had it? I suppose one can probably ditch > the xorg.conf file as is the default in Fedora 12. I kept my xorg.conf as I had it, with HDMI and TV out explicitly disabled. Your subsequent comment suggests it's not necessary, so I may try removing my xorg.conf.
i've a fully updated fedora 12 (at 2010-01-05) and i still have this issue. what i recognize is that my /var/log/Xorg.0.log is full of such messages -rw-r--r-- 1 root root 1564709 2010-01-05 17:36 /var/log/Xorg.0.log ---------------------------------------------------- (II) intel(0): Manufacturer: SAM Model: 30c Serial#: 1296380466 (II) intel(0): Year: 2008 Week: 9 (II) intel(0): EDID Version: 1.3 (II) intel(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) intel(0): Sync: Separate Composite SyncOnGreen (II) intel(0): Max Image Size [cm]: horiz.: 47 vert.: 30 (II) intel(0): Gamma: 2.20 (II) intel(0): DPMS capabilities: Off; RGB/Color Display (II) intel(0): First detailed timing is preferred mode (II) intel(0): redX: 0.644 redY: 0.333 greenX: 0.286 greenY: 0.603 (II) intel(0): blueX: 0.152 blueY: 0.079 whiteX: 0.313 whiteY: 0.329 (II) intel(0): Supported established timings: (II) intel(0): 720x400@70Hz (II) intel(0): 640x480@60Hz (II) intel(0): 640x480@67Hz (II) intel(0): 640x480@72Hz (II) intel(0): 640x480@75Hz (II) intel(0): 800x600@56Hz (II) intel(0): 800x600@60Hz (II) intel(0): 800x600@72Hz (II) intel(0): 800x600@75Hz (II) intel(0): 832x624@75Hz (II) intel(0): 1024x768@60Hz (II) intel(0): 1024x768@70Hz (II) intel(0): 1024x768@75Hz (II) intel(0): 1280x1024@75Hz (II) intel(0): 1152x864@75Hz (II) intel(0): Manufacturer's mask: 0 (II) intel(0): Supported standard timings: (II) intel(0): #0: hsize: 1680 vsize 1050 refresh: 60 vid: 179 (II) intel(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) intel(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) intel(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) intel(0): Supported detailed timing: (II) intel(0): clock: 119.0 MHz Image Size: 474 x 296 mm (II) intel(0): h_active: 1680 h_sync: 1728 h_sync_end 1760 h_blank_end 1840 h_border: 0 (II) intel(0): v_active: 1050 v_sync: 1053 v_sync_end 1059 v_blanking: 1080 v_border: 0 (II) intel(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 140 MHz (II) intel(0): Monitor name: SyncMaster (II) intel(0): Serial No: HS3Q219084 (II) intel(0): EDID (in hex): (II) intel(0): 00ffffffffffff004c2d0c033232454d (II) intel(0): 091201030e2f1e782ad515a455499a27 (II) intel(0): 145054bfef80b30081808140714f0101 (II) intel(0): 0101010101017c2e90a0601a1e403020 (II) intel(0): 3600da281100001a000000fd00384b1e (II) intel(0): 510e000a202020202020000000fc0053 (II) intel(0): 796e634d61737465720a2020000000ff (II) intel(0): 00485333513231393038340a20200041 (II) intel(0): EDID vendor "SAM", prod id 780 (II) intel(0): Using hsync ranges from config file (II) intel(0): Using vrefresh ranges from config file (II) intel(0): Printing DDC gathered Modelines: (II) intel(0): Modeline "1680x1050"x0.0 119.00 1680 1728 1760 1840 1050 1053 1059 1080 +hsync -vsync (64.7 kHz) (II) intel(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) intel(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) intel(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) intel(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz) (II) intel(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) intel(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) intel(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) intel(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) intel(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz) (II) intel(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) intel(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) intel(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) intel(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) intel(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) intel(0): Modeline "1680x1050"x0.0 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync (65.3 kHz) (II) intel(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) intel(0): Modeline "1280x960"x0.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz) (II) intel(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) intel(0): Not using mode "1680x1050" (bad mode clock/interlace/doublescan) (II) intel(0): Printing probed modes for output VGA1 (II) intel(0): Modeline "1680x1050"x59.9 119.00 1680 1728 1760 1840 1050 1053 1059 1080 +hsync -vsync (64.7 kHz) (II) intel(0): Modeline "1280x1024"x75.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) intel(0): Modeline "1280x1024"x60.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) intel(0): Modeline "1280x960"x60.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz) (II) intel(0): Modeline "1152x864"x75.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) intel(0): Modeline "1024x768"x75.1 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (II) intel(0): Modeline "1024x768"x70.1 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) intel(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) intel(0): Modeline "832x624"x74.6 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) intel(0): Modeline "800x600"x72.2 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) intel(0): Modeline "800x600"x75.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) intel(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) intel(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) intel(0): Modeline "640x480"x72.8 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (II) intel(0): Modeline "640x480"x75.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) intel(0): Modeline "640x480"x66.7 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) intel(0): Modeline "640x480"x60.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) intel(0): Modeline "720x400"x70.1 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) intel(0): EDID for output DVI1 (II) intel(0): EDID for output DP1 (II) intel(0): EDID for output DVI2 (II) intel(0): EDID for output DP2 ----------------------------------------------------
This is still a bug. I would apply the patch to a custom rolled kernel to the i915_irq.c file. Alternatively, you can just killall udevd for the session. In either case, after applying the patch my /var/log/messages now shows: Jan 7 10:54:12 x kernel: DRHD: handling fault status reg 3 Jan 7 10:54:12 x kernel: DMAR:[DMA Write] Request device [00:02.0] fault addr b08003000 Jan 7 10:54:12 x kernel: DMAR:[fault reason 05] PTE Write access is not set Jan 7 10:54:13 x kernel: DRHD: handling fault status reg 3 Jan 7 10:54:13 x kernel: DMAR:[DMA Write] Request device [00:02.0] fault addr b08003000 Jan 7 10:54:13 x kernel: DMAR:[fault reason 05] PTE Write access is not set repeatedly, but at least the screen doesn't get stalled. See Bug #25327
Created attachment 32825 [details] [review] kernel patch to stop i915 interrupt storm This problem still exists in Fedora kernel 2.6.31.12-174.2.3.fc12.i686. I'm using only the VGA output on my desktop. I tried Todd's patch and I'm happy to say I've been running for 5 days now without any interrupt storms. I commented out all three HDMI bits. I'm including my copy of the patch.
still exists on fedora 12 with kernel-PAE-2.6.31.12-174.2.22.fc12.i686
I have GMA4500 and witnessed spurious change events behavior on Fedora 12. By trial and error got rid of it only with nomodeset (either i915.modeset=0) boot option and kernel update to 2.6.32.9-67. System boots, resumes and wakes from hibernate without any signs of the problem. The evidence shows it's KMS related issue.
Hey gang, Thanks to everyone for trying different kernels, but please note that in the bug related to this (Bug 25327), Eric has proposed that this *might* be fixed in kernel v2.6.33rc7 or later. So testing kernels before this is not likely to yield new information. That is, it will be a waste of your time. There is one instance of the bug remaining with v2.6.33rc7, so testing kernels after that might be useful.
Hi there! Testing Fedora 13 Alpha kernel 2.6.33-0.52.rc8.git6.fc13.i686 Xorg 1.7.99.901 intel xorg module 2.10.0 No luck. Device triggers as soon as GUI is up. It gets tamed with udevd taken down. Though i915 irq thread can be busy for minutes. After that udevd can be up again and system seems to be quite stable. After hibernation or a few suspend/resume it gets wild again. This might be a problem as UMS is no longer supported by recent intel xorg modules.
Got unmarked as a dupe somehow? Adam's kernel patch may have fixed this, it changed the ordering of our IRQ enable code to avoid a window where we might get stuck servicing a hotplug interrupt. *** This bug has been marked as a duplicate of bug 25327 ***
*** Bug 27941 has been marked as a duplicate of this bug. ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.