https://bugs.freedesktop.org/show_bug.cgi?id=80419
GitLab Migration User changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #160 from Michel Dänzer ---
To clarify comment 155: If the problem happens with commit 52098fada7e, please
bisect between 6dc96de30329 and that. Otherwise, please bisect between
52098fada7e and the current commit you were testing.
--
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #159 from Michel Dänzer ---
Andrew, see comments 154 & 155.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #158 from andrew.m.mcma...@gmail.com ---
Hold on a minute!
I've just applied that patch to the latest mesa - now correct me if I'm wrong -
but the source already has that change applied:
https://gitlab.freedesktop.org/mesa/mesa/blob/ma
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #157 from andrew.m.mcma...@gmail.com ---
So I've had a go at compiling mesa with the fix applied.
I'll list what I've done here to be absolutely clear.
Cloned a new copy of mesa
> git clone https://gitlab.freedesktop.org/mesa/mesa.git
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #156 from andrew.m.mcma...@gmail.com ---
Picked up XCOM Complete for ~£3 @ Voidu.
I've played it before of course but thought I'd try out Feral's Linux version
rather than playing the Windows-only GOG release through WINE.
Debian Unst
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #155 from Michel Dänzer ---
Does the problem occur with Mesa built from
https://cgit.freedesktop.org/mesa/mesa/commit/?id=52098fada7e ?
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=80419
Kamil Páral changed:
What|Removed |Added
Version|10.1|18.2
--
You are receiving this mail becau
https://bugs.freedesktop.org/show_bug.cgi?id=80419
Kamil Páral changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #153 from hede ---
Why is this fix in older versions (like mesa 13.0) but not newer ones? Mesa
18.2.2 on Ubuntu 18.10 (cosmic) still needs manually patching. And upstream
version 19 still excludes this fix.
btw: I can confirm this b
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #152 from Timothy Arceri ---
*** Bug 88925 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing li
https://bugs.freedesktop.org/show_bug.cgi?id=80419
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #150 from ArneJ ---
I also suffered a lot from this issue on my R9 270X.
I was never able to go past the first tutorial mission because my PC hung
during that mission.
Now I tried it again with mesa 13.0.3 and I was finally able to f
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #149 from Daniel Exner ---
(In reply to Daniel Exner from comment #148)
> Will try to crash it again tomorrow, but looks promising.
Played about 3h straight today. More than the whole past year!
Guess this can finaly be closed.
Mar
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #148 from Daniel Exner ---
(In reply to Marek Olšák from comment #147)
> Possible fix:
> https://cgit.freedesktop.org/mesa/mesa/commit/
> ?id=6dc96de303290e8d1fc294da478c4f370be98dea
I wonder how _that_ could have not been found ea
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #147 from Marek Olšák ---
Possible fix:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=6dc96de303290e8d1fc294da478c4f370be98dea
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #146 from Daniel Exner ---
(In reply to Marek Olšák from comment #142)
[..]
> In my case, this is the data I've been able to obtain:
> - Reproduced on everything I was testing on: Hawaii (radeon), Tonga,
> Polaris11 (amdgpu)
Out of
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #145 from pandiculationfinch at gmail.com ---
disabling radeon.dpm I was stable for 70minutes with netflix and stellaris
running. usually I crash within 10-20 minutes.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #144 from AmarildoJr ---
BTW, Team Fortress 2 also has hangups, and I was able to play it for +40
minutes without issues with "radeon.dpm=0".
--
You are receiving this mail because:
You are the assignee for the bug.
-- n
https://bugs.freedesktop.org/show_bug.cgi?id=80419
AmarildoJr changed:
What|Removed |Added
CC||amarildosjr at riseup.net
--- Comment #143
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #142 from Marek Olšák ---
I've seen plenty of GPU hangs with XCOM: Enemy Within. It's basically the same
game with a little more content, but not much.
The reproducibility is random. The hangs usually happen between 1 minutes and 8
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #141 from Alassane Maiga ---
Well I can reliably make it stop locking the system completely now. I switch to
console with ctrl+alt+f2 as soon as the game locks up and then back as soon as
the ring stall messages start to fill up the s
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #140 from Jan Vesely ---
(In reply to Nicolai Hähnle from comment #139)
> Are you running with some kind of virtualization enabled? I'm not familiar
> with these AMD-Vi messages.
Those are printed by the IOMMU driver (device accesse
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #139 from Nicolai Hähnle ---
Are you running with some kind of virtualization enabled? I'm not familiar with
these AMD-Vi messages.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #138 from Daniel Exner ---
Created attachment 124896
--> https://bugs.freedesktop.org/attachment.cgi?id=124896&action=edit
crash journal kernel 4.7.0-rc6
Seems you where right: crashed again today.
I managed to log some of it, per
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #137 from Nicolai Hähnle ---
Nothing that I'm aware of. May have been just luck...
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #136 from Daniel Exner ---
I tried with:
* Kernel 4.7.0-rc5-00309-gdbdc3bb
* LLVM: 274446
* Mesa: 01ccb0d
This time I could play for a solid hour without crash. Will try again later to
confirm.
@Devs: any idea if there is something
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #135 from Alassane Maiga ---
I had something interesting happen with kernel 4.7 rc5 and mesa 12.1 git1591e66
The system would lock up, and the console would fill with the stalling ring
messages. But then it won't lock up and will reco
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #134 from Nicolai Hähnle ---
Hi Daniel, curious, but I doubt the crash is related to the lockup. Most
likely, buffer creation fails in radeon_cs_create_fence and then we get a NULL
pointer dereference. If you could get a backtrace wi
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #133 from Daniel Exner ---
Created attachment 124486
--> https://bugs.freedesktop.org/attachment.cgi?id=124486&action=edit
crash
I once again tried it:
Kernel: 4.7.0-rc2-00342-g8714f8f
Mesa: Dev git 54f755f
Llvm: Dev cd22fc5 (usin
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #132 from Edwin Smith (Feral Interactive) ---
(In reply to Davin McCall from comment #131)
> I think you missed the significance of my second paragraph above - I have
> established that the hang is _not_ caused by the mis-use of the
>
https://bugs.freedesktop.org/show_bug.cgi?id=80419
Davin McCall changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.fre
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #131 from Davin McCall ---
Edwin Smith:
> It might be useful to see what the Intel and/or r600 series drivers do as
> neither of these driver exhibit this crash in similar circumstances.
I think you missed the significance of my se
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #130 from Marek Olšák ---
Oh I see you did that. Sorry for the noise.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #129 from Marek Olšák ---
(In reply to Davin McCall from comment #127)
> diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
> index f0245fd..d1f4ac6 100644
> --- a/src/mesa/vbo/vbo_exec_array.c
> +++ b/src/me
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #128 from Edwin Smith (Feral Interactive) ---
(In reply to Davin McCall from comment #127)
> The comment above from Jose Fonseca (and follow up from Feral's Edwin Smith)
> imply that the problem here is with the game calling
> glDrawR
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #127 from Davin McCall ---
The comment above from Jose Fonseca (and follow up from Feral's Edwin Smith)
imply that the problem here is with the game calling
glDrawRangeElementsBaseVertex with bad start/end values, resulting in the
ind
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #126 from Nicolai H�hnle ---
That's interesting, because r600 is a different user space OpenGL driver. It
might be an interaction with the DDX or kernel though.
If you cannot ssh from a different computer, you can still recover the
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #125 from Vladislav Kamenev ---
How to get dmesg log during lockup?
Got this on r600 driver (AMD Radeon hd6650m TURKS)
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #124 from Daniel Exner ---
Well there is this (still) highly experimental amdgpu f�r southern islands
branch. Perhaps I'll try that if I feel very lucky.
--
You are receiving this mail because:
You are the assignee for the bug.
--
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #123 from Nicolai H�hnle ---
Thanks for the re-test. It's odd that I couldn't reproduce it any more. It may
be that I was just lucky.
However, it's worth noting that Daniel has a GCN 1.0 card and David has a GCN
1.1 card, i.e. runn
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #122 from Daniel Exner ---
Tested again, same setup as before: crashed after 5 Minutes.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbe
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #121 from Davin McCall ---
On a 7790 with latest versions of just about everything - kernel 4.5, mesa git
head (11.3.0-devel), llvm 3.8, XOrg 1.18.2 - I still see this crash regularly.
I'm happy to provide any further information/logs
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #120 from Daniel Exner ---
Using xorg 1.18.2, Kernel 4.5 and
OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN (DRM 2.43.0, LLVM 3.8.0)
OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.3.0-devel
(git-84b961d)
I was a
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #119 from Nicolai H�hnle ---
For what it's worth, I'd encourage people to update their graphics stack to
latest everything (including kernel + X.Org server) and see if they still get
lockups. I haven't been able to reproduce this an
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #118 from Edwin Smith ---
In summary I think it was intimated that the issue might be caused by how XCOM
deals with indices.
===
The game is passing indices outside start..end range, which is illegal per
https://www.opengl.org/sdk/do
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #117 from Kamil Páral ---
(In reply to Marek Olšák from comment #116)
> This thread is too long. Could someone please summarize the issues here?
> Also, how does the apitrace crash relate to the GPU hang?
I hoped somebody clever w
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #116 from Marek Olšák ---
This thread is too long. Could someone please summarize the issues here? Also,
how does the apitrace crash relate to the GPU hang?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #115 from Jose Fonseca ---
I think there are multiple issues being conflated here.
Yes, apitrace had some bugs, and they might have cause additional grief to Mesa
drivers when replaying traces from XCOM.
But if the question is "d
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #114 from Kamil P�ral ---
I see, thanks for explanation. In that case I was wrong in automatically
assuming there is a bug in XCOM. Sorry for the noise.
--
You are receiving this mail because:
You are the assignee for the bug.
---
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #113 from Nicolai H�hnle ---
Perhaps it does, and that would be bad, but the particular apitrace crash was
basically the following:
1) XCOM uses DrawRangeElements with an unnecessarily large range.
2) During tracing, apitrace scans
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #112 from Kamil P�ral ---
(In reply to Nicolai H�hnle from comment #111)
> However, if I recall correctly, XCOM issues DrawRangeElements calls with
> ranges that are larger than necessary.
My understanding was that exactly the op
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #111 from Nicolai H�hnle ---
The apitrace-related crash from those earlier comments is not an XCOM bug.
However, if I recall correctly, XCOM issues DrawRangeElements calls with ranges
that are larger than necessary. This hurts perfo
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #110 from Edwin Smith ---
(In reply to Kamil P�ral from comment #109)
> Hi Edwin, thanks for following this discussion! I got the impression that
> XCOM uses invalid or at least undefined behavior from comment 88, 91 and 92,
> and f
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #109 from Kamil P�ral ---
Hi Edwin, thanks for following this discussion! I got the impression that XCOM
uses invalid or at least undefined behavior from comment 88, 91 and 92, and
from the apitrace bug comments here:
https://github
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #108 from Edwin Smith ---
(In reply to Kamil P�ral from comment #107)
> We have found out that XCOM issues invalid OpenGL commands.
Have we confirmed that this is true and if so what call is supposedly
incorrect? I been following
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #107 from Kamil P�ral ---
We have found out that XCOM issues invalid OpenGL commands. The purpose of this
bug report is for radeon driver to stop crashing when that happens. But I
wonder if somebody contacted XCOM developers and ask
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #106 from darkm00n ---
Created attachment 121532
--> https://bugs.freedesktop.org/attachment.cgi?id=121532&action=edit
journald xcom: ew apitrace crash
Also tried to run apitrace after the lockup but it crashed the game when I
clic
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #105 from darkm00n ---
Created attachment 121531
--> https://bugs.freedesktop.org/attachment.cgi?id=121531&action=edit
journald xcom: ew lockup
Any news on this bug? I've just tried to play the game and my system got frozen
after a
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #104 from Nicolai Hähnle ---
At this point, I can reproduce the lockup albeit not deterministically, so it's
not really needed. If you are able to capture an apitrace that reproduces the
lockup deterministically (even after a cold re
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #103 from Kamil Páral ---
(In reply to Nicolai Hähnle from comment #100)
> re comment #98: That's to be expected. The problem was with *recording* the
> trace, not with playing it back. A trace recorded without the patch will
> cras
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #102 from Nicolai Hähnle ---
Yes, they're almost certainly related. A sequence of VM faults followed by a
lockup is not an unusual symptom.
--
You are receiving this mail because:
You are the assignee for the bug.
-- ne
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #101 from Daniel Exner ---
I added a new bug report about GALLIUM_HUD bug.
Are those faults related to this bug?
Jan 10 12:04:15 Joshua kernel: radeon :01:00.0: GPU fault detected: 146
0x0f653014
Jan 10 12:04:15 Joshua kernel: r
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #100 from Nicolai Hähnle ---
Hi Daniel,
re comment #98: That's to be expected. The problem was with *recording* the
trace, not with playing it back. A trace recorded without the patch will crash
when played back, whether the playbac
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #99 from Daniel Exner ---
Played a bit with GALLIUM_HUD.
Using:
GALLIUM_HUD="fps,cpu,ps-invocations+hs-invocations+ds-invocations+cs-invocations;num-compilations+num-shaders-created,draw-calls,buffer-wait-time;num-cs-flushes,num-bytes
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #98 from Daniel Exner ---
glretrace -v from apitrace (5e96ed318db1ba8037eb402724bc052240ac9e05) still
crashes with the trace:
#0 0x7f9d112fae6e __memcpy_sse2_unaligned (libc.so.6)
#1 0x7f9d0caf3f5f u_upload_data (radeonsi_d
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #97 from Jose Fonseca ---
I'm pushing a slightly modified version of Roland's patch.
(In reply to Nicolai Hähnle from comment #96)
> Created attachment 120742 [details]
> more conservative apitrace patch
>
> For what it's worth, I'
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #96 from Nicolai Hähnle ---
Created attachment 120742
--> https://bugs.freedesktop.org/attachment.cgi?id=120742&action=edit
more conservative apitrace patch
For what it's worth, I've attached a modified version of Roland's patch t
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #95 from Jose Fonseca ---
(In reply to Roland Scheidegger from comment #94)
> Created attachment 120734 [details] [review]
> apitrace patch for honoring range in DrawRangeElementsX commands
>
> So you'd want something like this (tota
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #94 from Roland Scheidegger ---
Created attachment 120734
--> https://bugs.freedesktop.org/attachment.cgi?id=120734&action=edit
apitrace patch for honoring range in DrawRangeElementsX commands
So you'd want something like this (tot
https://bugs.freedesktop.org/show_bug.cgi?id=80419
Nicolai Hähnle changed:
What|Removed |Added
CC||nhaehnle at gmail.com
--- Comment #93
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #92 from Jose Fonseca ---
(In reply to Daniel Exner from comment #91)
> So it seems like it is indeed a Bug in the game to try to address this index
> element but also the operation should not crash and its unspecified
> behaviour.
>
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #91 from Daniel Exner ---
Sorry for pasting instead of an attachement.
The specs for glDrawRangeElementsBaseVertex [1] say this case (array out of
bounds) should be handled like this:
"Index values lying outside the range [start, en
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #90 from Paulo Dias ---
just to let you guys know that with latest llvm 3.8 (256187) fixes and mesa up
to 50fc4a925644378c50282004304bc8fd64b95e3c, it takes much longer for xcom
enemy unknown to crash the GPU, i played for two solid h
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #89 from Michel Dänzer ---
(In reply to Daniel Exner from comment #83)
> Managed to get some more infos about glretrace crash:
>
> Stack trace of thread 13986:
> #0 0x7fca93b67945 loader_dri3_wai
https://bugs.freedesktop.org/show_bug.cgi?id=80419
Jose Fonseca changed:
What|Removed |Added
CC||brianp at vmware.com,
|
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #87 from Kamil Páral ---
Created attachment 120655
--> https://bugs.freedesktop.org/attachment.cgi?id=120655&action=edit
gdb backtrace from xorg when system locks up during glretrace replay
Thanks Nicolai and others for looking in
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #86 from Nicolai Hähnle ---
Many thanks for your patience! While I still did not see a crash, valgrind does
indeed report errors when playing back your crash. It is possible that such
errors are indirectly related to the lockup, if t
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #85 from Kamil Páral ---
(In reply to Daniel Exner from comment #80)
> Now I get (with radeonsi):
>
> glretrace game.x86_64.trace
> apitrace: warning: caught signal 11
> 47062: error: caught an unhandled exception
Great to see it
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #84 from Daniel Exner ---
Disabled DRI3 and the trace run through (without GPU crash) but glretrace
crash:
Wow, such stacktrace many interesting:
Stack trace of thread 26634:
#0 0x7fc683d6ce6e __
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #83 from Daniel Exner ---
Managed to get some more infos about glretrace crash:
Stack trace of thread 13986:
#0 0x7fca93b67945 loader_dri3_wait_gl (libGL.so.1)
#1 0x0042e6
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #82 from Michael Eagle ---
(In reply to Kamil Páral from comment #74)
>
> (I'm sorry, I still have the same month-old mesa as in comment 70, I didn't
> figure out how to update it easily before I started tinkering with the
> replays
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #81 from Daniel Exner ---
Don't get this error with llvmpipe. But also no crash. (Still running, slow as
hell).
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTM
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #80 from Daniel Exner ---
Yes, you where right. Some guy at my distro removed it without telling anyone.
Is back now.
Now I get (with radeonsi):
glretrace game.x86_64.trace
apitrace: warning: caught signal 11
47062: error: caught a
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #79 from Michel Dänzer ---
(In reply to Daniel Exner from comment #78)
> >10536: message: major api error 1: GL_INVALID_ENUM in
> >glCompressedTexImage2D(internalFormat=0x8c4d)
> >10536 @1 glCompressedTexImage2DARB(target = GL_TEXTU
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #78 from Daniel Exner ---
I tried to replay the trace attached:
> glretrace game.x86_64.trace
But all I get is this (many times repeated):
>10536: message: major api error 1: GL_INVALID_ENUM in
>glCompressedTexImage2D(internalFor
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #77 from Michel Dänzer ---
(In reply to Kamil Páral from comment #76)
> I could try to reproduce it by looping the replay over, if needed.
No need, it's not important. The assumption for now is that the Xorg crash is
caused by the
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #76 from Kamil Páral ---
> That said, we could probably confirm either way if we could look at a gdb
> backtrace of the Xorg crash.
Unfortunately I don't have it. ABRT deleted it due to some unfortunate
circumstances. I could try t
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #75 from Michel Dänzer ---
(In reply to Kamil Páral from comment #74)
> There's this line:
> (EE) 2: /lib64/libc.so.6 (__memcpy_avx_unaligned+0x1ab) [0x7fe7ee3ffafb]
> which is the same function that I reported to be crashing in api
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #74 from Kamil Páral ---
Created attachment 120647
--> https://bugs.freedesktop.org/attachment.cgi?id=120647&action=edit
system journal containing gpu hang during apitrace replay
And according to the Murphy's law, after I posted m
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #73 from Kamil Páral ---
I have managed to capture an apitrace while radeon driver locked up *and*
recovered afterwards, so that I was able to exit the game normally (this almost
never happens). I was hopeful that in this case it cou
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #72 from Edwin Smith ---
A steam key has been given to Nicolai Hähnle from Feral to help with his
investigations into the crash.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part ---
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #71 from Nicolai Hähnle ---
Hi Kamil, your version of Mesa is too old: it does not contain the
GALLIUM_DDEBUG feature yet.
At this point, the most helpful thing for you to do would be to reproduce this
with latest development versio
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #70 from Kamil Páral ---
Created attachment 120594
--> https://bugs.freedesktop.org/attachment.cgi?id=120594&action=edit
kernel messages from xcom hang
I'd like to help with resolving this. I added GALLIUM_DDEBUG=800 and checked
u
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #69 from Nicolai Hähnle ---
Thank you for the followup. Apparently, even the very first tracepoint is not
processed. This is weird.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #68 from David Beswick ---
Thank you Nicolai, I was able to reproduce the hang using the "noflush" option.
DDEBUG seemed to detect the hang and killed the process, but my machine still
locked up as usual.
--
You are receiving this m
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #67 from David Beswick ---
Created attachment 120587
--> https://bugs.freedesktop.org/attachment.cgi?id=120587&action=edit
Output of GALLIUM_DDEBUG="800 noflush" and R600_DEBUG="ps,vs,gs,vm"
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #66 from Nicolai Hähnle ---
Hi David, thank you for your efforts! Note that GALLIUM_DDEBUG=help explains a
"noflush" option that you can also use. In any case, can you post the resulting
file from ~/ddebug_dumps/?
Also, next time yo
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #65 from David Beswick ---
Hello everyone,
Just to keep you up to date, I switched tack and have been using the
"GALLIUM_DDEBUG" environment variable to try and capture data about the crash.
I found out about this option via a Google
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #64 from Alassane Maiga ---
FWIW I noticed the game seems to freeze for a second when playing on windows,
and then comes back online. Could it be related? maybe the game freezes the gpu
on windows too but the windows driver succeed du
1 - 100 of 166 matches
Mail list logo