steam-runtime
steam-runtime copied to clipboard
bad interactions between Mesa 20.3.4, MangoHud and Steam Linux Runtime
Your system information
- Steam Runtime Version: steam-runtime_0.20201203.1
- Distribution: Slackware 14.2-current
- Full system information
- Have you checked for system updates?: Yes
- Are you using the Steam Linux Runtime compatibility tool?: No
Please describe your issue in as much detail as possible:
I have tried to run World of Warships and Kingdom Come: Deliverance and both doesn't start. To Steam return from "Running" state, I need kill the pressure-vessel. I have tested using client_beta and previous_release but both didn't work. Also have deleted the pinned_libs to link any new libs which Steam needs but didn't work either. I also have tried Assassin's Creed Origins, this one worked as should be. slr-app552990-s5c2158af4b578f2e.log
Steps for reproducing this issue:
- Open Steam
- Run the game World of Warships or Kingdom Come: Deliverance
PS: I saw two other issue about pressure_vessel, maybe is related.
"build_id" : "0.20210126.1",
~~This version of SteamLinuxRuntime_soldier
has a known bug on some systems (#361, #362) and was pulled from the client_beta
branch. If you are seeing games getting stuck with the default (non-beta) branch of soldier, please could you get system information and a log with that version? You can check which version you are using by looking at SteamLinuxRuntime_soldier/VERSIONS.txt
.~~ — sorry, ignore that, I'm confused. 0.20210126.1 is the non-beta branch, not the beta that was pulled.
If you are finding that one game (like Assassin's Creed Origins) works, and another game (like World of Warships) gets stuck during setup, then it would also be useful to get a log from each game with nothing else changed, so we can compare them.
We often use Floating Point and Life Is Strange Episode 1 as test games. They're native Linux games, but if you force use of Proton 5.13 in the game's properties, Steam will download the Windows version.
Those games have the advantages that they're free-to-play (so everyone can compare them), available as native Linux games (so we can compare native with Proton), not too big (so they work on older hardware), and single-player (so we don't get anti-cheat mechanisms interfering with Proton).
Okay, I will do it at night, right now I am at work.
On Wed, Feb 3, 2021, 08:35 Simon McVittie [email protected] wrote:
"build_id" : "0.20210126.1",
This version of SteamLinuxRuntime_soldier has a known bug on some systems (#361 https://github.com/ValveSoftware/steam-runtime/issues/361, #362 https://github.com/ValveSoftware/steam-runtime/issues/362) and was pulled from the client_beta branch.
If you are seeing games getting stuck with the default (non-beta) branch of soldier, please could you get system information and a log with that version?
If you are finding that one game (like Assassin's Creed Origins) works, and another game (like World of Warships) gets stuck during setup, then it would also be useful to get a log from each game with nothing else changed, so we can compare them.
We often use Floating Point https://store.steampowered.com/app/302380/Floating_Point/ and Life Is Strange Episode 1 https://store.steampowered.com/app/319630/Life_is_Strange__Episode_1/ as test games. They're native Linux games, but if you force use of Proton 5.13 in the game's properties, Steam will download the Windows version.
Those games have the advantages that they're free-to-play (so everyone can compare them), available as native Linux games (so we can compare native with Proton), not too big (so they work on older hardware), and single-player (so we don't get anti-cheat mechanisms interfering with Proton).
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/steam-runtime/issues/363#issuecomment-772443032, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANCW7KDQF73IIH5NT5C6ODS5EYHDANCNFSM4XAARLFQ .
Do you know which version of Proton you were using?
I can reproduce a similar hang with World of Warships, which seems to be related to Vulkan drivers getting duplicated in the container. A fix is in progress.
Appears is the 5.13.5, is the default 5.13 from Steam. (I am still on the work, but I think my system log maybe has the correct info)
On Wed, Feb 3, 2021, 08:54 Simon McVittie [email protected] wrote:
Do you know which version of Proton you were using?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/steam-runtime/issues/363#issuecomment-772453223, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANCW7OZJQ635PZMFD2LMZ3S5E2PRANCNFSM4XAARLFQ .
We think this is fixed in the new client_beta
update with pressure-vessel 0.20210203.0.
I was able to reproduce a similar problem with World of Warships, soldier 0.20210201.0 and Proton 5.13-5, and this updated soldier beta seems to fix it.
I will try it in few hours with both games to check it.
I tested, and didn't worked for me, still hangs. slr-app552990-sd18968207f0ef110.log
This looks like not the same bug as #361 and #362. Your log contains this, which I didn't see in the others:
preloader: Warning: failed to reserve range 00010000-00110000
esync: up and running.
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
preloader: Warning: failed to reserve range 00010000-00110000
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
WARNING: radv is not a conformant vulkan implementation, testing use only.
preloader: Warning: failed to reserve range 00010000-00110000
0/0: preloader: Warning: failed to reserve range 00010000-00110000
src\clientdll\installscript_win32.cpp (2223) : Assertion Failed: V_strlen( pchInstallPath ) > 0
src\clientdll\installscript_win32.cpp (2223) : Assertion Failed: V_strlen( pchInstallPath ) > 0
src\clientdll\installscript_win32.cpp (2224) : Assertion Failed: V_IsAbsolutePath( pchInstallPath )
src\clientdll\installscript_win32.cpp (2224) : Assertion Failed: V_IsAbsolutePath( pchInstallPath )
src\clientdll\installscript_win32.cpp (2223) : Assertion Failed: V_strlen( pchInstallPath ) > 0
src\clientdll\installscript_win32.cpp (2223) : Assertion Failed: V_strlen( pchInstallPath ) > 0
src\clientdll\installscript_win32.cpp (2224) : Assertion Failed: V_IsAbsolutePath( pchInstallPath )
src\clientdll\installscript_win32.cpp (2224) : Assertion Failed: V_IsAbsolutePath( pchInstallPath )
src\clientdll\installscript_win32.cpp (2223) : Assertion Failed: V_strlen( pchInstallPath ) > 0
src\clientdll\installscript_win32.cpp (2223) : Assertion Failed: V_strlen( pchInstallPath ) > 0
src\clientdll\installscript_win32.cpp (2224) : Assertion Failed: V_IsAbsolutePath( pchInstallPath )
src\clientdll\installscript_win32.cpp (2224) : Assertion Failed: V_IsAbsolutePath( pchInstallPath )
src\clientdll\installscript_win32.cpp (2223) : Assertion Failed: V_strlen( pchInstallPath ) > 0
src\clientdll\installscript_win32.cpp (2223) : Assertion Failed: V_strlen( pchInstallPath ) > 0
src\clientdll\installscript_win32.cpp (2224) : Assertion Failed: V_IsAbsolutePath( pchInstallPath )
src\clientdll\installscript_win32.cpp (2224) : Assertion Failed: V_IsAbsolutePath( pchInstallPath )
src\clientdll\installscript_win32.cpp (2223) : Assertion Failed: V_strlen( pchInstallPath ) > 0
src\clientdll\installscript_win32.cpp (2223) : Assertion Failed: V_strlen( pchInstallPath ) > 0
src\clientdll\installscript_win32.cpp (2224) : Assertion Failed: V_IsAbsolutePath( pchInstallPath )
src\clientdll\installscript_win32.cpp (2224) : Assertion Failed: V_IsAbsolutePath( pchInstallPath )
Because it isn't immediately clear which component is going wrong here, it would be useful if you could capture a matching set (same versions of everything, without updating anything in between) of:
- Help -> System Information
- Steam Linux Runtime log (
slr-*.log
fromSTEAM_LINUX_RUNTIME_LOG=1
) - Proton log (
steam-*.log
fromPROTON_LOG=1
)
If you have a pair of scenarios where one works and the other doesn't, it would also be really useful to be able to compare that information from the working scenario and the non-working scenario.
For instance, if you have one game that works and one game that doesn't, you could collect: Help -> System Information; slr-*.log
from working game; steam-*.log
from working game; slr-*.log
from non-working game; and steam-*.log
from non-working game.
stopped work after system update
Can you find out from your package manager which packages were updated during this system update?
As a Debian user, I'd use /var/log/dpkg.log
and /var/log/apt/
for this, but I don't know whether Slackware has an equivalent of those logs.
This looks like not the same bug as #361 and #362. Your log contains this, which I didn't see in the others:
From my testings with World of Warships it seems like the assertions failings are harmless, because I'm getting them too and the game still runs. So the only part that is different is the beginning:
preloader: Warning: failed to reserve range 00010000-00110000
esync: up and running.
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
preloader: Warning: failed to reserve range 00010000-00110000
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
WARNING: radv is not a conformant vulkan implementation, testing use only.
preloader: Warning: failed to reserve range 00010000-00110000
0/0: preloader: Warning: failed to reserve range 00010000-00110000
Well, I didn't found any libs been updated which could mess with the game:
calligra-3.2.1-x86_64-4
calligraplan-3.3.0-x86_64-1
digikam-7.1.0-x86_64-3
dosfstools-4.2-x86_64-1
dvdauthor-0.7.2-x86_64-3
e2fsprogs-1.46.0-x86_64-1
emacs-27.1-x86_64-4
fcitx-libpinyin-0.5.4-x86_64-1
gamin-0.1.10-x86_64-8
gd-2.3.1-x86_64-1
hwdata-0.344-noarch-1
ibus-m17n-1.4.4-x86_64-1
imagemagick-7.0.10_61-x86_64-1
kdev-php-5.6.2-x86_64-1
kdev-python-5.6.2-x86_64-1
kdevelop-5.6.2-x86_64-1
kfilemetadata-5.78.0-x86_64-3
kid3-3.8.5-x86_64-1
kile-2.9.93-x86_64-4
krb5-1.19-x86_64-1
krita-4.4.2-x86_64-2
libevdev-1.11.0-x86_64-1
libgcrypt-1.9.1-x86_64-1
libwacom-1.8-x86_64-1
libwebp-1.2.0-x86_64-1
mesa-20.3.4-x86_64-1
musescore-3.6.1-x86_64-1alien
nghttp2-1.43.0-x86_64-1
okteta-0.26.5-x86_64-1
oprofile-1.4.0-x86_64-5
poppler-21.02.0-x86_64-1
python-packaging-20.9-x86_64-1
python-pip-21.0.1-x86_64-1
python-setuptools-53.0.0-x86_64-1
samba-4.13.4-x86_64-2
sysklogd-2.2.1-x86_64-1
xine-lib-1.2.11-x86_64-3
xorriso-1.5.4-x86_64-1
xpdf-4.03-x86_64-1
After I tried the games and they didn't work, I have upgraded again my compat32 libs (32bits libs for Slackware64). The list is extensive. After that didn't work too, I have opened this issue.
PS: I am working right now to create the logs for Floating Point(Proton), Life is Strange(Proton) and Assassin's Creed Origins.
The logs for the games with Proton+Pressure-vessel working. (Steam Linux Runtime - Soldier [client_beta]) Floating Point log Soldier Proton Life is Stranger Soldier Proton Assassin's Creed Origin Soldier Proton
Hello @gbschenkel, can you test if temporarily disabling MangoHud with something like sudo mv /usr/share/vulkan/implicit_layer.d/MangoHud.json /usr/share/vulkan/implicit_layer.d/MangoHud.json.disabled
has an effect?
Shit, it opened. The problem is with mangohud... don't believe...
Okay, so my hypothesis is that https://cgit.freedesktop.org/mesa/mesa/commit/?h=20.3&id=affb8eebe405854b93452eeca54b4ad0289542c2 lead to https://gitlab.freedesktop.org/mesa/mesa/-/issues/3801.
@kisak-valve, please could you retitle this to "bad interactions between Mesa 20.3.4, MangoHud and Steam Linux Runtime" to reflect our current understanding of what is going on here?
The list of known issues has more information on this, but the short version is that upgrading Mesa to 20.3.4 while using both MangoHud and Steam Linux Runtime can cause something to break. This can manifest as a crash, a freeze, games not starting or various other failure modes (it's undefined behaviour, so anything could happen).
I don't think this is really a bug in pressure-vessel or the Steam Linux Runtime, but for whatever reason, it seems like either the Steam Linux Runtime or Proton/DXVK triggers it more often than native games.
Mesa 20.3.5 and 21.0.0 have a workaround - or possibly a solution, nobody is really sure whose bug this is - so upgrading to one of those versions should hopefully resolve this.
We're continuing to look into whether this is a bug in Mesa, MangoHud, pressure-vessel, Vulkan-Loader or some other component. When we find out which, hopefully we can either solve it, or confirm that the Mesa changes are a correct solution.