Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Intel video drivers very slow with kernels post 2.6.31|
|Product:||[Fedora] Fedora||Reporter:||Paul F. Johnson <paul>|
|Component:||xorg-x11-drv-intel||Assignee:||Adam Jackson <ajax>|
|Status:||CLOSED DUPLICATE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||12||CC:||ajax, antonio.montagnani, ascii79, a_villacis, awilliam, bjohnson, bojan, bookreviewer, bugzilla.redhat, ctyler.fedora, edana, erik-fedora, geudtner, gm, holger.schletz, itamar, jaroslav.pulchart, kernel-maint, lsof, mschmidt, palazzotti, pankaj86, redhat-bugzilla, rhbugzilla, romain, seven, slicer69, spoyarek, stbaker81, stephen.eckel, theo148, tvujec, vhejral, whumphreys, xgl-maint, yohan.bataille, zingale|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-03-04 12:30:17 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||432388, 507681|
Description Paul F. Johnson 2009-09-16 06:12:03 EDT
Description of problem: With the newer versions of kernel, video output via gdm and gnome is unusable due to it being incredibly slow. Reverting back to pre 2.6.31 and everything is at it's usual high speed Version-Release number of selected component (if applicable): kernel >= 2.6.31 How reproducible: Always Steps to Reproduce: 1. Install kernel post 2.6.31 and reboot 2. Wait for the selinux relabel (no idea why this has to be done) 3. Desktop appears at normal speed then slows to almost dead stop Actual results: Unusable desktop environment Expected results: Should work at the same speed (if not quicker) than with the pre 2.6.31 kernel versions Additional info: Using the intel 955 chipset
Comment 1 Paul F. Johnson 2009-09-16 06:12:26 EDT
That should be 965 not 955 - d'oh!
Comment 2 Michal Schmidt 2009-11-08 05:03:56 EST
Please specify the exact version and release of the relevant packages (kernel, xorg-X11-drv-intel, xorg-X11-server-Xorg) and attach your xorg.conf (if you have any), the output of dmesg, and the /var/log/Xorg.0.log.
Comment 3 Romain LE DISEZ 2009-11-10 11:40:11 EST
I also have this problem : xorg-x11-server-Xorg-1.7.1-7.fc12.x86_64 xorg-x11-drv-intel-2.9.1-1.fc12.x86_64 kernel-188.8.131.52-127.fc12.x86_64 It works fine with kernel-184.108.40.206-96.fc11.x86_64 I do not have xorg.conf. The use of nomodeset did not change the behaviour. Looking at Xorg.0.log_220.127.116.11-127, Xorg seems to be in an infinite loop. The log of Xorg looks the same as in the bug #522909
Comment 4 Romain LE DISEZ 2009-11-10 11:41:08 EST
Created attachment 368434 [details] dmesg with kernel 2.6.30
Comment 5 Romain LE DISEZ 2009-11-10 11:41:23 EST
Created attachment 368435 [details] Xorg.0.log with kernel 2.6.30
Comment 6 Romain LE DISEZ 2009-11-10 11:41:43 EST
Created attachment 368436 [details] dmesg with kernel 2.6.31
Comment 7 Romain LE DISEZ 2009-11-10 11:42:39 EST
Created attachment 368437 [details] Xorg.0.log with kernel 2.6.31
Comment 8 Michal Schmidt 2009-11-10 14:34:46 EST
The reporter of bug 522909 had lots of repeated messages like "[drm] TV-10: set mode NTSC 480i 0" when he booted with KMS (without "nomodeset"). Are you seeing these as well?
Comment 9 Romain LE DISEZ 2009-11-10 17:25:27 EST
Well, I'm not sure what happened but I can't reproduce the bug anymore. It was systematic until yesterday... (I installed rawhide on 25th of october) The first point to note is that I mixed the logs files. The dmesg was indeed of the kernel 18.104.22.168-127 but the Xorg.0.log was of the previous kernel (22.214.171.124-122). I posted the wrong copy of the file. I updated the kernel to 2.6.31-127 today and now I can't reproduce the bug, even when booting with 126.96.36.199-122. I can't see what changed (could kernel-firmware < 188.8.131.52-127 be the cause ?). The fact is the problem is solved for me, but I don't know why.
Comment 10 Romain LE DISEZ 2009-11-10 17:57:02 EST
The bug is back :-( Now I'm sure I'm running 184.108.40.206-127. And yes, I see a line like in the bug #522909. I also see some error about drm that was not in the logs I previously attached : # dmesg | grep drm [drm] Initialized drm 1.1.0 20060810 [drm:intel_dp_i2c_init] *ERROR* i2c_init DPDDC-B [drm:intel_dp_i2c_init] *ERROR* i2c_init DPDDC-C [drm] TMDS-8: set mode 1920x1080 16 fb0: inteldrmfb frame buffer device [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 I re-post the dmesg and Xorg.0.log.
Comment 11 Romain LE DISEZ 2009-11-10 17:59:31 EST
Created attachment 368964 [details] New dmesg with error for kernel 220.127.116.11-127
Comment 12 Romain LE DISEZ 2009-11-10 18:01:00 EST
Created attachment 368965 [details] New Xorg.0.log with error for kernel 18.104.22.168-127
Comment 13 Michal Schmidt 2009-11-11 04:46:08 EST
(In reply to comment #10) > [drm:intel_dp_i2c_init] *ERROR* i2c_init DPDDC-B > [drm:intel_dp_i2c_init] *ERROR* i2c_init DPDDC-C Upstream recently downgraded the message from ERROR to DEBUG level. The repeated DDC/EDID probes in Xorg.0.log over and over again are interesting. Ajax, what do you think?
Comment 14 Bug Zapper 2009-11-16 07:28:03 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 15 pankaj pandey 2009-11-24 05:38:46 EST
I'm experiencing this problem in the rawhide kernel-2.6.32-0.51.rc7.git2.fc13.x86_64 (all rawhide kernels in fact) I need to boot into my old F12 kernel kernel-22.214.171.124-127.fc12.x86_64 in order to make the system usable (i upgraded from F12 beta to rawhide, and have not been able to use any rawhide kernel to a usable gnome). Fedora 12 install on the same system works well. Any info that i can provide to help fix this?
Comment 16 Bernard Johnson 2009-11-29 13:48:22 EST
FWIW, on F-12, I updated to kernel-126.96.36.199-145.fc12.x86_64 (in updates-testing) and I don't see this problem anymore... or at least not yet. I've been running it for the last 4 hours or so without incident.
Comment 17 Romain LE DISEZ 2009-11-29 14:41:30 EST
I still have the problem with 188.8.131.52-145.fc12.x86_64. I run XBMC as the desktop manager (so it starts when runlevel=5). When XBMC starts, everything is fine. As soon as I "do something" (eg: change the selected menu), the bug appears. But sometimes, it seems to happen by itself (maybe the RSS that scroll at the bottom of the screen)
Comment 18 Bernard Johnson 2009-11-30 03:12:43 EST
(In reply to comment #17) > I still have the problem with 184.108.40.206-145.fc12.x86_64. Are you having the repeated DDC/EDID probes?
Comment 19 Romain LE DISEZ 2009-11-30 11:56:47 EST
(In reply to comment #18) > Are you having the repeated DDC/EDID probes? Yes.
Comment 20 Bernard Johnson 2009-11-30 13:59:01 EST
Well, sorry to report - after ~16 hours on the newer kernel, my system reverted back to performing the repeated DDC/EDID probes :(
Comment 21 Matěj Cepl 2009-12-02 19:33:05 EST
*** Bug 541878 has been marked as a duplicate of this bug. ***
Comment 22 Matěj Cepl 2009-12-04 09:27:47 EST
*** Bug 539310 has been marked as a duplicate of this bug. ***
Comment 23 Stephen Eckel 2009-12-04 21:45:09 EST
I can also confirm this bug, with both kernel-PAE-220.127.116.11-127.fc12.i686 and kernel-PAE-18.104.22.168-145.fc12.i686. Reverting to kernel-PAE-22.214.171.124-99.fc11.i686 solved my problems. I am also seeing repeated EDID messages in my Xorg log. I'd be glad to provide more information if it would help...
Comment 24 Bojan Smojver 2009-12-04 21:55:48 EST
Not sure if this had any fixes for the problems reported here: https://admin.fedoraproject.org/updates/kernel-126.96.36.199-162.fc12 You may want to try it anyway. It does have Intel vblank sync fix, at least.
Comment 25 Romain LE DISEZ 2009-12-05 04:02:06 EST
(In reply to comment #24) > Not sure if this had any fixes for the problems reported here: > > https://admin.fedoraproject.org/updates/kernel-188.8.131.52-162.fc12 It didn't fix it for me.
Comment 26 Stephen Eckel 2009-12-05 09:00:27 EST
(In reply to comment #24) > Not sure if this had any fixes for the problems reported here: > > https://admin.fedoraproject.org/updates/kernel-184.108.40.206-162.fc12 > > You may want to try it anyway. It does have Intel vblank sync fix, at least. Still have the bug with this kernel as well....
Comment 27 Ralf Ertzinger 2009-12-05 10:06:17 EST
Just an additional data point: my Thinkpad X200s runs just fine under F12. 00:02.1 Display controller : Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07) xorg-x11-drv-intel-2.9.1-1.fc12.x86_64 kernel-220.127.116.11-145.fc12.x86_64
Comment 28 Bojan Smojver 2009-12-07 15:39:34 EST
(In reply to comment #25) > (In reply to comment #24) > > Not sure if this had any fixes for the problems reported here: > > > > https://admin.fedoraproject.org/updates/kernel-18.104.22.168-162.fc12 > > It didn't fix it for me. It also didn't fix it for me. Still slow unless I set sync_to_vblank to false.
Comment 29 Michal Schmidt 2009-12-17 04:55:46 EST
22.214.171.124-171 has a few EDID fixes from Ajax: http://koji.fedoraproject.org/koji/buildinfo?buildID=147452 Some of them may fix this bug. Could you test the build please?
Comment 30 Romain LE DISEZ 2009-12-17 07:38:30 EST
(In reply to comment #29) > 126.96.36.199-171 has a few EDID fixes from Ajax: It does not fix the bug. I get the same symptoms: 100% CPU and a lot of log about EDID in Xorg.0.log.
Comment 31 Paul F. Johnson 2009-12-20 06:34:19 EST
I'm not sure if it's also a problem with Gnome somewhere not playing ball. Up until the middle of this week, the F12 kernel would work fine on my laptop. Did an big updated on Tuesday and that was it. It didn't matter what the kernel was (f12 or f13 (2.6.32 flavours)), its dog slow. When I look at top, it's coming up with gdm using 100% processor time. When I get past that, things move slightly quicker, but something else is then eating the processor. Switching off selinux helps, but not by much. nomodeset helps, but not by much.
Comment 32 Steve Baker 2009-12-26 13:00:46 EST
Same issue: Intel i915 module with kernel-188.8.131.52-174.fc12.x86_64 Xorg.0.log shows what appears to be an endless loop probing EDID Top shows a cycling of high CPU usage on both cores for udev I haven't been able to isolate what is causing it. F11 doesn't have this issue.
Comment 33 Bojan Smojver 2009-12-26 19:57:45 EST
(In reply to comment #32) > Intel i915 module with kernel-184.108.40.206-174.fc12.x86_64 Do you mean .9 here?
Comment 34 Vaclav Hejral 2009-12-27 06:37:41 EST
I guess I have the same problem xorg-x11-drv-intel-2.9.1-1.fc12.i686 220.127.116.11-174.fc12.i686 bug 550505 (https://bugzilla.redhat.com/show_bug.cgi?id=550505)
Comment 35 Vaclav Hejral 2009-12-27 06:38:36 EST
*** Bug 550505 has been marked as a duplicate of this bug. ***
Comment 36 Steve Baker 2009-12-28 10:03:30 EST
(In reply to comment #33) > (In reply to comment #32) > > > Intel i915 module with kernel-18.104.22.168-174.fc12.x86_64 > > Do you mean .9 here? My bad... Yes. > > Intel i915 module with kernel-22.214.171.124-174.fc12.x86_64 Additionally, I tested F12 x64 KDE live version and found the same issue. I also tested the KDE version on a Toshiba M500-5401 laptop which has a different CPU (T6600) and found it to work normally. This machine uses the same intel GM45 chipset with 4500HMD graphics chipset as well as the i915 video module. My machine is an Asus UL50VT with SU7300 Processor hybrid power NVIDIA G210M 512MB DDR3 VRAM + Intel GMA 4500MHD (Switchable VGA under win7) Both gpu's are detected during boot without incident. Xlog shows the nVida gpu but sets no parameters for it. Default video is Intel, lsmod shows the Nouveau module loads, I unloaded Nouveau modprobe -r and restarted X with no success. I also booted run level 3 where performance is normal. Hope the additional info helps, it runs too slow to use and easily post logs.
Comment 37 Steven Dollins 2009-12-28 13:46:06 EST
I have the ASUS ul80vt with the same video hardware and the same infinite loop EDID probing. Just as a further point, XFCE and fvwm both have the same problem. On forums about these machines, people have talked about installing Ubuntu 9.10 with a 2.6.31 kernel but have not mentioned similar problems with X. I don't know what version of the intel driver Ubuntu is using.
Comment 38 Paul F. Johnson 2009-12-28 14:31:59 EST
I'm seeing this in rawhide (126.96.36.199-15.fc13 kernel, xorg-x11-drv-intel-2.9.1-1.fc13, 965 chipset) and have tried a pile of different ways to fix it (nomodeset etc), but X is still dog slow. Downgrading the driver does nothing - Xorg.0.log is showing very little other than AIGLX being suspended for VT switch. As this is being seen under rawhide (and it's been like this since well before Christmas) and it's not showing any signs of working, I'm going to up the priority and suggest it becoming F13Block
Comment 39 Jesse 2010-01-02 09:16:39 EST
I have this same error. Running Fedora 12 with KDE. All updates applied. I've tried with and without the nomodeset flag, without any improvement. kernel-188.8.131.52-174.fc12.i686 xorg-x11-drv-intel-2.9.1-1.fc12.i686 kdebase-4.3.4-1.fc12.i686 My smolt profile can be found here: http://www.smolts.org/client/show/pub_459c7c09-9b5a-43d2-827e-d4a12570b9e4
Comment 40 Paul F. Johnson 2010-01-05 09:15:17 EST
Moving back down to the 184.108.40.206-171.fc12 kernel has sorted the problem out on my laptop, so it is a kernel issue with certain Intel chipsets. xorg-x11-drv-intel is the current rawhide version (2.9.1-1)
Comment 41 Need Real Name 2010-01-06 09:48:23 EST
I also have this problem on kernel-220.127.116.11-174.fc12.x86_64 but not kernel-18.104.22.168-166.fc12.x86_64
Comment 42 Vaclav Hejral 2010-01-10 03:55:43 EST
22.214.171.124-166.fc12.i686 is also problematic
Comment 43 Siddhesh Poyarekar 2010-01-12 23:33:27 EST
Here's something I observed: 1) 126.96.36.199-174 works OK for me if I boot into runlevel 3 and do a startx. I have to start in runlevel 3 for a different reason -- nothing to do with X/kernel. 2) 188.8.131.52-18 has X consuming up to 95% CPU and really not getting anywhere. Switching to console and back (Alt+F1/F7) refreshes the screen, so it seems to be something to do with the actual drawing on screen which is problematic. 3) 2.6.32-18 with another monitor attached to my laptop via my docking station reduces the CPU consumption of X to about 10-30% and the refreshing of the screen is normal again -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 44 Steve Baker 2010-01-18 18:26:58 EST
Any progress toward a solution? Status update would be appreciated. Thanks!
Comment 45 shmem 2010-01-18 20:54:34 EST
This seems to be udev and usb related. Both on Fedora 11 and Fedora 12, running on an ASUS UL50VG laptop, I noticed repeated DDC/EDID probes in /var/log/Xorg.0.log as soon as I connected a USB device: - 2 probes after connecting a 4 port mini USB hub - several probes after connecting a USB mouse. The probes started again moving the mouse - endless repeated probes after connecting a UMTS modem stick The spook ceased with all devices after pulling the device, and as soon as udev/kernel have got rid of them. I finally installed OpenSuSE 11.2, which doesn't have this bug.
Comment 46 Paul F. Johnson 2010-01-19 06:30:17 EST
shmem : can't see how this is USB related. If I use the rawhide kernel everything slows to a dead stop. Shift back to kernel 184.108.40.206-171.fc12 and everything works fine. I'm not seeing anything about USB on my laptops Xorg.0.log. It is possible it's a udev problem, but it's very unlikely.
Comment 47 Chuck Ebbert 2010-01-19 11:46:53 EST
The rawhide kernel is now based on 2.6.33-rc4 . If you want to test 2.6.32 you should be getting kernels from koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=151791
Comment 48 Siddhesh Poyarekar 2010-01-22 16:00:14 EST
The 2.6.33-rc4 kernel works OK for me. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 49 Romain LE DISEZ 2010-01-23 11:39:56 EST
With 2.6.33-0.20.rc5.git0.fc13.x86_64, I still get the problem with the same symptoms.
Comment 50 Stephen Eckel 2010-01-23 17:04:28 EST
The 2.6.33-0.18.rc4.git7.fc13.i686 kernel works for me. Graphics performance is good, no choppiness and only 3 EDID probes in my Xorg log.
Comment 51 pankaj pandey 2010-01-24 01:48:44 EST
The kernel 2.6.33-0.20.rc5.git0.fc13.x86_64 seems to work good for me.
Comment 52 Jesse 2010-01-24 08:09:24 EST
I upgraded to kernel 2.6.33-0 from rawhide last night. Video performance is actually worse than with the previous 2.6.31 kernels. It also caused my wireless card to stop working.
Comment 53 Steven Dollins 2010-01-31 20:05:54 EST
A comment by mjg59 on LWN.net http://lwn.net/Articles/370650/ suggests that this problem stems from a kernel bug causing hotplug to fire continuously. Is there another bug number associated with this problem or a discussion of this issue somewhere? Is there any mechanism for disabling hotplug which, even at the risk of reducing functionality, might allow X to run?
Comment 54 Adam Williamson 2010-02-05 12:27:39 EST
I think this is the same as https://bugzilla.redhat.com/show_bug.cgi?id=528312 ?
Comment 55 Matěj Cepl 2010-02-06 08:40:52 EST
(In reply to comment #54) > I think this is the same as https://bugzilla.redhat.com/show_bug.cgi?id=528312 > ? I don't think so, there might be same underlying problem for both of them, but bug 528312 just happens after suspend/resume and after 30s max. computer recuperates and since then works flawlessly. This bug is IIRC endless disaster.
Comment 56 Danny Yee 2010-02-06 17:06:16 EST
I've managed to get X working (at reasonable speed) with kernel 220.127.116.11-174.2.3.fc12.i686.PAE, by putting "nomodeset" in the kernel line and Option "AccelMethod" "EXA" in the Device section of xorg.conf. I have "Display controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)" (on an Asus P5Q-VM motherboard). However X did revert to unusably slow once (redrawing at glacial pace, X process locked on 100% CPU), which lasted five minutes or so until it crashed. Since I can't get the integrated intel audio on this motherboard to work either, I think this series of Asus motherboards is a "no go" zone as far as Fedora 12 goes. (Everything used to work back on Fedora 10.)
Comment 57 Danny Yee 2010-02-11 04:15:44 EST
With the fix above, however, playing a DVD in totem is unusably jerky. Also, every so often X does revert to "frame per second" updates, making doing anything incredibly slow, but after a minute or so it reverts to normal (usable).
Comment 58 Danny Yee 2010-02-11 04:25:14 EST
There seem to be patches at https://bugs.freedesktop.org/show_bug.cgi?id=25259 and https://bugs.freedesktop.org/show_bug.cgi?id=25327 Is there any chance of these getting pushed out? This is kind of critical...
Comment 59 Alex Villacís Lasso 2010-02-17 10:53:41 EST
*** Bug 562255 has been marked as a duplicate of this bug. ***
Comment 60 Marco 2010-02-17 11:31:04 EST
Still have bug with this kernel 18.104.22.168-174.2.19.fc12.x86_64 (desktop not usable). This seems related to udev. Killing udev and restarting X it reverts to normal (usable). I can see 2 time at startup - ACPI: Invalid PBLK length  some ACPI errors in messages... kernel: ACPI Error (dsfield-0140): [CAPD] Namespace lookup failure, AE_ALREADY_EXISTS kernel: ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0._OSC] (Node ffff88007975f980), AE_ALREADY_EXISTS kernel: ACPI Error (dsfield-0140): [CAPD] Namespace lookup failure, AE_ALREADY_EXISTS kernel: ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0._OSC] (Node ffff88007975f980), AE_ALREADY_EXISTS localhost kernel: ACPI Error (dsfield-0140): [CAPD] Namespace lookup failure, AE_ALREADY_EXISTS kernel: ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0._OSC] (Node ffff88007975f980), AE_ALREADY_EXISTS kernel: ACPI Error (dsfield-0140): [CAPD] Namespace lookup failure, AE_ALREADY_EXISTS kernel: ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0._OSC] (Node ffff88007975f980), AE_ALREADY_EXISTS and this (....if dp is digital port it could be related to it). localhost kernel: [drm:intel_dp_i2c_init] *ERROR* i2c_init DPDDC-C Let me know if you need more info. It's really critical (unusable desktop).
Comment 61 Gerald Geudtner 2010-02-17 14:50:26 EST
I switched to kernel 22.214.171.124-48.rc2.fc12 one week ago and the problem disappeared on the Dell Optiplex 760 I'm using.
Comment 62 Romain LE DISEZ 2010-02-17 16:02:57 EST
(In reply to comment #61) > I switched to kernel 126.96.36.199-48.rc2.fc12 one week ago and the problem > disappeared on the Dell Optiplex 760 I'm using. You're right. I'm running 188.8.131.52-55.fc12.x86_64 for few hours and I can't reproduce the bug. With previous version, it was immediate.
Comment 63 Tomislav Vujec 2010-02-17 18:22:01 EST
Hardware: Lenovo ThinkPad X200 Workaround: I can make it work with any of the above kernels using the following procedure: 1) poweroff 2) power on 3) Enter BIOS 4) Request extended testing at BOOT 5) Save BIOS settings Every now and then I have to repeat the above twice procedure to make it work, while sometimes just rebooting works as well. I have a strong suspicion that this bug has something to do with the USB, since it doesn't happen if I disconnect my USB mouse during boot. However, since it is not always reproducible (see above procedure), I can't really guarantee that that's the case here. Also, there other USB related bugs on this hardware, namely, wireshark causing kernel panic in bz559152.
Comment 64 Jaroslav Pulchart 2010-02-24 03:54:06 EST
(In reply to comment #62) > (In reply to comment #61) > > I switched to kernel 184.108.40.206-48.rc2.fc12 one week ago and the problem > > disappeared on the Dell Optiplex 760 I'm using. > > You're right. I'm running 220.127.116.11-55.fc12.x86_64 for few hours and I can't > reproduce the bug. With previous version, it was immediate. Yes, this kernel help me too. One observation: I was bale reproduce this issue more frequently with loaded kvm_intel module (with kernel 2.6.31).
Comment 65 Romain LE DISEZ 2010-02-28 08:23:22 EST
After some days, I found that the problem persist with 2.6.32. But I noted something interresting : - If I do a cold start of my computer with a kernel >= 2.6.31, I have the problem - If I do a cold start with kernel = 2.6.30, and I restart with kernel >= 2.6.31, I don't have any problems. It is like 2.6.30 put the hardware in some state, so the bug can't appear. Can somebody test that on his computer ?
Comment 66 Tomislav Vujec 2010-03-01 15:15:24 EST
Romain, my experience is similar to yours, although I was also able to "put the hardware in workable state" by repeatedly cold and warm rebooting the box using only 2.6.31. It is also amazingly difficult to debug as well, since X11 is pretty much useless and switching to text console and monitoring udev seems to stop the problem every time. Having udev log debug output (with udevlog or udevdebug boot cmdline) all the time slows down the system and stops the problem as well. All that leads me to believe that there has to be some type of race condition here.
Comment 67 Andrew Parker 2010-03-03 04:49:19 EST
I have 2 almost identical PCs which suffer from this in varying degrees. On one host, X gets 90%+ of CPU every other boot or so, but its a quad core and it is usable. If you don't look at the CPU usage, you wouldn't know this was happening. On the other host, X gets the same 90%+ of CPU on every single boot, usually within a couple of minutes of logging in. This host is completely unusable as the mouse moves once every 1-5 seconds, windows don't get repainted. Installing F11 and upgrading to F12 has the exact same symptoms, but if I use F11 kernel (kernel-PAE-18.104.22.168-167.fc11.i686) everything is OK. These hosts differ in two ways. The responsive one has the keyboard & mouse plugged into a USB hub. Unplugging the keyboard & mouse and rebooting didn't help with the unresponsive host. The other difference is the monitors. Initially I dismissed this difference as they both use the same physical monitors. However, they're connected differently. The unresponsive one is plugged into an Acer X243W via the VGA port. Using the DVI port (normally used by the responsive host) however the system becomes usable, although a little jerky at times. The X log continues to grow, but X CPU usage is no longer excessive. Given that this problem is so easy for me to provoke, let me know if there is any other info or debugging that I can provide.
Comment 68 Tomislav Vujec 2010-03-03 14:01:43 EST
Created attachment 397638 [details] udevadm monitor --property A bit more info with "udevadm monitory --property". After a recent cold reboot, problem reappeared, and I was able to get the flood of kernel udev events generated apparently by the graphics subsystem. It is Intel's GM45 with i915 kernel driver .
Comment 69 Matěj Cepl 2010-03-04 12:30:17 EST
*** This bug has been marked as a duplicate of bug 528312 ***
Comment 70 Jaroslav Pulchart 2010-05-07 02:48:27 EDT
I updated to F13 (devel) and this issue is still valid (Xorg.0.log is full of "EDID for output ...") after suspend to disk and resume. Kernel version 22.214.171.124-79.fc13.x86_64.