Bug 20348

Summary: Xorg hangs frequently under heavy 2d - ATI RS740 chipset
Product: xorg Reporter: David Rees <drees76>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: avillaci, disturbedsaint
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg.log with AccelMethod=EXA, DRI=on
none
xorg.conf with stable configuration, DRI=off. Options I've tried are commented out.
none
Output from lspci -vv none

Description David Rees 2009-02-27 01:00:12 UTC
Created attachment 23358 [details]
Xorg.log with AccelMethod=EXA, DRI=on

I experience frequent (multiple times a day) Xorg hangs (100% CPU) when doing things like quickly scrolling in Firefox, working in OpenOffice or dragging windows around.  This is on a Fedora 10 system and I the behavior has been the same with the last few available ati packages (6.9 and 6.10).

When hung, the mouse cursor is still responsive, but it moves very slowly/sluggishly and in a jerky motion.  It is not possible to kill Xorg.  Trying to reboot the system cleanly doesn't work - it gets stuck somewhere.  Alt-SysRq works for syncing/umounting the filesystems and rebooting.

I have also compiled my own 6.11 package with the same result.

The only configuration option which fixes the Xorg hangs is turning off DRI, but this is not an acceptable solution given how much performance suffers.

I have tried the following options both by themselves and in various combinations:

DynamicClocks on/off
AccellMethod XAA/EXA
RenderAccel on/off

Any suggestions on how to get some 2D acceleration back would be appreciated.  

Since it's fairly easy to duplicate let me know what I can do to collect information or backtraces if it would be helpful.

xorg.conf, xorg.log and lspci -vv output coming in attachments.
Comment 1 David Rees 2009-02-27 01:01:45 UTC
Created attachment 23359 [details]
xorg.conf with stable configuration, DRI=off.  Options I've tried are commented out.
Comment 2 David Rees 2009-02-27 01:02:30 UTC
Created attachment 23360 [details]
Output from lspci -vv
Comment 3 Alex Villacís Lasso 2009-02-27 09:14:44 UTC
>(II) RADEON(0): Max desktop size set to 2560x1600
>(II) RADEON(0): For a larger or smaller max desktop size, add a Virtual line to >your xorg.conf
>(II) RADEON(0): If you are having trouble with 3D, reduce the desktop size by adjusting the Virtual line to your xorg.conf

Is a (maximum) desktop size of 2560x1600 really required? Lately the xorg-x11-drv-ati module wants to allocate enough texture memory for the absolute largest desktop it could possibly support. Maybe if you added a Virtual directive your problems might be solved:

>(II) RADEON(0): Output DVI-0 using initial mode 1680x1050

Probably this is the maximum size you need. This solved some crashes for my case (RC410 with 64Mb VRAM).
Comment 4 David Rees 2009-02-27 11:50:56 UTC
(In reply to comment #3)
> Is a (maximum) desktop size of 2560x1600 really required? Lately the
> xorg-x11-drv-ati module wants to allocate enough texture memory for the
> absolute largest desktop it could possibly support. Maybe if you added a
> Virtual directive your problems might be solved:
> 
> >(II) RADEON(0): Output DVI-0 using initial mode 1680x1050
> 
> Probably this is the maximum size you need. This solved some crashes for my
> case (RC410 with 64Mb VRAM).

I'll give it a shot, but personally I'm not holding my breath.  I have no reason at all for using a larger Virtual screen and didn't realize that it could pose problems.
Comment 5 David Rees 2009-03-03 17:26:29 UTC
OK, it crashed twice today with "Virtual 1680 1050" in my Screen->Display section.

Anything else should I try?  Should I try to capture a stack trace under gdb?  I'm not sure if it will work since X still appears to be somewhat responsive as the mouse still moves (slowly and very jerky).
Comment 6 Alex Deucher 2009-03-04 01:19:46 UTC
Would it be possible to try the drm-next branch of Dave's drm-2.6 kernel tree?

http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=summary
Comment 7 David Rees 2009-03-04 16:04:30 UTC
Would one of the recent kernels from Fedora rawhide (to be Fedora 11) suffice?  That way I don't have to build my own kernel...

http://koji.fedoraproject.org/koji/packageinfo?packageID=8
Comment 8 Alex Deucher 2009-03-04 16:07:03 UTC
(In reply to comment #7)
> Would one of the recent kernels from Fedora rawhide (to be Fedora 11) suffice? 
> That way I don't have to build my own kernel...
> 
> http://koji.fedoraproject.org/koji/packageinfo?packageID=8
> 

Yes, I those should have the appropriates bits.
Comment 9 David Rees 2009-03-09 23:25:44 UTC
Well, nearly 5 days now on kernel-2.6.29-0.197.rc7.fc11.x86_64 and no X hangs yet, so it's looking pretty good.  It would typically hang within 2-3 days with previous kernels and often much sooner.
Comment 10 David Rees 2009-03-12 00:41:06 UTC
I upgraded to kernel-2.6.29-0.218.rc7.git2.fc11 tonight and very quickly it hung up while browsing in Firefox

For some reason, kernel-2.6.29-0.197.rc7.fc11 has been very stable.  I haven't been able to get that kernel to hang yet.  Not sure why.

I can only assume that it will only be a matter of time before this kernel locks up to.

So - what can I do to gather more information to try to isolate this bug?
Comment 11 David Rees 2009-06-12 00:16:38 UTC
Upgraded this machine to Fedora 11 which includes:

kernel-2.6.29.4-167.fc11.x86_64
xorg-x11-drv-ati-6.12.2-14.fc11.x86_64

Still able to reproduce the same hang with DRI on.

FWIW, I also had to upgrade with nomodeset passed to the kernel - otherwise it would just simply hang (though strangely, the mouse still moved but using the keyboard to reboot did not seem to do anything).
Comment 12 disturbedsaint 2009-06-13 08:40:34 UTC
It seems I am having the same issue as well.
Though for me it hangs within a couple of minutes (maximum 30) not days.

Started when using the r6xx_r7xx_branch on 2.6.29, just upgraded to full 2.6.30 kernel and still happens.

100% CPU, mouse cursor moves in jerky motion but is unresponsive to further input, as is the keyboard.

Doesnt matter if radeon or radeonhd is used (though when using radeonhd it seemed to take longer before it hung)
Comment 13 Alex Deucher 2009-06-13 08:56:21 UTC
Does xf86-video-ati git master or the 6.12-branch help?
Comment 14 disturbedsaint 2009-06-16 01:44:09 UTC
Just tried GIT and 6.12 and both still hang.
Comment 15 David Rees 2009-08-07 12:36:38 UTC
I think this may be a duplicate of the much older bug #13176 (or at least very similar)

I have been testing with XAA on and XaaNoSoidFillRect on for a couple days now and so far, no crashes.

It'll take another week or two of use to say so for sure, but at least those settings seem to be a decent workaround to enable acceleration without crashing.
Comment 16 David Rees 2009-09-16 23:36:26 UTC
(In reply to comment #15)
> I have been testing with XAA on and XaaNoSoidFillRect on for a couple days now
> and so far, no crashes.

Still working well.  Saw bug #21598 - is it possible that's related to this one?
Comment 17 David Rees 2009-09-16 23:59:11 UTC
OK, not quite the same.  Simply opening the test images from bug #21598 in Firefox does not trigger any hangs with EXA on.

But clicking on any of the tall images (16x8191, 16x8192, 16x893) when they're open in Firefox which shrinks them to fit on the window instead of a 1-1 ratio locks up the screen as described in my first post every time, so at least I've got an easy to reproduce test case now. :-)

What should I do next?
Comment 18 Michel Dänzer 2009-09-17 01:20:08 UTC
(In reply to comment #15)
> I think this may be a duplicate of the much older bug #13176 (or at least very
> similar)
> 
> I have been testing with XAA on and XaaNoSoidFillRect on for a couple days now
> and so far, no crashes.

Can you try the latest patch attached to bug 13176? Note that you'll have to modify it to be effective for your GPU.


(In reply to comment #16)
> (In reply to comment #15)
> > I have been testing with XAA on and XaaNoSoidFillRect on for a couple days now
> > and so far, no crashes.
> 
> Still working well.  Saw bug #21598 - is it possible that's related to this
> one?

No, that's not related to solid fills. BTW that one should be fixed in the 6.12.3 release.
Comment 19 David Rees 2009-09-17 14:00:51 UTC
(In reply to comment #18)
> Can you try the latest patch attached to bug 13176? Note that you'll have to
> modify it to be effective for your GPU.

Unfortunately, it's not clear to me how I should change the patch - there are multiple references to the R300 and CHIP_R420 chipset in there I wouldn't know if are correct or not.
Comment 20 Alex Deucher 2009-09-17 14:16:07 UTC
(In reply to comment #19)
> (In reply to comment #18)
> > Can you try the latest patch attached to bug 13176? Note that you'll have to
> > modify it to be effective for your GPU.
> 
> Unfortunately, it's not clear to me how I should change the patch - there are
> multiple references to the R300 and CHIP_R420 chipset in there I wouldn't know
> if are correct or not.
> 

if you chip is an RS740, in the patch change:
if ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_R420)
to
if ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RS740)
or if you are not sure, change it to this:
if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_R100)
which will apply it to all chips.
Comment 21 David Rees 2009-10-19 16:51:17 UTC
Unfortunately, I still haven't been able to test the patch.  I ran into some issues compiling things and haven't been able to debug further.

However, I did want to supply an update - I have had a couple X hangs the past week while using XAA and XaaNoSolidFillRect.  The most recent one was triggered by watching a move on YouTube and moving the Firefox window.

I logged in remotely and saw that X was stuck using 100% CPU.  I was able to reboot the machine from the shell.
Comment 22 David Rees 2011-01-20 15:44:55 UTC
I haven't run into this issue in quite a while now - it must have been resolved.

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.