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.
Created attachment 23359 [details] xorg.conf with stable configuration, DRI=off. Options I've tried are commented out.
Created attachment 23360 [details] Output from lspci -vv
>(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).
(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.
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).
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
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
(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.
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.
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?
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).
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)
Does xf86-video-ati git master or the 6.12-branch help?
Just tried GIT and 6.12 and both still hang.
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.
(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?
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?
(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.
(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.
(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.
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.
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.