| Summary: | AMD Radeon 6950 (Cayman): Short freezes with KDE | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Nicos Gollan <gtdev> |
| Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> |
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | CC: | jlp.bugs |
| Version: | 7.6 (2010.12) | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | |||
Created attachment 48253 [details]
Xorg log
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. 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. (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. 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
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. That ioctl appears to be radeon_gem_create if I decoded the number right. 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. It feels faster with 3.0-rc6, but it's producing a lot of drawing errors. Looks like it's randomly corrupting surfaces. (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 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
(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. (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 Reverting that single commit fixes the glitches and brings back the freezes. 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. Created attachment 48880 [details]
dmesg output 3.0.0rc6, radeon.test=1
Here we go
(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. (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. 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. 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.
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