Here Are The Steam Survey Results For Linux During August 2016

[lockheed02]

very fun. I just upgraded to fedora 24 and after the second restart of steam I got the survey. Still, a very long time AFTER the article has been published. Well, I'm one of the 0,09% Linux 64bit. Yay! \o/

Lockheed

[castlefox]

I'll be finally building a linux gaming PC around the time AMD releases those Zen chips in the new year. I cant wait to boost the steam stat for Linux 64bit up by 0.00000001%

[dungeon]

Have you tested whether a previous kernel/mesa work? Then bisect?
Or is this a bug that has always been present but only became visible after a change to the game binary?

Well no, i don't play that recently, but after reading it on bugzilla observed it once months ago after 15 minutes or something... didn't investigate it further, but it is enough for at least M2 confirmation - so yep lockups happens there with radeonsi

[chrisb]

This is a very weird issue, because I don't really know where it is. I think it's not in Mesa, and here's why:

* On Debian Jessie with kernel 3.16 and Mesa 10.3, the problem doesn't happen;
* On the same Debian, but with mesa backported, the problem also doesn't happen;
* On the same Debian with Mesa backported and the Kernel backported, the problem still doesn't happen;
* On Arch Linux with Mesa downgraded to 10.3, the problem happens;
* On the same Arch Linux with Mesa and Kernel downgraded, the problem still happens;
* I'm not 100% sure I downgraded the Firmware on Arch, but I'll try today since I'm testing a few drivers in Linux;
* I have a vague memory about downgrading the kernel, mesa, and the firmware, and the issue was still there;
* On vanilla Arch with Catalyst/FGLRX, the problem doesn't happen;

So I do think this issue is much bigger than everybody things and only happens with a certain combination of Mesa, Kernel, Firmware, and possibly libdrm, llvm, and other pieces of software as well.

Maybe it is an interaction between certain packages, but it could be a single package (as somebody else pointed out, the firmware and LLVM would be prime suspects). Since you have a reproducible test case where the bug occurs, and another where it doesn't, you could probably find the root cause with some testing.

You could eliminate the kernel by booting Jessie kernel on Arch root or vice versa. Either boot the kernel and change root in the kernel parameters, or boot one distro and mount the alt distro on /mnt then "mount -obind /dev /mnt/dev/; mount -obind /proc /mnt/proc/; chroot /mnt" and try to reproduce. Alternatively build a custom kernel from Linus git and root mount and test both Arch and Jessie. If you get different results it probably isn't the kernel at fault.

Another possibility to eliminate is llvm/mesa. Build llvm from source, build mesa, and test on Jessie and Arch. Building mesa is easier than it sounds (basically git clone, autoconf, configure, make) (Debian instructions) and you can test without actually installing it by setting LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH. Once you have the same mesa on Debian and Arch you can see whether or not the bug is reproducible.

Yet another possibility is that this is a bug which has already been fixed upstream and some distributions happen to be missing the patch (or firmware update). This can be verified by using the latest upstream git (or packages built from it). It's a good idea not to waste time on bugs that are already fixed...

[eydee]

The survey system is very buggy. A few weeks ago I got 4 of them in a row. Literally. As soon as I clicked the finish button, another one popped up, and so on.

[dungeon]

So you as one you are counted as four, but many who never get it they does not exists

[Amarildo]

@Amarildo

LLVM issue?

To be honest I'm not sure. I think the issue is larger than what we think and isn't dependant on Mesa alone, as backporting Mesa in Debian Jessie still didn't cause the issue to happen. So IMO there could be an interaction problem between: xorg-server, mesa, llvm, libdrm, kernel drivers, and firmware, all with something new introduced in TF2 with that update. The problem didn't started happening because of a Mesa update, but because VALVe's update for TF2 at the time. Using the CVAR command to disable texture streaming didn't solve the issue, so VALVe could have introduced the problem for Linux users within another feature from that same December update.

He, he, not everything is llvm issue... TF2 enabled texture streaming feature to save some mem back then for Linux and issues with radeonsi started from there i think.

Without, they likely had higher memory footprint, longer loading times, but better performance. And now they had everything opposite plus random lockup on radeonsi

But if texture streaming was the cause, wouldn't that CVAR command have removed the lockup? Because for me it didn't.

[Amarildo]

Maybe it is an interaction between certain packages, but it could be a single package (as somebody else pointed out, the firmware and LLVM would be prime suspects). Since you have a reproducible test case where the bug occurs, and another where it doesn't, you could probably find the root cause with some testing.

I did try doing so this year, but was unable to reproduce. If you look some of my older comments, I backported Mesa/libc6/kernel to the latest available in Debian, and the problem didn't occur. At the same time, I did downgrade Mesa in Arch some while ago and the problem persisted.

IMO it's VALVe who should be looking at this since the problem started once they updated TF2.

You could eliminate the kernel by booting Jessie kernel on Arch root or vice versa. Either boot the kernel and change root in the kernel parameters, or boot one distro and mount the alt distro on /mnt then "mount -obind /dev /mnt/dev/; mount -obind /proc /mnt/proc/; chroot /mnt" and try to reproduce. Alternatively build a custom kernel from Linus git and root mount and test both Arch and Jessie. If you get different results it probably isn't the kernel at fault.

I did just try to boot a 3.16 Kernel in Arch. It does boot, but I didn't want to test it alone (silly me). I tried to downgrade the Kernel, Xorg, Mesa, libdrm, llvm, and sddm, but no display manger would start. I will try the 3.16 Kernel tonight, but I can almost certainly guarantee that it will still have the problem. Let's see what happens
[/QUOTE]

Another possibility to eliminate is llvm/mesa. Build llvm from source, build mesa, and test on Jessie and Arch. Building mesa is easier than it sounds (basically git clone, autoconf, configure, make) (Debian instructions) and you can test without actually installing it by setting LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH. Once you have the same mesa on Debian and Arch you can see whether or not the bug is reproducible.

To me, Mesa 10.3 in Debian Jessie works just fine, as well as Mesa 11.3 which is the version I backported several months ago, along with the 4.4 Kernel from jessie-backports.

I could build Mesa and LLVM in Arch but it takes too long and wouldn't make much sense because there's the archive where old packages can be found archive.archlinux.org That's where I installed my test packages from.

And I was building llvm-svn and mesa-git, but these also take quite a while to build and there's also repositories for them

Yet another possibility is that this is a bug which has already been fixed upstream and some distributions happen to be missing the patch (or firmware update). This can be verified by using the latest upstream git (or packages built from it). It's a good idea not to waste time on bugs that are already fixed...

Problem is, upstream Mesa can't fix the problem just yet. Marek did push a patch, but it didn't fix for us testers. I patched current mesa 12.0.1 in Arch with his patch, and the problem still happened. I also tried Mesa-Git, and the problem is still there, because the patch was merged upstream and if it was fixed in mesa-git we would've heard it by now

https://bugs.freedesktop.org/show_bug.cgi?id=93649

https://github.com/ValveSoftware/Source-1-Games/issues/1943

[Amarildo]

The survey system is very buggy. A few weeks ago I got 4 of them in a row. Literally. As soon as I clicked the finish button, another one popped up, and so on.

To me, VALVe already has stats of all it's users. And if they don't, they could easily get proper stats without the buggy survey system.

I've used Steam on Windows for several years and only got the survey twice, however in Linux I was surveyed 20 times in 2 years. Some people say they never got the survey on Linux but got it numerous times in Windows.

[Aeder]

I opened Steam in Linux like every other day but no survey. As soon as switched to Windows to check on something I get the survey :/