Bug 25259 - udev takes almost 100% CPU on resume from suspend (and Xorg is blamed)
udev takes almost 100% CPU on resume from suspend (and Xorg is blamed)
Status: RESOLVED DUPLICATE of bug 25327
Product: xorg
Classification: Unclassified
Component: Driver/intel
unspecified
Other All
: medium normal
Assigned To: Jesse Barnes
Xorg Project Team
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-24 07:45 UTC by Matej Cepl
Modified: 2010-09-02 04:45 UTC (History)
12 users (show)

See Also:


Attachments
output of udevadm monitor --env (69.68 KB, application/x-gzip)
2009-11-24 07:47 UTC, Matej Cepl
no flags Details
kernel patch to stop i915 interrupt storm (769 bytes, patch)
2010-01-26 08:28 UTC, William Hanlon
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Matej Cepl 2009-11-24 07:45:08 UTC
(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
Comment 1 Matej Cepl 2009-11-24 07:47:24 UTC
Created attachment 31444 [details]
output of udevadm monitor --env
Comment 2 ajax at nwnk dot net 2009-11-24 07:54:54 UTC
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.
Comment 3 Julien Cristau 2009-11-28 04:37:54 UTC
*** Bug 25327 has been marked as a duplicate of this bug. ***
Comment 4 William Hanlon 2009-12-10 13:04:38 UTC
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
Comment 5 Bob K 2009-12-12 15:35:19 UTC
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?  


Comment 6 Todd Brunhoff 2009-12-13 07:54:40 UTC
I should note that Bug 25327 (noted as a duplicate above) contains a working kernel patch for this issue.
Comment 7 Matthew Hails 2009-12-15 04:18:26 UTC
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).
Comment 8 Todd Brunhoff 2009-12-15 08:47:27 UTC
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.
Comment 9 Todd Brunhoff 2009-12-15 08:49:57 UTC
Oops... sorry. The patch I was talking about is the one in the other bug on this subject: Bug 25327.
Comment 10 Matthew Hails 2009-12-15 14:01:25 UTC
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.
Comment 11 Matthew Hails 2009-12-17 10:12:13 UTC
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.
Comment 12 Gary Sandine 2009-12-22 21:53:48 UTC
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)  
Comment 13 Gary Sandine 2009-12-22 22:00:20 UTC
(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).
Comment 14 Matthew Hails 2009-12-23 02:23:41 UTC
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.
Comment 15 Gary Sandine 2009-12-23 20:33:49 UTC
(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.

Comment 16 Gary Sandine 2009-12-23 21:52:23 UTC
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.
Comment 17 Matthew Hails 2009-12-24 01:54:08 UTC
(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.
Comment 18 Levente Farkas 2010-01-05 08:40:28 UTC
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
----------------------------------------------------
Comment 19 Elmo R 2010-01-07 07:57:36 UTC
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
Comment 20 William Hanlon 2010-01-26 08:28:35 UTC
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.
Comment 21 Levente Farkas 2010-03-03 08:54:09 UTC
still exists on fedora 12 with kernel-PAE-2.6.31.12-174.2.22.fc12.i686
Comment 22 Alexey Chentsov 2010-03-07 01:40:10 UTC
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.
Comment 23 Todd Brunhoff 2010-03-07 09:11:11 UTC
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.
Comment 24 Alexey Chentsov 2010-03-14 14:35:27 UTC
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.
Comment 25 Jesse Barnes 2010-07-01 15:44:30 UTC
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 ***
Comment 26 Jesse Barnes 2010-07-01 15:45:14 UTC
*** Bug 27941 has been marked as a duplicate of this bug. ***