Bug 571046 - The latest kernel/driver update causes the screen to flicker (with ATI mobility X1600 graphics card).
The latest kernel/driver update causes the screen to flicker (with ATI mobili...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Jérôme Glisse
Fedora Extras Quality Assurance
card_R500/mM
: Triaged
: 579576 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-06 11:08 EST by Matej
Modified: 2010-12-03 16:57 EST (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-03 16:57:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg output (without kernel parameter) (45.02 KB, text/plain)
2010-03-11 16:06 EST, Matej
no flags Details
content of '/var/Xorg.0.log' when booting normally (67.26 KB, text/plain)
2010-03-11 16:08 EST, Matej
no flags Details
dmesg output (with the 'radeon.new_pll=0' boot parameter) (44.57 KB, text/plain)
2010-03-11 16:19 EST, Matej
no flags Details
the '/var/log/Xorg.0.log' file (with the 'radeon.new_pll=0' boot parameter) (67.28 KB, text/plain)
2010-03-11 16:20 EST, Matej
no flags Details

  None (edit)
Description Matej 2010-03-06 11:08:50 EST
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:
Comment 1 Xaeroman 2010-03-07 09:05:09 EST
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.
Comment 2 Jon Senior 2010-03-08 03:48:09 EST
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.
Comment 3 ptg21 2010-03-08 08:41:06 EST
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
Comment 4 Eric Hedström 2010-03-08 14:22:29 EST
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.
Comment 5 Eric Hedström 2010-03-10 14:23:33 EST
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.
Comment 6 Matěj Cepl 2010-03-10 19:47:42 EST
(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.
Comment 7 Dave Airlie 2010-03-11 01:01:16 EST
can you boot with radeon.new_pll=0 on the kernel command line in grub?
Comment 8 Dave Hatton 2010-03-11 04:30:11 EST
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.
Comment 9 Xaeroman 2010-03-11 06:41:35 EST
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.
Comment 10 Alex Kelly 2010-03-11 14:52:48 EST
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.
Comment 11 Alex Kelly 2010-03-11 15:16:37 EST
After some searching, I was able to get it working if I also appended "radeon.modeset=0" to the kernel parameters.
Comment 12 Matej 2010-03-11 16:06:59 EST
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).
Comment 13 Matej 2010-03-11 16:08:10 EST
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).
Comment 14 Matej 2010-03-11 16:18:08 EST
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.
Comment 15 Matej 2010-03-11 16:19:40 EST
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.
Comment 16 Matej 2010-03-11 16:20:43 EST
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.
Comment 17 Xaeroman 2010-03-16 05:58:51 EDT
Setting the "radeon.modeset=0" kernel parameter works for me too! thanks to all.
Comment 18 Ali Sobhi 2010-03-24 11:19:44 EDT
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.
Comment 19 Shiraz 2010-03-31 09:19:56 EDT
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.
Comment 20 Duboucher Thomas 2010-04-01 05:04:22 EDT
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)
Comment 21 Lars Gunther 2010-04-04 10:29:26 EDT
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.
Comment 22 Saikat Guha 2010-04-04 11:57:52 EDT
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.
Comment 23 Yanko Kaneti 2010-04-07 02:11:23 EDT
*** Bug 579576 has been marked as a duplicate of this bug. ***
Comment 24 Miro Hadzhiev 2010-04-07 09:39:45 EDT
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.
Comment 25 Lars Gunther 2010-04-08 06:13:21 EDT
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.
Comment 26 Shiraz 2010-04-12 03:31:11 EDT
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.
Comment 27 Miro Hadzhiev 2010-04-12 04:06:15 EDT
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
Comment 28 Xaeroman 2010-04-12 04:47:29 EDT
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!
Comment 29 Shiraz 2010-04-12 05:36:36 EDT
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
Comment 30 Shiraz 2010-04-12 05:36:36 EDT
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
Comment 31 Ali Sobhi 2010-04-12 10:36:49 EDT
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.
Comment 32 Shiraz 2010-04-12 10:56:15 EDT
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.
Comment 33 Ali Sobhi 2010-04-14 10:52:24 EDT
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
Comment 34 Lars Gunther 2010-04-15 16:11:37 EDT
Absolutely no improvement for me with kernel 2.6.11-99. Both flags still needed.
Comment 35 Ray 2010-05-10 13:44:19 EDT
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
Comment 36 Lars Gunther 2010-05-19 15:51:16 EDT
Does anyone know if this is fixed in Fedora 13?
Comment 37 Ray 2010-05-20 13:36:41 EDT
Latest kernel 2.6.32.12-115 does not fix this.
Comment 38 António Lima 2010-05-25 17:59:25 EDT
I a slight flicker issue with fedora 13. My graphics card is a Radeon HD3400. 

Adding adeon.new_pll=0 fixed the problem.
Comment 39 Ali Sobhi 2010-06-03 16:02:12 EDT
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.
Comment 40 Srinivas 2010-06-23 01:06:26 EDT
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.
Comment 41 Ray 2010-07-22 11:17:26 EDT
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.
Comment 42 Ray 2010-07-22 11:21:11 EDT
I forgot to mention: the KDE issue also didn't happen when I booted without an external monitor.
Comment 43 Andrej Kvasnica 2010-08-07 18:27:48 EDT
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.
Comment 44 Bug Zapper 2010-11-03 16:38:47 EDT
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
Comment 45 Bug Zapper 2010-12-03 16:57:23 EST
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.

Note You need to log in before you can comment on or make changes to this bug.