Bug 44800

Created attachment 55598 [details]
Artefacts in text console

The artefacts seem to come during scrolling. If scrolling a lot, like in a long directory listing, they flash there and sometimes some of them stay on screen after it stops. They are horizontal lines, not blocks like in X.

Please attach your xorg log and dmesg output.

Created attachment 55599 [details]
A kernel panic

To test the card, I usually booted with "text" on kernel command line to prevent gdm from starting. This time I forgot that and gdm started. I switched to text console immediately and tried to continue in text mode, but got this panic while reading dmesg output.

Created attachment 55600 [details]
lspci -vvnn

Created attachment 55601 [details]
dmesg output to text console

Created attachment 55604 [details]
X server log, before panic if I remember right

The panic backtrace doesn't look obviously related to the radeon driver — all the symptoms sound like something might be scribbling more or less randomly over memory.

I wonder if the line

 mtrr: type mismatch for e0000000,10000000 old: write-back new: write-combining

in dmesg might be relevant. Can you try resolving that, e.g. using https://linuxindetails.wordpress.com/2010/06/27/mtrr-type-mismatch-for-e000000010000000-old-write-back-new-write-combining/ and see if that helps? Might be interesting seeing the contents of /proc/mtrr before and afterwards (if it changes).

Created attachment 55650 [details]
dmesg with enable_mtrr_cleanup

Attached the dmesg with The /proc/mtrr is 

reg00: base=0x000000000 (    0MB), size= 8192MB, count=1: write-back
reg01: base=0x200000000 ( 8192MB), size=  512MB, count=1: write-back
reg02: base=0x0e0000000 ( 3584MB), size=  512MB, count=1: uncachable
reg03: base=0x21f800000 ( 8696MB), size=    8MB, count=1: uncachable

and with enable_mtrr_cleanup mtrr_spare_reg_nr=1 options

reg00: base=0x000000000 (    0MB), size= 2048MB, count=1: write-back
reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
reg02: base=0x0c0000000 ( 3072MB), size=  512MB, count=1: write-back
reg03: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-back
reg04: base=0x200000000 ( 8192MB), size=  512MB, count=1: write-back
reg05: base=0x21f800000 ( 8696MB), size=    8MB, count=1: uncachable
reg06: base=0x0e0000000 ( 3584MB), size=  256MB, count=1: write-combining

It makes no difference.

I installed 32-bit debian 3.1.0 kernel and compiled fglrx for it and am now reporting this with it. It does not have the artefacts, but is not quite perfect either (gnome-shell 3.2.1 animations flicker like scaling of windows does not work as expected, but no artifacts, possibly of no interest to you).

Created attachment 55651 [details]
Artefacts in X, screencapture

This capture was with the enable_mtrr_cleanup mtrr_spare_reg_nr=1 to kernel. Here I started the X server from command line and only an xterm and a window manager. 

The artefacts appear to the window while I scroll the window pressing enter.

There was some constantly running horizontal artefacts, but they were flickering and got erased immediately thus leaving no mark. Seems like it could be ramdac reading bad for some scanlines, but more likely it goes on in the framebuffer. The blue part lower in the window could be one of those caught. I wonder if the squares in the xterm window are a result of that flickering, but due to scrolling it does not get erased.

The blue and green spots came one by one slowly while doing something else in the xterm. They stayed.

This happens only with this CAICOS card (I have an older radeon X300 that has no problems, as well as a nVidia card goes without these problems). So I'd expect whatever memory corruption there is, it is somehow in the CAICOS support in kernel.

May or may not be related, but I've seen similar corruption with CAYMAN related to bug 45018 from time to time. But about comment 3, I was tempted to point at bug 42373.

Marko, if you are willing to try patches proposed in both mentionned bugs to see if it helps in any way, that could be interesting.

@Marko Kohtala

Currently you are bootin in UEFI mode.
Can you boot in BIOS mode to test?

Your board is P8P67-M with BIOS 1701

Is your board "Rev B"?
Also check asus website, since a bios 3602 is there.

I have also tried booting in BIOS mode using Ubuntu 12.04 live USB. It does not help.

The board is "New P67 B3 Revision".

I have since upgraded to BIOS 3602. Same problem is still there.

I've followed kernels now to 3.5. I will try patches mentioned in comment 10 once I get the spare time to upgrade to 3.5.1.

Thank you for your comments.

I applied "drm/radeon: cleanup and fix crtc while programming mc" and "drm/radeon: fence virtual address and free it once idle [3.5] v2" on top of 3.5.2.

Did not change this. I saw the usual corruption in the fb console as well as in the xinit running only xterm.

This time I run 64-bit kernel under my 32-bit userspace. I had problems getting the 32-bit kernel to boot on my EFI.

At BIOS 3703, kernel 3.13.2 and Debian xorg-server 2:1.15.1-1, ati_drv.so and radeon_drv.so at module version 7.3.0. I reinstalled the HD 6450 CAICOS and it seems the problem no longer occurs.

I tried with Ubuntu 13.10 live, and the screen corruption appeared. So it was not a BIOS fix.