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
That should be 965 not 955 - d'oh!
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.
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-2.6.31.5-127.fc12.x86_64 It works fine with kernel-2.6.30.9-96.fc11.x86_64 I do not have xorg.conf. The use of nomodeset did not change the behaviour. Looking at Xorg.0.log_2.6.31.5-127, Xorg seems to be in an infinite loop. The log of Xorg looks the same as in the bug #522909
Created attachment 368434 [details] dmesg with kernel 2.6.30
Created attachment 368435 [details] Xorg.0.log with kernel 2.6.30
Created attachment 368436 [details] dmesg with kernel 2.6.31
Created attachment 368437 [details] Xorg.0.log with kernel 2.6.31
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?
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 2.6.31.5-127 but the Xorg.0.log was of the previous kernel (2.6.31.5-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 2.6.31.5-122. I can't see what changed (could kernel-firmware < 2.6.31.5-127 be the cause ?). The fact is the problem is solved for me, but I don't know why.
The bug is back :-( Now I'm sure I'm running 2.6.31.5-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.
Created attachment 368964 [details] New dmesg with error for kernel 2.6.31.5-127
Created attachment 368965 [details] New Xorg.0.log with error for kernel 2.6.31.5-127
(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?
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
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-2.6.31.5-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?
FWIW, on F-12, I updated to kernel-2.6.31.6-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.
I still have the problem with 2.6.31.6-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)
(In reply to comment #17) > I still have the problem with 2.6.31.6-145.fc12.x86_64. Are you having the repeated DDC/EDID probes?
(In reply to comment #18) > Are you having the repeated DDC/EDID probes? Yes.
Well, sorry to report - after ~16 hours on the newer kernel, my system reverted back to performing the repeated DDC/EDID probes :(
*** Bug 541878 has been marked as a duplicate of this bug. ***
*** Bug 539310 has been marked as a duplicate of this bug. ***
I can also confirm this bug, with both kernel-PAE-2.6.31.5-127.fc12.i686 and kernel-PAE-2.6.31.6-145.fc12.i686. Reverting to kernel-PAE-2.6.30.9-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...
Not sure if this had any fixes for the problems reported here: https://admin.fedoraproject.org/updates/kernel-2.6.31.6-162.fc12 You may want to try it anyway. It does have Intel vblank sync fix, at least.
(In reply to comment #24) > Not sure if this had any fixes for the problems reported here: > > https://admin.fedoraproject.org/updates/kernel-2.6.31.6-162.fc12 It didn't fix it for me.
(In reply to comment #24) > Not sure if this had any fixes for the problems reported here: > > https://admin.fedoraproject.org/updates/kernel-2.6.31.6-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....
Just an additional data point: my Thinkpad X200s runs just fine under F12. 00:02.1 Display controller [0380]: 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-2.6.31.6-145.fc12.x86_64
(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-2.6.31.6-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.
2.6.31.8-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?
(In reply to comment #29) > 2.6.31.8-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.
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.
Same issue: Intel i915 module with kernel-2.6.31.6-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.
(In reply to comment #32) > Intel i915 module with kernel-2.6.31.6-174.fc12.x86_64 Do you mean .9 here?
I guess I have the same problem xorg-x11-drv-intel-2.9.1-1.fc12.i686 2.6.31.9-174.fc12.i686 bug 550505 (https://bugzilla.redhat.com/show_bug.cgi?id=550505)
*** Bug 550505 has been marked as a duplicate of this bug. ***
(In reply to comment #33) > (In reply to comment #32) > > > Intel i915 module with kernel-2.6.31.6-174.fc12.x86_64 > > Do you mean .9 here? My bad... Yes. > > Intel i915 module with kernel-2.6.31.9-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.
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.
I'm seeing this in rawhide (2.6.32.2-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
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-2.6.31.9-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
Moving back down to the 2.6.31.8-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)
I also have this problem on kernel-2.6.31.9-174.fc12.x86_64 but not kernel-2.6.31.6-166.fc12.x86_64
2.6.31.6-166.fc12.i686 is also problematic
Here's something I observed: 1) 2.6.31.9-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) 2.6.32.2-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
Any progress toward a solution? Status update would be appreciated. Thanks!
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.
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 2.6.31.8-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.
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
The 2.6.33-rc4 kernel works OK for me. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
With 2.6.33-0.20.rc5.git0.fc13.x86_64, I still get the problem with the same symptoms.
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.
The kernel 2.6.33-0.20.rc5.git0.fc13.x86_64 seems to work good for me.
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.
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?
I think this is the same as https://bugzilla.redhat.com/show_bug.cgi?id=528312 ?
(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.
I've managed to get X working (at reasonable speed) with kernel 2.6.31.12-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.)
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).
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...
*** Bug 562255 has been marked as a duplicate of this bug. ***
Still have bug with this kernel 2.6.31.12-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 [7] 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).
I switched to kernel 2.6.32.8-48.rc2.fc12 one week ago and the problem disappeared on the Dell Optiplex 760 I'm using.
(In reply to comment #61) > I switched to kernel 2.6.32.8-48.rc2.fc12 one week ago and the problem > disappeared on the Dell Optiplex 760 I'm using. You're right. I'm running 2.6.32.8-55.fc12.x86_64 for few hours and I can't reproduce the bug. With previous version, it was immediate.
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.
(In reply to comment #62) > (In reply to comment #61) > > I switched to kernel 2.6.32.8-48.rc2.fc12 one week ago and the problem > > disappeared on the Dell Optiplex 760 I'm using. > > You're right. I'm running 2.6.32.8-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).
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 ?
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.
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-2.6.29.4-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.
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 .
*** This bug has been marked as a duplicate of bug 528312 ***
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 2.6.33.3-79.fc13.x86_64.