Yes, this is patched in 6.9. Since it’s a new major release, it’ll take a few weeks before we see it in Fedora while they check for major regressions and stability. Stable updates (like 6.8.8 to 6.8.9) are much quicker, usually taking only a few days, but major releases add much more to the kernel and need to be properly tested for regression. If you wanted to use Bazzite, you’d have to compile the 6.9 kernel yourself and overlay it, though I’m not sure the steps you’d need to take exactly given that I’ve never tried compiling the kernel for an atomic distro before. Perhaps you can find something online about it, but I didn’t find an easy guide when I searched it (just non-atomic kernel compilation). I did find documentation on how to change the kernel in an rpm-ostree based system, but you’ll still have to compile it yourself and then override the rpm you compile with that method. Instructions on compiling a kernel for Fedora can be taken from here for reference.

I’m going to hack together some stuff from both sources with what I think will work in Bazzite using rpm-ostree (and a toolbox so you don’t have to overlay a bunch of packages as build dependencies). This is untested, as I really don’t want to have to compile a kernel myself; my computer isn’t nearly fast enough for that to be reasonable right now. Luckily, based on the custom kernel documentation, it seems this process is quite easy with Fedora’s kernel dist-git. No manual configuration should be required, just a few commands (Secure Boot complicates things dramatically, but the Fedora documentation already has the instructions for getting this to work with Secure Boot, so that should hopefully just work).

None of the commands I provide are irreversible, and can be reverted easily. Since we are working with an atomic distro, you can always rollback to a previous version if you encounter issues. Reverting to the default kernel is as simple as removing the override we create for the compiled one.

WARNING: This will use Fedora 41’s kernel configuration. It may differ from both Fedora 40 and Bazzite’s kernel configuration. Understand that there is a small chance this will cause problems, in which case you can rollback to the previous version or remove the override at any time to uninstall and revert back to the base kernel.

Open up a terminal, and enter the default toolbox (if you do not have a default toolbox yet, you can create one with toolbox create)

toolbox enter

From the Fedora custom kernel documentation

Install dependencies inside toolbox

sudo dnf install fedpkg
fedpkg clone -a kernel
cd kernel
sudo dnf builddep kernel.spec

Checkout from the Fedora kernel dist-git

git clone https://src.fedoraproject.org/rpms/kernel.git

Switch to Fedora 41 branch (since it has 6.9 already)

git switch f41

Do you use Secure Boot? Because if you do, then it gets WAY more complicated and I don’t know for a fact that this will work properly. Only do the stuff in the Secure Boot section if you use Secure Boot!

---------------SECURE BOOT CONFIG---------------

NOTE: Update values enclosed in <> to appropriate values (for example, changing <your name> to mranachi or <MOK certificate nickname> to MOK-temp-6-9-kernel)

Add your user to /etc/pesign/users if it does not already exist.

nano /etc/pesign/users

Run authorize user script

sudo /usr/libexec/pesign/pesign-authorize

Create a new Machine Owner Key

openssl req -new -x509 -newkey rsa:2048 -keyout "key.pem" \
        -outform DER -out "cert.der" -nodes -days 36500 \
        -subj "/CN=<your name>/"

Import MOK into your UEFI key database

mokutil --import "cert.der"

Create a PKCS #12 key file

openssl pkcs12 -export -out key.p12 -inkey key.pem -in cert.der

Import the certificate and key into the nss database

certutil -A -i cert.der -n "<MOK certificate nickname>" -d /etc/pki/pesign/ -t "Pu,Pu,Pu"
pk12util -i key.p12 -d /etc/pki/pesign

Add line %define pe_signing_cert <MOK certificate nickname> to the kernel.spec file (I am assuming it is in the current directory based on the wording of the Fedora documentation, though I have not seen any of these files. It may be located elsewhere, but I have no idea where if that is the case)

nano kernel.spec

---------------SECURE BOOT CONFIG---------------

Build RPMs using the default Fedora 41 configs (this could take a very long time on slow hardware, but assuming you have a good CPU, it could actually take as little as 4 minutes)

fedpkg local

Exit the toolbox so we can install the RPM

exit

From the rpm-ostree kernel change documentation

Install the new kernel. I don’t know what the name of the RPM will actually be, so you may want to ls x86_64 and modify this command to match the appropriate RPM(s). Also, I can’t remember if exiting the toolbox keeps you in the same folder, so you may need to navigate back to the correct folder with cd kernel after exiting.

rpm-ostree override replace ./x86_64/kernel-*6.9.0*.rpm

Clean up

cd ../
rm -r kernel/

You may also optionally want to remove the build dependencies inside the toolbox if you want to save space.

Reboot, and in theory, you should be done (if you did the Secure Boot steps, you’ll have to accept the key when you reboot). I’d like to remind you that you can rollback any changes if you encounter any issues, as that is one of the many benefits of atomic distros.

Uninstalling compiled kernel

To revert the override (once 6.9 releases to Fedora 40 repos), simply do the following (this effectively uninstalls the compiled kernel and reverts back to whatever is in the base image):

rpm-ostree override remove kernel-*6.9.0*.rpm

you’d be better using debian than popos

I replied about getting the updated kernel on Bazzite on another one of your comments, but I want to clarify that this is not only a bug for those that have resizable bar and 4g decoding as BIOS options, and it does not always happen on game start. I just want to reinforce that this is very likely the exact issue you are experiencing, and it is patched in kernel version 6.9. This particular kernel bug happens when the CPU runs out of VRAM space that is accessible to it, and tries to move data to other parts of VRAM (with the help of the GPU) to make space in the section visible to the CPU. Since resizable bar makes all VRAM visible to the CPU, that’s why it fixes the issue for some, but that is not the root cause of the problem. There is an off by one error discussed in the kernel bug thread that was linked that incorrectly handles the VRAM swapping and only became an issue after a check was written to validate the hardware capabilities (which fails due to the off by one error). This can happen after some time playing the game, after the CPU-accessible part of VRAM is filled up, however long that takes.

This will be fixed in a few weeks when the 6.9 kernel is pushed to the Fedora repos, or you could compile and install the 6.9 kernel using my instructions on your other comment. Or you could continue to use Mint until the kernel is updated, whatever works for you. Other than this one obscure kernel bug, Bazzite will generally be the much better option for gaming as far as performance and user experience goes. Mint follows the Debian/Ubuntu update cycle, so its kernels are old and without many enhancements to gaming that exist in the newer versions of the kernel present in Bazzite and Fedora. Of course, you can choose whatever distro you’d like, I just wanted to provide a method for you to switch back to Bazzite if you prefer it (and explain what the issue is and how to fix it).

On Bazzite you could also swap to the gnome version for a bit without worrying. That one is still X11

True its still in the repo, I thought it was only on COPR.

Dont know GPU names but well, that is the issue when using Fedora and not SteamOS, where they test everything before shipping it.