Clicking in and out of input boxes in Firefox seems to force this. I have tried everything up until the latest GIT 10th November 2007. Others seem to have similar problems without resolution.
Created attachment 12439 [details] Xorg.0.log Xorg.0.log after its hard-locked
Created attachment 12440 [details] Xorg.conf /etc/X11/xorg.conf
Created attachment 12441 [details] Output of "lspci"
Created attachment 12442 [details] Output of "lspci-n"
Created attachment 12443 [details] Output of "lspci-v"
Created attachment 12444 [details] Output of "lspci-vn"
Can you try turning off the dri, not forcing the agp mode and turning off colortiling and see what combinations help?
Turning off dri everything is 100% stable. Turning on/off colortiling makes no difference Not forcing agp mode means that it *detects* my AGP mode automatically. I've tried various combinations of the above. I can now force a hard-lock consistently by click on an input box and drag off it with nothing selected.
I can duplicate this behavior with my ATI Radeon Mobility 9100 IGP.
Does updating your drm to the version in git help? Do you still get the lockups with exa? how about if you disable renderaccel?
I still get lockups with RenderAccel set to false. I tried EXA but it ended up breaking a number of other things in both compiz/emerald and fluxbox so I had some trouble getting firefox up. That said, when I did, I was unable to reproduce the crash. It should also be noted that the crashes with firefox only occur when using compiz/emerald, but will still occur under fluxbox for certain opengl screensavers.
(In reply to comment #10) > Does updating your drm to the version in git help? Do you still get the > lockups with exa? how about if you disable renderaccel? > I still get lockups with when I replace xaa with exa. I have disabled RenderAccel and experience exactly the same problem. The latest version of DRM even though it is reported as working, although doesn't seem to be accelerated, and crashed 3D programs...still has exactly the same problem.
(In reply to comment #11) > I tried EXA but it ended up breaking a number of other things in both > compiz/emerald and fluxbox so I had some trouble getting firefox up. That said, > when I did, I was unable to reproduce the crash. As this is not true for Robert, your problems are probably different. Robert, does it still happen with Option "XaaNoSolidFillRect"? If yes, can you try other similar options documented in the xorg.conf manpage? Always verify in the log file after the line (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) that each option actually has an effect.
> Robert, does it still happen with Option "XaaNoSolidFillRect"? If yes, can you > try other similar options documented in the xorg.conf manpage? Always verify in > the log file after the line > > (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) > > that each option actually has an effect. > I can't seem to force it to hard lock with Option "XaaNoSolidFillRect" fred@localhost ~ $ cat /var/log/Xorg.0.log | grep rectangles 8x8 mono pattern filled rectangles fred@localhost ~ $ cat /var/log/Xorg.0.log.old | grep rectangles Solid filled rectangles 8x8 mono pattern filled rectangles
*** Bug 17278 has been marked as a duplicate of this bug. ***
duplicate bug confirmed. (II) RADEON(0): XAA Render acceleration unsupported on Radeon 9500/9700 and newer. Please use EXA instead. (**) RADEON(0): Option "XaaNoSolidFillRect" "true" (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) thx, but suggest You do not remove the above warning, cause it is a hint for quick+easy workaround on hanging systems, even if gnome terminal scrolling with EXA is stuttering and slow, smooth with XAA. I switched back to XAA now. y tom
Does booting with radeon.no_wb=1 (or setting the radeon kernel module parameter no_wb to 1 by whatever means you prefer) work around the problem? Verify with dmesg|grep writeback that writeback is really disabled.
Created attachment 28598 [details] [review] workaround possible CP hang on r420 Does this patch against the drm help? We may need to apply the workaround on CP reset as well.
*** Bug 23793 has been marked as a duplicate of this bug. ***
(In reply to comment #18) > Created an attachment (id=28598) [details] > workaround possible CP hang on r420 > > Does this patch against the drm help? We may need to apply the workaround on > CP reset as well. > Applying the patch made OpenOffice work for me (it hung the entire X server before)- I still have problems with some 3D games in wine, though. Dunno if it's wine's fault or X's.
is this still an issue with KMS?
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.
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.