Well, purging and reinstalling the Nvidia drivers seems to have helped with at least 50% of my test games. The purge knocked out Mint's Nvidia Prime Applet so I had to reinstall that as well.

The Ardenfall Demo and The First Templar have stopped locking up. Haven't checked Mordheim yet. Styx: Shards of Darkness still locks up before it reaches the main menu (but it could have been corrupted before the Mint upgrade -- I didn't check).

The frustrating one is Divinity 2: Developer's Edition. I know it was working fine before the Mint upgrade but it still randomly locks up the video after reinstalling the drivers. The sound and game continue on behind the frozen video. Gstreamer and GameMode continue to throw errors in the log. Apparently, though, this kind of screen lockup happens randomly in Windows as well. It could be the game, I suppose.

I do clean installs on major version upgrades for my daily driver laptop. I guess I'll have to consider doing the same on my T580. Less hassle and frustration, even if I have to reserve more space for an extra filesystem partition...

Last edited by Caldathras on 9 Mar 2026 at 5:07 pm UTC

The problem is an insidious unpredictably random and intermittent lock up that only affects Wine/Proton games utilizing the Nvidia dGPU. Anything on the Intel iGPU works fine. Native games on OpenGL or Vulkan are unaffected. Windows 10 is completely unaffected, so it's not a hardware issue. My test games in Wine/Proton are still locking up.

I give up. I can't figure out what's wrong, much less fix it. Clearly, something corrupted during the upgrade. Time to fire up Clonezilla.

Back to Mint 21.3 I go ...

The next time I try Mint 22, it will be via a clean install.

what was the driver version? 590?
i have seen some people had issues with 590 drivers compared to 580 or 595. Maybe that was the issue
but anyway journalctl logs would have been nice to see what actually happens i guess..
but if you went back to earlier mint then i guess thats it atm.

Quoting: Xpanderwhat was the driver version? 590?
i have seen some people had issues with 590 drivers compared to 580 or 595. Maybe that was the issue
but anyway journalctl logs would have been nice to see what actually happens i guess..
but if you went back to earlier mint then i guess thats it atm.

Thanks for the response. My dGPU is a Pascal chipset, so I won't be progressing past the 580 series. I rolled back to Mint 21.3 yesterday and everything is functioning normally again so it was definitely some sort of corruption.

My next attempt will be a clean install in a separate partition, so I can maintain my old setup until I know the new one is working correctly. Got to love Linux's dual-boot feature (multi-boot, really). I use this approach on my daily driver and it has never failed me.

Sorry. I wasn't aware of these journalctl logs. What are they and, more importantly, how do I obtain them if I need help in the future?

Thanks again.

Quoting: CaldathrasThanks for the response. My dGPU is a Pascal chipset, so I won't be progressing past the 580 series. I rolled back to Mint 21.3 yesterday and everything is functioning normally again so it was definitely some sort of corruption.

My next attempt will be a clean install in a separate partition, so I can maintain my old setup until I know the new one is working correctly. Got to love Linux's dual-boot feature (multi-boot, really). I use this approach on my daily driver and it has never failed me.

Sorry. I wasn't aware of these journalctl logs. What are they and, more importantly, how do I obtain them if I need help in the future?

Thanks again.

journalctl -b -1 
for example to check the logs from one boot before current.
or
journalctl -b
from current boot
and you look for the timestamps where the lockup happened, if theres anything funny going on

Quoting: Xpander

Quoting: CaldathrasThanks for the response. My dGPU is a Pascal chipset, so I won't be progressing past the 580 series. I rolled back to Mint 21.3 yesterday and everything is functioning normally again so it was definitely some sort of corruption.

My next attempt will be a clean install in a separate partition, so I can maintain my old setup until I know the new one is working correctly. Got to love Linux's dual-boot feature (multi-boot, really). I use this approach on my daily driver and it has never failed me.

Sorry. I wasn't aware of these journalctl logs. What are they and, more importantly, how do I obtain them if I need help in the future?

Thanks again.

journalctl -b -1 
for example to check the logs from one boot before current.
or
journalctl -b
from current boot
and you look for the timestamps where the lockup happened, if theres anything funny going on

Well, everything was working fine after I rolled back to Mint 21.3. Then I connected to the Internet and let Mint install updates (including Steam updating itself). Now I am having the same problem I was having in 22.3.

I've looked through the journalctl logs but I can't really make heads or tails of what I'm seeing. Nothing obvious. I have noticed that the games that are locking up the most are running on Proton 10 Experimental (Steam) or GE-Proton 10.25 (Heroic UMU).

I haven't had time to pursue the matter further. Once I do, I am going to test the Proton 10 theory and capture the journalctl log to upload. I'm thinking that a list of the recently updated components might be good as well. I just have other priorities at the moment, so it will have to wait.

I have been trying for a while to research the problem myself with little luck, until it dawned on me that the games running in Proton/Wine that were locking up were the ones using DXVK on the Nvidia dGPU. Those using Vulkan, OpenGL or running on the Intel iGPU were not having problems. So I searched under DXVK locking up instead.

I immediately discovered a GitHub bug report that exactly matched my problem. In fact, there are numerous threads/complaints posted on the DXVK GitHub about the problem. I've traced it back as far as 2024. What I find curious is why it took so long for this bug to affect my systems.

https://github.com/doitsujin/dxvk/issues/5308

Both my Kepler and my Pascal laptops are experiencing this issue, but only in Linux Mint. I also have Pop!_OS 22.04 installed on my Kepler laptop and it is not affected by the issue (admittedly, I'm a little behind on the updates with Pop!_OS).

According to my research, the issue is related to the proprietary Nvidia drivers, DXVK and Xorg (x11). The problem only seems to affect Optimus/ Prime users. Nvidia doesn't seem to care. Some users have had luck by placing the Nvidia dGPU in "performance mode". Others say moving to Wayland has solved the problem. They also say that using the open source drivers (Mesa/NVK) works as well.

I have a lot to test. Pop!_OS on my Kepler laptop is set to Nvidia only. That might be a good indication of where to begin...

Still working on the Kepler laptop but I can confirm that placing the Nvidia dGPU in "performance mode" worked on my Pascal laptop. I couldn't test the Wayland solution, since my DE is XFCE on that laptop.

The DXVK games are stable again. The "prime-run" command (or rather, the environment variable equivalent), on the other hand, did some bizarre things to my Native Linux games. The framerate was all over the place, causing massive stuttering -- and that was just loading and getting to the main menu. Curiously, the AppImages were unaffected. Removing/clearing the "Use Nvidia GPU" command/toggle dealt with that issue. I guess that's a side-effect of trying to use that feature when you are already in "performance mode".

Lutris does not seem to do well with "performance mode" enabled. Lots of screen fragmentation and weird flashes. At least the games still launch and it's not so bad that it's unusable.

Interestingly, Heroic Launcher is not affected at all and runs normally. Even having the "Use Nvidia GPU" toggle enabled (old version, recently removed in newer versions) didn't cause any issues in Heroic (it did in Lutris).

Like Heroic, Steam was rock-solid and unaffected by being in "performance mode".

Last edited by Caldathras on 31 Mar 2026 at 5:06 pm UTC