[SOLVED] valve games (dota2) not working in latest -current

WhiteWolf1776 · 12-23-2014, 05:58 PM

Posting in the hopes of helping others avoid or fix this issue. If you are running -current, and you suddenly find that dota2 and other valve games no longer run, you will need to downgrade your libdrm back to the earlier 2.4.54.
You can do this by getting the source from here:
http://dri.freedesktop.org/libdrm/
and using the slack script from the source directory for this package under x.

Here's hoping it helps avoid dota2 withdraw and merry Christmas to all.

Alien Bob · 12-23-2014, 07:35 PM

Quote:

Originally Posted by WhiteWolf1776

Posting in the hopes of helping others avoid or fix this issue. If you are running -current, and you suddenly find that dota2 and other valve games no longer run, you will need to downgrade your libdrm back to the earlier 2.4.54.
You can do this by getting the source from here:
http://dri.freedesktop.org/libdrm/
and using the slack script from the source directory for this package under x.

Here's hoping it helps avoid dota2 withdraw and merry Christmas to all.

Are you on a multilib system? Did you also upgrade the mesa-compat32 and libdrm-compat32 package?

WhiteWolf1776 · 12-23-2014, 08:20 PM

Yes I am on a multilib system and yes I upgraded the compat32 package for libdrm, mesa, etc. For a hat trick, I am also on an optimus system which may be the final piece to make it break.

looking here:
https://bugs.debian.org/cgi-bin/bugr...cgi?bug=768045

My error was as stated in that bug and the solution is workable... downgrade libdrm for now. Based on some chatter on the steam forum this seemed tho not limited to optimus enabled systems, but I am looking through the code to see if there is something in primus or bumblebee that may need fixed or that may fix this. If not, I would expect valve to patch their code at some point.

ryanpcmcquen · 12-24-2014, 12:26 AM

Put me down as a +1 for this issue.

Alien Bob · 12-24-2014, 04:47 AM

Hmm.

First, if you already had libvdpau installed from a 3rd party repository don't forget to replace it with the new libvdpau package in slackware-current.

Half-Life works OK after the upgrade, but Half-Life 2: Lost Cost crashes when loading the level. Dmesg shows:

Code:

hl2_linux[2722]: segfault at 0 ip           (null) sp 00000000ffbeb21c error 14 in hl2_linux[8048000+1000]

Haven't tried DOTA2 yet (did not have that installed yet) but since it also uses the Source engine like HL2, I suppose it will crash the same way.

I do not have Optimus, just a regular GeForce GT 240 card.

Eric

ryanpcmcquen · 12-24-2014, 11:09 AM

Thanks Eric.

I made sure to remove libvdpau from building in Nick's repo with my build script (crazybee.sh). Nick has subsequently removed that folder and sent it to pasture with the 14.1 branch.

I found that downgrading to libdrm 2.4.56 (2.4.57 would not build) is working with Dota 2 and Half Life 2. FYI, I'm on multilib/64-current/bumblebee/primus.

rworkman · 12-24-2014, 11:43 AM

If someone has some time to play with this stuff and wants to (try to) figure out where it broke:

Code:

git clone git://anongit.freedesktop.org/git/mesa/drm
git bisect start
git checkout libdrm-2.4.56
git bisect good
git checkout libdrm-2.4.58
git bisect bad

At that point, you'll get a different commit to build and test.
What I usually do is something like this:

Code:

./autogen.sh
./configure (options from build script)
make
make install DESTDIR=/tmp/testing
*open a new root terminal window*
cd /tmp/testing
chown -R root:root .
rm -rf ./usr/man ./usr/doc ./usr/share/doc
makepkg -c n -l y /tmp/libdrm-testing1-$arch-1.tgz

Upgrade to that package, test it (no reboot needed - just a kill/restart of X, I would think), and then go back into the libdrm git directory. If all is well with that package, then do this:

Code:

git bisect good

If not, then do this:

Code:

git bisect bad

Either way, you'll get a new revision to test. You'll need to clean out the leftovers from the prior build first though:

Code:

make clean
git clean

Now repeat the build/install process and loop until you find the bad commit.

Alien Bob · 12-24-2014, 01:37 PM

My first guess is that this is the culprit: http://cgit.freedesktop.org/mesa/drm...6ba1b79ccdcf2e (configure: Support symbol visibility when available).
The opensource drivers have been updated to support this symbol visibility feature but probably this causes issues with the binary blobs.
Other commits between 2.4.56 and 2.4.58 don't appear to be relevant to the issue.

ryanpcmcquen · 12-24-2014, 01:41 PM

Quote:

Originally Posted by rworkman

If someone has some time to play with this stuff and wants to (try to) figure out where it broke:

The first two bisects were good, I'll try to finish up the testing but need to do some X-Mas eve stuff for now. Thanks for the detailed instructions, I had never used git bisect before, seems very useful. ;-)

Hopefully I am doing the right thing in building these as compat32, I have not touched the 64-bit package as I do not believe Steam relies on it anyways.

rworkman · 12-24-2014, 01:43 PM

Quote:

Originally Posted by ryanpcmcquen

The first two bisects were good, I'll try to finish up the testing but need to do some X-Mas eve stuff for now. Thanks for the detailed instructions, I had never used git bisect before, seems very useful. ;-)

FYI, hopefully I am doing the right thing in building these as compat32, I have not touched the 64-bit package as I do not believe Steam relies on it anyways.

Yep, but probably alienBOB is correct. Either way, the exercise is useful. :-)

ryanpcmcquen · 12-25-2014, 12:36 AM

Quote:

Originally Posted by rworkman

Yep, but probably alienBOB is correct.

I'd be hard-pressed to find a scenario where this was not true. :-)

Alien Bob · 12-26-2014, 05:32 AM

I tried disabling setting the visibility to "hidden" of the dsrm library's internal symbols, something which had been added between 2.4.56 and 2.4.58, but I could not see a difference. I installed the 64-bit modified package as well as the compat32 package (steam is 32-bit).

$ cat libdrm-2.4.58_visibility.patch

Code:

--- libdrm-2.4.58/configure.orig        2014-09-28 20:55:06.000000000 +0200
+++ libdrm-2.4.58/configure     2014-12-26 00:18:51.724704379 +0100
@@ -13220,7 +13220,7 @@
 
 
 
-if test "x$GCC" = xyes; then
+if test "x$GCC" = foo; then
     # Enable -fvisibility=hidden if using a gcc that supports it
     save_CFLAGS="$CFLAGS"
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC supports -fvisibility=hidden" >&5

$ diff -u /stuff/slackware/non-public/alien/slackware64/source/x/libdrm/libdrm.SlackBuild ~/work/curdev/libdrm/libdrm.SlackBuild

Code:

--- /stuff/slackware/non-public/alien/slackware64/source/x/libdrm/libdrm.SlackBuild     2014-11-27 23:04:08.000000000 +0100
+++ /home/eha/work/curdev/libdrm/libdrm.SlackBuild      2014-12-26 00:31:41.159343138 +0100
@@ -68,6 +68,9 @@
   \( -perm 666 -o -perm 664 -o -perm 600 -o -perm 444 -o -perm 440 -o -perm 400 \) \
   -exec chmod 644 {} \;
 
+# Fix issues in Steam and other games:
+cat $CWD/libdrm-2.4.58_visibility.patch | patch -p1 --verbose || exit 1
+
 # Configure:
 CFLAGS="$SLKCFLAGS" \
 ./configure \

Perhaps my crude lobotomy was insufficient, or perhaps there is another issue which eludes me.

Game that does not run (as stated before) even with the modified libdrm package is Half-life 2: Lost Coast. It crashes during loading of the game. The games that do work (with the original Slackware libdrm as well as with my modified version) are Half-life, Half-life 2 and DOTA2. Did not try others.

Eric

frushiyama · 12-26-2014, 08:27 AM

I have bumblebee too and until now this games are working:
War Thunder
And this are not working:
Team Fortress 2
Left 4 Dead 2
I am on Slackware64 multilib current and with WhiteWolf's bumblebee git, all updated.

ryanpcmcquen · 12-26-2014, 11:47 AM

Strangely, dota 2 launched through all the bisects ...

WhiteWolf1776 · 01-19-2015, 06:06 AM

This seems to have been fixed with the Nvidia driver 346.35 . Anyone having issues with this should update to that driver or newer.