protonscr

Total kernel lockup with games ran through Wine on a Lynnfield CPU

dxvkclosed
doitsujin/dxvk#4457 · opened 2024-11-14 by ghost · updated 2024-11-15 · 9 comments · github
?ghost 2024-11-14 github

Software information

Any game that is remotely demanding. Experienced with Honkai Star Rail, Zenless Zone Zero, Cloudpunk with any settings.

System information

  • CPU: Intel Xeon X3450
  • GPU: AMD HD 7870 (attempted using an RX 5700 too, it didn't help)
  • Driver: amdgpu, RADV (mesa 24.2.7)
  • Wine version: staging 9.18
  • DXVK version: 2.2, 2.4, 2.4.1, 2.5

Neither apitrace nor logging worked here because it locks up so quickly that nothing works, sysrq, TTY, you name it. I end up having to shut down the PC with the power button and the files either get corrupted or there isn't anything crash-related in the logs, presumably because they fail to record once it crashes. Games do not crash with wined3d (although they run much worse) and the PC runs them perfectly fine in Windows with no DXVK. I tested the 7870 GPU in my main Arch rig with a 5700X3D and it also ran DXVK games fine, so almost certainly something's up about the way DXVK works with old CPUs.

What makes me think it's a DXVK issue is the fact that this issue disappears once I try using a fork called dxvk-gplasync. It's definitely not a coincidence, because with vanilla DXVK, the same games crash within a minute 90% of the time and no matter how hard I tried, I couldn't get that fork to crash. I'm not sure what exactly is different about that fork aside from (I guess?) some tweaks to async and gpl features, but I don't use async or gpl cache regardless. Also tried running the games with these options enabled for vanilla DXVK, but it didn't help. I'll try adding more information if I manage to get any, including the logs.

Mmbriar 2024-11-14 github

Cyberpunk doesn't even use DXVK being a DX12 game.

Ddoitsujin maintainer 2024-11-14 github

Well Cyberpunk is a D3D12 game for starters, so are you sure your system isn't just untable?

?ghost 2024-11-14 github

Well Cyberpunk is a D3D12 game for starters, so are you sure your system isn't just untable?

Had a brain fart, I meant Cloudpunk. I'm mostly sure about it being ok, because I ran lots of tests, bumped the CPU/IMC voltage etc and no problem ever arises until I try running a game in Linux with a translation layer specifically. Native Linux games run fine. OCCT didn't show RAM errors and I ruled out GPU issues by trying to run the PC with an RX 5700.

I guess having someone else test Wine with DXVK on an LGA1156/1155 machine would be a good idea because I couldn't find any info on Linux (or Vulkan in general) gaming experiences with them, but despite being old and lacking AVX instructions, these CPUs are still capable for many games if the expectations aren't too high.

Ddoitsujin maintainer 2024-11-14 github

DXVK can run on a Pentium 4 (we require SSE3, but nothing beyond that), so I really don't see why it wouldn't work on these CPUs.

And the fact that you say it locks up your entire system rather than just crashing the game makes me rather doubtful that this is a software issue in the first place. You could always try building DXVK with custom build flags or something though and see if changing anything there fixes your issue.

VViNi-Arco 2024-11-14 github

I guess having someone else test Wine with DXVK on an LGA1156/1155 machine would be a good idea because I couldn't find any info on Linux

This sounds like a ram memory problem to me, remove the memory, wipe it with a contact cleaner and make sure it's connected properly and reset the bios settings, beforehand, if possible, discharge the static energy from your body and wear anti-static gloves.

I say this because I have two old configurations here, an LGA775 Q9650+DDR3 and an 1155 I3 3240, which are working very well, and I even use an RX 570 on the Q9650.

?ghost 2024-11-14 github

Well, some helpful tweak is seemingly applied to DXVK in gplasync fork, as it runs okay with the same games even though I'm still not using async or gpl. I don't understand DXVK's code very well at the moment but I'll try to report if I find anything interesting, or if it was a hardware issue all along. It's a very confusing case for me so far as I never had specific software (Linux with translation layers in this case) bring out hardware issues that weren't already manifesting in other ways (trust me, I tried really hard to make it crash in other scenarios).

Bbrittyazel 2024-11-14 github

Well, some helpful tweak is seemingly applied to DXVK in gplasync fork, as it runs okay with the same games even though I'm still not using async or gpl. I don't understand DXVK's code very well at the moment but I'll try to report if I find anything interesting, or if it was a hardware issue all along. It's a very confusing case for me so far as I never had specific software (Linux with translation layers in this case) bring out hardware issues that weren't already manifesting in other ways (trust me, I tried really hard to make it crash in other scenarios).

Since version 2.3, dxvk-gplasync now enables async by default. So unless you explicitly disabled it, you likely are making use of async.

Nnetborg-afps 2024-11-15 github

In such a case, I'd look into options to reduce stress to your hardware, like
DXVK_FRAME_RATE env variable and dxvk.numCompilerThreads in the dxvk.conf.

?ghost 2024-11-15 github

Turns out this probably was CPU failure manifesting itself in a really weird way, which is a first for me. I tried replacing the only part I didn't try replacing yet (the CPU) with an i3 540 I had laying around. Now, it may run about as fast as a snail on redbull, but it no longer crashes at all, with vanilla DXVK versions as well.

Not sure what's up with gplasync fork (or Windows for that matter) masking this problem so well, or why isn't it showing up in actual stress tests. Power delivery seems fine for the Xeon as well (PC has a year old tier B 500W PSU and a P7H55-M/USB3 motherboard). So, closing I guess.

Launch options