Created attachment 119654 [details]
Every time CS:GO has finished loading a level and is about to draw 3D graphics it crashes with this error before any 3D graphics is displayed.
Attaching the backtrace.
64-bit Ubuntu 15.10
Linux both 4.3.0 and agd5f/powerplay tested
Other games work fine, Borderlands, Civ 5, Shadow of Mordor, Metro: Last Light (old version).
I got the same trouble on arch with mesa-git and llvm-svn. Working fine with the stable release.
Might be a duplicate of bug 92709.
If http://lists.freedesktop.org/archives/mesa-dev/2015-November/100742.html doesn't help, please run the game with the environment variable R600_DEBUG=vs,gs,ps and attach its stderr output.
Created attachment 119989 [details]
Oh, haven't tried the patch yet. Here's the log with R600_DEBUG=vs,gs,ps anyway.
Created attachment 120065 [details]
cs_go console log with R600_DEBUG=vs,gs,ps with patched LLVM-git and mesa-svn
Hi, i tried to recompile llvm-git and mesa-svn including both the patch that i found in Michel Dänzer message. The attachment contain the last two mesa debug dump from the console. Honestly I don't know if you need the full log from the game start to the crash, but the full log is over 3Mb. I hope this can help, and this is the dmesg generated from the crash.
[nov23 19:01] csgo_linux: segfault at c ip 00000000f17cb7ed sp 00000000d3d56a0c error 4 in libLLVM-3.8svn.so[f11b6000+29d3000]
Doesn't look related to bug 92709. I was able to reproduce the crash with llc and the LLVM IR from the attached debugging output. Tom/Matt/Nicolai could any of you take a look?
(In reply to Bogar Boris from comment #1)
> I got the same trouble on arch with mesa-git and llvm-svn. Working fine with
> the stable release.
Can you first isolate whether the crash was introduced by a change in Mesa or LLVM, and then bisect that component?
(In reply to Michel Dänzer from comment #6)
> (In reply to Bogar Boris from comment #1)
> > I got the same trouble on arch with mesa-git and llvm-svn. Working fine with
> > the stable release.
> Can you first isolate whether the crash was introduced by a change in Mesa
> or LLVM, and then bisect that component?
I tried but i can't. I looked on my package manager log and i see that i discover the bug around 2015/10/09. So i tried to compiled an old revision of mesa but around that date i found that the mesa fail to configure/compile because of some new virgl driver. And the compilation fail for an huge gap of commit, so, finding out this is beyond my knowledge.
With my current git snapshots of everything I can actually load a game and play one round if I set shader detail to Low, everything else can be set to max it seems.
However it crashes a bit later when loading the next round. Haven't captured the tracebacks from that yet...
(In reply to Bogar Boris from comment #7)
> So i tried to compiled an old revision of mesa but around that date i found
> that the mesa fail to configure/compile because of some new virgl driver.
Can't you just disable the virgl driver build? If that doesn't work either, please attach the failure output from configure / make.
It's not a mesa change that caused this.
I have the same problem with Hawaii. The first time I saw this I tried an older version of mesa which worked a day before and the problem was still there.
I can't say which change in llvm caused this, because I'm only building mesa on my own and receive a prebuilt llvm copy from a repository.
I can upload a backtrace as well if you want, but the segfault I see also happens in SlotIndex::getIndex().
The change in LLVM happend somewhere between November 9th (known good) and yesterday (known bad).
Okaaay... sorry for the noise, I don't have the _same_ problem.
My problem is not due to a change in either mesa or llvm but cs go as it seems.
I switched to a llvm r251632 (October 29th) and mesa c6b24448b578c4a8ab031923df3ef1e2d865d5bb (also October 29th) and my problems is still there.
I'm opening a new bug.
Couldn't reproduce this today. Could set shaders to very high, change graphics settings on the fly (though slow), run multiple matches in a row etc...
Latest padoka-ppa + drm-next-4.6-wip kernel.
Indeed, the offending shaders no longer crash. Not sure which of the recent LLVM changes is responsible, let's just be happy it works :)