Bug 13176

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.