Bug 38539 - AMD Radeon 6950 (Cayman): Short freezes with KDE
Summary: AMD Radeon 6950 (Cayman): Short freezes with KDE
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 7.6 (2010.12)
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-21 12:56 UTC by Nicos Gollan
Modified: 2011-10-28 00:09 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg output (65.66 KB, text/plain)
2011-06-21 12:56 UTC, Nicos Gollan
no flags Details
Xorg log (37.46 KB, text/plain)
2011-06-21 12:57 UTC, Nicos Gollan
no flags Details
strace of the X process (57.07 KB, text/plain)
2011-07-07 04:21 UTC, Nicos Gollan
no flags Details
Desktop with glitches under 3.0-rc6. The yellow/black areas are just anonymised areas. The glitches are e.g. visible in the KDE menu on the upper right. (309.30 KB, image/png)
2011-07-07 08:08 UTC, Nicos Gollan
no flags Details
dmesg output 3.0.0rc6, radeon.test=1 (105.87 KB, text/plain)
2011-07-07 23:32 UTC, Nicos Gollan
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nicos Gollan 2011-06-21 12:56:30 UTC
Created attachment 48252 [details]
dmesg output

Since I upgraded from a Radeon HD4870 to a 6950, I'm getting frequent short freezes of up to maybe 5-6 seconds when KDE draws (new? large?) surfaces, e.g. when a new application opens, or when switching desktops with effects enabled. I haven't encountered the freezes without acceleration yet.

What happens is that sometimes, the system seems to stop entirely, but it really seems to be limited to the X server. The image is frozen, the mouse pointer does not move, and the system does not react to e.g. the numlock key. Additionally, sometimes when it happens when clicking the mouse (e.g. when trying to get a partially covered window to the foreground) the system seems to miss the button-up event and handles mouse movements after recovery like dragging.

However, mplayer in the background continues playing without even a hitch.

There are no messages related to this in dmesg, syslog, Xorg.log, or .xsession-errors. I'm attaching dmesg and Xorg.0.log anyway.

xorg and the radeon driver are from Debian packages. Versions:
 * xserver-xorg: 1:7.6+7
 * xserver-xorg-video-radeon: 1:6.14.2-1
Comment 1 Nicos Gollan 2011-06-21 12:57:17 UTC
Created attachment 48253 [details]
Xorg log
Comment 2 Jure Repinc 2011-06-21 14:17:27 UTC
This doesn't appear to be a 6950 problem only. I experienced the same symptoms of freezing the graphics and X today on AMD Radeon HD 5750 (Juniper). When this happened I was browsing in fullscreen (resolution 1920×1200) Firefox 4 under KDE Plasma desktop 4.6.4 with KWin desktop effects enabled. I'm using Linux kernel 3.0-rc3, xorg-server 1.10.99.901, xf86-video-ati from trunk, mesa from trunk git-e251b39.
Comment 3 Nicos Gollan 2011-07-07 01:40:02 UTC
It would be nice to have any kind of feedback. Suggestions on how to diagnose what hangs, consoling words, anything. It's really annoying to the point of being unusable. Opening a new window freezes for several seconds, changing virtual desktops freezes for several seconds, loading websites that are more than text on white background freezes for several seconds multiple times (Firefox 5).

Basically doing anything other than staring at a static screen or using Konsole (changing tabs freezes by the way) causes it.

Disabling acceleration/desktop effects does _not_ help by the way.
Comment 4 Michel Dänzer 2011-07-07 03:15:04 UTC
(In reply to comment #3)
> Disabling acceleration/desktop effects does _not_ help by the way.

Weird that disabling acceleration doesn't help...

Maybe you can try logging in remotely via ssh and see if the X server or another process uses a lot of CPU during the freezes, and maybe attach gdb to the X server to see where it's at.

Also, maybe you can try a 3.0-rc kernel from experimental to see if that works any better.
Comment 5 Nicos Gollan 2011-07-07 04:21:09 UTC
Created attachment 48848 [details]
strace of the X process

I attached strace to the X process. When I managed to provoke the freeze by switching desktops randomly, the entire SSH session of the strace froze along with the X display. SSHing in and killing (needed SIGKILL) strace unfroze the X session again.

As much of the strace output as fit in the console buffer is attached. FD 9 which is mentioned as the target of the last shown ioctl is /dev/dri/card0
Comment 6 Nicos Gollan 2011-07-07 05:07:18 UTC
Trying it again, the complete freeze doesn't seem to happen, but I can observe ioctl 0xc020645d on FD 9 taking a long time when the freezes occur.
Comment 7 Nicos Gollan 2011-07-07 06:29:57 UTC
That ioctl appears to be radeon_gem_create if I decoded the number right.
Comment 8 Alex Deucher 2011-07-07 06:40:50 UTC
Does it work better with a 3.0 kernel?  If your system uses a lot of graphics memory, you may end up running low and the memory manager has to swap a lot of stuff around.  Kernel 2.6.39 did not have support for vram beyond the PCI BAR (generally 256 MB) on cayman cards.  Support for using the full amount of VRAM was added in 3.0.
Comment 9 Nicos Gollan 2011-07-07 08:01:53 UTC
It feels faster with 3.0-rc6, but it's producing a lot of drawing errors. Looks like it's randomly corrupting surfaces.
Comment 10 Alex Deucher 2011-07-07 08:06:57 UTC
(In reply to comment #9)
> It feels faster with 3.0-rc6, but it's producing a lot of drawing errors. Looks
> like it's randomly corrupting surfaces.

Can you bisect the kernel?  Does disabling tiling help?
Option "ColorTiling" "False"
in the device section of your xorg.conf
Comment 11 Nicos Gollan 2011-07-07 08:08:08 UTC
Created attachment 48854 [details]
Desktop with glitches under 3.0-rc6. The yellow/black areas are just anonymised areas. The glitches are e.g. visible in the KDE menu on the upper right.

Might as well attach a screenshot
Comment 12 Nicos Gollan 2011-07-07 08:35:31 UTC
(In reply to comment #10)
> Can you bisect the kernel?

I'd really prefer not to do that :-/ If you have a manageable number of commits I should test (say 3 or 4) which won't eat my system, I'd be willing to try. But I won't randomly hop around the kernel tree.

> Does disabling tiling help?
> Option "ColorTiling" "False"
> in the device section of your xorg.conf

No, doesn't help. Same effect with and without after a few minutes of starting applications and switching desktops.
Comment 13 Alex Deucher 2011-07-07 08:40:08 UTC
(In reply to comment #12)
> I'd really prefer not to do that :-/ If you have a manageable number of commits
> I should test (say 3 or 4) which won't eat my system, I'd be willing to try.
> But I won't randomly hop around the kernel tree.

You can try reverting the commit that enables the use of the full amount of vram:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cb92d452ba665205ad6bfb424c0ef009cf26587d
Comment 14 Nicos Gollan 2011-07-07 09:58:09 UTC
Reverting that single commit fixes the glitches and brings back the freezes.
Comment 15 Alex Deucher 2011-07-07 10:19:26 UTC
Can you boot the 3.0 kernel without anything reverted and load radeon with test=1 and post the dmesg output?  Add radeon.test=1 to the kernel command line in grub or manually load radeon with test=1 on the command line.
Comment 16 Nicos Gollan 2011-07-07 23:32:59 UTC
Created attachment 48880 [details]
dmesg output 3.0.0rc6, radeon.test=1

Here we go
Comment 17 Alex Deucher 2011-07-08 08:04:58 UTC
(In reply to comment #16)
> Created an attachment (id=48880) [details]
> dmesg output 3.0.0rc6, radeon.test=1

The tests completed successfully, so the blitter seems to be working fine.
Comment 18 Nicos Gollan 2011-07-08 11:33:59 UTC
(In reply to comment #17)
> The tests completed successfully, so the blitter seems to be working fine.

The question then is, what fails?

I'm fairly confident that the hardware is fine, considering that the card runs the 2D UI and 3D games on Windows 7 for hours without any obvious corruption.

The glitches also don't appear immediately, but need some time under load to develop. It might be a result of the use patterns of X or KDE. So far, text rendering in Firefox or Qt applications doesn't seem to be affected, just UI "chrome" (buttons, menu bar backgrounds, icons,...) and other graphical elements (background images in FF, but only very rarely).

The card is a 2GB model (1GB seems to be normal), could that have something to do with the glitches? I tried setting the vramlimit parameter of the radeon module, but it doesn't seem to have any effect.
Comment 19 Nicos Gollan 2011-07-26 03:17:04 UTC
This is still an issue with the final 3.0 kernel (not surprising when looking at the changelog).

So right now, I have the choice of running a 2.6.39 kernel or creating a hacked-up kernel without the blitting "fix" that freezes every time an application wants to draw something new, or watching my desktop deteriorate over time until it's just a messed-up jumble.
Comment 20 Nicos Gollan 2011-10-28 00:09:58 UTC
This was really "fixed" with 3.0, and the card works with the patch from bug #40221


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.