Bug 44141

Please attach (individually) the Xorg.0.log file and the output of dmesg and glxinfo.

Created attachment 54896 [details]
output of dmesg

Created attachment 54897 [details]
output of glxinfo

Created attachment 54898 [details]
Xorg.0.log

Do you need anything else or is there something so obvious in the attachments that I didn't saw?

Is this still an issue with r600g from mesa git master?  There have been a few original R600 fixes since this bug was filed.

Still an issue despite I upgrade to Fedora 16 (xorg-x11-drv-6.14.3-3.20111125git534fb6e41.fc16)
Unable to compile git source even with correct builddeps (error in r600_exa.c: In function 'R600SetAccelState':)

(In reply to comment #7)
> Unable to compile git source even with correct builddeps (error in r600_exa.c:
> In function 'R600SetAccelState':)

You need to build and run against libdrm 2.4.31 or from upstream Git.

Well, F16 still provide libdrm 2.4.30 so I won't try to compile.
By the way, still an issue with xorg-x11-drv-ati 6.14.3.4.

This problem is similar to what I'm experiencing that it could be the same.

I'm wondering where I can discover what libdrm is used?  I feel like this should be in the glxinfo output, but I can't find it.  Either way, I'm upgrading libdrm to 2.4.33+git20120403.43704256-0ubuntu0ricotz.

Then I'll test my apitrace.

I think it's a problem with Fedora, because all is right with Debian Squeeze and driver 6.13.1-2.

My issue may be resolved with:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=783e4da72aa203a645737dec81b001341951a942

You can check to see if your Debian drivers have this, however I don't think this is too likely.

(In reply to comment #12)
> My issue may be resolved with:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=783e4da72aa203a645737dec81b001341951a942

glxgears couldn't possibly be affected by the problem fixed by this.

I'm afraid you're focussing too much on the GPU lockup symptoms, which are similar between a huge number of different problems.

Yes,
  What's the determining factor in identifying symptoms that are likely to have a similar cause?

Is it one or more of these?:
GRBM_STATUS
GRBM_STATUS2
SRBM_STATUS
GRBM_SOFT_RESET

(In reply to comment #14)
> Yes,
>   What's the determining factor in identifying symptoms that are likely to have
> a similar cause?

You don't really know until you figure out what the problem is or narrow it down to a simple reproducible test case.

> 
> Is it one or more of these?:
> GRBM_STATUS
> GRBM_STATUS2
> SRBM_STATUS
> GRBM_SOFT_RESET

Those will tell you what part of the pipeline is locked up, but just because the a particular block is hung doesn't mean it's the same bug causing the hang.

This is interesting, if we can't just lump every GPU lockup into one bug.  Then are you prepared to manage individual bug(s) for each user?

There are several bugs that I found looking for this one that didn't receive a reply.

I believe given the circumstances one bug for all GPU lockup cases that match specifically(even when the specifics are vary general) with no distinguishing features can be tracked.  Once a bug has distinguishing features the "one size fits all" bug can be cloned and this can then split the affected users 3 ways...  Ppl having one bug or the other and ppl having both.

(In reply to comment #16)
> This is interesting, if we can't just lump every GPU lockup into one bug.  Then
> are you prepared to manage individual bug(s) for each user?
> 
> There are several bugs that I found looking for this one that didn't receive a
> reply.
> 
> I believe given the circumstances one bug for all GPU lockup cases that match
> specifically(even when the specifics are vary general) with no distinguishing
> features can be tracked.  Once a bug has distinguishing features the "one size
> fits all" bug can be cloned and this can then split the affected users 3
> ways...  Ppl having one bug or the other and ppl having both.

This isn't really the place to have this discussion.  If you want to discuss it further please inquire to the mailing list.  Generally unless your bug is an obvious duplicate (e.g., app X locks up on GPU Y), then file a new bug.  If it's determined to be a duplicate later, it can be marked as such.  Unfortunately, GPU lockups are hard to debug.

(In reply to comment #14)
>   What's the determining factor in identifying symptoms that are likely to have
> a similar cause?

Basically, if *anything* is different, it's better to assume different problems and keep separate reports. It's easy to combine reports that turn out to be duplicates, but mixing up different problems in a single report quickly turns it into an unmanageable mess.

Just as one obvious example in this case, the original report says: 'Every time I try tu use an OpenGL program my computer freeze.' Whereas your lockup only happens under very specific circumstances. That's a pretty big difference.

In fact, the problem still the same on Debian when I use firmware-linux-nonfree to have 3D acceleration with xserver-xorg-video-radeon 6.14.2.
Perhaps is it hardware related, because I tried Pardus and have softreset, Opensuze freeze and crash. So do you think I should close the bug?

(In reply to comment #19)
> In fact, the problem still the same on Debian when I use firmware-linux-nonfree
> to have 3D acceleration with xserver-xorg-video-radeon 6.14.2.
> Perhaps is it hardware related, because I tried Pardus and have softreset,
> Opensuze freeze and crash. So do you think I should close the bug?

Even if it is hardware related, we would want to track the bug and prevent the lockup on that hardware.

However unless you know what the problem is, there is no way of knowing if the bug you are talking about has anything to do with this bug or not.  I'd like to hear what Alex's plans are, as may bug reporters will post here with a wide range of issues.  Sorting them out into individual bugs seams to be impossible until after the bug has been solved.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/25.