KDE4 display corruption on radeon - 10 day cycle of doom

radio_flyer

Well, this has been going on for over 6 months now, and I still haven't figured it out. So, I'm curious to know if any one else has encountered something like it.

Stable amd64 system, KDE4 desktop (4.14.3:4), xf86-video-ati7.5.0. Graphics card is an HD6450, running three Dell 1920x1200 monitors via Eyefinity.

The output of 'dmesg | grep -e drm -e radeon

radio_flyer · Posted: Sat Jan 02, 2016 4:42 am Post subject:

Argh. I apparently screwed up the Xorg.0.log post. Here's the rest of Xorg.0.log:

kernelOfTruth · Posted: Mon Jan 04, 2016 5:19 pm Post subject:

So it only happens with KDE ?

is compositing for kwin enabled ?

(-> hinting at opengl issue)

The corruption also happens when you, e.g. run glxgears,

I assume the pixellation applies to the whole monitor all the time like indicated in your screenshot ?

FYI: https://wiki.gentoo.org/wiki/Radeon it's a NI (northern islands) chipset

Can you file a bug at https://bugs.freedesktop.org/ ?

Make sure to update mesa, libdrm, xf86-video-ati (7.6.1), pixman and the xorg-server libraries including xorg-server

Is there the possibility for you to run it for some time with the fglrx proprietary drivers ? (could e.g. also be via Sabayon liveDVD)

to mostly rule out that it's an hardware issue and more related to the opensource drivers

Are you running anything "special" or is it mostly coding, web-browsing, multimedia (video ?), audio, etc. [assumption] with those 3 monitors
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004

radio_flyer · Posted: Mon Jan 04, 2016 7:03 pm Post subject:

Aquous · l33t Joined: 08 Jan 2011 Posts: 700

Dumb suggestion, but have you tried disabling ksplash? Given that you're saying the problem is right after you log in from kdm. I don't really see how ksplash could be causing... well, this

and also how it would keep doing so well after login, but since the issue is already really strange...

I would recommend trying a different display manager and/or desktop environment to start ruling things out.

radio_flyer · Posted: Sun Jan 10, 2016 5:26 pm Post subject:

Well, I made it six days this time. Logged in to KDE, and the screens filled with 1 cm blocks of random patterns--some from the background, some just solid color.

Like Aquous mentioned, I had gone ahead and set up XFCE as a second window manager so I could determine whether it was KDE or not. Ctrl-Alt-Backspace out of KDE got me back to KDM, but that screen was now as pixellated as the desktop. Ctrl-Alt-F1 to a VT and browsing the logs showed no errors in either dmesg, /var/log/messages or Xorg.0.log. I tried restarting xdm, but no change. So I stopped xdm, switched to a different VT, and ran startxfce4. I could see XFCE start up and run by watching the changing patterns of the blocks, but it was just as pixellated as KDE was. I browsed the logs again, and still nothing. Ctrl-C'd XFCE, ran it again, same issue, same lack of warnings in the logs. Finally rebooted, and everything returned to normal.

So at this point it's really looking like a driver issue. Time to head off to freedesktop.org and see what I can do to start troubleshooting in that department.

chithanh · Posted: Sun Jan 10, 2016 6:37 pm Post subject:

It could be that some video memory on your card is going bad. Try limiting what the card uses with the radeon.vramlimit=... kernel parameter (in MiB; 256 should be enough to run KDE)

Other than that, you can also check whether this problem disappears after a suspend-to-disk cycle.

radio_flyer · Posted: Sun Jan 10, 2016 8:17 pm Post subject:

I may try some of that during debugging, but I doubt it's a hardware fault (although after 30 years of engineering design, I've seen enough to never say never...) I have three identical cards in my possession, running in two systems. One is on a backup system driving a single monitor and never exhibits this issue. The two systems are nearly identical except for the number of monitors. The other two I cycle through my main workstation with three monitors, and both display the exact same symptoms on that system. I doubt it's heat or stress related, because my temperature monitor shows no issues, and a simple reboot will clear the problem up, typically for a week. These two systems rarely get turned off--they stay up 24/7/365 unless I have to work on them. I would expect a hardware problem like overstress or failing memory to still exhibit symptoms after a short non-power-cycled reboot, but in this case when I reboot the displays resume proper operation and stay that way for days.

To my eyes, this looks more like a bug in the driver that slowly but surely corrupts registers on the card or leaks video/texture memory until the card ceases to function. The lack of errors in the logs is probably indicative of something happening to the video card itself that is not being reported back to the driver and/or other apps higher in the API stack. There's also the slim chance it could be a genetic bug in the video card hardware design itself, but as I noted in my earlier posts this same setup ran fine with three monitors for over a year before this issue started manifesting itself about 6 months ago. It doesn't help that this problem has a week-long cycle time--that slows debugging quite a bit, although it does allow me to get real work done in the interim :-)

What I'm trying to figure out now is how to turn on debugging in the kernel/xopen driver stack, and how to check things like memory utilization, etc. on a video card. Anyone know of a 'vtop' :-)

chithanh · Posted: Sun Jan 10, 2016 10:08 pm Post subject:

There are some cards like the Radeon 4870 X2 which had a design defect, which lead to improper cooling of the memory chips on the back side of the PCB. For the 6450 this is less likely, I agree.

Something else you can try is "vbetool post" which will re-run the initialization code of your card's video BIOS. This however can confuse the drm, so you may need to disconnect the radeon kernel module from the framebuffer console and then unload the module first.

You can turn on debugging on the kernel side with the drm.debug=... parameter (it is a bitfield, a value 15 will turn on everything).
VRAM usage and other kinds of GPU utilization can be monitored with the radeontop utitily.

radio_flyer · Posted: Mon Jan 11, 2016 3:37 am Post subject:

Thanks for the pointers chithanh. I just emerged the radeontop tool and took a screenshot. I'll take another in a week or so when the problem re-occurs to see if memory is leaking. I'll also start working on enabling the debug stuff so I can (hopefully) get more data when it happens again.

radio_flyer · Posted: Thu Jan 21, 2016 5:10 am Post subject:

Happened again today, exactly 10 days since the last 'episode'.

10 days ago, radeontop reported 'Graphics pipe' at 0.83% usage, and VRAM at 207M / 1024M, or 20.20%. This while logged in to KDE running in a Konsole window just after a reboot.

Today, could not run Konsole as the desktop was unusable (until after reboot). However, running radeontop from a VT reported everything as 0.00% except for VRAM, which was reported as 13.85%. CTRL-ALT-BACKSPACE back to the kdm login screen (also corrupted) dropped VRAM down to 3.03%, with everything else still at 0.00%.

So, it does not appear to be a memory leak on the video card.

Time to turn on the debug stuff and wait some more...

radio_flyer · Posted: Mon Feb 15, 2016 4:51 am Post subject:

Consistently 10 days. Still. This time when X pixellated when logging in I went to a VT and did 'echo 0x3f > /sys/module/drm/parameters/debug'. That generated reams of debugging output from dmesg when I switched back to X and moved the mouse around. A sample is below. Curiously, though, none of it seems to be all that unusual.

chithanh · Posted: Mon Feb 15, 2016 3:32 pm Post subject:

You can increase the dmesg buffer size with the log_buf_len=... kernel parameter, see /usr/src/linux/Documentation/kernel-parameters.txt for details. Or instruct your system logger to log kernel messages.

Before you run vbetool post, it is probably a good idea to unload the radeon kernel module. To do that, you have to detach it from the framebuffer console first:

radio_flyer · Posted: Mon Feb 15, 2016 4:32 pm Post subject:

Thanks chithanh! I'll give it a try in about 9 days