Describe the bug
If I open SteamVR without first making sure that my GUI has been restarted and without making sure that no programs which use any significant graphical resources (Waterfox, Blender, etc) are open, SteamVR will almost always cause my entire graphics stack to freeze. This will say something in dmesg like:
[112114.167264] [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, signaled seq=3094506, emitted seq=3094508
[112114.167276] [drm:amdgpu_job_timedout] *ERROR* Process information: process vrcompositor pid 12498 thread vrcompositor pid 12498
[112114.167281] amdgpu 0000:03:00.0: amdgpu: GPU reset begin!
Due to a kernel bug, the GPU reset is usually not successful and even shutdown does not work due to this. I have to manually close all programs and then do a hard reset by holding the power button. This makes this bug extremely severe on my system.
This is not only a kernel bug, however, as despite also communicating with the HMD, Monado does not have this issue and I can restart it as much as I want without any problems. So, although the reset bug is not a SteamVR issue, I believe the fact that it triggers the GPU breaking in the first place is a SteamVR issue.
To Reproduce
Steps to reproduce the behavior:
Launch a bunch of programs, perhaps a few instances of Blender with complex shaders.
Launch SteamVR.
Expected behavior
SteamVR launches smoothly and bugs are limited to SteamVR itself rather than killing the entire graphics stack.
System Information (please complete the following information):
Distribution: Gentoo Linux.
SteamVR version: Every version I have used since January 2021, including the Linux v 1.14 beta, the beta, and the current version, have this bug.
Steam client version: May 28 2022 at 01:45:53
Opted into Steam client beta?: Yes, but I also had this bug before I did that.
Graphics driver version: [run nvidia-settings or vulkaninfo | grep driverInfo: Mesa 22.1.0, but this has also occurred in many previous versions.
Gist for SteamVR System Information: See one of the gists from my previous issues: https://github.com/ValveSoftware/SteamVR-for-Linux/issues/430. I do not have any way to access the gitsts after this bug is occured due to them only being accessible by GUI, and do not want to make a new one right now as doing so requires either closing all my programs, or risking triggering the bug resulting in needing to wait 20 minutes to restart if it occurs, and downtime for services running on this computer.
Other important information:
Motherboard: SuperMicro x8dt3-ln4f. This uses PCI-E 2.0.
Processors: 2x Intel Xeon X5690. This also occurred on my previous Intel Xeon X5560 processors.
GPU: AMD Radeon RX 480.
If this does not occur when testing on other systems, I believe this may be a conflict as a result of using PCI-E 2.0 instead of 3.0, as this can cause a conflict when trying to use AMD ROCm drivers. It is also probably AMD-specific as most other graphics bugs reported seem to be.
Additional context
An older dmesg from a time I experienced the bug on 2021-03-12: https://gist.github.com/happysmash27/56108a55f159f57c18e19aa44a509d8d
From the logs, this appears to be one of the instances where it was caused by SteamVR (Ethereum mining can cause similar bugs) and where it was not recoverable.
dmesg from my most recent crash in 2022-05-26: https://gist.github.com/happysmash27/a625c3b3141d04a795b423ba7f8c16c4
I attempted to reset the GPU but it did not seem to work (processes that were using the GPU could not be killed and shutdown would not occur without hard reset). It does, however, have different messages than this bug usually has, most notable being the lack of the: failed to send message <3-digit number around 200> ret is 0
that usually occurs with this bug.
Note: Commenters who are also experiencing this issue are encouraged to include the "System Information" section in their replies.
Describe the bug
If I open SteamVR without first making sure that my GUI has been restarted and without making sure that no programs which use any significant graphical resources (Waterfox, Blender, etc) are open, SteamVR will almost always cause my entire graphics stack to freeze. This will say something in dmesg like:
Due to a kernel bug, the GPU reset is usually not successful and even shutdown does not work due to this. I have to manually close all programs and then do a hard reset by holding the power button. This makes this bug extremely severe on my system.
This is not only a kernel bug, however, as despite also communicating with the HMD, Monado does not have this issue and I can restart it as much as I want without any problems. So, although the reset bug is not a SteamVR issue, I believe the fact that it triggers the GPU breaking in the first place is a SteamVR issue.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
SteamVR launches smoothly and bugs are limited to SteamVR itself rather than killing the entire graphics stack.
System Information (please complete the following information):
nvidia-settingsorvulkaninfo | grep driverInfo: Mesa 22.1.0, but this has also occurred in many previous versions.Other important information:
Motherboard: SuperMicro x8dt3-ln4f. This uses PCI-E 2.0.
Processors: 2x Intel Xeon X5690. This also occurred on my previous Intel Xeon X5560 processors.
GPU: AMD Radeon RX 480.
If this does not occur when testing on other systems, I believe this may be a conflict as a result of using PCI-E 2.0 instead of 3.0, as this can cause a conflict when trying to use AMD ROCm drivers. It is also probably AMD-specific as most other graphics bugs reported seem to be.
Additional context
An older dmesg from a time I experienced the bug on 2021-03-12: https://gist.github.com/happysmash27/56108a55f159f57c18e19aa44a509d8d
From the logs, this appears to be one of the instances where it was caused by SteamVR (Ethereum mining can cause similar bugs) and where it was not recoverable.
dmesg from my most recent crash in 2022-05-26: https://gist.github.com/happysmash27/a625c3b3141d04a795b423ba7f8c16c4
I attempted to reset the GPU but it did not seem to work (processes that were using the GPU could not be killed and shutdown would not occur without hard reset). It does, however, have different messages than this bug usually has, most notable being the lack of the:
failed to send message <3-digit number around 200> ret is 0that usually occurs with this bug.
Note: Commenters who are also experiencing this issue are encouraged to include the "System Information" section in their replies.