Bug 16198

Created attachment 16870 [details]
Xorg.0.log

reassigning to Driver/Radeon for now (it seems there's no r500 component for mesa yet)

I suppose it's technically r300, since that driver supports r3xx-r5xx.

I experienced lock ups on compiz. (actually almost immediately) In contrast to the bug report: All other stuff worked ((opengl video playing with xine seemed to cause also lockups, but I haven't it enough tested to report a clear bug ).

I've updated the drm modules tonight. I would say it is possibly solved (no lockup so far). 

Running the following: 
Mesa             git-commit      f688827ebdc7fa8ef1160086565f9e109768a250
DRM              git-commit      ba7263b8c2f8c14c647da725ecbc73fcd456d63c
xf86-video-ati:  git-commit      6e4e6d2a8f29f92efc219dca24ea31d1f37d5a0f
X-server:        fedora-9        X.Org X Server 1.4.99.901 (1.5.0 RC 1)

I had experienced hard-lockups as well; no entry into the system. 

After updating to these builds a few days ago I haven't had a problem. 

(In reply to comment #5)
> 
> After updating to these builds a few days ago I haven't had a problem. 
> 

I keep getting the lock-up, randomly.
For example yesterday I didn't get any freeze, after almost 1 day uptime.
Today I got it after 3 hours, without any particular activity... bah..

Still happening randomly, even after this commit:
http://cgit.freedesktop.org/mesa/drm/commit/?id=1aafbb83d97ccc78b78d5cbd311f1239a3dad11e

I can confirm random lockups too. I have an Intel Centrino Duo (x86_64) running Gentoo Linux x86_64 (arch=amd64) and kernel 2.6.26-gentoo-r1. My video card is ATI Radeon Mobility X1400 (RV515). As far as I remember I got lockups mostly while compiling but not necessarily while both cores were 100%. Only one core busy is enough.

My last freeze has just occurred today. I was running two KVM virtual machines, one of them was busy compiling. Hence one physical core was 100% the other was almost idle. The system froze as soon as I started Apache2 on my laptop. I was using xf86-video-ati as the system froze. Now I've switched to radeonhd.

Don't know if if matters but while the system was frozen I could still see my WiFi LED blinking. Maybe I could have spared my hard drive from a wild power down using Alt+SysReq,B. Let's see.

Hope this helps.

Maybe the bug I'm encountering at the moment is the same.

MY freezes only occur if I use EXA as the AccelMethod. What happens if you try using AccelMethod "XAA"? For me this works.
I would like to use EXA instead - but have the random freezes there...

I'm still experiencing hard lockups, mostly while compiling.
I use EXA, XAA is not an option for me.

Afaik, Jerome Glisse is aware of this problem (and has been for months) but unfortunately it seems it's not an easy fix :(

I'm currently using:
xorg-server 1.5.99.902
mesa git
drm git
xf86-video-ati git

Wow, the same hard lockup just happened to my brother on a totally different setup.

ubuntu Jaunty 9.04 32 bits:

01:05.0 VGA compatible controller: ATI Technologies Inc RS690 [Radeon X1200 Series]
xorg-server 1.6.0
mesa 7.3+git20090207+mesa-7-4-branch.7e8f2c56-0ubuntu0tormod
drm 7.3+git20090207+mesa-7-4-branch.7e8f2c56-0ubuntu0tormod
radeonHD 1.2.4+git20090302.9c8ab2df-0ubuntu0tormod


This has been happening pretty much since R500 3d support was merged, back in May.

Someone should really look into this, as it seems pretty major to me.

Are you running compiz or any other 3D apps?

It happens both with desktop effects enabled or without.

On my pc (Core2Duo x86_64), it tends to happen more often while the system is under heavy load (for example compiling).
On my brother's pc, it happens more often while he's watching a video.

I remember some months ago it happened quite more frequently on my system, so things have surely improved, but still...

Anyway, if you ask Glisse he will surely know about this.

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

I've also pulled some of the fixes into the r6xx-r7xx-support branch in the fdo drm tree.  So you could try that if it's easier.
http://cgit.freedesktop.org/mesa/drm/?h=r6xx-r7xx-support

this may be a dup of bugs 20348, 18097.

Alex, can you tell me how to switch from master to the other git branches?

And about the other bugs: I guess the cause could be the same, but the result is totally different. I'm getting a *hard lockup*: no pinging, no SysReq Key works...
I wish it was just a crash or Xorg hanging :)

(In reply to comment #15)
> Alex, can you tell me how to switch from master to the other git branches?

git checkout -b <local_branch_name> origin/<remote_branch_name>
e.g.,
git checkout -b r6xx-r7xx-support origin/r6xx-r7xx-support

(In reply to comment #14)
> I've also pulled some of the fixes into the r6xx-r7xx-support branch in the fdo
> drm tree.  So you could try that if it's easier.
> http://cgit.freedesktop.org/mesa/drm/?h=r6xx-r7xx-support
> 
> 

I've tried this branch but the lockup still happens. It might be less frequent, but definitely still there.

Created attachment 24459 [details] [review]
possible fix

Does this patch (against xf86-video-ati git master) help?

(In reply to comment #18)
> Created an attachment (id=24459) [details]
> possible fix
> 
> Does this patch (against xf86-video-ati git master) help?
> 

Nope, I just got the usual hard lockup while compiling and your patch was applied to git master :(

I'm running Jaunty on a compaq 6820s. Lspci reports:

01:00.0 VGA compatible controller: ATI Technologies Inc RV516 [Mobility Radeon X1350]

When running Google Earth (or turning desktop effects on), the system would reliably crash after a minute or so. After installing kernel 2.6.29 I had no more crashes.

Maybe this helps...

Created attachment 25262 [details] [review]
possible fix

Does this patch (against xf86-video-ati git master) help?

Just got the lockup while doing my weekly kde-svn recompile with the patch applied to git master :(

Alex, pardon my ignorance but in the past, I was always told by glisse that this lockup was caused/related to 3d/drm and in fact it happens with radeonHD too.
How can patches to xf86-video-ati solve this?
And thanks for trying to fix this, as it's very very frustrating.

(In reply to comment #22)
> Alex, pardon my ignorance but in the past, I was always told by glisse that
> this lockup was caused/related to 3d/drm and in fact it happens with radeonHD
> too.
> How can patches to xf86-video-ati solve this?

It's hard to say what causes the lock up.  I could be a bad command stream from mesa or the ddx or some bad interaction between the two.

Created attachment 25392 [details] [review]
use 1/12 subpixel mode in the ddx

Does this patch help?  Perhaps the lockups are related to switching the subpixel mode.

I saw soft lockups (one core hanging at 100% sys load) with the radeonhd driver (not the radeon one - mmh). X was able to recover by switching to text console and back, but soon after, softlock occured again.
So I ported the patch from comment #24 to radeonhd (as much as I could). The soft lockup went away.
Only thing which is still there is some 
(WW) RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY!
messages, but no noticable hanging. 
Will also post this to the radeonhd list. Alex: please check if it is also applicable.

(In reply to comment #24)
> Created an attachment (id=25392) [details]
> use 1/12 subpixel mode in the ddx
> 
> Does this patch help?  Perhaps the lockups are related to switching the
> subpixel mode.
> 

I haven't had a lockup in these past 2 weeks, but I'd like to test a couple more weeks before closing this.. Just to be sure :)
Thanks a lot Alex!!

Meh, I just got the lockup during my usual kde-svn recompile :(

Another hard lockup while I was browsing with Firefox: I was just moving the mouse around :(

Mass version move, cvs -> git

Closing due to lack of feedback. Please reopen if this continues to occur with KMS enabled. If this only happens against radeonhd, then refile with them, please.

~ C.