Created attachment 117421 [details]
dmesg

Note: I did a couple of DRI_PRIME test, so some of the dmesg, if from the other etsts.

Can you install the debugging symbols and get a proper backtrace with gdb?

http://www.x.org/wiki/Development/Documentation/ServerDebugging/

Created attachment 117422 [details]
gdb

Created attachment 117423 [details]
GDB with 7.5.0.r88.g5510cd6-1 debug symbols.

FWIW I have an r600+si dual-radeon system that until recently has been trucking along like a champ (after I fix the output name duplication bug which I have filed a bug for here and a patch).  Lately I get these lockups all the damn time.  I see stack traces somewhat like yours, OP.

Best way I have to trigger them, although they are infuriatingly intermittent and unpredictable, is to play wine video games -- I didn't realize the fullscreen component but I usually have something fullscreen on one screen or another so that may be the same here.  FWIW I run the bleeding-edge KF5 compositor.

I am reluctant to leave my system in the state these lockups leave me and debug them because I'm scared about shit burning up on me (although sometimes it happens when I'm not around and sits there for hours in this state I admit).
 
I haven't entirely ruled out bad hardware on either side of the PCIe bus, but I have more-or-less ruled out thermal crisis as the root cause.

Looks like it might be memory corruption. Can one of you try running Xorg in valgrind and see if that gives more clues?

I have switched to DRI3 where the bug is gone. If Greg Turner can't test with valgrind, maybe I can find time for it.

After rebuilding lots of stuff I haven't seen these crashes for a conspicuous period of time.  Could have just gotten lucky so far, but I'm beginning to wonder if this is a subtle reverse build-time dependency or something like that.

Next time it happens to me, if ever, I'll immediately cook up some backtraces and try the valgrind thing.

I like the memory corruption hypothesis, that's consistent with the sort of intermittent and seemingly inexplicable behavior I was having.

Ugh, well behavior keeps changing on me.

Lately I get DOS'ed on all interfaces most of the time which isn't helpful.

Time I looked up how to access the simulated scroll-lock on my fancy-pants tiny keyboard -- or better yet printed it out and taped it to my wall :)

Currently trying not to crash as I'm rebuilding Everything (capital e!) just to rule out any subtle toolchain abi shenanigans, as I did recently upgrade gcc (51->53)

Unfortunately, I tried DRI3 and it was way, way worse, suggesting Kristian and I don't have the same problem (except maybe "memory corruption").

Also, looked into Valgrind.  It's going to be an uphill battle without changing the cflags I used here (march=bdver2).  I didn't adjust it for fear of heisen-fixing the problem, I'll built it one more time if need be -- takes a couple days, but for me it'd be well worth it if it leads to bugsquishification.

(In reply to Greg Turner from comment #10)
> Unfortunately, I tried DRI3 and it was way, way worse, suggesting Kristian
> and I don't have the same problem (except maybe "memory corruption").

Scratch that.

Just found that backporting (maybe that's not technically the right word -- I simply applied the patch without incident) commit 25eca802656 from xorg-server to 1.18.0 fixes the DRI3-mode trouble I was formerly able to repeatably cause by moving gl windows around between crtc's.

That makes it much more plausible OP and I suffer from the same bug since, but for this known and already-fixed-upstream problem, my issue also seems to be fixed by moving to DRI3.

Also, after my huge full-system rebuild I see much better behavior overall on this box.  So, as I kind of suspected, some kind of toolchain or reverse-dependency issue remains a plausible cause of my non-repeatable lockups under DRI2.

I'll move back to DRI2 now*, stress the hell out of this machine (I do so naturally in the course of my day-to-day activities) and if everything works we can infer my issue was caused by something other than a bug in xorg.

--

* For a while, at least.  DRI3 is /so/ much less janky here than DRI2 was, I'm fairly eager to migrate for good.

Just an update.  Unfortunately with kernel 4.4.1 and xorg 1.18.1 I can't keep the server running long enough to reach this bug.  Instead, within minutes the primary display begins having what appears to be some sort of memory geometry crisis.  Content from the framebuffer starts bleeding all over the place, and quickly it resolves to a state where the affected output is frozen or reduced to rendering some kind of non-3-dimensional hyper-shape that barely intersects the plane of the screen.

Maybe I simply have a hardware problem on top of the original bug.  FWIW since I upgraded I've had uncharacteristically long stable runs without hitting the old lockup -- it could very well have been fixed by my kernel/xorg update.  Indeed at one point I almost came on here and posted the bug was fixed (simply never got around to it and then observed the new crash which gave me pause).

I'm going to pull the card and play some musical hardware.  Even if it's software-related the new behavior seems orthogonal to the old and prevents me from testing further.  I'm comfortable closing this bug on the basis that it's not reproducible for anybody ATM.

-- 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/136.