Up-to-date fedora rawhide on x86_64.
This is a recent tahiti XT board (marketing name is R9 280X).
I have an "old" tahiti XT board (marketing name is HD 7970), I recalled dota2 working fine a few weeks ago (not tested recently though) on that "old" board.
Then I don't know if it fits into regression since I guess the atombios is probably different.
Created attachment 105057 [details]
dmesg till after the crash
Created attachment 105058 [details]
xorg log file till after the crash
Created attachment 105247 [details]
new dmesg till after the crash
Created attachment 105248 [details]
new Xorg.0.log till after the crash
massive mesa update in fedora rawhide today. Many error messages from the kernel are gone. Seems to be related to mesa.
Still crashing though.
(In reply to comment #0)
> Then I don't know if it fits into regression since I guess the atombios is
> probably different.
You're too fixated on ATOM BIOS. :) It's mainly used for things like modesetting, not for 3D rendering.
There's no sign of a GPU lockup or anthing like that in the files you attached, so what exactly are the symptoms?
Assuming the problem is that the DOTA2 process itself crashes, we'll need to see a gdb backtrace of the crash or at least the console output corresponding to the crash.
I was just saying the chips are the same but their bios could be different, hence that would be
a regression if the bios were identical.
The atombios is mainly for modesetting *and* dpm: you have that horrible
code path which translates atombios dpm tables to smc tables.
Back to our pb: dota2 crashes while loading. I'll get a console output and
if we need more, I'll attach a gdb to the loading process.
Created attachment 105300 [details]
steam log file
It shows a LLVM error and a steam runtime IPC error
Created attachment 105301 [details]
dota2 gdb backtrace with the crash
steam log file and dota2 gdb backtrace of the crash
If it still happens with LLVM 3.5, can you run the game with the environment variable R600_DEBUG=vs,gs,ps and attach the output from that?
fedora rawhide is still using llvm kludge 3.4, notified fedora guy:
Let you know once they get llvm 3.5 into rawhide.
If you attach the output from R600_DEBUG=vs,gs,ps , we might be able to check if current LLVM still chokes on it.
Created attachment 105573 [details]
steam output with R600_DEBUG
I can reproduce the failure with llc from LLVM 3.4, but it seems fixed in LLVM 3.5.
upgrade to a fresh rawhide today: that crash disapeared to be replaced by another one (seems glibc related).