Component name: xorg-x11-drv-ati Description of problem: The whole screen flickers like crazy. Sometimes things are still recognisable. However, it is very annoying and makes the desktop not usable. Version of related components: kernel-PAE-2.6.32.9.67.fc12.i686 xorg-x11-drv-ati-firmware-6.13.0.0.21.20100219gite68d3a389.fc12.i686 xorg-x11-drv-ati-6.13.0.0.20.20091221git4b05c47ac.fc12.i686 xorg-x11-server-Xorg-1.7.5.1.fc12.i686 xorg-x11-server-common-1.7.5.1.fc12.i686 Grphics card: ATI Mobility X1600 How reproducible: Always. Steps to Reproduce: 1. Choose the correct kernel version (kernel-PAE-2.6.32.9.67.fc12.i686) -- old versions work well. 2. Boot and wait. Actual results: Flickering screen -- not usable. Expected results: Normal screen -- usable. Additional info:
I am having *exactly* the same problem with kernel-PAE-2.6.32.9.67.fc12.i686. Older versions (like, 2.6.31.12-174.2.22.fc12.i686.PAE) work perfectly. I got the newer kernel-PAE-2.6.32.9.67.fc12.i686 when I did a yum update recently on a laptop having a ATI X1400 mobility graphics card.
Same problem here with a T60 w/ X1300 mobility Radeon card. Only effects the external (BGA-0) display. It appears to be unrelated to the video driver (xorg-x11-drv-ati) as removal of the driver show the symptoms during boot, but a black screen at login. This implies that the problem is at a lower-level than xorg.
Same problem here with Acer Aspire 1410 with integrated Intel GMA4500MHD graphics 2.6.32.9-67.fc12.x86_64 kernel / xorg-x11-server 1.7.5-5.fc12 package
Same problem here with an HP nw8440 laptop with ATI FireGL V5200. Booting back to the 2.6.31 kernel works fine, so the problem is not the xorg ati driver that got updated at the same time. Also the grub boot menu looks ok, but once the kernel loads the screen goes all flickery as others have described.
Unfortunately still a problem with new kernel 2.6.32.9-70.fc12.i686. Can the owner or someone change the component to kernel and assignment of this bug from the X/OpenGL mailing list? Thanks.
(In reply to comment #5) > Unfortunately still a problem with new kernel 2.6.32.9-70.fc12.i686. > > Can the owner or someone change the component to kernel and assignment of this > bug from the X/OpenGL mailing list? Thanks. No please not, we prefer to keep video graphics drivers in xorg-x11-* components even though we are talking about kernel code ... no need to overload already too large kernel component with our junk. Please attach your X server config file (/etc/X11/xorg.conf, if available), output of the dmesg command, system log (/var/log/messages), and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
can you boot with radeon.new_pll=0 on the kernel command line in grub?
Appending "radeon.new_pll=0" to the kernel command line in grub does indeed prevent the flickering problem I see on my HP nx9420 which has Radeon X1600. Without this option I see very bad flickering after grub has completed - during the boot "f" splash screen, in X and if I alt-F2 to a VT.
setting "radeon.new_pll=0" on grub command line doesn't seem to work for me with the kernel-PAE-2.6.32.9-70.fc12.i686. I can still see flickering on the bigger secondary screen attached to my laptop. The laptop display works fine, as has always been the case. I have a ATI X1400 mobility.
The addition of the kernel parameter also did not fix the issue for me. It also added a very slight flicker to the laptop screen which was not present before.
After some searching, I was able to get it working if I also appended "radeon.modeset=0" to the kernel parameters.
Created attachment 399449 [details] dmesg output (without kernel parameter) This is the output of `dmesg` when booting normally (without specifying the radeon.new_pll=0 and with KMS enabled).
Created attachment 399450 [details] content of '/var/Xorg.0.log' when booting normally This is the full content of '/var/Xorg.0.log' when booting normally (without specifying the radeon.new_pll=0 and with KMS enabled).
The kernel boot parameter 'radeon.new_pll=0' made the symptoms disappear completely (I have no external screen -- I am talking about the laptop's only screen). I also posted some attachments.
Created attachment 399455 [details] dmesg output (with the 'radeon.new_pll=0' boot parameter) Again the `dmesg` output. This time with the 'radeon.new_pll=0' boot parameter.
Created attachment 399457 [details] the '/var/log/Xorg.0.log' file (with the 'radeon.new_pll=0' boot parameter) Again the '/var/log/Xorg.0.log' file. This time with the 'radeon.new_pll=0' boot parameter.
Setting the "radeon.modeset=0" kernel parameter works for me too! thanks to all.
Running F12 on an IBM thinkpad t60p with ATI FireGL. The updates has caused the external display (analog) connected through docking station flickers. I have added "nomodeset" on the kernel boot command and it removes the flickers. But it has side-effects. This is a temporary work-around. "radeon.new_pll=0" does not work for me alone. I have to include "radeon.modeset=0" also to stop the flickering. This practically is the same for nomodeset for me since I only have one GPU (unlike the latest TP like w500 which have two GPU, Intel and ATI or nVidia). The side effects of "nomodeset" that I have seen have to do with standby. When going into the standby mode the first time, it is OK. coming out of the standby, both the laptop screen and external screen are blank. I have to switch to virtual console (alt+ctrl+F2) and come back to the graphic console (alt+ctrl+F1) to make the screen visible. The bluetooth and network are off and I have to manually enable them. There is a "vbetool post" command that starts and consumes 100% of CPU at times and I have to kill that. I guess that command is trying to set the events correctly and can't. at this point I can use the laptop. But the second standby never completes and I have to power down. So I guess since the thinkpad acpi or buttons are not need with "KMS", they don't get installed and the kernel update without KMS activated can't handle the standby mode correctly. I have not tried to get the tp acpi and event packages installed and manually configured to see if it helps with the standby.
Same problem with HP 6910p with ATI Technologies Inc M64-S [Mobility Radeon X2300]. I don't know which update broke this since I didn't upgrade my machine for the whole of February. Right now I am running 2.6.32.10-90.fc12.i686.PAE. "nomodeset" kernel parameter worked for me too but with the same side effects as mentioned by Ali. For me, it is only disturbing my external monitor connected to my docking stations (doesn't matter). I checked my colleague's 6910p with fully patched Ubuntu 9.10 and it ran smooth on my same docking station with same external monitor. Let me know if more information is required.
The issue is also present on an HP nc8430 (Ati mobility X1600) with the secondary screen (VGA); affected kernels are (all x86_64): * 2.6.32.9-67 * 2.6.32.9-70 * 2.6.32.10-90 * 2.6.32.10-92 (testing)
I have the same problem on my Thinkpad z61p. Up until today I have handled it by using the older kernel, but the last upgrade removed that option from the GRUB menu. Googling, I found this page and adding radeon.new_pll=0 did work, but I can no longer put one screen above the other. I like to put the external monitor above the built in one, for a screen resolution of 1920 x 2400. This worked perfectly until I applied this fix.
I have this problem on a Thinkpad T60p (Mobility FireGL V5250). == Problem With all recent F12 kernels (2.6.32.9, 2.6.32.10) every so often the screen initially flickers a little (e.g. overlays the top half on the bottom half), and then 4-5 seconds later, the screen completely fills with flickering white horizontal lines making it impossible to see anything. == Mitigation/Workarounds 1. This problem doesn't exist with the release F12 kernel (2.6.31.5). Installing the old kernel fixes the problem (but the old kernel has other issues like suspend/resume). 2. On the new kernel, cycling video modes or chaging VTs does NOT fix the problem. However, inducing a suspend/resume cycle (e.g. blind typing pm-suspend) does temporarily fix the problem. The flickering begins again sometimes seconds after resuming, sometimes minutes (completely random). 3. radeon.new_pll=0 does *NOT* work for me. Disabling modesetting altogether (radeon.modeset=0) works around the problem.
*** Bug 579576 has been marked as a duplicate of this bug. ***
However, I believe that the 3D performance of my ati Mobility X1600 (rv515) is a little bit worse when "radeon.new_pll=0" parameter is set.
The problem has returned for me, using 2.6.32.10-90 or 2.6.32.9-70. Very annoying! I have added "radeon.modeset=0" as well now. It seems to work - so far! The fact that one switch seemed to work on its own for a while is really food for thought.
somebody screwed this up big time. With all the latest updates in my FC12, I don't even get to see my gdm screen. I just blindly enter the password and then I get the desktop without any wallpaper. That is, if I have external monitor connected and I remove 'nomodeset' from the kernel arguments. It is definitely worse then how it was before this bug. I don't know if it is new or old but external monitor is badly broken now. I am still wondering why Ubuntu has no issues with that. I might as well change the distro.
https://bugs.launchpad.net/bugs/541737 Think again. (: I came here from Ubuntu. And here I found the workaround (which maybe you've not noticed) which is to add to the kernel parameters: radeon.new_pll=0
I still see the problem in 2.6.32.10-90. But radeon.modeset=0 seems to be working for me, so far! I am hoping the next kernel update would fix it!
my comment on going away from Fedora was only out of frustration. I am a very loyal Fedora user and I truly believe that it is the best distro around. I connected my colleagues Ubuntu laptop to my dock and tested the whole external monitor functionality and it worked like a charm, like it used to with Fedora a few updates ago. Kernel 2.6.33 seems to have latest Radeon drivers. Does anyone know if that would help us with our miseries? I'll pass on radeon.modeset=0 argument to the kernel and see what it does for me. Right now, this whole external monitor thing is in pretty bad shape. Once I lock my desktop screen, I don't get it back. I again have to blindly swap my finger and then I see my desktop but the display output moves from my external monitor back to the laptop screen. I again have to hit function keys repetitively to get the display back on to my external monitor. Thanks
my comment on going away from Fedora was only out of frustration. I am a very local Fedora user and I truly believe that it is the best distro around. I connected my colleagues Ubuntu laptop to my dock and tested the whole external monitor functionality and it worked like a charm, like it used to with Fedora a few updates ago. Kernel 2.6.33 seems to have latest Radeon drivers. Does anyone know if that would help us with our miseries? I'll pass on radeon.modeset=0 argument to the kernel and see what it does for me. Right now, this whole external monitor thing is in pretty bad shape. Once I lock my desktop screen, I don't get it back. I again have to blindly swap my finger and then I see my desktop but the display output moves from my external monitor back to the laptop screen. I again have to hit function keys repetitively to get the display back on to my external monitor. Thanks
Just updated this morning to 2.6.32.11-99.fc12.i686.PAE flickering on external display (analog 1280x1024) still exists. I have IBM/Lenovo T60p with ATI FileGL 5200. radeon.new_pll=0 does not help radeon.modeset=0 is the same as adding nomodeset kernel parameter and it makes the display look good, no flickering but has its own suspend/resume issues (mentioned in my previous post). If this helps, I've noticed that large vertical area on left and right of the screen have the most flickering and a narrow vertical band in the middle of the screen is perfect and no flickering. I'm using kernel parameter "notmodeset" for now.
Thanks for explaining the exact flickering behavior. I am seeing the same ever since this problem started. Haven't tried radeon.modeset=0 but I am using nomodeset as a workaround. It makes things somewhat better but as a side-effect (apart from what you mentioned), moving display from internal to external monitor and vice versa is not really seamless. The behavior is very flaky. In fact, I can't move my display to external monitor completely when using nomodeset. Extended display spanning both the LCDs are working, indeed. I cannot believe that only a handful of guys (us) are seeing this problem. Do we know what the commonality is here? Is it the Radeon driver? I might have to read all the posts.
I just noticed that with the updates on 4/13, the flickering is reduced. However the external display still has some flickering which makes it unusable. "yum history info" shows the relevant and possible culprit to be: Updated libdrm-2.4.17-1.fc12.i686 Update 2.4.18-2.fc12.i686 Updated libdrm-devel-2.4.17-1.fc12.i686 Update 2.4.18-2.fc12.i686 This may be just a coincidence. I'm using the following kernel with "nomodeset" 2.6.32.11-99.fc12.i686.PAE #1 SMP
Absolutely no improvement for me with kernel 2.6.11-99. Both flags still needed.
Another victim here. radeon.new_pll=0 does not work for me and radeon.modeset=0 renders the system completely unbootable. I also cannot run system-config-display (blank screen) (tried to create an xorg.conf). I'm on a Gateway laptop with Radeon Mobility X1400 and docking station using an external monitor. Kernel 2.6.31.12-174.2.3.fc12.i686 works fine and booting with that is my work around. 2.6.32.11-99.fc12.i686 (and related xorg ati driver), which came down with an update over the weekend, is causing the issue. I hadn't updated in a while after an update on my home desktop system (also radeon) nearly killed my system back in March. That bug (571084) still has no solution and there's been virtually no (visible) action on it. The only work-around that worked there was to disable ALL acceleration with 'Option "NoAccel" "On"'. (On my laptop though I can't even create an xorg.conf to try that.) These issues are getting really old. The thing that kills me is that both of these systems were working PERFECTLY until an update back in ~January sometime. It's getting pretty hard to maintain a reliable system based on Fedora when clearly half-baked experiments are being pushed out in updates. I hope some resolution comes soon. As with the other bug I mentioned, I'll be happy to do anything I can to help diagnose this issue. Thanks
Does anyone know if this is fixed in Fedora 13?
Latest kernel 2.6.32.12-115 does not fix this.
I a slight flicker issue with fedora 13. My graphics card is a Radeon HD3400. Adding adeon.new_pll=0 fixed the problem.
Just did a fresh install of Fedora 13 on my thinkpad (t60p + ATI FireGL) no flickering at all. What do I need to do to preserve the kernel and X drivers when updating to make sure that it works. Because if it doesn't I need to be able to fall back to previous version and blacklist the updates.
I am using Acer 5100 with ATI graphics module. After suspend and resume - the screen flickers like anything. This happens again and again - until I restart the laptop.
I still have this issue even with the latest kernel (2.6.32.16-141) installed earlier this week. (My xorg driver is xorg-x11-drv-ati-6.13.0-0.21.20100219gite68d3a389, apparently from May? -- is that really the last xorg update?). After the last round of updates however, KDE is broken with my old working kernel (2.6.31.12-174.2.3). When I try to login to KDE it kills the system hard (no keyboard, etc). I don't know if this is related to this bug but I managed to fix it by installing an xorg.conf. I managed to make one using my old working kernel (I previously was unable to and I'm not sure why) and I was going to try some of the workaround settings but before I added them I tried booting with just the vanilla xorg.conf and KDE works now!) I've also noticed one new thing regarding the flickering bug: it doesn't happen when I boot the laptop without an external monitor. My laptop has a wide screen panel and it boots with that just fine. I have two setups (home and work), however, where I use an external monitor (in both cases, 1280x1024 LEDs, with a KVM and a port replicator). It appears to me that something (KMS?) is trying to use the same settings for the external monitor as it does for the laptop's wide screen panel. I suspect this may be behind the flickering issue. I suspect this partly because if I boot into console mode (run level 3), the size of the text screen is wrong: it appears to be too short and too wide for the external monitor (like a wide screen panel perhaps?). It has occurred to me that it may be useful to test the external monitors without the KVM. I will try that first chance I get and report the results here.
I forgot to mention: the KDE issue also didn't happen when I booted without an external monitor.
Mobile Radeon 1600 on Fedora 13 (running 2.6.33.6-147.2.4.fc13.x86_64 kernel). Adding radeon.new_pll=0 kernel parameter fixed the problem. Also removing SYSFONT=latarcyrheb-sun16 kernel parameter partially fixed the problem in text mode.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.