Went back to NVIDIA 465.31 and no issues at all. So it's a problem somewhere caused by the 470 driver.

I have the same issue. I tested what @kisak-valve suggested and it works.

Had two crashes playing Groove Gunner today (-203).

First when I tried to go into the Steam system menu/library from the game. After killing SteamVR I can't start it again without a power cycle on the headset because it will only display garbage.

Second crash when I quit the game after playing it again.

My uninformed suspicion would point to the compositor crashing under certain circumstances in combination with async reprojection.

From my recent experiences, I can confirm that enabled async reprojection can cause SteamVR failures to happen a lot more likely.

When playing GTFO in VR with async reprojection (on nVidia), I experience about 2-3 crashes in a 3h play session. The game with the VR mod is quite demanding, so async reprojection does help with performance without downscaling.
I tried now 2 ~3h sessions in GTFO VR without async reprojection and didn't experience a single crash (have to downscale for a good experience then though).

My suspicion is, that a SteamVR failure with async reprojection occurs more likely, when the game is more demanding. I didn't experience crashes with Beat Saber, Synth Riders or Pistol Whip even when async reprojection was enabeld, but those games are way less demanding and work perfectly without async reprojection too.

I'd have to disagree with that, I can't play more that a few minutes of Beatsaber with async reprojection without experiencing a crash, sometimes it does it even straight away during the first song. Turning it off, all is fine. I'm running it at 150% res on the index though, so it might be a touch more demanding than on default settings. Also, Mods might add to that. That said, beatsaber works flawlessly at 150% without async reprojection too.

i cannot even start anything. before even home is started my pc freezes for a very short time and after that it points out error 203. hmd is black the whole time. it works flawlessly on windows and did before the nvidia driver update

I'm also experiencing increased SteamVR crashes with async reprojection enabled on Linux. I have a 100% reproducible test case.

I'm running a GTX 1070 with NVIDIA 470 driver with SteamVR Beta 1.19.6. With async reprojection I experience the already reported jitter and wobbliless of the overlay and chaperone. In addition, when I play VRChat, and visit the Vket 6 Carryol WindChorus world and walk up to the Nullmoto Universe booth, SteamVR (but not VRChat) will crash. Without async reprojection the framerate drops but Steam VR keeps running.

OS is Arch Linux.

I just found out that on my 3-monitor-setup,when i disable all but one, steamvr just works.
With all 3 on i get an instant 203

With custom SteamVR drivers on Linux same thing happens, last time i tested it was an Ubuntu machine, no external monitors, and the behavior is just "great" :) you start SteamVR and it works fine and dandy for maybe 5-10 minutes, it then proceeds to die for no reason with -203, no errors from the driver, only an "unusual" sleep state before crash, if i remember correctly

I just found out that on my 3-monitor-setup,when i disable all but one, steamvr just works.
With all 3 on i get an instant 203

This is an unrelated issue. This happens on AMD as well. What's happening here is specific to Nvidia 470

I can confirm this irritating, seemingly random -203 error is still an issue with the following setup in SteamVR:

Ubuntu 20.04
NVIDIA driver 470.57.02
Geforce 1080
Valve Index

While I could go back to a previous driver version which doesn't support asynchronous reprojection, I would end up with the double-image stutters again... but that's why I upgraded to the 470 driver.

If SteamVR developers need a highly (and quickly) reproducible case, try this:

1. Make sure your system is running the NVIDIA 470 driver which supports asynchronous reprojection.
2. Run "Waltz of the Wizard: Natural Magic" under Proton.
3. Dismiss the complaint about a json file if it appears.
4. Once at the starting point, go to the door called "Courtyard" and touch the circle on the door until you hear the door creaking open sound. If the "Courtyard" door does not appear the first time, re-run the game.
5. Once in the courtyard, move to the center of the stone magic circle and stand there. Swirling magic will appear to transport you to...
6. Oopsie! Error -203 rears its head. Headset goes blank. Audio from the game continues, but you're no longer in VR.

Rarely, this action actually works as intended, VR stays working and the -203 error does not appear, but for the vast majority of the time, it bugs out like clockwork. Very reproducible.

The -203 error seems to occur during transitions, but not always. I've seen the error also happen in titles like "X-Plane 11" (native), "Myst" (proton), "Half-Life: Alyx" (native), "Go for Launch: Mercury" (proton), "Google Earth VR" (proton).

Pops up out of nowhere constantly during Elite Dangerous and Phasmophobia in Proton on 470 drivers as well, where both of these titles previously worked great. This is still occurring even after disabling asynchronous reprojection in the settings.

These seem to be the only relevant messages from the web console:

Fri Sep 10 2021 01:22:26.004081 - Failed Watchdog timeout in thread Render in WaitForPresent after 6.004832 seconds. Aborting.
Fri Sep 10 2021 01:22:26.061325 - IPC: recovering abandoned mutex 0x7f9af7e163a4
Fri Sep 10 2021 01:22:26.603525 - Excessive binding loads from steam (18668): crc=3209310505 lc=2 Reload=F res=2
Fri Sep 10 2021 01:22:26.603591 - ===== vive: state=4, NOT empty, uri=file:///home/orangestar/.local/share/Steam/steamapps/common/SteamVR/resources/config/legacy_bindings_generic_hmd.json
                                  [Snip: Previous 2 messages repeated 11 times]
Fri Sep 10 2021 01:22:34.676967 - Socket closed
Fri Sep 10 2021 01:22:34.677029 - Unable to read message from socket: 0
Fri Sep 10 2021 01:22:34.677067 - Process vrcompositor (45034) disconnected (Thread(0x0x7f3a200030d0/0x0x7f)
Fri Sep 10 2021 01:22:34.677104 - AppInfoManager.ProcessQuit processid=45034 eLaunchingApp=LaunchingApp_None
Fri Sep 10 2021 01:22:34.677119 - AppInfoManager.ProcessQuit: Clearing application openvr.component.vrcompositor PID was 45034
Fri Sep 10 2021 01:22:34.677137 - AppInfoManager.ProcessQuit: Clearing application openvr.component.vrcompositor PID because 45034 has exited
Fri Sep 10 2021 01:22:35.019778 - Excessive binding loads from steam (18668): crc=3209310505 lc=2 Reload=F res=2
Fri Sep 10 2021 01:22:35.019845 - ===== vive: state=4, NOT empty, uri=file:///home/orangestar/.local/share/Steam/steamapps/common/SteamVR/resources/config/legacy_bindings_generic_hmd.json
Fri Sep 10 2021 01:22:42.591620 - [System] Transition from 'SteamVRSystemState_Ready' to 'SteamVRSystemState_NotReady'.
Fri Sep 10 2021 01:22:42.684436 - Excessive binding loads from steam (18668): crc=3209310505 lc=2 Reload=F res=2
Fri Sep 10 2021 01:22:42.684500 - ===== vive: state=4, NOT empty, uri=file:///home/orangestar/.local/share/Steam/steamapps/common/SteamVR/resources/config/legacy_bindings_generic_hmd.json
Fri Sep 10 2021 01:22:43.671803 - Excessive binding loads from steam (18668): crc=3209310505 lc=2 Reload=F res=2
Fri Sep 10 2021 01:22:43.671883 - ===== vive: state=4, NOT empty, uri=file:///home/orangestar/.local/share/Steam/steamapps/common/SteamVR/resources/config/legacy_bindings_generic_hmd.json
Fri Sep 10 2021 01:22:43.825925 - [Status Alert] SteamVR Fail (-203)

After this, the headset goes dark and the monitor window displays the -203 error.
Ignore the "Excessive binding loads" messages, it seems to be a separate issue (#307)

Manjaro Linux
NVidia Driver 470.63.01
Geforce 1060
Original Vive
Steam client beta, version 1631237534
SteamVR Beta, version 1.19.7 (1629236071)
Here's my System Report

I am suffering from the same problem. Although I just acquired a valve index recently. It seems to me to some games tigger the 203 error faster than others. I can play Alyx fopr quite some time. If I try No Man's Sky VR I get 203 error almost instantly.

Here is my inxi Output:

System:    Host: kai-Z390 Kernel: 5.14.0-0-MANJARO x86_64 bits: 64 Desktop: Xfce 4.16.0 Distro: Manjaro Linux 
Machine:   Type: Desktop Mobo: ASUSTeK model: ROG STRIX Z390-F GAMING v: Rev 1.xx serial: 180937134403225 
           UEFI: American Megatrends v: 1602 date: 06/04/2020 
Memory:    RAM: total: 15.55 GiB used: 3.67 GiB (23.6%) 
           Array-1: capacity: 64 GiB slots: 4 EC: None 
           Device-1: ChannelA-DIMM1 size: No Module Installed 
           Device-2: ChannelA-DIMM2 size: 8 GiB speed: 3200 MT/s 
           Device-3: ChannelB-DIMM1 size: No Module Installed 
           Device-4: ChannelB-DIMM2 size: 8 GiB speed: 3200 MT/s 
CPU:       Info: 6-Core model: Intel Core i5-9600K bits: 64 type: MCP cache: L2: 9 MiB 
           Speed: 800 MHz min/max: 800/4600 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 846 5: 800 6: 800 
Graphics:  Device-1: NVIDIA TU106 [GeForce RTX 2070] driver: nvidia v: 470.63.01 
           Display: server: X.Org 1.20.13 driver: loaded: nvidia resolution: 1: 1920x1200~60Hz 2: 2560x1440 
           OpenGL: renderer: NVIDIA GeForce RTX 2070/PCIe/SSE2 v: 4.6.0 NVIDIA 470.63.01 
Audio:     Device-1: Intel Cannon Lake PCH cAVS driver: snd_hda_intel 
           Device-2: NVIDIA TU106 High Definition Audio driver: snd_hda_intel 
           Sound Server-1: ALSA v: k5.14.0-0-MANJARO running: yes 
           Sound Server-2: PipeWire v: 0.3.34 running: yes 
Info:      Processes: 317 Uptime: 53m Shell: Zsh inxi: 3.3.06 

It fixes this if you disable async re-projection as someone stated above. Async re-projection when it works makes it so it is more smooth when you have low fps. The Nvidia 470 driver recently implemented support for async re-projection so its either a problem with the driver or valves implementation of it. It crashes on Half life alyx and NEOS vr. So basically anything with it enabled for me.

Hello @LiamDawe, it might be interesting to test if nvidia 470.xx + [#227 (comment)](https://github.com/ValveSoftware/SteamVR-for-Linux/issues/227#issuecomment-520459572) works around the issue you're seeing.

Edit: It seems to work for awhile with async reprojection. It is a lot smoother but ends up crashing after awhile and is kind of annoying.

This is more of an issue now that you can't build a kernel module for 465 drivers on 5.14 kernels.
SteamVR also locks up the whole machine requiring a hard reboot when it is closed.

It fixes this if you disable async re-projection as someone stated above.

How do I do that (#470 is without an application even running, and afaik you can only disable async on a per application basis)

This is more of an issue now that you can't build a kernel module for 465 drivers on 5.14 kernels.

I don't know where you got that idea from. Building 465 drivers works fine for me on 5.14 using nvidia-all. If you haven't used that yet, give it a shot.

This is more of an issue now that you can't build a kernel module for 465 drivers on 5.14 kernels.

I don't know where you got that idea from. Building 465 drivers works fine for me on 5.14 using nvidia-all. If you haven't used that yet, give it a shot.

The kernel headers changed in such a way as to break both the nvidia installer, eg
https://www.nvidia.com/download/driverResults.aspx/171980/en-us

and kmod-nvidia from rpmfusion

rather not blow up my system with random guesses, 465 is end of life and SteamVR requires a hard system reboot to close it down on 470+.

Are you sure you didn't just fall back on llvmpipe?

EDIT:Some progress on this. switching to wayland, recompling stuff, enabling gdm and a couple of other things I forget improved the situation somewhat, but its not really in a usable state (legacy reprojection and async reprojection both now unusable on 470+) guess Im just SOL until this lot matures.

I don't think I'd be getting the performance (or VR support) I'm getting on my computer with pure llvmpipe.

FYI: SteamVR Fail (-203) error is still present with the latest SteamVR 1.20.4 beta update, which is a "build candidate for full release" according to the release notes.
GPU: NVIDIA GTX 1080
Driver: 470.74
OS: Ubuntu 20.04

Still an issue even with Async Reprojection disabled
Nvidia RTX 2060 Super, Driver 495, Linux Mint
Sat Nov 06 2021 18:01:21.838229 - Failed Watchdog timeout in thread Render in WaitForPresent after 5.572546 seconds. Aborting.
This is likely an issue with the game itself and not Proton.

Im back up and running after updating to nvidia driver 470.82
still get artifacts, but at least it works and well once an application starts.

the 495.44 on new feature branch is still really buggy.

So its an nvidia driver issue by the looks of it.
Cant open the settings page tho.

For me async reprojection completely freezes my computer for a few seconds until steamvr crashes and vr stops working. This happens 100% of the time. It happens immediately after steamvr launches.

I really wish nvidia would just open source their drivers. Like amd gpu users aren't having this issue. I know people using vr on Linux with amd cards perfectly fine. Sadly its still hard to get new gpus without getting it from a scalper. There is really no reason for nvidia to not open source them. So it is definitely a nvidia driver issue like @mSparks43 mentioned.

Just adding to the pile. I also seem to get frequent freezes/crashes with looping sound when running demanding games (particularly VRChat and Blade & Sorcery) with asynchronous reprojection on. Seems like some process in the chain is overwhelmed because it always happen when there's "a lot going on" or upon loading into a new world. Maybe there has been an update trying to fix some of the other async bugs considering the crashes seem to happen under circumstances where asynchronous reprojection should kick in?

This is on the latest proton, Radeon 6800XT and Ryzen 5900X.

The latest SteamVR release, 1.21.1, still has the -203 error issue.

I sure wish some friendly, helpful developers at Valve would take some time to address this reoccurring error. We customers would appreciate it quite a lot. I'd try my hand at fixing it myself but, hey... closed source. Can't do much without access to source code.

OS: Ubuntu 20.04 (Linux)
SteamVR: 1.21.1
NVIDIA driver: 470.82.00
GPU: GTX 1080

I can not reproduce the issue anymore, my custom driver works fine no crashes so far, my consumer headset works fine too, didn't experience any crashes in a really long while

OS: Ubuntu 20.04.3 LTS
SteamVR: 1.12.1 [beta]
GPU driver: nvidia 470.82.00

Error (-203) still reproducible with the 1.21.2 beta release. Easily reproduced with "Waltz of the Wizard: Natural Magic", but that is by no means the only title where it can be reproduced.

OS: Ubuntu 20.04 (Linux)
SteamVR: 1.21.2
NVIDIA driver: 470.82.00
GPU: GTX 1080

Error (-203) still reproducible with the 1.21.2 beta release.

Can confirm, High CPU utilisation still causes ERROR SteamVR Fail (-203)
OS: Fedora Core 35 (5.14.16-301.fc35.x86_64)
SteamVR: 1.21.2
NVIDIA driver: 470.86
CPU: AMD 5900X
GPU: RTX 3070

Interesting, @quantumac I'll try that title on my Linux machine, do you have any other titles worth testing?

@mSparks43 can you go into more details? Cause back when I did have this issue I also got CPU spikes, but only when it actually crashed

Error (-203) still reproducible with the 1.21.2 beta release. Easily reproduced with "Waltz of the Wizard: Natural Magic", but that is by no means the only title where it can be reproduced.

OS: Ubuntu 20.04 (Linux) SteamVR: 1.21.2 NVIDIA driver: 470.82.00 GPU: GTX 1080

What do you mean by custom driver though ? Like did you modify 470.82.00?

Error (-203) still reproducible with the 1.21.2 beta release. Easily reproduced with "Waltz of the Wizard: Natural Magic", but that is by no means the only title where it can be reproduced.

OS: Ubuntu 20.04 (Linux) SteamVR: 1.21.2 NVIDIA driver: 470.82.00 GPU: GTX 1080

What do you mean by custom driver though ? Like did you modify 470.82.00?

I work with custom SteamVR drivers, think of as a final user space translation layer between the hardware, OS and SteamVR

@mSparks43 can you go into more details? Cause back when I did have this issue I also got CPU spikes, but only when it actually crashed

If I start SteamVR before there is nearly 100% CPU usage It 203's pretty much without fail
https://www.youtube.com/watch?v=EPoIVQSWml8

Start it after, when load is low (and presumably no skipped frames) and its fine
https://www.youtube.com/watch?v=ic-CTEUnGpw

@okawo80085 Interesting, @quantumac I'll try that title on my Linux machine, do you have any other titles worth testing?

I have seen this problem rarely with "Half Life: Alyx" and "X-Plane 11". I see it more frequently with "Waltz of the Wizard: Natural Magic". I'm sure there are other titles (see my steps to reproduce in my Sep 8 message above). I agree with @mSparks43 that this may be CPU load related.

However, without source code it's hard to say. It's all a black box. Like Schrödinger, all I can do is shake the box and listen for a screaming cat. 😄

I have seen this problem rarely with "Half Life: Alyx" and "X-Plane 11". I see it more frequently with "Waltz of the Wizard: Natural Magic". I'm sure there are other titles (see my steps to reproduce in my Sep 8 message above). I agree with @mSparks43 that this may be CPU load related.

Gotcha, i'll try to test most of them, i have "Half Life: Alyx" but not the other titles, "Waltz of the Wizard: Natural Magic" looks interesting tho, i might buy it

However, without source code it's hard to say. It's all a black box. Like Schrödinger, all I can do is shake the box and listen for a screaming cat. smile

With my driver i have a bit more insight into how it works, but not too much, lower level SteamVR is still a black box xD

However, without source code it's hard to say. It's all a black box.

If we are dissecting the issue.
Nvidia 470 drivers seem to have added the bit that was causing

https://github.com/ValveSoftware/SteamVR-for-Linux/issues/277

So reprojection now actually works without stutter.
But reprojection also seems to be bugged, causing 203 errors.

So right now the choice is between stutters with reproj off, or 203 errors with it on. Up until someone in Valve gets time off the steam deck to save us, perhaps needing the stars to align and nvidia to change something to. hopefully also fixing
KNOWN ISSUES Even with Vulkan applications, performance issues are still being worked on on both the runtime and the game engine side

So its a waiting game, I hold absolutely nothing against Valve protecting the significant IP they have put into Linux VR, I just wish we didn't have to wait so long for these things to get fixed....

I finally got enough time to test "Half Life: Alyx", and its runs great, no stuttering, good fps, it's enjoyable to play. Until about 1.5 hours into my play session, SteamVR crashes out of nowhere xD

Same symptoms as originally described by this issue.

Tested with

OS: Ubuntu 20.04.3 LTS
SteamVR: 1.12.1 [beta]
GPU driver: nvidia 470.82.00

I will also run a synthetic test with my driver later, to see if its triggered by gameplay or not, exactly how long it takes, etc.

I can confirm the error showing up quite readily in "Phasmophobia".

I can confirm the error showing up quite readily in "Phasmophobia".

Can you tell approximately how long it took to crash?

I can confirm the error showing up quite readily in "Phasmophobia".

Can you tell approximately how long it took to crash?

The disconnect from SteamVR occurred when I try to leave the van. Performance to that point was very choppy with lots of stuttering.

OS: Ubuntu 20.04 (Linux)
SteamVR: 1.21.2
NVIDIA driver: 470.82.00
GPU: GTX 1080

Replying to https://github.com/ValveSoftware/SteamVR-for-Linux/issues/452#issuecomment-980367468

Huh, i have "Phasmophobia", i'll check if i have the same behavior later

Error reproduced with another title, "Paper Beast", and with a new version of the NVIDIA driver.

Playing "Chapter 1", after you have pulled the red drapes away and as the large beast above you wanders off, the dreaded -203 error appears.

OS: Ubuntu 20.04 (Linux)
SteamVR: 1.21.2
NVIDIA driver: 470.86
GPU: GTX 1080
VR Headset: Valve Index

More on this error appearing in "Paper Beast":

The error is consistently triggered when the giant "4" falls from the sky at the begining of Chapter 1. I'm guessing somehow spawning or loading the "4" object is causing an issue with reprojection.

I was able to get past this point by editing the file:

      ~/.steam/steam/config/steamvr.vrsettings

And adding the following line:

      "enableLinuxVulkanAsync" : false

to the "steamvr" section of the config file.

Of course this disables asynchronous reprojection (sad face). I then reran the game and the (-203) error did not appear.

OS: Ubuntu 20.04 (Linux)
SteamVR: 1.21.2
NVIDIA driver: 470.86
GPU: GTX 1080
VR Headset: Valve Index

@quantumac I can not reproduce the "Phasmophobia" crash, when i leave the wan nothing happens, the game runs fine.
To be fear my test wasn't very long, 20 minutes maybe. In my case it could be time based since "Half Life: Alyx" crashes after about an hour.

I'll probably do a more prolonged test of "Phasmophobia" later.

I did update my GPU driver, had to do so for Steam to stop crashing on start x)

OS: Ubuntu 20.04.3 LTS
Steam: built Nov 22 2021 22:06:59 [beta]
Proton Version: Proton Experimental
SteamVR: 1.21.2
GPU: RTX 3060
NVIDIA driver: 495.44
VR Headset: Valve Index

Error (-203) persists with the new SteamVR Beta 1.21.3 under Linux. Quickly verified with three titles which reproduced the error before (i.e. "Waltz of the Wizard: Natural Magic" as described in my Sep 8th message, "Phasmophobia" as described in my Nov 26th message, and "Paper Beast" as described as described in my Nov 29th message). No change in symptoms.

OS: Ubuntu 20.04 (Linux)
SteamVR: 1.21.3
NVIDIA driver: 470.86
GPU: GTX 1080
VR Headset: Valve Index

Has anyone seen error -203 using an AMD GPU or is this limited to NVIDIA?

Has anyone seen error -203 using an AMD GPU or is this limited to NVIDIA?

pretty sure this one is nvidia specific, we all here reporting it on nvidia cards and it doesnt happen with 465 drivers.
But 465 drivers are a stutter mess and (at least on fedora 35) also cant be installed any more without some hackery.

As of this moment, with
"disableAsync" : true,
"enableLinuxVulkanAsync" : true,

kernel 5.15.5-200.fc35.x86_64
steamvr beta 1.21.3
Nvidia 470.62.12

I "think" I'm golden, I'll edit this post if it happens again.

I tried the 495.44 NVIDIA driver. The (-203) error persists. I saw the same issues with same titles using the same steps I've outlined above.

I noticed on Steam that a Windows 11 user was complaining about error (-203) with SteamVR Beta 1.21.3, so the issue may not be limited to Linux.

OS: Ubuntu 20.04 (Linux)
SteamVR: 1.21.3
NVIDIA driver: 495.44
GPU: GTX 1080
VR Headset: Valve Index

I note that X-Plane is the only title I have found thus far where I can recover from this error without restarting the title. This is because the user can toggle VR mode from within X-Plane, not just when X-Plane starts. So when this error occurs (...sometimes startlingly out of the blue...), I can pause X-Plane, toggle out of VR mode, restart SteamVR, then reenter VR mode in X-Plane. It's annoying, but it's doable. Other titles I just have to lose my progress, which is even more annoying.

note that X-Plane is the only title I have found thus far where I can recover from this error without restarting the title.

Same here (but also the only title I play, "waves")
Try these in your settings

"disableAsync" : true,
"enableLinuxVulkanAsync" : true,

Just been flying all afternoon without incident on those.

@mSparks43

I tried adding:

"disableAsync" : true,
"enableLinuxVulkanAsync" : true,

to the "steamvr" section of the settings file, but I could still reproduce the error.

I noticed other "title-specific" sections in the settings file had the opposite "disableAsync" state set, namely:

"disableAsync" : false,

So I created a "title-specific" section in the settings file for "Paper Beast" and set "disableAsync" to true. With that change, the error did not appear, but async reprojection was also not happening. It was a stutter mess in places.

Async reprojection is so very useful that my current policy is to turn it off when playing titles which trigger the error often, and then turn it back on for titles which trigger the error rarely.

Sure wish a developer with access to source code would take some time to look into this. I note a Windows 11 user has reported the same error, so it might not be just a Linux issue. Investing time into finding out what's wrong may benefit both Windows and Linux users.

but async reprojection was also not happening. It was a stutter mess in places.

yes. but I believe enableLinuxVulkanAsync true fixes that for me (although I am getting 60fps in XP)
disableAsync true stops the bug
enableLinuxVulkanAsync true gives smooth tracking.

This error -203 happens to me while simply navigating the steamvr menu, steam within steamvr and sometimes when launching a game.
I have created a system report here: https://gist.github.com/Fynises/6fbb7aa91213902abbdd4ea74c5f2550

OS: Arch Linux (linux-tkg-pds 5.15.6)
GPU: GTX 1070
Graphics Drivers: 495.44
SteamVR: 1.21.3 (Beta)
Headset: Valve Index
Steam: steam-native-runtime 04/12/2021

I haven't done any extra configurations to steamvr outside of the provided settings menu.

Got a -203 crash in "The Walking Dead: Saints & Sinners" after about 15 minutes up time and finishing a radio conversation in the home camp.

OS: Ubuntu 20.04.3 LTS
Steam: built Dec 2 2021 07:35:48 [beta]
Proton Version: Proton Experimental
SteamVR: 1.21.2
GPU: RTX 3060
NVIDIA driver: 495.44
VR Headset: Valve Index

I examined the "~/.steam/steam/logs/vrmonitor.txt" file in my steam install and I saw these lines around the error:

Wed Dec 08 2021 15:28:25.815541 - [Status Alert] SteamVR Fail (-203)
Wed Dec 08 2021 15:28:25.816238 - Large number of events this frame caused the poll loop to exit without draining
Wed Dec 08 2021 15:28:25.832634 - Large number of events this frame caused the poll loop to exit without draining
Wed Dec 08 2021 15:28:25.853133 - Large number of events this frame caused the poll loop to exit without draining

So it sounds like some event queue is backing up. Why? I have no idea! Debugging without access to source code is near impossible.

Replying to https://github.com/ValveSoftware/SteamVR-for-Linux/issues/452#issuecomment-989295022

Omg, i'm like 98% sure about what is causing it, SteamVR on Linux has this weird issue that causes the runtime to spam vr::VREvent_ActionBindingReloaded because of failed binding loads on literally every headset. See #307.

You can't see it in the vrmonitor process log (i don't remember if it's visible in vrclient or vrserver), but you can see all logs chronologically as they happen in the developer console, which you can access by going to http://localhost:27062/console/index.html
while SteamVR is running.

Its hard to miss this one in the developer console.

I was playing "RUSH" (i.e. the wingsuit racing title) and saw the -203 error preceded by -301 errors in the vrmonitor.txt log. RUSH doesn't error out often, but when it does, it always seems to be at the beginning of a race.

Thu Dec 09 2021 10:05:30.059005 - [System] Transition from 'SteamVRSystemState_Ready' to 'SteamVRSystemState_NotReady'.
Thu Dec 09 2021 10:05:30.073410 - [Status Alert] SteamVR Fail (-301)
Thu Dec 09 2021 10:05:31.053943 - [System] Transition from 'SteamVRSystemState_NotReady' to 'SteamVRSystemState_Ready'.
Thu Dec 09 2021 10:08:46.055544 - [System] Transition from 'SteamVRSystemState_Ready' to 'SteamVRSystemState_NotReady'.
Thu Dec 09 2021 10:08:46.056852 - [Status Alert] SteamVR Fail (-301)
Thu Dec 09 2021 10:08:47.053829 - [System] Transition from 'SteamVRSystemState_NotReady' to 'SteamVRSystemState_Ready'.
Thu Dec 09 2021 10:11:56.053086 - [System] Transition from 'SteamVRSystemState_Ready' to 'SteamVRSystemState_NotReady'.
Thu Dec 09 2021 10:11:56.054444 - [Status Alert] SteamVR Fail (-301)
Thu Dec 09 2021 10:11:57.057576 - [System] Transition from 'SteamVRSystemState_NotReady' to 'SteamVRSystemState_Ready'.
Thu Dec 09 2021 10:12:02.054085 - [System] Transition from 'SteamVRSystemState_Ready' to 'SteamVRSystemState_NotReady'.
Thu Dec 09 2021 10:12:02.055396 - [Status Alert] SteamVR Fail (-301)
Thu Dec 09 2021 10:12:03.057877 - [System] Transition from 'SteamVRSystemState_NotReady' to 'SteamVRSystemState_Ready'.
Thu Dec 09 2021 10:14:18.055242 - [System] Transition from 'SteamVRSystemState_Ready' to 'SteamVRSystemState_NotReady'.
Thu Dec 09 2021 10:14:18.056373 - [Status Alert] SteamVR Fail (-301)
Thu Dec 09 2021 10:14:19.053212 - [System] Transition from 'SteamVRSystemState_NotReady' to 'SteamVRSystemState_Ready'.
Thu Dec 09 2021 10:14:22.054735 - [System] Transition from 'SteamVRSystemState_Ready' to 'SteamVRSystemState_NotReady'.
Thu Dec 09 2021 10:14:22.055685 - [Status Alert] SteamVR Fail (-301)
Thu Dec 09 2021 10:14:23.058629 - [System] Transition from 'SteamVRSystemState_NotReady' to 'SteamVRSystemState_Ready'.
Thu Dec 09 2021 10:14:31.056024 - [System] Transition from 'SteamVRSystemState_Ready' to 'SteamVRSystemState_NotReady'.
Thu Dec 09 2021 10:14:31.057433 - [Status Alert] SteamVR Fail (-301)
Thu Dec 09 2021 10:14:32.054043 - [System] Transition from 'SteamVRSystemState_NotReady' to 'SteamVRSystemState_Ready'.
Thu Dec 09 2021 10:14:49.053145 - [System] Transition from 'SteamVRSystemState_Ready' to 'SteamVRSystemState_NotReady'.
Thu Dec 09 2021 10:14:49.054092 - [Status Alert] SteamVR Fail (-301)
Thu Dec 09 2021 10:14:50.052793 - [System] Transition from 'SteamVRSystemState_NotReady' to 'SteamVRSystemState_Ready'.
Thu Dec 09 2021 10:16:12.044295 - [System] Transition from 'SteamVRSystemState_Ready' to 'SteamVRSystemState_NotReady'.
Thu Dec 09 2021 10:16:12.045894 - [Status Alert] SteamVR Fail (-203)
Thu Dec 09 2021 10:16:35.433159 - [Status Alert] SteamVR Fail (-203)
Thu Dec 09 2021 10:16:36.033983 - [Status Alert] Headset Error (-202)
Thu Dec 09 2021 10:16:37.233044 - [Status Alert] Headset Error (-202)
Thu Dec 09 2021 10:16:38.050096 - [System] Transition from 'SteamVRSystemState_NotReady' to 'SteamVRSystemState_Ready'.
Thu Dec 09 2021 10:16:41.503419 - [System] Transition from 'SteamVRSystemState_Ready' to 'SteamVRSystemState_ShutdownRequested'.
Thu Dec 09 2021 10:16:41.516482 - [System] Quit gracefully: Waiting for process quitting...
Thu Dec 09 2021 10:16:42.877738 - [System] Transition from 'SteamVRSystemState_ShutdownRequested' to 'SteamVRSystemState_Shutdown'.
Thu Dec 09 2021 10:16:42.877771 - [Audio] Audio shutdown!
Thu Dec 09 2021 10:16:43.685008 - Drops over entire run:- 374 single frame- 72 2 frame- 38 3 frame- 45 4 or more- Total 9490 in 42684 frames

I am having this issue with Half Life Alyx since summer 2021. I spoke to Steam support. They told me to downgrade. I thought the issue was fixed, but now I started playing the game again, and it still persists!

@quantumac I can see you have perfectly described the issue I face. Did you find any solutions?

@mato6666663 No solutions yet. I'm just trying to provide as much context as possible for those tasked with fixing the issue. Hopefully that will be sooner rather than later.

The (-203) error persists with SteamVR [beta] 1.21.4.

I saw the same issues with same titles using the same steps I've outlined above. No change.

OS: Ubuntu 20.04 (Linux)
SteamVR [beta]: 1.21.4
NVIDIA driver: 495.44
GPU: GTX 1080
VR Headset: Valve Index

Can confirm, that the -203 crash still persists in the latest SteamVR beta 1.21.4

However i also have an interesting finding. I had to make a few test apps with OpenGL and OpenVR, and wouldn't you know it, my apps get -203 too, except this time i am 100% positive it's not the app or the driver, i didn't get a crash/error/exception from either. Here is the interesting part tho: my app and driver get spammed with VREvent_ActionBindingReloaded events, no idea what's spawning them yet, but my app and drivers are set to ignore them for now. Never seen this event before, it's data is presumably a process, never seen it processed by other open apps/drivers.
Oh and the weirdest thing is that this event is not spammed on windows.

OS: Ubuntu 20.04.3 LTS
SteamVR [beta]: 1.21.4
NVIDIA driver: 495.44
GPU: RTX 3060
VR Headset: Valve Index

Wife and I are encountering the same issue on our respective computers/headsets. We crashed playing Phasmophobia. We crashed at different times, but in nearly the same place in game, which makes me wonder if what was rendered is relevant. -203 error for both, headset turns off, same console spam as others are reporting. Been having this issue for a while now and no amount of tinkering or updating has helped, including wiping/reinstalling steam and re-setting up my playspace.

OS: Kubuntu 21.10
SteamVR [beta]: 1.21.4 (& latest nonbeta)
NVIDIA driver: 470.74
GPU: 2080 TI
VR Headset: Valve Index

Edit: Same issue presented in Bean Stalker, but not until after 30 minutes of play and shortly after loading a new map, whereas Phasmophobia is within the first 30 (or the first few seconds if the new camp map).

Update 12/17: Upgraded both our rigs to 495.44. Phas didn't cause a 203 during a quick test solo, but crashed once everyone loaded in on multiplayer. Beat saber never seems to trigger it, nor does bean stalker.

There was a certain VR game that kept on crashing, throwing this 203 error after some time, no matter what Nvidia driver version I was using. Seems to go away after performing a quick test since updating "Proton Experimental" to the newest version and running the game under this Proton version.

OS : 5.10.84-1-MANJARO
SteamVR[Beta]: 1.21.4
NVIDIA Driver : 495.44
GPU : 2060 Super
VR Headset : Vive Pro

@eighthourblink I can reproduce the error in native Linux apps as well as Proton Experimental and other versions of Proton, with both the 470 and 495 NVIDIA drivers. It seems to more likely to occur when there's a lot of CPU load, but not always.

@quantumac For me it feels like its more memory bound, there is a CPU load spike, but its caused by the crash not the other way around.

I've still not had a 203 error since switching from Async to LinuxVulkanAsync

I've still not had a 203 error since switching from Async to LinuxVulkanAsync

Implemented these fixes on my my computer as well as my wife's. I crashed immediately upon entering a map in phasmo, she didn't (for the minute she was in the map before quitting).

Both using Proton Experimental, SteamVR nonbeta.

Changing to @mSparks43's suggestions has fixed my sudden crashes to SteamVR, was almost instantaneous crashing without it. Haven't used it enough to confirm this has been a conclusive fix for me.

Proton 6.3-8
SteamVR: non-beta
GPU: GTX 1080
Driver: Nvidia 495.44
OS: PopOS 21.04
Kernel: 5.15
Oculus Rift CV1 & OpenHMD (thaytan branch)

Edit: Spoke too soon, have to play the, "restart steam until it works game", again.

I've still not had a 203 error since switching from Async to LinuxVulkanAsync

LinuxVulkanAsync is on by default on Linux, and i still get -203 crashes same as before.
My latest -203 crash was from just running SteamVR without any apps (even SteamVR Home), it crashed after just running for a few minutes when i was looking at my desktop. It's really inconsistent though, after that crash i restarted it and it did not crash under the same circumstances.

OS: Ubuntu 20.04.3 LTS
Steam Build [beta]: Dec 16 2021, at 22:39:26
SteamVR [beta]: 1.21.4
NVIDIA driver: 495.44
GPU: RTX 3060
VR Headset: Valve Index

is on by default on Linux, and i still get -203 crashes same as before.

Maybe it is now, maybe its disabled by disableasync and needs turning back on. maybe it does nothing and I just have high enough fps not to need it.

When I posted afaict
disableasync stopped the 203 errors as others reported
enablevulkanasync stopped the unusable stuttery mess caused by disableasync.

Not had it since, still get them reliably if i remove the disableasync line. so not fixed, but work aroundable for me.

is on by default on Linux, and i still get -203 crashes same as before.

Maybe it is now, maybe its disabled by disableasync and needs turning back on. maybe it does nothing and I just have high enough fps not to need it.

When I posted afaict disableasync stopped the 203 errors as others reported enablevulkanasync stopped the unusable stuttery mess caused by disableasync.

Not had it since, still get them reliably if i remove the disableasync line. so not fixed, but work aroundable for me.

HA! disableAsync is different though, or more like its gone. At some point it got removed from the list of all default SteamVR settings -> it could still be doing something and it missing a default could potentially be a cause to some issues as well... I'll need to test this a bit.

some point it got removed from the list of all default SteamVR settings

from the settings menu it moved to per application settings a few months back.
but since the settings menu doesnt work for me at all i have to edit the config with a text editor.

some point it got removed from the list of all default SteamVR settings

from the settings menu it moved to per application settings a few months back. but since the settings menu doesnt work for me at all i have to edit the config with a text editor.

That's the thing though, you see applications have access to the same IVRSettings API drivers do and disableAsync is still present in the OpenVR API vrsettings key list (because this API didn't get updated for almost a year now...), now why is this a problem? Well you see to catch errors when using IVRSettings one needs to pass a pointer to an output variable which will get filled with the error code, now here is the kicker: it's not needed to use this API xD

Now that doesn't mean the app will get garbage, the IVRSettings API will return sane defaults in case of error, but those still might not be ideal.

So in conclusion ¯\_(ツ)_/¯ its a mess

Edit: Spoke too soon, have to play the, "restart steam until it works game", again.

Are you saying you're experiencing the same phenomenon as okawo80085 seems to be, in which sometimes it'll crash and sometimes it'll just work solid forever?

This issue persisting for so long is definitely the nail in the coffin for me, going to be buying an AMD GPU next time i'm in the market for upgrading.

Getting the exact same errrors in my vrmotnitor log as the above Large number of events this frame caused the poll loop to exit without draining and then a prompt 203/202 error code a few seconds later

Arch, base kernel 5.15.11-arch2-1
latest nvidia drivers
RTX 2070 Super

Replying to https://github.com/ValveSoftware/SteamVR-for-Linux/issues/452#issuecomment-1002852365

Don't bother? You'll get the same behavior on AMD. Its a general SteamVR on Linux issue, everyone gets excessive binding load events, which don't get processed and end up killing SteamVR eventually. Why? No clue, it literally should not be an issue.

Edit: Spoke too soon, have to play the, "restart steam until it works game", again.

Are you saying you're experiencing the same phenomenon as okawo80085 seems to be, in which sometimes it'll crash and sometimes it'll just work solid forever?

I don't know about "solid forever" but it did seem to be fine for hours on end and other times will crash intermittently, sometimes within second (when starting the room setup). I think it could be worse on the 495 drivers but that's probably cognitive bias. I haven't had a long session without it crashing recently so I'm going to say 2 thumbs down on the current experience, doesn't bother me too much just have to save the game frequently and restart steam & SteamVR multiple times until it's playable.

Please stop using this as a random discussion forum and spamming notifications for people following. This is for bug reports only.

So I noticed two errors on repeat:
The one about
filter 'z' in click_button_actions_legacy_17_user_hand_left_input_thumbstick (and the right hand equivalent)
Which seems to stem from
===== knuckles: state=3, empty, uri=file:~/.local/share/Steam/steamapps/common/SteamVR/drivers/indexcontroller/resources/input/legacy_bindings_index_controller.json

and
===== indexhmd: state=4, NOT empty, uri=file:~/.local/share/Steam/steamapps/common/SteamVR/resources/config/legacy_bindings_generic_hmd.json

I renamed the legacy_bindings_index_controller.json to .bak and restarted steamVR. The logs produced the following new error:
Spinning up controllerbinding because binding_load_failed was sent to bindingui/overlay
But I am no longer getting bombarded by the z filter error. Things seem a little quicker to load in game too, but it's anecdotal.
I started Phasmophobia and loaded into the campsite multiple times without an error, something that reliably 203s me.

I tried to rename /legacy_bindings_generic_hmd.json as well but it caused showstopping problems.

TLDR, can others test and report back:
Rename ~/.local/share/Steam/steamapps/common/SteamVR/drivers/indexcontroller/resources/input/legacy_bindings_index_controller.json` to anything else, and see if you still -203.

TLDR, can others test and report back: Rename ~/.local/share/Steam/steamapps/common/SteamVR/drivers/indexcontroller/resources/input/legacy_bindings_index_controller.json` to anything else, and see if you still -203.

I renamed the .json file, had an immediate crash to desktop error in half life alyx almost immediately, did the restart everything musical chairs game a few times and then it was fine for approx 30 minutes until it came up with the -203 error agai.

This hasn't helped in my situation unfortunately, good try though!

The only other thing I did was try another binding from within the game. It crashed after that (but before renaming the json) so I didn't include it in the report. Figured maybe an old community-contributed profile may work around a bug complaining that something's missing.

Replying to [#452 (Comment)](https://github.com/ValveSoftware/SteamVR-for-Linux/issues/452#issuecomment-1003410068)

I tried that, and well its not that simple, I have more devices and i get like 5 different legacy binding loads from different devices depending on which one is set as the active one....
Last time i had enough time to test it i missed 1 controller legacy binding file, although even with 1 binding still missing loads it got better, "Half-Life: Alyx" didn't crash for way longer. Feels like a step in the right direction, still needs more testing though, for example applications that rely on legacy bindings might miss behave (e.g. VRChat).

I'm out of time for the week, so if anyone is up for testing that'd help a lot!

From my limited testing this week:

• All legacy bindings generate excessive binding loads
• There is such a thing as default legacy binding which get assigned to some devices, if the said devices don't have legacy bindings explicitly defined in their input profiles
• Only the currently used devices will load their legacy bindings, so if the user only has an HMD and controllers active, those will try to load legacy bindings
• It seems like literally all legacy bindings miss behave like that, but again more testing needed.

@okawo80085
Any chance you verified you got the same error as I did at some point about "spinning up controllerbinding", or did the one config you missed prevent that?

I still haven't had a crash since implementing the steps I listed above, I'm hoping the hard-coded "controllerbinding" is formed in such a way as to be exempt from this problem.

Ultimately it's looking like the fix is as simple as valve preventing the binding load infinite loop, at least for this case so it can error gracefully and be done with it.

@earldbjr I'm not really sure, I ran out of time and didn't go through the entirety of the log. But until I connected a new device type (which still had legacy bindings) I didn't see any serious errors.

Again I need to test it more, in my last half-life alyx test I didn't notice that I still had 3 device types with legacy bindings still active.

I need to disable all legacy bindings and try again really.

That lines up with my experience as well. Turn on vr but not knuckles and no relevant errors. As soon as a controller light goes green the flood starts.

I finally weeded out all legacy bindings (including controllers), no more infinite failed binding load loops! 🥳

I used beat saber for testing this time, before it usually crashed like once in a few hours, so far its been up 2 hours without any crashes. It also feels a bit snappier, but thats most likely me just imaging things.

Gotta note this tho, I had to manually load new bindings for beat saber using the legacy binding UI, I broke the default... So yeah gotta fix that xD

I'll keep a few heavier things running to stress test it more, hopefully it gets better.

It also feels a bit snappier, but thats most likely me just imaging things.

I noticed this as well. It's easy to dismiss as bias, but it there is a logic to it. I noticed if I let those errors go for even 10 seconds I could stop steamvr and the console would continue to catch up for a long time.

Can you list all the files you disabled?

Can you list all the files you disabled?

No, there were too many.

Also further testing doesn't look good... Half Life: Alyx crashed with -203 on loading a save... Could be caused by my mess of devices, I'll try to disconnect some.

Ok after disconnecting all the trackers i had lying around it started fine and the default binding for controllers loaded fine so thats good (but since HLA doesn't use legacy bindings i expected that), didn't stutter when loading a save.

Lets see how long it stays stable. (I can't really play the game rn, so if it doesn't crash i'll try that a few hours later, before HLA usually crashed after 40 minutes)

And it crashed after an hour... It did perform a bit better, but it still crashes so back to square 1...

Was the error the same?
Any instances of "Large number of events this frame caused the poll loop to exit without draining"?

Any instances of "Large number of events this frame caused the poll loop to exit without draining"?

None.

Was the error the same?

Yes, preceded by a few second hang of my DE, like every other time.

Since I had some free time, I was messing around trying to reproduce -203 crashes, and I think I got it.
After attaching gdb to every process spawned by SteamVR, and wasting like 4 hours to catch natural -203s in "Half-Life: Alyx": I found a pattern. The only process that crashes is vrcompositor, while literally every other process keeps running like normal... including the game (at like 10fps though)...
Nonetheless the interesting part is that if you kill the vrcompositor process with SIGSEGV it produces a -203 crash, killed it a few times with different apps to verify the -203 crash behaves the same way a natural -203 would and it does.

Now a better question is: why is vrcompositor getting seg faults? No idea, I didn't get that far yet, but its most likely a bad memory write.

OS: Ubuntu 20.04.3 LTS
Kernel: 5.11.0-43-generic
DE: Gnome
Steam version: Built Dec 16 2021, at 22:39:26
SteamVR version: 1.21.4 [beta]
Proton version: Proton Experimental
GPU: RTX 3060
GPU driver: 495.46

why is vrcompositor getting seg faults? No idea, I didn't get that far yet, but its most likely a bad

I'd say something with asynchronous reprojection, given it doesn't do it if you disable async reprojection, doesn't do it if you use an old driver before they added whatever was needed for async repoj, and can be made to reliably do it with async reproj enabled on nvidia 470+.

of course, there can also be more than one way to crash it.

Replying to [#452 (Comment)](https://github.com/ValveSoftware/SteamVR-for-Linux/issues/452#issuecomment-1005027441)

Yeah nvidia's drivers is my bet too, not sure if async reprojection is the root cause of this, but i will try to fix it nonetheless.

HA! I finally digged up a stack trace of the vrcompositor crash

$ coredumpctl info
           PID: 116073 (vrcompositor)
           UID: 1000 (okawo)
           GID: 1000 (okawo)
        Signal: 6 (ABRT)
     Timestamp: Tue 2022-01-04 22:28:04 EET (2min 20s ago)
  Command Line: /home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor
    Executable: /home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor
 Control Group: /user.slice/user-1000.slice/[email protected]/apps.slice/apps-org.gnome.Terminal.slice/vte-spawn-083c5ad7-1742-4222-aa7c-0f527229a421.scope
          Unit: [email protected]
     User Unit: vte-spawn-083c5ad7-1742-4222-aa7c-0f527229a421.scope
         Slice: user-1000.slice
     Owner UID: 1000 (okawo)
       Boot ID: 1e8bf646c8cb4853b4ae6167e3a21000
    Machine ID: 48b93e9f9d08410ab31494403c4441bc
      Hostname: okawo
       Storage: /var/lib/systemd/coredump/core.vrcompositor.1000.1e8bf646c8cb4853b4ae6167e3a21000.116073.1641328084000000000000.lz4
       Message: Process 116073 (vrcompositor) of user 1000 dumped core.
                
                Stack trace of thread 116132:
                #0  0x00007f130479318b __GI_raise (libc.so.6 + 0x4618b)
                #1  0x00007f1304772859 __GI_abort (libc.so.6 + 0x25859)
                #2  0x000055d388dbd233 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x53233)
                #3  0x000055d388e9b495 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x131495)
                #4  0x000055d3890c61e0 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x35c1e0)

Not very useful still, but at least now there is a chance that this is actually not only nvidia's fault

And here is another one, this one is from a Hlaf-Life: Alyx crash on level transition, the last one was from VRChat.
This time it got killed by a SIGSEGV after a mov instruction. Together with the last crash this indicates that this thing can crash in more than one way (i.e. more pain in the @$%).

$ coredumpctl info
           PID: 11529 (vrcompositor)
           UID: 1000 (okawo)
           GID: 1000 (okawo)
        Signal: 11 (SEGV)
     Timestamp: Tue 2022-01-04 23:07:03 EET (48s ago)
  Command Line: /home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor
    Executable: /home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor
 Control Group: /user.slice/user-1000.slice/[email protected]/gnome-launched-steam.desktop-9811.scope
          Unit: [email protected]
     User Unit: gnome-launched-steam.desktop-9811.scope
         Slice: user-1000.slice
     Owner UID: 1000 (okawo)
       Boot ID: 74d4298785fb4c4da3f9876b4a667a3b
    Machine ID: 48b93e9f9d08410ab31494403c4441bc
      Hostname: okawo
       Storage: /var/lib/systemd/coredump/core.vrcompositor.1000.74d4298785fb4c4da3f9876b4a667a3b.11529.1641330423000000000000.lz4
       Message: Process 11529 (vrcompositor) of user 1000 dumped core.
                
                Stack trace of thread 11588:
                #0  0x0000555a7fed6f40 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x22ff40)
                #1  0x0000555a7fd28f79 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x81f79)
                #2  0x0000555a7fd33288 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x8c288)
                #3  0x0000555a7fd340b9 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x8d0b9)
                #4  0x0000555a7fd35d54 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x8ed54)
                #5  0x0000555a7fd9cb41 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0xf5b41)
                #6  0x0000555a7fd9ee03 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0xf7e03)
                #7  0x0000555a7fda2f10 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0xfbf10)
                #8  0x0000555a7fdd6919 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x12f919)
                #9  0x00007ffbf869d609 start_thread (libpthread.so.0 + 0x9609)
                [#10](/issue/ValveSoftware/SteamVR-for-Linux/10) 0x00007ffbf8475293 __clone (libc.so.6 + 0x122293)

More stack traces of crashes would help a lot! (you can get one by running coredumpctl info right after a -203 crash, provided you have coredumpctl installed of course)

FYI: just upgraded to the NVIDIA 495.46 driver (from the 495.44 driver) and I'm running the SteamVR 1.21.4 beta. No change in behavior.

Got one today, loading into a phas map:

           PID: 1203989 (vrcompositor)
           UID: 1000 (me)
           GID: 1000 (me)
        Signal: 6 (ABRT)
     Timestamp: Wed 2022-01-05 19:53:58 EST (33s ago)
  Command Line: /home/me/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrcompositor
    Executable: /home/me/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrcompositor
 Control Group: /user.slice/user-1000.slice/[email protected]/app.slice/app-steam-218620d9e8284f63a8ed13895a130046.scope
          Unit: [email protected]
     User Unit: app-steam-218620d9e8284f63a8ed13895a130046.scope
         Slice: user-1000.slice
     Owner UID: 1000 (me)
       Boot ID: 9cbcca472eeb460684bf8b809770cbf3
    Machine ID: 30a0b826d3c1458090934ae402c39a8b
      Hostname: vulcan
       Storage: /var/lib/systemd/coredump/core.vrcompositor.1000.9cbcca472eeb460684bf8b809770cbf3.1203989.1641430438000000.zst
       Message: Process 1203989 (vrcompositor) of user 1000 dumped core.
                
                Stack trace of thread 1204039:
                #0  0x00007f185e237fbb __GI_raise (libc.so.6 + 0x40fbb)
                #1  0x00007f185e21d864 __GI_abort (libc.so.6 + 0x26864)
                #2  0x00005585f24ce619 n/a (/home/me/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x4d619)
                #3  0x00005585f25a4445 n/a (/home/me/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x123445)
                #4  0x00005585f27a0bf0 n/a (/home/me/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x31fbf0)

Final lines from vrcompositor prior to crash:

vrmonitor
Wed Jan 05 2022 19:45:15.214188 - Large number of events this frame caused the poll loop to exit without draining
vrmonitor
Wed Jan 05 2022 19:45:15.237252 - [Status Warning Added LHR-94615D5A Controller(4)] Searching...
vrmonitor
Wed Jan 05 2022 19:45:15.980776 - Large number of events this frame caused the poll loop to exit without draining
vrmonitor
Wed Jan 05 2022 19:45:16.236334 - [Status Warning Removed LHR-94615D5A Controller(4)] Searching...
vrmonitor
Wed Jan 05 2022 19:45:16.236739 - [Status Warning Added LHR-BEB7845D Controller(5)] Searching...
vrmonitor
Wed Jan 05 2022 19:45:18.236590 - [Status Warning Removed LHR-BEB7845D Controller(5)] Searching...
vrmonitor

// These lines repeat probably 20x. Looks like probably an obstructed lighthouse, which would make sense.
Wed Jan 05 2022 19:45:44.236152 - [Status Warning Added LHR-94615D5A Controller(4)] Searching...
vrmonitor
Wed Jan 05 2022 19:45:51.236707 - [Status Warning Removed LHR-94615D5A Controller(4)] Searching...
vrmonitor


Wed Jan 05 2022 19:53:58.327732 - [System] Transition from 'SteamVRSystemState_Ready' to 'SteamVRSystemState_NotReady'.
vrmonitor
Wed Jan 05 2022 19:53:58.362882 - [Status Alert] SteamVR Fail (-203)
vrmonitor
Wed Jan 05 2022 19:54:14.256562 - [Status Alert] SteamVR Fail (-203)
vrmonitor
Wed Jan 05 2022 19:54:18.366851 - [Status Warning Added LHB-D515CBB6 Base Station(6)] Searching...
vrmonitor
Wed Jan 05 2022 19:54:18.389389 - [Status Alert] SteamVR Fail (-203)
vrmonitor
Wed Jan 05 2022 19:54:23.273964 - [Status Alert] SteamVR Fail (-203)
vrmonitor
Wed Jan 05 2022 19:54:44.183630 - [System] Transition from 'SteamVRSystemState_NotReady' to 'SteamVRSystemState_ShutdownRequested'.
vrmonitor
Wed Jan 05 2022 19:54:44.478191 - [System] Quit gracefully: Waiting for process quitting...
vrmonitor
Wed Jan 05 2022 19:54:46.826196 - [System] Transition from 'SteamVRSystemState_ShutdownRequested' to 'SteamVRSystemState_Shutdown'.
vrmonitor
Wed Jan 05 2022 19:54:46.826562 - [Audio] Audio shutdown!

Replying to [#452(Comment)](https://github.com/ValveSoftware/SteamVR-for-Linux/issues/452#issuecomment-1006198779)

I finally had a minute to review your crash dump. In your case it seems to be catching an abort, which is most likely the result of an assert, weird thing is that the stack trace from vrcompositor shows that the last few calls were: encoding conversion, log, and right before the abort and raise calls it was executing vr::CSystemLayer::FreeRenderModel(std::string const&), the abort signal seems to originate from the last call in vr::CSystemLayer::FreeRenderModel(std::string const&).

All very interesting considering that so far i only got aborts from CThreadWatchdogManager::EvaluateWatchdogs(void), which (if im reading the assembly correctly) literally has 1 call instruction to abort and thats it, while your crash starts at vr::CSystemLayer::FreeRenderModel(std::string const&) which calls whatever _Unwind_Resume is after unlocking a mutex and that can call abort if a string compare fails and if another compare fails.

The saddest part is that i doubt this is fixable on our side, aside from some crazy voodoo re-assembly magic, which im pretty sure no one here is willing to do... yet...

My other crash seem to happen in CVulkanVRRenderer::UpdateTexture(CVulkanVRRenderer *__hiden this, VRRenderer::TextureBase*, const void*, bool) on what i think is a void* pointer cast to a function before it's about to be called, which is extremely weird since this method (i assume) is called every frame and its fine for hours. Good chance im wrong on this, its not exactly easy to understand assembly when the crash happens in the middle of a bunch moves and pushes right before a call on the result of one of the moves with some offset.

Thanks for breaking those down. It's unfortunate that we've had radio silence for ~6 months from valve.

Anyone else have a dump? Seems like the cause is all over the place, more data may make for a clearer picture.

looks like a new nvidia driver was released today NVIDIA 510.39.01 any one able to test if -203 still happens with the latest driver?

looks like a new nvidia driver was released today NVIDIA 510.39.01 any one able to test if -203 still happens with the latest driver?

Can you link it? I can't find it on their website or in my distro's repos

https://forums.developer.nvidia.com/c/gpu-graphics/announcements-and-news/146

https://forums.developer.nvidia.com/c/gpu-graphics/announcements-and-news/146

Thanks, will test it in a few days.

Same issue for me. 100% replicable if I try to open the desktop viewer inside of Steam VR, specifically only when trying to see my 4k display in flipped portrait mode. This issue occurs often during gameplay at random points. I'm assuming there might be too high of a load on my GPU. I have a multi monitor setup as well.

System Information:

Windows 11
SteamVR version: Tested on beta 1.21.5 and also on the stable build
Steam client version: 163967812
Opted into Steam client beta?: Yes
Graphics driver version: 497.29

RTX 3070
Ryzen 9 5900x
32GB DDR4-3600mhz

Main monitor on 3440x1440p, second monitor is at 4k res

You're encountering this on Windows?

Both the stations I'm testing on are also multimonitor.
2 monitors + headset
3monitors + headset
Both have a 2080TI, though, and the problem occurs most often during intensive loading rather than intensive graphics.

I also have 3 monitors (1xfull hd, 1xquad K, 1x4k) and sometimes encounter this error while playing half life alyx

You're encountering this on Windows?

Both the stations I'm testing on are also multimonitor. 2 monitors + headset 3monitors + headset Both have a 2080TI, though, and the problem occurs most often during intensive loading rather than intensive graphics.

Yeah, it happens to me on Win 11. It never happened with my Oculus Quest 2 with link. Ever since I got my Index I got this issue.

Also intensive loading is a good observation. Either way, it happens consistently when trying to display my 4K display - so I assumed it was just my GPU getting overloaded. My fans do ramp up a lot when it happens, but I'm definitely not overheating any parts.

I don't have any 4k displays so you're probably in a better place than me to test... try disabling all but your smallest monitor, and see if it crashes (or crashes as quickly).

I got 2 new Half-Life: Alyx segfaults, both crashes are from SteamVR 1.21.5, but funnily enough the last one was not from vrcompositor but rather from vrwebhelper. Gotta mention though, until I implemented the fix suggested by @kisak-valve in [vrwebhelper.sh affected by steam-for-linux#7935 #465 (Comment)](https://github.com/ValveSoftware/SteamVR-for-Linux/issues/465#issuecomment-1012386712) I didn't have a dashboard in the last beta update, my first crash happen without that fix in place.

First, the vrcompositor crash:

$ coredumpctl info
           PID: 47005 (vrcompositor)
           UID: 1000 (okawo)
           GID: 1000 (okawo)
        Signal: 11 (SEGV)
     Timestamp: Thu 2022-01-13 01:13:09 EET (22h ago)
  Command Line: /home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor
    Executable: /home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor
 Control Group: /user.slice/user-1000.slice/[email protected]/gnome-launched-steam.desktop-35118.scope
          Unit: [email protected]
     User Unit: gnome-launched-steam.desktop-35118.scope
         Slice: user-1000.slice
     Owner UID: 1000 (okawo)
       Boot ID: e89e283e15cc493896e745bab2c69710
    Machine ID: 48b93e9f9d08410ab31494403c4441bc
      Hostname: okawo
       Storage: /var/lib/systemd/coredump/core.vrcompositor.1000.e89e283e15cc493896e745bab2c69710.47005.1642029189000000000000.lz4
       Message: Process 47005 (vrcompositor) of user 1000 dumped core.
                
                Stack trace of thread 47056:
                #0  0x000055bac16c5940 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x204940)
                #1  0x000055bac153aea2 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x79ea2)
                #2  0x000055bac15451d8 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x841d8)
                #3  0x000055bac1546009 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x85009)
                #4  0x000055bac1547ca4 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x86ca4)
                #5  0x000055bac15a9d78 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0xe8d78)
                #6  0x000055bac15ac053 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0xeb053)
                #7  0x000055bac15affae n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0xeefae)
                #8  0x000055bac15e2839 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x121839)
                #9  0x00007f762c967609 start_thread (libpthread.so.0 + 0x9609)
                [#10](/issue/ValveSoftware/SteamVR-for-Linux/10) 0x00007f762c73f293 __clone (libc.so.6 + 0x122293)
                
                Stack trace of thread 47005:
                #0  0x00007f762c6fd3bf __GI___clock_nanosleep (libc.so.6 + 0xe03bf)
                #1  0x00007f762c703047 __GI___nanosleep (libc.so.6 + 0xe6047)
                #2  0x00007f762c7359bf usleep (libc.so.6 + 0x1189bf)
                #3  0x000055bac159b432 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0xda432)
                #4  0x000055bac15a1acc n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0xe0acc)
                #5  0x000055bac1520270 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x5f270)
                #6  0x00007f762c6440b3 __libc_start_main (libc.so.6 + 0x270b3)
                #7  0x000055bac15213a1 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x603a1)

This one isn't really interesting to be honest, appears to be the same sigsegv on oCVulkanVRRenderer::UpdateTexture(CVulkanVRRenderer *__hiden this, VRRenderer::TextureBase*, const void*, bool) as before.

Second, the vrwebhelper crash:

$ coredumpctl info
           PID: 45800 (vrwebhelper)
           UID: 1000 (okawo)
           GID: 1000 (okawo)
        Signal: 11 (SEGV)
     Timestamp: Fri 2022-01-14 01:16:02 EET (5s ago)
  Command Line: ./vrwebhelper
    Executable: /home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/vrwebhelper/linux64/vrwebhelper
 Control Group: /user.slice/user-1000.slice/[email protected]/gnome-launched-steam.desktop-15614.scope
          Unit: [email protected]
     User Unit: gnome-launched-steam.desktop-15614.scope
         Slice: user-1000.slice
     Owner UID: 1000 (okawo)
       Boot ID: 38d0b5421dd44ccbac5e324e294451ef
    Machine ID: 48b93e9f9d08410ab31494403c4441bc
      Hostname: okawo
       Storage: /var/lib/systemd/coredump/core.vrwebhelper.1000.38d0b5421dd44ccbac5e324e294451ef.45800.1642115762000000000000.lz4
       Message: Process 45800 (vrwebhelper) of user 1000 dumped core.
                
                Stack trace of thread 46292:
                #0  0x0000000000415f90 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/vrwebhelper/linux64/vrwebhelper + 0x15f90)
                #1  0x0000000000418cd2 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/vrwebhelper/linux64/vrwebhelper + 0x18cd2)
                #2  0x0000000000419086 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/vrwebhelper/linux64/vrwebhelper + 0x19086)
                #3  0x00000000005337ae n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/vrwebhelper/linux64/vrwebhelper + 0x1337ae)
                #4  0x00007fbdb40d7840 n/a (n/a + 0x0)

This is interesting because I never had vrwebhelper be the one to go down with a segfault, calls leading up to the segfault seem pretty normal too, crashed on a memory move just like every other segfault so far, but still something just feels off :/

This made think, what else is similar between the crashes, not just these 2, all of my Hlaf-Life: Alyx crashes? And turns out there is something similar: scene loads, all crashes happen on second or third scene loads! Now the weird thing is that the game itself does not crash, only SteamVR does, now why is that? What could be so different between scene loads in the game in terms of texture updates that it crashes SteamVR? And then it hit me! Half-Life: Alyx has a different animation submited to the flat screen window, now that could be affecting the compositor update texture calls... except that its most likely a proton/Half-Life: Alyx specific issue...

I guess I need to find a new game that crashes with -203 reliably :/

Replying to https://github.com/ValveSoftware/SteamVR-for-Linux/issues/452#issuecomment-1012579862

Interesting, I have a 4k display too and can confirm that crashes occur most often during intensive loading rather than intensive graphics.

Ok so far we have crashes resulting in a -203 from multiple processes, throwing a few different signals, mostly but not exclusively during intensive loading. Affects Windows and Linux, Beta and nonbeta steamvr, NVidia graphics drivers newer than 465.*

Am I missing any similarities?

I've been running with the "disableAsync" : true, "enableLinuxVulkanAsync" : true for a while now. Definitely not a fix since I've had two crashes. But it was over 40 hours of playing, so it's been very rare. Half of that time were put into playing games that didn't give me any issues anyway (Groove Gunner, Synth Riders). But the other two were more problematic (Borderlands 2 VR, Fallout 4 VR). BL2VR was extremely problematic before and I've put 10 hours into it now with the only crashes being the game itself.

The two remaining -203s were one after an exit from FO4. And one after a death that crashed exactly at the start of loading. Both instances still show the same as VR. The vr compositor crashes and it happens on occasions with lag spikes. This is an improvement over what it was before, when even unstable framerates would crash the compositor.

Whether the settings are even contributing to reduction improvement is hard to say. It may just be that steamvr or the drivers are improving. This is definitely a factor because back when we got async for nvidia, a compositor crash required a power cycle of the headset to make it display again and this is no longer needed.

And this is all just stability. There is still the issue that the "asynchronous" reprojection doesn't feel very asynchronous to me. It still obliterates the actual rendered framerate. Which is not always a good sacrifice for smooth rotational head tracking.

Anyway, good to see things having improved a bit, but still a long way to go.

Oh, and I forgot to mention that I noticed this crash started occurring after I upgraded my HDD to SSD. Before, my Windows installation was on the HDD. All my games, as well as the Windows installation are on SSD now. Is this something that could be related? I have read some comments by other people experiencing this issue too.

That would be wild. Both our rigs are using nvme.

My setup uses nvme ssds too, but that being the reason could only mean that the kernel ssd driver is miss behaving, which afaik is not the case.

Just to be safe though, i'm on kernel 5.13.0-25-generic.

Found a new way to consistently reproduce the -203 crash by the watchdog manager thread eval method, with nothing running at all, not even SteamVR Home, just plain compositor.

So Valve Index has this funny refresh rate setting, and turns out i had mine at 90hz this entire time, so i decided to switch to 144hz and wouldn't you know it, almost an instant crash... right after i connected my controllers.
Let me reiterate, there is no crash until i connect controllers, nothing seems wrong, tracking is smooth and all, but as soon as i turn on my controllers and they connect: boom, DE hangs for a bit and SteamVR crashes with -203 (caused by the same ThreadWatchdogManager::EvaluateWatchdogs() method every time, according to the stack trace). Furthermore reading into that method's assembly (also considering the exit signal) it looks like this particular crash is caused by an unhandled exception...

Upside is that bumping my refresh rate to 144hz almost completely fixed #21 for me.

coredump:

$ coredumpctl info
           PID: 46614 (vrcompositor)
           UID: 1000 (okawo)
           GID: 1000 (okawo)
        Signal: 6 (ABRT)
     Timestamp: Mon 2022-01-31 21:06:24 EET (13h ago)
  Command Line: /home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor
    Executable: /home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor
 Control Group: /user.slice/user-1000.slice/[email protected]/gnome-launched-steam.desktop-8423.scope
          Unit: [email protected]
     User Unit: gnome-launched-steam.desktop-8423.scope
         Slice: user-1000.slice
     Owner UID: 1000 (okawo)
       Boot ID: a3fa7b168ba5425fba65785a6395e24c
    Machine ID: 48b93e9f9d08410ab31494403c4441bc
      Hostname: okawo
       Storage: /var/lib/systemd/coredump/core.vrcompositor.1000.a3fa7b168ba5425fba65785a6395e24c.46614.1643655984000000000000.lz4
       Message: Process 46614 (vrcompositor) of user 1000 dumped core.
                
                Stack trace of thread 46669:
                #0  0x00007f85826e318b __GI_raise (libc.so.6 + 0x4618b)
                #1  0x00007f85826c2859 __GI_abort (libc.so.6 + 0x25859)
                #2  0x0000560dacfdf619 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x4d619)
                #3  0x0000560dad0b5445 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x123445)
                #4  0x0000560dad2b1bf0 n/a (/home/okawo/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor + 0x31fbf0)

Headset: Valve Index
Controllers: Vive Wands
SteamVR version: 1.21.6 [beta]
OS: Ubuntu 20.04.3 LTS
Kernel: 5.13.0-27-generic
GPU: RTX 3060
GPU driver: 495.46

Problem has occurred for me at both 90 and 144, for what it's worth.

Don't get me wrong it happens to me on all refresh rates too, but on 144hz it just happens way faster than usual.

Just moved to the new 510 Nvidia driver. First one since 470.86 which doesn't seem to have this issue.

Can confirm. Checked all the crash spots on phas with Nvidia 510 and neither of us could 203 over the course of an hour.

Yup, unless someone says otherwise I think this is solved. It is for me now too.

You guys really brought my hopes up. I just installed 511 nvidia driver, but the game crashed again...

Crashed with a 203? What were you doing when it happened? What game?

Yes. Half life alyx. Just tried it now. The same behavior as always. When the crash occurs, I got the screen in my VR headset frozen, the sounds countinued though, and the mirrored picture of the game on my desktop screen was still moving as I moved my headset. To me, upgrading or downgrading the nvidia driver has never helped in this.

The error started coming after I changed my HDD for a newer SSD after a clean windows installation. Even after upgrading to windows 11, the problem persisted. :(

My apologies. There doesn't seem to be another forum with the same issue that has so much feedback from other users experiencing the same error, so I thought I would drop in to contribute, as the error reported here has the same behavior as what I'm experiencing.

PS: my game crashed again. First, it showed error code -204, then it changed to -203.

I can not reproduce any of my prior crashes with the 510.39.01 nvidia driver either. 144hz device activation does not trigger a watchdog manager eval throw, Half-Life: Alyx save loads work flawlessly too; Beat Saber, Pistol Whip, Zenith MMO, all work fine as well.
Haven't tried VRChat yet though, i'll test it next time. Hopefully it also works without a hitch🤞.

I tried manually installing the NVIDIA 510.39.01 and the 510.47.03 drivers. SteamVR HOME ran with them, but VRChat wasn't happy. Some DirectX library was missing. I tried uninstalling and reinstalling VRChat, but no difference. So I reverted to my backup. I guess I'll wait until the Ubuntu NVIDIA PPA repository maintainers provide support for 510.

Fwiw when I manually installed the 5.10 I had to search and destroy remnant files from previous drivers. Might be worth looking through apt and searching in the terminal. Causes all kinds of random problems sometimes.

@quantumac the Ubuntu PPA at https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa now has the 510.47.03 driver.

I tried my very reliable method to produce the -203 error with the 510.47.03 driver and it still crashes for me. What I do is load up X-Plane (Vulkan) in VR with a very demanding scene (ToLiss A319, Orthos, detailed Airport). SteamVR will crash within max 5 seconds.

Thu Feb 03 2022 22:37:54.142766 - Excessive binding loads from steam (20826): crc=4054094268 lc=6 Reload=F res=2
Thu Feb 03 2022 22:37:54.142822 - ===== indexhmd: state=4, NOT empty, uri=file:///home/mh/.steam/steamapps/common/SteamVR/resources/config/legacy_bindings_generic_hmd.json
Thu Feb 03 2022 22:37:54.142886 - ===== knuckles: state=4, NOT empty, uri=file:///home/mh/.steam/steamapps/common/SteamVR/drivers/indexcontroller/resources/input/legacy_bindings_index_controller.json
Thu Feb 03 2022 22:37:54.145474 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.174490 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.195372 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.236301 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.292563 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.343100 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.360839 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.392988 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.423195 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.442486 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.485392 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.540340 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.591679 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.610923 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.640340 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.673155 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.688421 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.735072 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.788182 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.837271 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.856313 - Excessive binding loads from steam (20826): crc=4054094268 lc=6 Reload=F res=2
Thu Feb 03 2022 22:37:54.856388 - ===== indexhmd: state=4, NOT empty, uri=file:///home/mh/.steam/steamapps/common/SteamVR/resources/config/legacy_bindings_generic_hmd.json
Thu Feb 03 2022 22:37:54.856475 - ===== knuckles: state=4, NOT empty, uri=file:///home/mh/.steam/steamapps/common/SteamVR/drivers/indexcontroller/resources/input/legacy_bindings_index_controller.json
Thu Feb 03 2022 22:37:54.860125 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.885352 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.920541 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.936134 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:54.983942 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:55.035064 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:55.085569 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:55.108503 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:55.135725 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:55.166733 - 0 - entering standby
Thu Feb 03 2022 22:37:55.170742 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:55.184474 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:55.232014 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:55.283714 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:55.294359 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:55.333490 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:55.356421 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:55.382667 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:55.418486 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:55.432908 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:55.481620 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:55.528710 - Excessive binding loads from steam (20826): crc=4054094268 lc=6 Reload=F res=2
Thu Feb 03 2022 22:37:55.528778 - ===== indexhmd: state=4, NOT empty, uri=file:///home/mh/.steam/steamapps/common/SteamVR/resources/config/legacy_bindings_generic_hmd.json
Thu Feb 03 2022 22:37:55.528860 - ===== knuckles: state=4, NOT empty, uri=file:///home/mh/.steam/steamapps/common/SteamVR/drivers/indexcontroller/resources/input/legacy_bindings_index_controller.json
Thu Feb 03 2022 22:37:55.531241 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:55.543641 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:55.581998 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:55.605485 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:55.631968 - Unable to find input 'z' in filter click_button_actions_legacy_18_user_hand_right_input_thumbstick
Thu Feb 03 2022 22:37:55.636884 - [Status Alert] SteamVR Fail (-203)

I just managed to hit -203 failure on paper beasts.
Previously it happened almost straight away unless switched to legacy reprojection mode, but still happened eventually.
This time (NVIDIA 510.47.03, archlinux) I switched back to default reprojection settings and it lasted 20mins, but still hit it at I think about the same point as with legacy reprojection before. SteamVR seemed to recover back to SteamVR home after closing paper beasts.
So I'm guessing only a subset of triggers of this issue (relating to async reprojection) have been resolved by the new driver.

@kisak-valve (pinging you as you are the most recent committer on this repo):

This issue seems to be affecting a lot of people across lots of distros. This and that it is hard to say whether this is a SteamVR and/or Nvidia issue, maybe some insights from the SteamVR side would be great.

Affects me in NeosVR.(If that's of any note all my other VR games/apps run fine.

More recent NVidia drivers have largely mitigated this problem for me, but I still get this crash during prolonged playtimes or more strenuous VR applications (such as the above-mentioned Neos VR - mostly when running it through Proton to use the KFC/NCR-enabled build.)

More recent NVidia drivers have largely mitigated this problem for me, but I still get this crash during prolonged playtimes or more strenuous VR applications (such as the above-mentioned Neos VR - mostly when running it through Proton to use the KFC/NCR-enabled build.)

I believe Neos is the cause of the issues and not Proton, is it the issue where the screen freezes and it'll randomly either crash or continue to be frozen and output unresponsive engine messages in the logs? If so, there are Windows users that have the issue as well.

I believe Neos is the cause of the issues and not Proton, is it the issue where the screen freezes and it'll randomly either crash or continue to be frozen and output unresponsive engine messages in the logs? If so, there are Windows users that have the issue as well.

I would agree with this sentiment if I didn't experience the precise, exact same issue with Elite Dangerous and Pavlov VR, and didn't experience them on my Windows install. As far as I can tell, the issue is localized to SteamVR on Linux.

Replying to https://github.com/ValveSoftware/SteamVR-for-Linux/issues/452#issuecomment-1046316080

I've played Boneworks, H3VR, Skyrim VR (modded with Mod Organizer 2), No Man's Sky, Blade and Sorcery, Phasmophobia, The Wizards, The Wizards: Dark TImes, and Ancient Dungeon VR through Proton, and Garry's Mod VR and Half-Life: Alyx without, and have never had the issue. Only Neos has this for me.

I'm unsure of how this all really mixes together, but could it be possible a fix for this could happen upstream now that the NVIDIA GPU kernel modules are open source?
https://github.com/NVIDIA/open-gpu-kernel-modules

Well, this issue is already hard to catch, but still present for some peeps. Nvidia open sourcing their driver will help a lot though, it'll take some time, but we are not fighting black boxes anymore!

Interesting tidbid, i run a windows 11 vm purely for vr at the moment because of this issue.

I got this exact crash on windows 11, it was related to their gpu scheduling feature in windows 11. After turning it off it never happened again. Might be related to gpu scheduling here too

Also: if you're thinking about debugging this, and want to reproduce it, the prime suspect games are VRChat, and ChilloutVR, in worlds with a lot of players. High load situations seem to force it forward

Starting Beat Saber instantly crashes with -203, while other VR games run fine...

Arch Linux, 6.3.5-1-cachyos-bore, NVidia driver 530.41.03. Tried both betas of Steam as well as SteamVR - same behavior.

EDIT: I installed dual boot on my PC. Here are my remarks:

1. VR performance/stability/latency and everything else difference is like day & night. It's so good on Windows...
2. Installed Windows:
   2.1 BTRFS partition which is used by OS can be reduced on live system, using Gparted. This made things so much easier.
   2.2 Installed Windows on an unused space.
   2.3 Installed WinBtrfs. Now my HDD and separate SSD (for games) is visible in Windows without requiring to format them.
   2.4 Steam on both Windows and Linux can share the same library.

Guys, don't waste your time for VR on Linux. It has, does and will suck on Linux. It's been quite a few years and yet not much of a progress. Either sell it or use on Windows, no other way. Valve should stop advertising Linux as supported platform or dedicate some serious resources for this.

Considering Steam Deck success, it might be the beginning of Linux as a gaming platform, so things might get better in the future. :)

Recently started getting this issue with a GTX 1080 and NVidia drivers 535.54.03-3 on Xorg. I hadn't encountered this issue in the past, but now it inevitably happens after a few minutes, sometimes even sooner.

Disabling async reprojection (opening up mirror view, debug commands, and toggling it off with shift+a) seems to completely resolve the issue (although obviously you'd prefer not to turn it off). Was able to stay one hour in VRChat and Beat Saber without crashing after trying this.

I just found out that on my 3-monitor-setup,when i disable all but one, steamvr just works. With all 3 on i get an instant 203

I have two monitors. Turned one off - now it works! Thank you so much.

still no fix for this?

SteamVR: 2.13.6
GPU: RTX4070, 580.82.07 - Single Monitor (Aside from headset)
VR Headset: Quest 3
OS: Ubuntu 25.10

Frequent crashes with -203

Experiencing crashes even without a native or proton game open, just interacting with the dashboard or letting it idle active for a few minutes is enough to cause a -203.
NVIDIA Driver: 580.105.08 on 1650 Super - one display
Arch Linux: default 'linux' kernel (currently 6.17.8), default NVIDIA driver package
Headset: vrlink on Quest 2