Original issue for Arc Raiders play test: https://github.com/ValveSoftware/Proton/issues/8636

Constant crashes after a few minutes. Can't play. Void Linux. Tried Hotfix, Experimental, and Experimental Bleeding-Edge. Tried Steam overlay enabled/disabled.

# /etc/sysctl.conf
fs.file-max = 524288
vm.max_map_count = 1048576

$ ls /var/service/
NetworkManager  agetty-tty1  agetty-tty2  agetty-tty3  agetty-tty4  agetty-tty5  agetty-tty6  alsa  bluetoothd  dbus  elogind  libvirtd  nanoklogd  polkitd  socklog-unix  udevd  virtlockd  virtlogd

Running PipeWire at user level, Herbstluftwm (Xorg).

steam-log.tar.gz

Steam Runtime System Information

I cannot reproduce this on 25.1.5 driver or main, but I did find something a little suspect which might explain your crash. Filed:

https://gitlab.freedesktop.org/mesa/mesa/-/issues/14225

This is quite hard to provide a decent log for due to the random nature of it but I have attached one that is quite large due to the amount of attempts it took to get a crash. (2GB when uncompressed)

https://drive.google.com/file/d/1dj_wXhw_Ne8JS-tRmjgO2kFU7tIX8Ah4/view?usp=sharing
Provided in Google Drive due to it being over the Github file size limit even when compressed.

Essentially, sometimes when loading into a match with the game window out of focus, it will randomly completely freeze and require the game to be restarted. I've noted several reports on ProtonDB with both Nvidia and AMD reporting the same, though I'm personally on Mesa 25.2.5 and an RX9070.

For clarity, this is with FSR4 running, but it also occurs without any launch options etc.

Replying to https://github.com/ValveSoftware/Proton/issues/9164#issuecomment-3474124131

I do have the same issue, crash when the game window is out of focus.

@astrayblackcat @gbip while I haven't repro'd on my end, I found tha thte game has two idle settings in the graphics settings, have you tried if turning them off prevents the issue from manifesting?

Replying to https://github.com/ValveSoftware/Proton/issues/9164#issuecomment-3478222291

I have tried, makes no difference unfortunately.

@astrayblackcat

I've encountered similar issues running ARC on arch linux, proton 10.0.2 and proton experimental.

The crashes typically occur right after we start the match, during the cut scene.
There was one time that I fully loaded into the match, but before I was able to move the character it crashed (froze, no pop up error messages).

Has anyone else seen this issue or had any luck mitigating it?

@astrayblackcat @gbip while I haven't repro'd on my end, I found tha thte game has two idle settings in the graphics settings, have you tried if turning them off prevents the issue from manifesting?

I will try this, thanks.

Just had a crash when redeeming some coins on the earnable store page 5, file is big so it is on mega.

RX 6700 10GB, Ryzen 7600, Cachyos, Mesa 25.2.6, Kernel 6.17.7, Proton Experimental

https://mega.nz/file/sBAEVJRb#EGJYcjWDtpPCJ4u8wuLQ7uRdozqHjqJxqV7weo3AytI

The game is great and I'm enjoying it. I've played for several hours, but it's true that there have been some problems.

When I played for the first 3 or 4 hours, everything was fine with the following flags: game-performance mangohud %command%

Then I was curious to try the game with the flags PROTON_ENABLE_WAYLAND=1 PROTON_USE_NTSYNC=1 + the previous ones, and what happens here is that the game works quite well, but if you are looking for a game and you are outside the game, it will never load the game, and if you are inside the game focus and it puts you in the game, the gameplay works fine, but the game cursor remains active on the screen.

This problem is caused by the variable PROTON_ENABLE_WAYLAND=1. so I removed these last two variables and the game worked fine as usual, but then it crashed for the first time. I don't know if it was a coincidence or completely random. I was in focus when I loaded the game, and once inside, I moved a few metres and the game crashed. Unfortunately, I don't have a screenshot to send, but if it happens again, I'll send it. I hope these issues get fixed, as I don't know if it's a vkd3d-proton issue or a Mesa issue.

The performance is quite good, but I think it's a little better on Windows. With everything set to Ultra, TSR 100% at 1440p with my rx 9070 xt, I got an average of 110-120fps, and on Linux a little less, around 100~, sometimes dropping to 90 and something.

mi setup specs: CachyOS, KDE plasma 6.5.1, kernel 6.17.6, ryzen 7 5800x3d, rx 9070 xt, mesa 25.2.6 and proton experimental / proton-cachyos-native

Proton logs compress well, so always try compressing them before uploading them, for convenience.

There are probably multiple factors leading to issues in this game, it's important to try and recall as many details as you can from the run where the issue occurred. As well as game settings, and device information.

The game has settings for idle energy settings that might cause some issues when out of focus in some setups.

For now, I can say that when using TSR the game can crash when switching graphics quality, at least on amd. This crash, when it happens, is instant and doesn't bring up the crash handler. It's possible that the game may also crash in other scenarios while using TSR so it's something worth taking into account.

Update:

Nvapi doesn't load successfully on amd, and during the run of the game the dll gets loaded and unloaded many times. This can be avoided by either disabling, or force enabling, nvapi through PROTON_DISABLE_NVAPI=1 %command% or PROTON_FORCE_NVAPI=1 %command% respectively in the game's launch parameter. Thus far, this seems to prevent the TSR crash that may happen when cycling through graphics preset.

This issue is also still present: https://github.com/ValveSoftware/Proton/issues/8636#issuecomment-3420008982
After 30 minutes arc raiders crashes no matter where you are in the game, could be main menu, in game or in cutscene.
One reason for that might be that some distros (like gentoo) have their vm.max_map_count at 65530.
Changing that to 1048576 gives me a cttc (constant time till crash) of exactly 1 hour and 50 minutes.
Changing it to 2147483642 does not increase that, instead I now only get a cttc of exactly 1 hour and 30 minutes.

Up until that crashing point the game runs like a charm. Great performance, feels very well optimized.
It does not matter which proton version I'm on (including betas like bleeding edge), it's always the same. Also EXPO settings does not seem to matter, graphic settings also does not seem to matter. I switched to single monitor, no change.
I'm on 580.95.05 with rtx 4070 ti super.

edit:
Figured it out. Also the hard file descriptor limit has to be set. It is quite low on gentoo by default. So I added * hard nofile 524288 to /etc/security/limits.conf.
No more crashes so far.

Replying to https://github.com/ValveSoftware/Proton/issues/9164#issuecomment-3481332753

The wine wayland cursor problem has been resolved in plasma 6.5.2, it was a regression with plasma 6.5

https://bugs.kde.org/show_bug.cgi?id=511075
https://invent.kde.org/plasma/kwin/-/merge_requests/8326

A crash related to the presence of nvapi on non Nvidia systems have now been worked around in Proton Bleeding Edge

I've managed to crash once, a few seconds after joining a match. The game gave me an option to reconnect the match after starting the game again, which made it crash again. Unfortunately, when starting the game with extra debugging options it didn't crash, and in other matches I couldn't crash even when going to the same zone.

For those who have crashed starting a match, have you been able to rejoin the match? And did it crash again after doing so?

Game appears with a newer driver window warning when launching on latest update on amd hardware atleast on 2 different computers running nobara and cachyos, one running experimental and one running experimental(bleeding edge)

That dialog doesn't read like an outdated warning. Instead, it's saying the claimed driver version is newer than a known working point release.

yes sorry, i wasn't reading it properly for some reason, thanks!

The driver version popup should still likely be worked around (or potentially fixed by the devs? Embark is fairly attentive to Steam Deck/Proton compatibility) as it will likely always show due to it being read incorrectly.

As well as, of course, being completely bogus on Linux as it's referring to known issues with the Windows AMD drivers.

While I haven't gotten the game to hang again on dam battlegrounds, I could reliably get it to hang my 9060 xt by spending a few minutes in "buried city". For those affected by the same there are currently two options, the easy thing to do is to disable ray tracing, or if you know how to compile mesa yourself, you can add the merge request number 38290.

The above report sounds very definitive about it not working, but voice chat is working fine for me. Others can hear me just fine, both with regular as well as with Raider voice. I'm using Proton experimental, no launch options.

The above reports sounds very definitive about it not working, but voice chat is working fine for me, others can hear me just fine, bot with regular as well as with Raider voice. I'm using Proton experimental, no launch options.

Can you post your system info and what audio stack you have? pulse, pipewire, alsa, audio card ect? Distro? Im on OpenSuse pipewire and I have a USB audio interface.

Another error I want to report is that if you run the game with the variable: PROTON_ENABLE_WAYLAND=1
when you are in the game and press 2 to change weapons, it doesn't work for some reason. The 1 key, which is for changing the main weapon, does work. and if I change the weapon with the mouse wheel, it also works, but it's annoying that the 2 key doesn't work. The same thing happens with the q key, which is for selecting the inventory to browse. Sometimes it works and sometimes it doesn't. This doesn't happen if I run it normally without that variable.

pd: I have tested it with ProtonGE 25 and proton-cachyos.

@Skrappjaw

Can you post your system info and what audio stack you have? pulse, pipewire, alsa, audio card ect? Distro? Im on OpenSuse pipewire and I have a USB audio interface.

It's nothing special. Gentoo, GNOME on OpenRC using pipewire 1.4.7 via wireplumber 0.5.10, no pulseaudio installed. Sound is onboard. No launch options, just Proton Experimental.

Screenshot of the voip part of the audio settings

pactl list-sources also lists it, but only during a raid, not when in Speranza/the menus.

pactl list source-outputs
Source Output [#212](/issue/ValveSoftware/Proton/212)
	Driver: PipeWire
	Owner Module: n/a
	Client: 201
	Source: 68
	Sample Specification: s16le 2ch 48000Hz
	Channel Map: front-left,front-right
	Format: pcm, format.sample_format = "\"s16le\""  format.rate = "48000"  format.channels = "2"  format.channel_map = "\"front-left,front-right\""
	Corked: no
	Mute: no
	Volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 / 100% / 0.00 dB
	        balance 0.00
	Buffer Latency: 0 usec
	Source Latency: 0 usec
	Resample method: PipeWire
	Properties:
		client.api = "pipewire-pulse"
		pulse.server.type = "unix"
		application.name = "ARC Raiders"
		application.process.id = "7265"
		application.process.user = "simon"
		application.process.host = "simon-desktop"
		application.process.binary = "wine64-preloader"
		application.language = "en_US.UTF-8"
		window.x11.display = ":0"
		application.process.machine_id = "<machine id>"
		media.name = "audio stream #3"
		pulse.corked = "false"
		node.rate = "1/48000"
		node.latency = "480/48000"
		stream.is-live = "true"
		node.name = "ARC Raiders"
		node.want-driver = "true"
		node.autoconnect = "true"
		media.class = "Stream/Input/Audio"
		port.group = "stream.0"
		adapt.follower.spa-node = ""
		object.register = "false"
		factory.id = "7"
		clock.quantum-limit = "8192"
		node.loop.name = "data-loop.0"
		library.name = "audioconvert/libspa-audioconvert"
		client.id = "96"
		object.id = "107"
		object.serial = "212"
		pulse.attr.maxlength = "384000"
		pulse.attr.fragsize = "1920"
		node.driver-id = "46"
		module-stream-restore.id = "source-output-by-application-name:ARC Raiders"

Maybe the 48kHz is to blame?

Not sure if this should go here or somewhere else, but is anyone else having issues with Steam game recording working with this game? Works in other games but doesn't seem to be doing anything in ARC Raiders. I'm using Proton Experimental

OS: Arch Linux
KERNEL: 6.17.7-arch1-1
CPU: 12th Gen Intel Core i7-12700K
GPU: NVIDIA GeForce RTX 4080 SUPER
GPU DRIVER: NVIDIA 580.95.05
RAM: 64 GB

Another error I want to report is that if you run the game with the variable: PROTON_ENABLE_WAYLAND=1
when you are in the game and press 2 to change weapons, it doesn't work for some reason. The 1 key, which is for changing the main weapon, does work. and if I change the weapon with the mouse wheel, it also works, but it's annoying that the 2 key doesn't work. The same thing happens with the q key, which is for selecting the inventory to browse. Sometimes it works and sometimes it doesn't. This doesn't happen if I run it normally without that variable.

Valve does not have wine Wayland enabled on default proton, please report wine Wayland problems on proton-em github instead as that's where all of the patches come from with the custom proton runners

https://github.com/Etaash-mathamsetty/Proton/issues

Replying to https://github.com/ValveSoftware/Proton/issues/9164#issuecomment-3514926506

I have tried it with ProtonGE 25 and proton-cachyos and the same thing happens. I do not know why those keys do not work properly.

What's this message about?
kernel: PioneerGame.exe[56852] vsyscall read attempt denied -- look up the vsyscall kernel parameter if you need a workaround ip:7000007e3fac cs:33 sp:b9b918 ax:b9b980 si:c38f73 di:ffffffffff600000

Game seems to work tho', I got one game crash while looking at the pre-mission map but that seems not easily reproducable.

@HansKristian-Work Sorry to ping you, but since Arc Raiders is a DX12 game, are you aware of these issues with it? It would be great to fix a few things like the ones mentioned above. Thanks!

I'm running pipewire-pulse and my in-game mic works, and I'm not experiencing audio crackling.

Essentially, sometimes when loading into a match with the game window out of focus, it will randomly completely freeze and require the game to be restarted. I've noted several reports on ProtonDB with both Nvidia and AMD reporting the same, though I'm personally on Mesa 25.2.5 and an RX9070.

I'm getting the same issue on Arch Linux with Nvidia drivers running Hyprland. I notice that there is a toast notification in the bottom right that only appears if you tab out. That could be worth investigating as the root cause.

I just noticed another error. I activated “night mode” in the audio settings and there is now crackling in the audio, which is annoying. If I turn it off, it still happens but less so because the sound is lower without night mode. I would like to use night mode but it's annoying that the audio crackles.

@rcv11x no audio crackling on my end, it's possible the crackling is a symptom of your system not being able to keep up with the audio latency. Something you can try is playing with the latency to see if it changes anything for you, for example PULSE_LATENCY_MSEC=60 %command% in your game's launch parameters, the higher you make the value the lesser the chance you'll get crackling.

@simonvanderveldt

Thanks for the info. I figured it might be something to do with opensuse implementation of pipewire or something else distribution related. I've removed the hardware and virtual sink variables and have now attempted to play this game on Linux Mint. Same machine. Same voip issue. it seems that Voice Chat is a problem for other on not only linux, but on windows PC an Console as well. Some have reported firewall issues and or ipv6 being a problem. I'm about to dig more into the network portion.

the game is currently unplayable due to full system lockups for 10 seconds every few minutes. looking into the proton logs I can see a spam loop of thousands of syscalls during the lockups

693.346:01e8:01ec:trace:seh:sigsys_handler SIGSYS, rax 0x17, rip 0x7000008f52a3. 693.346:01e8:01ec:trace:seh:sigsys_handler SIGSYS, rax 0x17, rip 0x7000008f52a3. 693.346:01e8:01ec:trace:seh:sigsys_handler SIGSYS, rax 0x17, rip 0x7000008f52a3. 693.346:01e8:01ec:trace:seh:sigsys_handler SIGSYS, rax 0x7d, rip 0x70000082e658. 693.346:01e8:01ec:trace:seh:sigsys_handler SIGSYS, rax 0x1d, rip 0x700000824244. 693.346:01e8:01ec:trace:seh:sigsys_handler SIGSYS, rax 0x7d, rip 0x70000082e658. 693.346:01e8:01ec:trace:seh:sigsys_handler SIGSYS, rax 0x1d, rip 0x700000824244. 693.346:01e8:01ec:trace:seh:sigsys_handler SIGSYS, rax 0x7d, rip 0x70000082e658. 693.346:01e8:01ec:trace:seh:sigsys_handler SIGSYS, rax 0x1d, rip 0x700000824244. 693.346:01e8:01ec:trace:seh:sigsys_handler SIGSYS, rax 0x7d, rip 0x70000082e658. 693.346:01e8:01ec:trace:seh:sigsys_handler SIGSYS, rax 0x1d, rip 0x700000824244. 693.346:01e8:01ec:trace:seh:sigsys_handler SIGSYS, rax 0x7d, rip 0x70000082e658. 693.346:01e8:01ec:trace:seh:sigsys_handler SIGSYS, rax 0x1d, rip 0x700000824244. 693.346:01e8:01ec:trace:seh:sigsys_handler SIGSYS, rax 0x7d, rip 0x70000082e658. 693.346:01e8:01ec:trace:seh:sigsys_handler SIGSYS, rax 0x1d, rip 0x700000824244. 693.346:01e8:01ec:trace:seh:sigsys_handler SIGSYS, rax 0x7d, rip 0x70000082e658. 693.346:01e8:01ec:trace:seh:sigsys_handler SIGSYS, rax 0x1d, rip 0x700000824244. 693.346:01e8:01ec:trace:seh:sigsys_handler SIGSYS, rax 0x7d, rip 0x70000082e658. 693.346:01e8:01ec:trace:seh:sigsys_handler SIGSYS, rax 0x1d, rip 0x700000824244.

@rcv11x no hay crujidos de audio por mi parte, es posible que el crujido sea un síntoma de que su sistema no puede seguir el ritmo de la latencia del audio. Algo que puedes probar es jugar con la latencia para ver si cambia algo para ti, por ejemplo PULSE_LATENCY_MSEC=60 %command% En los parámetros de lanzamiento de tu juego, cuanto mayor sea el valor, menor será la probabilidad de que se produzcan crujidos.

I just noticed the crackling in the audio. It only happens with the voices of the NPCs in the main menu and game, as well as with the music, but there is no crackling during gameplay. It doesn't matter whether night mode is enabled or disabled, it applies to both. It's worth noting that I have my Pipewire sample rate set to 192 kHz. I don't know if this affects anything, but I don't get audio crackling in other games.

P.S.: I've entered the command you gave me, PULSE_LATENCY_MSEC=60, but it hasn't made any improvement.

edit 2:

Does it have anything to do with me using Easyeffects? I don't have anything unusual there, just an equalization preset for my Beyerdynamic DT 990 Pro headphones. I know that the game didn't crackle before, and I have a feeling that it's because of the 192 kHz. I think I remember it used to be 48000 and it didn't happen, but a few days ago I increased it because I have Tidal and the music sounds better. It seems to be a problem with this game because, as I said, it doesn't happen with others.

my pipewire config:

{
  "context.properties": {
    "default.clock.rate": "192000",
    "default.clock.allowed-rates": [
      "44100",
      "48000",
      "96000",
      "192000"
    ],
    "default.clock.min-quantum": "1024",
    "default.clock.max-quantum": "2048"
  }
}

@rcv11x
crackling audio issues seem to be tied to pulseaudio
they can be resolved by forcing use of alsa with the following command

protontricks 1808500 sound=alsa

@rcv11x I also said you can play around with the value, 60 is just a reference, but you can always increase it to see if it makes a difference. As for the sample rate, you can check the sample rate each of your active programs are using with pw-top

Update: I just added this launch option:

WINEDLLOVERRIDES="winepulse.drv=d;winealsa.drv=b"

and the game no longer crackles in the voices and music, as I mentioned in my previous comment. Why did this fix it? I'm not entirely sure what this does either.

@rcv11x you're changing the audio stack the game is using. Odds are, the settings you have for pipewire don't apply here.

@rcv11x

... I have my Pipewire sample rate set to 192 kHz. I don't know if this affects anything, but I don't get audio crackling in other games.

This is definitely your problem. the higher the sample rate, the more CPU it will use and you'll have to increase your buffer some. The crackle is the buffer under run. Lower your Sample Rate to 96k or 48k.

To your other point about easy fx, anything that requires digital processing is going to eat up CPU cycles. Something to remember in linux is that the frame buffer for your video and your audio both rely on CPU power. Yes, your DAC and GPU do the heavy lifting but the CPU has to keep it all in sync and process any digital audio fx. Dial it back. Unless you're attempting to record music with near zero latency, there is no reason to use 192 khz. you'll never hear the difference anyway.

@rcnoob I have complete freezes of the game every now and then. Those lines you posted are the last ones in the log before killing the process

@rcnoob I have complete freezes of the game every now and then. Those lines you posted are the last ones in the log before killing the process

These are very early results but after trying MANY things to no avail, I have found the most stability using the scx_bpfland scheduler. Previously I was using lavd as I understood it was for gaming. Take this with a grain of salt however until I test more, as this game has a tendency to run fine sometimes then return with the freezes randomly

Reading about the current state of the game, it seems like it got issues on Windows too. So some crashes you see might actually be game bugs.

Replying to https://github.com/ValveSoftware/Proton/issues/9164#issuecomment-3530458947

OK, I'll try setting my Pipewire sample rate to 96 kHz. If that solves the problem, I'll leave it like that, as it's great even for listening to Tidal. Thanks, I'll let you know the result.

I'm starting to get pissed off. I just got home from work and set Pipewire to 96 kHz, and I'm still getting crackling in the audio! Why doesn't this shit work properly? And don't tell me the solution is to lower it to 44 or 48 kHz like I had it before, because NO, there has to be some other solution. I've tried running the game like this:

PULSE_LATENCY_MSEC=60 PIPEWIRE_RATE=48000 ... %command%

But it does absolutely nothing, since it should force the game to use 48 kHz, but it ignores it, and I'm really pissed off now.

The only solution I've found is to use this variable WINEDLLOVERRIDES="winepulse.drv=d;winealsa.drv=b" and now there's no more crackling. I'm fed up, I'm going to use it until it's fixed (if it gets fixed), hopefully. Thanks, and I hope some developer from Wine, vkd3d, or whoever it may be sees this, since I'm not really sure who would be in charge of this.

@rcv11x

You also should try increasing the quantum (buffer). I had the crackle issue as well when I was using OpenSuse. But I since went to mint and there's no crackle. Sometimes it's the implementation of the pipe wire stack or other processes eating cpu. Crackle is a buffer thing. You also have easy effects.

Anyway. This isn't a proton specific issue. It's the audio stack.

@rcv11x

You also should try increasing the quantum (buffer). I had the crackle issue as well when I was using OpenSuse. But I since went to mint and there's no crackle. Sometimes it's the implementation of the pipe wire stack or other processes eating cpu. Crackle is a buffer thing. You also have easy effects.

Anyway. This isn't a proton specific issue. It's the audio stack.

Okay, I see. How do I increase the quantum (buffer)? What value do you recommend?

@rcv11x

Get an app called Pipe Control. It will be easier to play with and adjust settings and pick the buffer that works for you.

The other thing to consider is if you're pushing your GPU farther than it needs. If you cap frame rate or reduce other CPU intensive graphics settings that will leave room for audio processes.

But do one at a time and be patient. If using ALSA is the fix or work around for you, then stick with it.

Got an amdgpu driver crash playing this game last night, halfway into a Stella Montis raid. I could see KDE try to recover, but I was eventually forced to reboot. The GPU reset several times according to the logs.

I don't know if this is a game, driver, or hardware issue, but I thought I'd post here in case it's interesting.

I'm using an AMD 6950XT. Edit: I forgot to mention I'm on kernel 6.17.7-5-cachyos. Here's some info from vulkaninfo --summary:

GPU0:
        apiVersion         = 1.4.318
        driverVersion      = 25.2.7
        vendorID           = 0x1002
        deviceID           = 0x73a5
        deviceType         = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU
        deviceName         = AMD Radeon RX 6950 XT (RADV NAVI21)
        driverID           = DRIVER_ID_MESA_RADV
        driverName         = radv
        driverInfo         = Mesa 25.2.7-cachyos1.2
        conformanceVersion = 1.4.0.0

Here's the kernel log:

Nov 15 00:11:37 linuxgamingpc kernel: [drm:gfx_v10_0_priv_reg_irq [amdgpu]] *ERROR* Illegal register access in command stream
Nov 15 00:11:37 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: Dumping IP State
Nov 15 00:11:37 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: Dumping IP State Completed
Nov 15 00:11:37 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: [drm] AMDGPU device coredump file has been created
Nov 15 00:11:37 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: [drm] Check your /sys/class/drm/card1/device/devcoredump/data
Nov 15 00:11:37 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring gfx_0.0.0 timeout, signaled seq=30543959, emitted seq=30543961
Nov 15 00:11:37 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:  Process GameThread pid 62477 thread vkd3d_queue pid 66631
Nov 15 00:11:37 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: Starting gfx_0.0.0 ring reset
Nov 15 00:11:37 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: Ring gfx_0.0.0 reset failed
Nov 15 00:11:37 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: GPU reset begin!
Nov 15 00:11:38 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: MODE1 reset
Nov 15 00:11:38 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: GPU mode1 reset
Nov 15 00:11:38 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: GPU smu mode1 reset
Nov 15 00:11:38 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: GPU reset succeeded, trying to resume
Nov 15 00:11:38 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: VRAM is lost due to GPU reset!
Nov 15 00:11:38 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: PSP is resuming...
Nov 15 00:11:38 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: reserve 0xa00000 from 0x83fd000000 for PSP TMR
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: SECUREDISPLAY: optional securedisplay ta ucode is not available
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: SMU is resuming...
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: smu driver if version = 0x00000040, smu fw if version = 0x00000041, smu fw program = 0, version = 0x003a5a00 (58.90.0)
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: SMU driver if version not matched
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: use vbios provided pptable
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: SMU is resumed successfully!
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: kiq ring mec 2 pipe 1 q 0
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: [drm] DMUB hardware initialized: version=0x02020021
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring gfx_0.1.0 uses VM inv eng 1 on hub 0
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 4 on hub 0
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 5 on hub 0
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 6 on hub 0
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 7 on hub 0
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 8 on hub 0
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 9 on hub 0
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 10 on hub 0
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 11 on hub 0
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring kiq_0.2.1.0 uses VM inv eng 12 on hub 0
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring sdma0 uses VM inv eng 13 on hub 0
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring sdma1 uses VM inv eng 14 on hub 0
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring sdma2 uses VM inv eng 15 on hub 0
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring sdma3 uses VM inv eng 16 on hub 0
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring vcn_dec_0 uses VM inv eng 0 on hub 8
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring vcn_enc_0.0 uses VM inv eng 1 on hub 8
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring vcn_enc_0.1 uses VM inv eng 4 on hub 8
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring vcn_dec_1 uses VM inv eng 5 on hub 8
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring vcn_enc_1.0 uses VM inv eng 6 on hub 8
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring vcn_enc_1.1 uses VM inv eng 7 on hub 8
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring jpeg_dec uses VM inv eng 8 on hub 8
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: GPU reset(1) succeeded!
Nov 15 00:11:39 linuxgamingpc kernel: [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!
Nov 15 00:11:39 linuxgamingpc kernel: [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!
Nov 15 00:11:39 linuxgamingpc kernel: amdgpu 0000:12:00.0: [drm] device wedged, but recovered through reset
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:3 pasid:32812)
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:  Process firefox pid 65351 thread firefox:cs0 pid 65412
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:   in page starting at address 0x0000800040002000 from client 0x1b (UTCL2)
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00301431
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:          Faulty UTCL2 client ID: SQC (data) (0xa)
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:          MORE_FAULTS: 0x1
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:          WALKER_ERROR: 0x0
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:          PERMISSION_FAULTS: 0x3
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:          MAPPING_ERROR: 0x0
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:          RW: 0x0
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:3 pasid:32812)
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:  Process firefox pid 65351 thread firefox:cs0 pid 65412
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:   in page starting at address 0x0000800040002000 from client 0x1b (UTCL2)
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00301431
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:          Faulty UTCL2 client ID: SQC (data) (0xa)
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:          MORE_FAULTS: 0x1
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:          WALKER_ERROR: 0x0
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:          PERMISSION_FAULTS: 0x3
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:          MAPPING_ERROR: 0x0
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:          RW: 0x0
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:3 pasid:32812)
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:  Process firefox pid 65351 thread firefox:cs0 pid 65412
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:   in page starting at address 0x0000800040002000 from client 0x1b (UTCL2)
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:3 pasid:32812)
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:  Process firefox pid 65351 thread firefox:cs0 pid 65412
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:   in page starting at address 0x0000800040002000 from client 0x1b (UTCL2)
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:3 pasid:32812)
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:  Process firefox pid 65351 thread firefox:cs0 pid 65412
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:   in page starting at address 0x0000800041002000 from client 0x1b (UTCL2)
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:3 pasid:32812)
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:  Process firefox pid 65351 thread firefox:cs0 pid 65412
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:   in page starting at address 0x0000800041002000 from client 0x1b (UTCL2)
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:3 pasid:32812)
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:  Process firefox pid 65351 thread firefox:cs0 pid 65412
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:   in page starting at address 0x0000800041002000 from client 0x1b (UTCL2)
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:3 pasid:32812)
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:  Process firefox pid 65351 thread firefox:cs0 pid 65412
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:   in page starting at address 0x0000800041002000 from client 0x1b (UTCL2)
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:3 pasid:32812)
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:  Process firefox pid 65351 thread firefox:cs0 pid 65412
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:   in page starting at address 0x0000800041002000 from client 0x1b (UTCL2)
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:3 pasid:32812)
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:  Process firefox pid 65351 thread firefox:cs0 pid 65412
Nov 15 00:11:46 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:   in page starting at address 0x0000800042002000 from client 0x1b (UTCL2)
Nov 15 00:11:50 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: Dumping IP State
Nov 15 00:11:50 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: Dumping IP State Completed
Nov 15 00:11:50 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: [drm] AMDGPU device coredump file has been created
Nov 15 00:11:50 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: [drm] Check your /sys/class/drm/card1/device/devcoredump/data
Nov 15 00:11:50 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring gfx_0.1.0 timeout, signaled seq=6554101, emitted seq=6554102
Nov 15 00:11:50 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu:  Process kwin_wayland pid 1927 thread kwin_wayla:cs0 pid 1957
Nov 15 00:11:50 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: Starting gfx_0.1.0 ring reset
Nov 15 00:11:50 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: Ring gfx_0.1.0 reset failed
Nov 15 00:11:50 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: GPU reset begin!
Nov 15 00:11:51 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: MODE1 reset
Nov 15 00:11:51 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: GPU mode1 reset
Nov 15 00:11:51 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: GPU smu mode1 reset
Nov 15 00:11:51 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: GPU reset succeeded, trying to resume
Nov 15 00:11:51 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: VRAM is lost due to GPU reset!
Nov 15 00:11:51 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: PSP is resuming...
Nov 15 00:11:51 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: reserve 0xa00000 from 0x83fd000000 for PSP TMR
Nov 15 00:11:51 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: SECUREDISPLAY: optional securedisplay ta ucode is not available
Nov 15 00:11:51 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: SMU is resuming...
Nov 15 00:11:51 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: smu driver if version = 0x00000040, smu fw if version = 0x00000041, smu fw program = 0, version = 0x003a5a00 (58.90.0)
Nov 15 00:11:51 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: SMU driver if version not matched
Nov 15 00:11:51 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: use vbios provided pptable
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: SMU is resumed successfully!
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: kiq ring mec 2 pipe 1 q 0
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: [drm] DMUB hardware initialized: version=0x02020021
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring gfx_0.1.0 uses VM inv eng 1 on hub 0
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 4 on hub 0
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 5 on hub 0
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 6 on hub 0
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 7 on hub 0
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 8 on hub 0
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 9 on hub 0
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 10 on hub 0
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 11 on hub 0
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring kiq_0.2.1.0 uses VM inv eng 12 on hub 0
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring sdma0 uses VM inv eng 13 on hub 0
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring sdma1 uses VM inv eng 14 on hub 0
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring sdma2 uses VM inv eng 15 on hub 0
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring sdma3 uses VM inv eng 16 on hub 0
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring vcn_dec_0 uses VM inv eng 0 on hub 8
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring vcn_enc_0.0 uses VM inv eng 1 on hub 8
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring vcn_enc_0.1 uses VM inv eng 4 on hub 8
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring vcn_dec_1 uses VM inv eng 5 on hub 8
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring vcn_enc_1.0 uses VM inv eng 6 on hub 8
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring vcn_enc_1.1 uses VM inv eng 7 on hub 8
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: ring jpeg_dec uses VM inv eng 8 on hub 8
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: amdgpu: GPU reset(2) succeeded!
Nov 15 00:11:52 linuxgamingpc kernel: [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!
Nov 15 00:11:52 linuxgamingpc kernel: amdgpu 0000:12:00.0: [drm] device wedged, but recovered through reset

Thanks, @kisak-valve . Here is a link to the results of Steam Runtime Diagnostics.

I uploaded two logs to a gDrive folder. The first is launching the game from desktop mode (which works as expected), and the second is launching the game from game mode (which seems to crash somehow).

Let me know if I can provide more details.

I am also getting amdgpu driver crashes. Happens after a couple hours or so, but then after reboot it will crash again within minutes. Same behavior with kernel 6.17 and 6.18

Nov 16 16:58:30 srv1 kernel: umip: wine_threadpool[18852] ip:700001915377 sp:87c5d210: SMSW instruction cannot be used by applications.
Nov 16 16:58:30 srv1 kernel: umip: wine_threadpool[18852] ip:700001915377 sp:87c5d210: For now, expensive software emulation returns the result.
Nov 16 16:58:32 srv1 kernel: umip: wine_threadpool[21148] ip:700001915377 sp:a48bd170: SMSW instruction cannot be used by applications.
Nov 16 16:58:32 srv1 kernel: umip: wine_threadpool[21148] ip:700001915377 sp:a48bd170: For now, expensive software emulation returns the result.
Nov 16 16:58:34 srv1 kernel: umip: wine_threadpool[18646] ip:700001915377 sp:2730d210: SMSW instruction cannot be used by applications.
Nov 16 16:58:54 srv1 kernel: amdgpu 0000:0c:00.0: amdgpu: Dumping IP State
Nov 16 16:58:54 srv1 kernel: amdgpu 0000:0c:00.0: amdgpu: Dumping IP State Completed
Nov 16 16:58:54 srv1 kernel: amdgpu 0000:0c:00.0: amdgpu: [drm] AMDGPU device coredump file has been created
Nov 16 16:58:54 srv1 kernel: amdgpu 0000:0c:00.0: amdgpu: [drm] Check your /sys/class/drm/card1/device/devcoredump/data
Nov 16 16:58:54 srv1 kernel: amdgpu 0000:0c:00.0: amdgpu: ring gfx_0.0.0 timeout, signaled seq=385028, emitted seq=385030
Nov 16 16:58:54 srv1 kernel: amdgpu 0000:0c:00.0: amdgpu:  Process GameThread pid 17036 thread vkd3d_queue pid 21931
Nov 16 16:58:54 srv1 kernel: amdgpu 0000:0c:00.0: amdgpu: Starting gfx_0.0.0 ring reset
Nov 16 16:58:54 srv1 kernel: amdgpu 0000:0c:00.0: amdgpu: Ring gfx_0.0.0 reset succeeded
Nov 16 16:58:54 srv1 kernel: amdgpu 0000:0c:00.0: [drm] device wedged, but recovered through reset
Nov 16 16:59:05 srv1 kernel: amdgpu 0000:0c:00.0: amdgpu: Dumping IP State
Nov 16 16:59:05 srv1 kernel: amdgpu 0000:0c:00.0: amdgpu: Dumping IP State Completed
Nov 16 16:59:05 srv1 kernel: amdgpu 0000:0c:00.0: amdgpu: [drm] AMDGPU device coredump file has been created
Nov 16 16:59:05 srv1 kernel: amdgpu 0000:0c:00.0: amdgpu: [drm] Check your /sys/class/drm/card1/device/devcoredump/data
Nov 16 16:59:05 srv1 kernel: amdgpu 0000:0c:00.0: amdgpu: ring gfx_0.0.0 timeout, signaled seq=385029, emitted seq=385032
Nov 16 16:59:05 srv1 kernel: amdgpu 0000:0c:00.0: amdgpu:  Process GameThread pid 17036 thread vkd3d_queue pid 21931
Nov 16 16:59:05 srv1 kernel: amdgpu 0000:0c:00.0: amdgpu: Starting gfx_0.0.0 ring reset
Nov 16 16:59:05 srv1 kernel: amdgpu 0000:0c:00.0: amdgpu: Ring gfx_0.0.0 reset succeeded
Nov 16 16:59:05 srv1 kernel: amdgpu 0000:0c:00.0: [drm] device wedged, but recovered through reset

GPU0:
        apiVersion         = 1.4.318
        driverVersion      = 25.2.7
        vendorID           = 0x1002
        deviceID           = 0x744c
        deviceType         = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU
        deviceName         = AMD Radeon RX 7900 XTX (RADV NAVI31)
        driverID           = DRIVER_ID_MESA_RADV
        driverName         = radv
        driverInfo         = Mesa 25.2.7-arch1.1
        conformanceVersion = 1.4.0.0
        deviceUUID         = 00000000-0c00-0000-0000-000000000000
        driverUUID         = 414d442d-4d45-5341-2d44-525600000000

Edit: I think this is not specific to arc raiders, might be https://gitlab.freedesktop.org/drm/amd/-/issues/1974

@kisak-valve @frzifus - Same issue regarding not launching through Steam Gaming Mode using a controller (works fine in desktop). Weirdly enough it launches if you have a mouse connected and use that to launch the game and press 'No' on the AMD driver warning.

@kisak-valve @frzifus - Same issue regarding not launching through Steam Gaming Mode using a controller (works fine in desktop). Weirdly enough it launches if you have a mouse connected and use that to launch the game and press 'No' on the AMD driver warning.

I have the same issue on Steam Deck. If I select 'No' on the driver warning and press 'A' the game just quits. When I use the touchscreen to tap 'No' the game works without issue.
I think this might be an issue with xalia. It feels like it just looks like 'No' is selected but still 'clicks' on 'Yes'.

mh... strangely, on my Steam Deck, I can confirm (press no) on the popup using the controller input. (same SteamOS version and also using Proton Experimental)

Update Just tried to launch the game on my steam deck 5min ago. I did not work using the controller input. (I swear it worked during the last days). Anyway, using the touch screen resolves the issue.

I will try to use the mouse on my gaming PC once I am home. 🙅

@Etmix @frzifus Looks like they removed the AMD driver warning in the latest update. Also the game is now marked verified on Steam Deck and Compatible on Steam OS. Tested and launches just fine with controller!

@thiago-negri
Found that running Steam Recording in the background causes me to crash in several games after it boots the game up or several minutes into it, usually after loading into the game, on Arc Raiders it crashes constantly but after turning off Steam Recording Ive had no problems whatsoever, this seems to be a problem across several Proton versions as i crash on all Ive tested, not sure what is the cause of this if its driver/kernel or just hardware mix that does this, it crashed before patch 1.2 and after 1.3.

Not sure if this should go here or somewhere else, but is anyone else having issues with Steam game recording working with this game? Works in other games but doesn't seem to be doing anything in ARC Raiders. I'm using Proton Experimental

OS: Arch Linux KERNEL: 6.17.7-arch1-1 CPU: 12th Gen Intel Core i7-12700K GPU: NVIDIA GeForce RTX 4080 SUPER GPU DRIVER: NVIDIA 580.95.05 RAM: 64 GB

Yeah, I'm having issues with background recording. Most of the time it doesn't do anything (i.e save recordings) - but sometimes it does. I've run steam in the foreground (as a flatpak) and see:

src/steamUI/gamestream/gamestreamsystem.cpp (1042) : pState->m_nProcess == nProcess

over and over when it doesn't work. If you're in the overlay, and turn off recording and watch the output, that error stops occuring when you turn off recording. If you turn it back on, the error starts up again.

I.E I'm running the flatpak in the foreground via:

flatpak run com.valvesoftware.Steam

OS: Fedora Linux 42 (Workstation Edition) x86_64
Kernel: Linux 6.17.8-200.fc42.x86_64
DE: GNOME 48.6
CPU: AMD Ryzen 9 7900X3D (24) @ 5.66 GHz
GPU 1: AMD Radeon RX 9070 XT [Discrete]
RAM: 64GB
Proton: Experimental

just like @Shelfen I had a few crashes after enabling background recording, I have disabled it now again as before that I have never experienced crashes after playing around 10-20 hrs.

FSR Frame Generation and AMD Anti-Lag 2 options don't seem to appear at all for me in the settings.
Proton Experimental bleeding-edge as of today
Mesa 26.0.0-devel (git-f9ef7e0f64) (Anti-lag 2 support merged)
Radeon 9070xt
Linux 6.17.9-arch1-1 kernel, KDE 6.5

Anyone managed to get those features to work? Apparently DLSS FG and Reflex are working for Nvidia peeps.

@Maselkov FSR3 is working for some people, see for example https://github.com/ValveSoftware/Proton/issues/8636#issuecomment-3473109746 I still haven't been able to figure out why it isn't work for me.

@simonvanderveldt I'm not talking about FSR3 itself, but FSR3 Frame Generation in particular, which is a separate setting. FSR3 works fine for me as well

Replying to https://github.com/ValveSoftware/Proton/issues/9164#issuecomment-3567039090

I also have this issue, running a Fedora 42 KDE with CachyOS kernel, RX 6700 XT and a 5800 X3D.

Tried many proton versions and launch flags, and found a thread on Steam mentioning this:
gamemoderun PROTON_USE_WINED3D=1 %command%

This seems to fix recording however it introduces artifacts / stuttering, but hopefully narrows things down on why recording fails.

Regarding the recording issue on arc raiders. I am able to break the capability by deleting the background recording entry from steam's gallery, after doing this steam won't record the game anymore. As pointed out by a few people PROTON_USE_WINED3D=1 works around this issue makes the recording work again, and after the recording is working again you can remove the option and recording will continue working.

Having said this, when switching to steam client beta, I haven't been able to break recording by deleting the background recording entry in the gallery. I'm curious if anyone can break the recording on steam client beta

and after the recording is working again you can remove the option and recording will continue working.

Not in my case.

@o4zloiroman is this also the case on steam client beta?

Replying to https://github.com/ValveSoftware/Proton/issues/9164#issuecomment-3567039090

Same issue / similar logs as this while using the deb version of steam and I can recall maybe 3 instances game recording actually worked, To note this issue also affects Steam Link (black screen) and Broadcasting Features (infinite loading wheel).

Tried many possible workarounds like forcing specific Vulkan layers or specifically forcing use of AMD iGPU or NVIDIA dGPU

Recording issues may be an windowing/disappearing/hidden process ID issue related to EAC
Current solution: for me fixes Game Recording, Broadcasting and Steam Link
Open & Edit:

<SteamLibrary/steamapps/common/Arc Raiders/EasyAntiCheat/Settings.json> 

Flip these flags:

  "wait_for_game_process_exit": "true",
  "hide_bootstrapper": "false",
  "hide_gui": "false"

OS: Linux Mint 22.2, Kernel: 6.17.9-x64v3-xanmod, CPU: AMD Ryzen 9 7900X, Mem: 64GB, GPU: NVIDIA GeForce RTX 5070, GPU-Driver: 580.105.08 Proton: 10 / 10-25-GE

Replying to https://github.com/ValveSoftware/Proton/issues/9164#issuecomment-3620714787

I flipped all of those values to what you have listed there - and it does seem to record consistently now. I've launched Arc Raiders a few times with Steam in the foreground and no longer see the error message. Opening the overlay also shows a blue bar (i.e I am recording).

Replying to https://github.com/ValveSoftware/Proton/issues/9164#issuecomment-3623018069

fix Since I'm impatient, I built a fix myself! I'm sharing it on my GitHub! https://github.com/L2b2n/arc-raiders-linux-fix

@p5k369 Gentoo here too, thank you for the fix!

Replying to [#9164 (comment)](https://github.com/ValveSoftware/Proton/issues/9164#issuecomment-3623018069)

fix Since I'm impatient, I built a fix myself! I'm sharing it on my GitHub! https://github.com/L2b2n/arc-raiders-linux-fix

Right on!
Did you by chance try this?
VKD3D_DISABLE_EXTENSIONS=VK_KHR_ray_tracing_pipeline

https://github.com/ValveSoftware/Proton/issues/9025

Replying to https://github.com/ValveSoftware/Proton/issues/9164#issuecomment-3625055801

That didn't work. In the start option . Since the error is deeper. I just rewrote it so that the error does not appear first. The game starts through my fix quite normally without crash, and the game runs smoothly

Replying to https://github.com/ValveSoftware/Proton/issues/9164#issuecomment-3620714787

This does fix recording for me, but the game crashes within minutes and sometimes while still on the menu. Tried with Proton Experimental and Proton GE-10-26 (latest).

More specifically, it's the wait_for_game_process_exit which makes it crash, and also what makes it work, even with the other two set to true instead of false as you suggested.

Replying to [#9164 (comment)](https://github.com/ValveSoftware/Proton/issues/9164#issuecomment-3620714787)

This does fix recording for me, but the game crashes within minutes and sometimes while still on the menu. Tried with Proton Experimental and Proton GE-10-26 (latest).

More specifically, it's the wait_for_game_process_exit which makes it crash, and also what makes it work, even with the other two set to true instead of false as you suggested.

can you me send PROTON_LOG=1 %command% ?

@viktorcsati
Does your voicechat in general work? I have the issue that I can neither hear others nor speak to them. When pressing the push to talk key, a crossed-out speaker is visible.

@viktorcsati Does your voicechat in general work? I have the issue that I can neither hear others nor speak to them. When pressing the push to talk key, a crossed-out speaker is visible.

In my case, I can hear others, but I cannot speak, regardless of open mic or push to talk. Thanks for checking in.

ARC Raiders - Microphone Not Detected In-Game (Arctis Nova 7x USB) on Linux (Steam Snap)

steam snap issue? try the official steam deb package instead?

i personally haven't had any issues with this type of stuff, i just needed to change the audio input device in the game.

Since patch 1.6.0 performances have severely decreased. My FPS dropped from 100/120 to below 50.
Lowering/Increasing graphic does not have much impact.

For reference i'm on 5800X3D CPU, 6950XT GPU using last proton experimental on arch.

Hi xpander69,
This seems to have fixed the problem for a few rounds! Sometimes it still
stops working though but at least the audio device is selectable now.
Thanks

xpander69 @.***> ezt írta (időpont: 2025. dec. 14., V,
9:07):

xpander69 left a comment (ValveSoftware/Proton#9164)
https://github.com/ValveSoftware/Proton/issues/9164#issuecomment-3650455242

ARC Raiders - Microphone Not Detected In-Game (Arctis Nova 7x USB) on
Linux (Steam Snap)

steam snap issue? try the official steam deb package instead?

i personally haven't had any issues with this type of stuff, i just needed
to change the audio input device in the game.

—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/9164#issuecomment-3650455242,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BZR4U2KG6MKJ3OTJ67LJ4KD4BULF5AVCNFSM6AAAAACKX2W6DGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMNJQGQ2TKMRUGI
.
You are receiving this because you were mentioned.Message ID:
@.***>

I would like to add to my initial post that the same configuration runs perfectly fine in Windows 11 using the latest drivers. DLSS/FG remains stable and does not drop.

Putting this out here so that any hardware related considerations can be excluded from the investigation.

Update 25.01.2026:
The above issue has been identified and a fix is available. Apparently there has been an issue within vkd3d-proton and how Swapchains are being addressed. A detailed breakdown of what is breaking where has kindly been supplied by @wcampbell-nv over here.

Additionally, a fix has also been implemented which can be tested following the comments within the corresponding merge request.

@mchlschlz I ran into the exact same issue. A few minutes after enabling Frame Generation, the frame rate drops dramatically. In my case, it seems that the problem disappears if I run the game with the following launch options:

gamescope -W 1920 -H 1080 --adaptive-sync --force-grab-cursor -- prime-run %command%

(You may have to tweak the flags. prime-run if you have a discrete GPU. After launch, press Super + F to go fullscreen.)

I'll have to confirm this over a longer game session, but since the issue usually shows up within a few minutes, I would say that it looks promising so far.

EDIT: No issues for multiple sessions with FrameGen 2x + DLSS Quality + Cinematic preset.

I will add my voice to this. After updating to 590 series drivers the performance is really bad after few minutes. Disabling DLSS fixes the stuttering but FPS stays around 50% what it was before.

@kisak-valve Here is the gist https://gist.github.com/SirRahikkala/58b5a26c90ebbe94283ef508961dcba4 and attached is the proton log. Do note that I activated the DLSS in the settings about midway and when frames dropped to half, it took few minutes to exit to desktop.

steam-1808500.zip

I have the same issue as above (Arc raiders (1808500) crash while using secondary monitor), however, the reproduction is:

• Start Queue
• Alt tab to other window, same monitor (only one monitor plugged in)
• Freeze, and eventual crash.

Steam runtime: https://gist.github.com/Noremac201/106767c085b0e4e9ebd107bc0a9d2f0c

steam-1808500.log.gz

GPU0:
        apiVersion         = 1.4.328
        driverVersion      = 25.3.3
        vendorID           = 0x8086
        deviceID           = 0xe20b
        deviceType         = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU
        deviceName         = Intel(R) Arc(tm) B580 Graphics (BMG G21)
        driverID           = DRIVER_ID_INTEL_OPEN_SOURCE_MESA
        driverName         = Intel open-source Mesa driver
        driverInfo         = Mesa 25.3.3-arch1.3
---
Kernel Version: 6.18.6-arch1-1
---
Proton Version: 10.1000-200

Some further info on this.

Setting a kernel variable with the following: sudo grubby --update-kernel=ALL --args='nvidia-drm.modeset=1' and setting the following launch options in steam: PROTON_ENABLE_WAYLAND=1 gamemoderun gamescope -W 2560 -H 1440 -r 144 --borderless --force-grab-cursor -- %command% -dx12 -USEALLAVAILABLECORSE -high got rid of the issue on my system.

I have a strong suspicion that gamescope is solving the issue as it heavily influences rendering of the game and I remember seeing vulkan errors after the crash

Hey thanks @66Gramms this fixed my issue on my Intel card, my command was simply this though:

PROTON_ENABLE_WAYLAND=1  gamescope -W 2560 -H 1440 -r 144  -f --force-grab-cursor -s 2.0  -- %command%  -USEALLAVAILABLECORES

So the kernel command, gamemoderun, and dx12 weren't required.

@kisak-valve Why is this labeled NVIDIA drivers when the original post, and others, all reference mesa? 😅

I'm running into this issue as well.

GPU: AMD Radeon RX 6750 XT
CPU: AMD Ryzen 7 5800X3D

Computer Information:
Manufacturer: ASRock
Model: X570 Taichi
Form Factor: Desktop
No Touch Input Detected
Processor Information:
CPU Vendor: AuthenticAMD
CPU Brand: AMD Ryzen 7 5800X3D 8-Core Processor
CPU Family: 0x19
CPU Model: 0x21
CPU Stepping: 0x2
CPU Type: 0x0
Speed: 4552 MHz
16 logical processors
8 physical processors
Hyper-threading: Supported
FCMOV: Supported
SSE2: Supported
SSE3: Supported
SSSE3: Supported
SSE4a: Supported
SSE41: Supported
SSE42: Supported
AES: Supported
AVX: Supported
AVX2: Supported
AVX512F: Unsupported
AVX512PF: Unsupported
AVX512ER: Unsupported
AVX512CD: Unsupported
AVX512VNNI: Unsupported
SHA: Supported
CMPXCHG16B: Supported
LAHF/SAHF: Supported
PrefetchW: Unsupported
BMI1: Supported
BMI2: Supported
F16C: Supported
FMA: Supported
Operating System:
"Arch Linux" (64 bit)
Kernel Name: Linux
Kernel Version: 6.18.6-zen1-1-zen
X Server Vendor: The X.Org Foundation
X Server Release: 12101021
X Window Manager: i3
Steam Runtime Version: steam-runtime_1.0.20251202.187498
Client Information:
Version: 1769025840
Browser GPU Acceleration Status: Disabled
Browser Canvas: Unavailable
Browser Canvas out-of-process rasterization: Disabled
Browser Direct Rendering Display Compositor: Disabled
Browser Compositing: Disabled
Browser Multiple Raster Threads: Enabled
Browser OpenGL: Disabled
Browser Rasterization: Disabled
Browser Raw Draw: Disabled
Browser Skia Graphite: Disabled
Browser Video Decode: Disabled
Browser Video Encode: Disabled
Browser Vulkan: Disabled
Browser WebGL: Unavailable
Browser WebGL2: Unavailable
Browser WebGPU: Disabled
Browser WebNN: Disabled
Video Card:
Driver: AMD AMD Radeon RX 6750 XT (radeonsi, navi22, LLVM 21.1.6, DRM 3.64, 6.18.6-zen1-1-zen)
Driver Version: 4.6 (Compatibility Profile) Mesa 25.3.4-arch1.1
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 180 Hz
VendorID: 0x1002
DeviceID: 0x73df
Revision Not Detected
Number of Monitors: 2
Number of Logical Video Cards: 1
Primary Display Resolution: 2560 x 1440
Desktop Resolution: 3640 x 1920
Primary Display Size: 27.44" x 15.43" (31.46" diag), 69.7cm x 39.2cm (79.9cm diag)
Primary VRAM: 12288 MB
Sound card:
Audio device: ATI R6xx HDMI
Memory:
RAM: 64217 Mb
VR Hardware:
VR Headset: None detected
No VR configuration with trackers detected
Most number of trackers in a session: 0
Miscellaneous:
UI Language: English
LANG: en_US.UTF-8
Total Hard Disk Space Available: 3379417 MB
Largest Free Hard Disk Block: 1234631 MB
Storage:
Number of SSDs: 5
SSD sizes: 4000G,2000G,1024G,1024G,32G
Number of HDDs: 0
Number of removable drives: 1
Removable drive sizes: 15G

Replying to https://github.com/ValveSoftware/Proton/issues/9164#issuecomment-3620714787

Tried to apply this fix for Game Recording today. Seemed to work, until the game kicked me out for a System Integrity Violation (illegal file modification). Other proposed fixes using gamescope or scopebuddy didn't work either.

Have read reports this only stopped working after a recent update.

Same Issue On Linux Mint
Except The Game Crashes Anywhere From Literaly A Few Secconds Or Interacting With Literaly Any Part Of The Game
System Specs
proton: Literaly Any wether vales latest/experimental or any ProtonGE

@YourWaterSpencer the game seems to be working fine on my end. It'd be best if you grab a proton log for the game by adding this to the launch paramaters and running the game PROTON_LOG=1 %command%, this will create a file in your home folder called steam-1808500.log, you should upload it here.

That said, in your case, it might be worth updating your kernel version, 6.8 was released almost 2 years ago, and behavior might change with more recent versions.

@simifor no clue how to do that as a linux noob
and as far as i can see update manager shows me that i have the latest kernel

@YourWaterSpencer mint uses ubuntu lts as base which is why you get older kernel versions, it's by design. But there's software like this https://github.com/bkw777/mainline that allow you to install more recent kernel versions. After you install a kernel you have to select it during the boot menu

@YourWaterSpencer mint uses ubuntu lts as base which is why you get older kernel versions, it's by design. But there's software like this https://github.com/bkw777/mainline that allow you to install more recent kernel versions. After you install a kernel you have to select it during the boot menu

@simifor not gonna mess arround in the kernel for that soo ill pass

@YourWaterSpencer the game seems to be working fine on my end. It'd be best if you grab a proton log for the game by adding this to the launch paramaters and running the game PROTON_LOG=1 %command%, this will create a file in your home folder called steam-1808500.log, you should upload it here.

That said, in your case, it might be worth updating your kernel version, 6.8 was released almost 2 years ago, and behavior might change with more recent versions.

cant upload log since apparently its too big

the log file is 93 megabytes from like a minute of play (just clicking through tabs in the main menu) before i clicked on the quests tab and it crashed instantly

honestly i have no clue how this game went form working perfectly on first launch
to just crashing like theres no tomorrow the next day
and now just crashing on either the intro sequence or the quest tab
edit: it also crashes on loading into any run

@YourWaterSpencer
cant upload log since apparently its too big

The logs compress really well. zip or tar.gz the file, and upload that instead.

@YourWaterSpencer
cant upload log since apparently its too big

The logs compress really well. zip or tar.gz the file, and upload that instead.

ok so i updated my system to the newest available after getting help from the linux mint forums about missing updates and now the game crashes the moment the shaders are preloaded (as far as i can see from just watching when the game freezes)

logs.tar.gz

update we got back into the game and it still crashes the same way as i said in my previous commment
(crashes on quest tab on npcs BUT NOT on loading run :3)

logs.tar.gz

update # 2 as i was testing out how long till the game crashes i managed to get into the quests menu without changing anything so for now i am 50% sure my problems are resolved but i will report back immediately if any crashes reoccur

Hello everyone,

I'm joining this conversation as I have some issues with the game that I can't seem to fix with any tinkering whatsoever, and that looks unknown among ProtonDB reports for the game.

Specs :

• GPU : AMD Radeon RX 9070 XT
• CPU : AMD Ryzen 9 9950X3D
• RAM : 64 GB DDR5
• Linux Kernel : 6.17.7
• Distribution : Bazzite (Fedora)
• Driver : Mesa 25.3.3
• System info : Gist to device info
• PROTON_LOG output : steam-1808500.tar.gz
• Proton version : experimental-10.0-20260227

Issue :
Systematically, a couple minutes after the game launched, it crashes. I've found nothing that influences it, whether I stay AFK or quickly navigate the menus and try to play, the crash looks unrelated and happens anyway.
Launch options and env vars make no difference (the logfile is from a "clean" environment launch just to be safe).
The issue persists between system reboots.
My system is up to date but I'm carefully watching for new updates in case there is a new one.

If there is anything I can provide that would help, please let me know.

Thank you !!

@SeraphFive we have similar hardware, but on my end the game is stable. With a 9070, 7800X3D, mesa git from 2 days ago and stable 26.0.1, linux 6.18.13. No crashes.

After the game crashes, do you see amdgpu errors when running sudo dmesg in your terminal?
Do you have any sort of overclock or undervolt going for you cpu/gpu/ram?

@simifor Hey ! Thank you for your response ! I'm happy to hear that the game works okay for you, to be honest this actually gives me hope.
I tried again and checked the output of the command you gave me, and yup I got more info about the crash compared to the Proton log ! I'm not 100% sure about what I should do next but there you go !

[ 1361.819345] PioneerGame.exe[13567] vsyscall read attempt denied -- look up the vsyscall kernel parameter if you need a workaround ip:70000086815c cs:33 sp:b9b988 ax:b9b9f0 si:b9e670 di:ffffffffff600000
[ 1361.823355] PioneerGame.exe[13567] vsyscall read attempt denied -- look up the vsyscall kernel parameter if you need a workaround ip:70000086815c cs:33 sp:b9b988 ax:b9b9f0 si:b9e670 di:ffffffffff600000
[ 1361.835831] PioneerGame.exe[13567] vsyscall read attempt denied -- look up the vsyscall kernel parameter if you need a workaround ip:70000086815c cs:33 sp:b9b988 ax:b9b9f0 si:b9e670 di:ffffffffff600000
[ 1361.837963] PioneerGame.exe[13567] vsyscall read attempt denied -- look up the vsyscall kernel parameter if you need a workaround ip:70000086815c cs:33 sp:b9b988 ax:b9b9f0 si:b9e670 di:ffffffffff600000
[ 1361.842327] PioneerGame.exe[13567] vsyscall read attempt denied -- look up the vsyscall kernel parameter if you need a workaround ip:70000086815c cs:33 sp:b9b988 ax:b9b9f0 si:b9e670 di:ffffffffff600000
[ 1361.848154] PioneerGame.exe[13567] vsyscall read attempt denied -- look up the vsyscall kernel parameter if you need a workaround ip:70000086815c cs:33 sp:b9b988 ax:b9b9f0 si:b9e670 di:ffffffffff600000
[ 1361.851269] PioneerGame.exe[13567] vsyscall read attempt denied -- look up the vsyscall kernel parameter if you need a workaround ip:70000086815c cs:33 sp:b9b988 ax:b9b9f0 si:b9e670 di:ffffffffff600000
[ 1361.855814] PioneerGame.exe[13567] vsyscall read attempt denied -- look up the vsyscall kernel parameter if you need a workaround ip:70000086815c cs:33 sp:b9b988 ax:b9b9f0 si:b9e670 di:ffffffffff600000
[ 1361.868319] PioneerGame.exe[13567] vsyscall read attempt denied -- look up the vsyscall kernel parameter if you need a workaround ip:70000086815c cs:33 sp:b9b988 ax:b9b9f0 si:b9e670 di:ffffffffff600000
[ 1361.878838] PioneerGame.exe[13567] vsyscall read attempt denied -- look up the vsyscall kernel parameter if you need a workaround ip:70000086815c cs:33 sp:b9b988 ax:b9b9f0 si:b9e670 di:ffffffffff600000
[ 1363.646910] umip: wine_threadpool[13592] ip:700001a9dafb sp:3ccbd210: SMSW instruction cannot be used by applications.
[ 1363.646915] umip: wine_threadpool[13592] ip:700001a9dafb sp:3ccbd210: For now, expensive software emulation returns the result.
[ 1365.648644] umip: wine_threadpool[13586] ip:700001a9dafb sp:3877d210: SMSW instruction cannot be used by applications.
[ 1365.648655] umip: wine_threadpool[13586] ip:700001a9dafb sp:3877d210: For now, expensive software emulation returns the result.
[ 1367.662138] umip: wine_threadpool[13698] ip:700001a9dafb sp:8eeed210: SMSW instruction cannot be used by applications.

Also, to answer your question, I've done no tinkering at all on my CPU, GPU or RAM...

Again, thank you so much for your time ! <3

@SeraphFive unfortunately, those are red herrings, as I get them on my end too. When the game crashes, do you get the unreal engine crash handler window? If you do, that's likely to dump extra information about the crash in the game's prefix.

Also, as you've said that nothing you've tried has helped, I imagine you already did this, but just in case. Does the issue persist if you use the low graphic preset, disable ray tracing and disable upscalers? because there's always a chance a specific setting, or combination of settings might have an effect

For me, this is still constantly crashing, no matter what I do.

The things I tried:

• adjusted sysctl as recommended here (that actually helped back in november)
• all different graphic settings from low to cinematic, RTX on/off, power saving options
• even tried gamescope
• dx11 vs dx12
• proton ge vs normal proton vs proton experimental
• Switched from Sway to Hyprland in the hope this might make an answer

Nothing fixes constant crashes, sometimes it just closes, other times it will give me the UE Crash Dialog, and then there is these types of crashes where it freezes my entire computer.

System

OS: CRUX
CPU: Ryzen 7 5800X
GPU: Radeon RX 7800 XT
Memory: 64 GB DDR4
Steam: native (non flatpak)

Edit: I should note that I don't under-/overclock this system either.
@EmersonBiggons We seem to have a very similar system, do you still play this game and if you do, is this solved for you or not?

Compatibility Report

• Name of the game with compatibility issues: ARC Raiders
• Steam AppID of the game: 1808500

System Information

• GPU: NVIDIA GeForce RTX 2060 Max-Q + AMD Radeon iGPU hybrid setup
• Video driver version: NVIDIA 595.71.5
• Kernel version: Linux 7.0.2-arch1-1-g14
• Link to full system information report as Gist: https://pastebin.com/Dwt3rDmC
• Proton version: Proton Experimental, latest GE-Proton, and Proton-TKG tested

I confirm:

• [x] that I haven't found an existing compatibility report for this game.
• [x] that I have checked whether there are updates for my system available.

Symptoms

ARC Raiders runs correctly under Proton, but the FSR3 Frame Generation option never appears in-game on Linux/Proton.

This happens even though the log shows that FSR and frame generation related components appear to load successfully:

• amd_fidelityfx_upscaler_dx12.dll loads successfully
• amd_fidelityfx_framegeneration_dx12.dll loads successfully
• VKD3D detects FSR resources
• NVAPI works
• Reflex latency markers work
• DX12/VKD3D swapchain initializes correctly

Relevant log lines include:

NtGdiDdDDIQueryAdapterInfo type 31 stub
NtGdiDdDDIQueryAdapterInfo type 48 stub
FSR resource detected. Forcing retained GPU reference to work around broken integration code in either game or UE5.

Observed behavior:

• FSR upscaling components load
• FSR frame generation DLL loads
• FSR resources appear active during runtime
• DLSSG / NVIDIA Streamline components initialize but unload shortly afterward
• Frame Generation option never appears in the game UI

This was tested with:

• Proton Experimental
• latest GE-Proton
• Proton-TKG
• NVAPI enabled
• VKD3D_FEATURE_LEVEL=12_2
• PROTON_HIDE_APU=1
• NVIDIA-only Vulkan ICD
• Gamescope
• latest NVIDIA driver available on system

The issue does not appear to be a local configuration issue. It is reproducible across multiple Linux systems, including another PC, and public reports exist describing missing ARC Raiders frame generation options on Linux.

Theory

ARC Raiders may be querying WDDM / D3DKMT / HAGS-related capability APIs through Streamline or frame-generation capability checks. Proton/Wine appears to stub or incompletely implement some D3DKMTQueryAdapterInfo paths, especially type 31 and type 48, which may cause the game to hide or disable frame generation support despite FSR resources loading correctly.

Potentially related:

• D3DKMTQueryAdapterInfo
• D3DKMTEnumAdapters2
• WDDM_2_7_CAPS
• Hardware Accelerated GPU Scheduling / HAGS capability reporting
• NVIDIA Streamline frame generation capability checks
• ValveSoftware/wine#259

Reproduction

1. Install ARC Raiders on Linux through Steam.
2. Use any version of Wine or Proton (Tested with CachyOS, all possible forks of Proton that are still valid to try, and all Wine forks).
3. Launch with logging enabled:

PROTON_LOG=1 PROTON_ENABLE_NVAPI=1 DXVK_ENABLE_NVAPI=1 PROTON_HIDE_NVIDIA_GPU=0 PROTON_HIDE_APU=1 %command%

1. Open the game.
2. Go to graphics settings.
3. Observe that FSR3 Frame Generation does not appear as an available option.
4. Check the generated ~/steam-1808500.log.

Expected result

FSR3 Frame Generation should appear and be enableable when the game loads FSR3 components successfully.

Actual result

FSR3 Frame Generation does not appear in the UI, despite FSR3-related DLLs and resources being loaded/detected in logs.

Summerised logs around FSR3/Frame Generation in general: https://pastebin.com/izNADNvw

Replying to https://github.com/ValveSoftware/Proton/issues/9164#issuecomment-4412032699

I did another controlled test based on Saancreed’s suggestion: fresh compatdata/prefix, NVIDIA-only Vulkan, then a hide-NVIDIA / disable-NVAPI run.

The test used a fresh ARC Raiders prefix and launch options intended to prevent the game from seeing the normal NVIDIA/NVAPI path:

VK_DRIVER_FILES=/usr/share/vulkan/icd.d/nvidia_icd.json \
PROTON_DISABLE_NVAPI=1 \
DXVK_ENABLE_NVAPI=0 \
PROTON_HIDE_NVIDIA_GPU=1 \
WINE_HIDE_NVIDIA_GPU=1 \
PROTON_HIDE_APU=1 \
PROTON_LOG=1 %command%

This did appear to work mechanically. The Proton log shows options including:

disablenvapi
hidenvgpu
hideapu

and VKD3D reports the device as:

AMD Radeon RX 6700 XT (NVIDIA 610.43.2)

So the game was no longer seeing the GPU as a normal NVIDIA/NVAPI device, while still rendering through the NVIDIA Linux driver.

Important result: in this run, the previous NtGdiDdDDIQueryAdapterInfo type 31 / type 48 / type 70 warnings were no longer present in the relevant grep output. So hiding NVIDIA/NVAPI seems to avoid that previous AdapterInfo path.

However, AMD FSR Frame Generation still did not become available.

The game still loads its bundled FidelityFX DLLs:

amd_fidelityfx_upscaler_dx12.dll
amd_fidelityfx_framegeneration_dx12.dll

and VKD3D still repeatedly logs:

FSR resource detected. Forcing retained GPU reference to work around broken integration code in either game or UE5.

Another suspicious line in this run is:

AmdExtStub1_QueryInterface2 unknown guid {f714e11a-b54e-4e0f-abc5-df58b18133d1}

This appears around the FSR/DXGI area and may be more relevant now than the previous type 31/48 AdapterInfo warnings.

There are also still D3D12/resource related gaps, including NtGdiDdDDIOpenResourceFromNtHandle ... semi-stub, plus descriptor/resource pressure warnings later in the log.

So my current narrowed conclusion is:

• Fresh prefix alone does not fix it.
• HAGS registry workaround alone does not fix it.
• Hiding NVIDIA/NVAPI does not fix it.
• The old type 31 / 48 / 70 AdapterInfo path may not be the final blocker.
• The game still reaches the FidelityFX path, creates FSR resources, and loads the FSR Frame Generation DLL.
• The remaining blocker may be deeper in VKD3D / D3D12 / AMD extension handling / UE5 FidelityFX integration rather than simple GPU detection.

I can provide the full deep grep log if useful.