[lucid][R500 X1400] intermitent screen corruption (pink world ) - regression from -20 to -21 kernel

Have you tried using the "nomodeset" kernel boot option?

Lollerke : no, I didn't touched anythiing. How can I try such option ?

Currently, the only workaround I've found is to boot on the Karmic kernel ( 2.6.31-20-generic ). It works fine, no more problem. Everything is fine (except the boot screen which is ugly but that not an issue for productivity)

In GRUB navigate to the lucid kernel and press the 'e' key.
At the end of a line can see this: quiet splash
modify it to: quiet splash nomodeset
and press ctrl+x to boot up the kernel.

I've upgraded to kernel 2.6.32-17-generic and the freeze/glow disappeared.

Instead, the brightness is blinking and I can see some horizontal white lines filckering on the screen. But at least, it is not freezing anymore.

(This is without the nomodeset option, still using the default kernel on grub. I will reboot to try with nomodeset)

2.6.32-17-generic with nomodeset option : no problem, the bug disappeared.

(but the boot is ugly ;-) )

Hi Lionel, well at least turning off KMS sounds like it's working around the issue.

Would you mind reproducing the issue, taking a photo of the screen and attaching it? You've described the corruption quite well but sometimes being able to see what the screen looks like provides a strong clue about what's gone wrong.

Also, please run `apport-collect 545096` - this will attach your dmesg and various other files useful in debugging X issues in general.

In addition to that, there is a tool called avivotool (provided in the 'radeontool' package that can be used to help get an idea of what is going on in the gpu registers. Run it two times, once when you're reproducing the issue (you might have to ssh into the box to do this):

    avivotool regs all > regdump_broke.txt

And then again with your graphics configured to display properly (e.g. using -vesa or nomodeset):

    avivotool regs all > regdump_broke.txt

In this video, you can see how the green/pink corruption invades the screen (video was started after the start)

Other video. The part were black "regain" some space over the green invasion is because I switched console (but the keystroke was done 30 seconds before).

my desktop, invaded by the pink invasion (everything is frozen)

switching to console

note that the black "patch" on the right of the screen is not an artifact of the picture. It is well visible as something part of the corruption.

regdump done by ssh during the corruption

regdump during a clean set (with nomodeset option at boot)

unfortunatly, I cannot use apport-collect because I'm behind a proxy. Ask me what you need.

Hi Lionel, thanks for all the files. It looks really weird, haven't seen anything quite like that. I've gone ahead and forwarded the bug upstream and subscribed you to it. Please follow up with them if they need any additional info or wish you to test something.

Since you've narrowed it to KMS, it's almost certainly a kernel bug rather than X.org, but we can continue tracking it here until we hear from upstream. Booting the mainline kernel might be worth trying, although our drm is pretty close to the latest upstream stuff so I wouldn't expect the issue is already fixed there yet. You probably have found nomodeset to be an acceptable workaround for the time being.

Hi Bryce,

I currently have two possible workarounds : nomodeset or booting the Karmic kernel (that I kept for that kind of situation).

For me, there's no problem of course. I use beta release to find such bugs but I hope it will be fixed before the final release. The strange point is that it seems I'm the only one affected by that bug.

Thanks for your good work :-)

With the latest upgrade (changelog says that DKMS is now enabled by default), the bug happens all the time, even with the nomodeset option or an old kernel. It looks like the nomodeset option is not working. (= The computer is totally unusable on Lucid)

Also, it happens in recovery mode in console, as soon as the driver is loaded, without starting X!

Finally, it seems to be related to the heat. In the morning, it doesn't happen for hours then it starts and become more and more frequent. Even full shut down are not sufficient. Shutting down the computer for one hour make it bug free for a couple of hours again.

Do you have an older LiveCD you could boot to verify that the recent behaviors are software regressions? Given that you're noticing some relation to heat, I'm starting to wonder if it might be hardware death throws? I recently had an R5xx card go out on me due to heat issues (the fan on the card died), and that led to some pretty bad bugs. Swapped out the card with an R6xx one and the things been going strong since.

I gather your system is a laptop though, so video cards swaps might not be in the cards so to speak...

Hi Bryce,

Hardware problem is the first think I thought but :

- There's never any problem under intrepid or under Windows
- The problem appeared the very day I upgraded to Lucid
- The problem still doesn't appear if I fall back to the VESA driver

Could you provide me a build of the Lucid radeon driver which is pre-KMS
by default ? (more than 8 days old, unfortunatly my cache doesn't go
that far).

I could then confirm that nomodeset is working or not with those older
driver and not the newest.

Le vendredi 02 avril 2010 à 22:52 +0000, Bryce Harrington a écrit :
> Do you have an older LiveCD you could boot to verify that the recent
> behaviors are software regressions? Given that you're noticing some
> relation to heat, I'm starting to wonder if it might be hardware death
> throws? I recently had an R5xx card go out on me due to heat issues
> (the fan on the card died), and that led to some pretty bad bugs.
> Swapped out the card with an R6xx one and the things been going strong
> since.
>
> I gather your system is a laptop though, so video cards swaps might not
> be in the cards so to speak...
>

Try pci=nomsi option instead of nomodeset.

Without using any option, I worked the whole day without having the bug. But I did two things in the morning :

1) I installed the fglrx package

2) I removed -ati and -radeon, rebooted in VESA then reinstalled them and rebooted in radeon.

So, I see only 4 possible explanations :

1) It's an hardware problem only triggered by KMS that was uncovered by the Lucid upgrade, that becames more important the day KMS was switched on by default and then suddenly disappeared. It looks like a lot of coincidence to me but still possible.

2) Having the fglrx package solves the bug, even if lspci says that I'm using radeon, ttm, drm_kms_helper, drm, i2c_algo_bit.

3) The bug was caused by some bad values in some registers of the card. Those registers were reset when I rebooted with the VESA driver. It has to be noted that the bug appeared after I booted once with the VESA driver just after my lucid upgrade.

4) The bug isn't related to heat and is even more random. (it appears only on weekday!)

ok, it's becoming more and more crazy.

Now, the bug appears if I write "nomodeset" at boot. And only in that case.

If I don't write anything, I don't have that bug but very very low window switching. (and glxinfo crashes when trying to get information about the situation)

It looks like the situation is reverted.

pci=nomsi allows me to have snappy windows switching and, so far, no bug (but some light brightness changes. I cross my fingers that it will not become a pink screen).

Also, could you point me to user files in $HOME that could affects the behaviour of X ?

I've discovered that another profile on the same computer was able to connect to a beamer while mine cannot. The other profile seems to not have the slowness (but I need to confirm that).

There is a monitors.xml file that gnome uses to set stuff up, that might be worth removing. Other files named ~/.x* could be worth study. Also look in `env` for settings that could result in X changes (e.g. DISPLAY). There is also a ~/.drirc which controls your 3D settings (driconf edits this file)

Btw, when moving from -fglrx -> -ati, be careful as if you manually uninstall stuff it can leave your system in a funky state.

For more info, see the proprietary driver conflict page at http://wiki.ubuntu.com/X/Troubleshooting/

Bryce > you were right. A fglrx .so was still present on the system. Removing it froze everything. Now, my system is back to normal : "pink world" when booting normally, no problem when using nomodeset.

I've been runing without any corruption for 3 days using kernel 2.6.32-20-generic since Monday night. (there were both a kernel upgrade and a radeon upgrade)

There was obviously a fix in this kernel. I've even seen a related line in the changelog but I can't find it back. It was something like "fixing the pulsating backlight horizontal sync".

I still have some subtles backlight changes but those are a lot less annoying, a lot less frequent and, most of all, there's no corruption anymore !

Now, I hope that today's upgrade will not bring back the problem :-) If the problem is not back, this bug can be considered as fixed.

bad news : corruption is back with 2.6.32-21-generic !

Alright, well at least this has pinpointed the problem to a kernel regression. I will forward to that team to investigate further. If you're comfortable building the kernel you could test out reverting the suspect patch(s) and see if you can narrow down to the specific patch that causes the issue (or that got dropped from -20 -> -21).

Hi there, i have (pink world) also on my screen with grafic card: ATI 9800PRO to with kernel -21 but not then i use kernel -20

Something similar was triggered yesterday on my Lenovo Thinkpad R60, having an ATI X1400 graphics system - this started when using the game "battle tanks". The GPU temperature rose quickly to above 70 degrees. The problem did not stop even after quitting the game, but the GPU temperature was reduced to 62-63 degrees C.

Symptoms:
The display became "over-exposed" at the edges, approximately 2-3 cm, flickering and some overall "noise/bright spots". The whole computer was slowing down/locking completely at times. Temperature reading for the CPU was at 59 degrees C.

The fan speed was at medium all the time at around 2700 rpm.

Further details:

Ubuntu Lucid Lynx amd64 kernel, updated as of 25 April.
Compiz effects turned off.

I was able to reproduce that bug with -21 kernel but it seems a lot less frequent. So, to summarize, this is what happens:

There are four possible situations :
1) Everything is smooth and fine.
2) Splash screen is ugly but everything is fine once logged (not a real problem)
3) Normal session with backlight flickering. This starts immediatly at login and appears randomly during the whole session. This is a bit annoying but a bit subtle and you can work with it the whole day (if you are in a bright room. A bit more annoying in darker places).
4) Pink world. Heavy corruptions with freezes. This is appears randomly during the session but starts only after at least 4 or 5 minutes. This make it impossible to work with the computer but also impossible to know if you will hit the bug or not..

It has to be noted that those 4 situations are mutually exclusives. It means that if I have an ugly splash screen, I'm sure I will not have any corruption. Also, as soon as I see backlight flickering, I know I will not have any Pink World !

* With normal boot (-21 kernel) :
  - 50% of the time, everything is fine and smooth (1)
 - 40% of the time, backlight flickering (3)
 - 10% of the time, pink world (4)

* With normal boot (-20 kernel) :
  - 80% of the time, pink world (4)
  - 20% of the time, (3)

* With nomodeset (any known kernel):
 - 100% of the time, everything work but splashscreen (2)

kms + x1400 == complete waste of time
use 'radeon.modeset=0' for any of those: Archlinux (2.6.32 and 2.6.33) / Fedora 13 / Ubuntu Lucid

I have a related problem with my ATI x1400, open source driver, and dual monitors. If I setup a secondary monitor, the image on that monitor looks all distorted with waves. Primary screen (the one on my laptop) works with, though. This problem disappears if I use "nomodeset" at boot time.

Following from my last comment, after setting "nomodeset" at boot time, full screen video (or enlarged up to a certain size) looks weird, as if it was decomposed on separate color grids that have different offsets.

I got an ATI x1400 mobility radeon as well, using a ThinkPad T60. (german bug dscription here: http://forum.ubuntuusers.de/post/2472883/ )

1. the overall GPU performance is worse on lucid, then on karmic - on both kernels so far. for example, I get 40 fps less in quake live, and 50 fps less in openarena, when comparing performance under karmic, with performance under lucid (using exactly the same hardware and settings, of course).

2. often, the colors go wild. and parts of the screen flicker in pink and green - 3d applications definitely cause this, but it also happens seemingly at random when only using office programs.

failed attempts to solve this:
- disabling KMS didn't help
- the radeonHD driver didn't do any good
- I waited for a kernal update (2.6.32-22)
- the proprietary driver from ATI ( http://support.amd.com/us/gpudownload/linux/legacy/Pages/radeon_linux.aspx?type=2.4.2&product=2.4.2.3.9&lang=us&rev=9.3&ostype=Linux%20x86 ) does not support the X.Org 7.5 of lucid, because support was dropped from ATI since X.Org 7.4.

--> so by now I simply installed karmic again, everything works fine there (with the normal radeon driver).

I am having the same exact issues. When playing enemy territory on 9.10, I got 70+ FPS using an X1400, now I'm lucky to get 15 FPS.

archlinux now has 2.6.34 (vanilla as usually I think) and the screen corruption looks a little different (flickering/scrolling instead of grey lines on black background) -> radeon.modeset=0 still needed

et/true combat: never installed it on ubuntu, but on archlinux and x1400 there is no problem with low FPS... maybe creating a xorg.conf with the exact same settings that karmic uses might help?

I think I found out in detail how to fix the slow FPS and the flickering.

sudo gedit /etc/default/grub

Edit this line to look exactly like this

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash radeon.modeset=1"

Save and close then run

sudo update-grub

Restart and pray.

Good luck

Bug confirmation:

I upgrade ti 10.04 on Notebook Toshiba Sattelite M100 (Ati X1400) with Dual Monitor Configuration.
After reboot image on external monitor has corruption (on notebook LCD all fine)

Set "nomodeset" in kernel line fixes bug.

PS Sorry for poor foto quality

still no luck with radeon.modeset=1 for me ):

neither with me, inspiron 6400

Could those of you able to test please confirm that this bug still exists with the -proposed kernel. Also could you test the latest Maverick kernel and see if that helps any. Maverick kernels can be found on the kernel version page at the URL below (search for maverick):

    https://edge.launchpad.net/ubuntu/+source/linux

please remember to revert the nomodeset changes before testing these.

Hi,

i use an asus Z53J laptop, with a ATI Mobility Radeon X1700. I installed recently ubuntu 10.04 and since the installation (and i mean even during the installation) i 've got this intermittent screen corruption (Dual screen with an external lcd flat screen helps since external LCD does not get the corruption.)
My kernel is 2.6.32-22-generic
I tried the nomodset change in grub : GRUB_CMDLINE_LINUX_DEFAULT="quiet splash radeon.modeset=1" with no success.

Attached a picture of what it is for me.

i would like to help with testing the new kernel but i'm not sure how to do this.

I still have the bug with the 2.6.32-24-generic kernel. Will try 2.6.35-14.19 and post results.

still no luck: 2.6.35-22-generic (ubuntu 10.10)
some X1400 in a Toshiba Satellite A100 that needs _toshiba_ drivers for XP (win7 has drivers included) catalyst did not support this X1400

-nomodeset works, but unity is broken
-kms produces a black screen with some horizontal gray lines after one or two minutes (or even >10 minutes sometimes)

how can I produce usefull data for a bug report?

might be workarounds for those still affected - and forget about nomodeset!:

-on fedora 14 use lxrandr to set a different resolution and then switch back to (eg 1400x800/Auto for me)... was stable for 2 hours...

then I tried..

-vanilla 2.6.37-rc2 on fedora 14. no problems with flickering or lines (never had pink world) for about 30min now... maybe this is already fixed.

second option might be interesting for ubuntu users as well.
I'll test this when I have time for it

2.6.37-rc3 (ubuntu 10.10 this time)

-download from kernel.org (, tar xjf etc.)
-make clean distclean mrproper
-make menuconfig (and just exit)
-make
-make modules_install
-make firmware_install
-make install
-update-initramfs -c -k 2.6.37-rc3
(-remove nomodeset)
-update-grub
-reboot

works ok for me.

unity still looks funny -> UNUSABLE (see attachment)

Lionel Dricot, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

Don't have the hardware anymore.

Lionel Dricot, this bug report is being closed due to your last comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/545096/comments/62 regarding you no longer have the hardware. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.