Not 100% sure this is it, but mucking with kernel parameters is generally suspicious, and a kernel version change is likely to be the culprit here.
Those settings specifically are described by the kernel docs like this:
sg_display (int)
Disable S/G (scatter/gather) display (i.e., display from system memory). This option is only relevant on APUs. Set this option to 0 to disable S/G display if you experience flickering or other issues under memory pressure and report the issue.
exp_hw_support (int)
Enable experimental hw support (1 = enable). The default is 0 (disabled).
The former sounds like the kind of thing you enable for a week if you use a cutting edge kernel. The latter sounds like the kind of thing you enable for a week when you use cutting edge hardware on a cutting edge kernel.
Neither will be true during a NixOS upgrade, so I imagine neither should be set. In all likelihood, most of the kernel params you’re setting are similarly inadvisable to set permanently; try to remove them all and boot again.
If that solves it, it’s probably technically a kernel bug, but who knows whether upstream will bother to fix these kinds of edge cases for workarounds that have likely long since stopped being useful.
You should also consider to stop using the _latest kernel - the nvidia driver doesn’t play nicely with anything but LTS (which is the default), so this config will eventually cause issues for you anyway.
Just to clarify: those kernel parameters were added later while trying to diagnose and work around this issue, not something I was intentionally carrying forward as a permanent configuration.
Unfortunately, removing them again and booting with all default kernel parameters did not resolve the problem — the graphics still break after a rebuild.
The currently working system generation uses kernel 6.17.8 - this is the only configuration where both graphics and Wi-Fi are functional.
Additional observations:
Kernel 6.18.0: Wi-Fi driver fails to load completely (device not detected), so that kernel is unusable for me.
Kernel 6.17.10: graphics issues persist, same behavior as with newer kernels.
Kernel 6.17.8-zen: same result, graphics still broken after rebuild.
So far, 6.17.8 (non-zen) is the only kernel version that works reliably on this system.
I’m currently keeping the system functional by sticking to that specific kernel, but I’m trying to understand what changed between these versions.
Kernel 6.17.8, which is the only version that works reliably for me, is no longer available in the nixos repositories. This means I currently have no straightforward way to install that kernel on a clean or “normal” rebuild - only the old system generation still has it pinned.
Because of that, I’m effectively locked to the old generation for now and can’t reproduce the working setup using the current nixpkgs/kernel packages.
I think this is a question for the upstream Linux kernel maintainers. Personally, I’d figure out what the regression in the wifi driver is about, rather than this bug in amdgpu that has already been fixed.
Does the LTS kernel not support your hardware at all? Tbh, in that case the device is recent enough I’d send it back and exchange it for a slightly older one; You need at least six monthsish old support for all hardware in the kernel if you want to use a device with an nvidia card on Linux reliably.
My setup relies solely on amdgpu, and the regression I’m seeing is entirely within the amdgpu / DRM path. The issue reproduces even when the NVIDIA driver is not loaded or involved in any way.
So while I understand the general advice about NVIDIA and LTS kernels, in this particular case the problem is specifically with amdgpu on newer kernels, not with NVIDIA compatibility.
Moreover, the Radeon 610M was released in October 2022, so it is not particularly new hardware and should already be well within the support window for LTS kernels.
Without asking on the kernel mailing list, the best way to get to the bottom of this is bisecting the kernel and getting the precise commit that introduced the regression. Once you have that you can do with the information what you will; reverting the commit and running a custom kernel altogether might be a solution if you’re not willing to risk running an unsupported kernel base (though it’s arguable whether patches like that are less risky than just running an EOL kernel from a support perspective, which you could also totally do if you wanted to).
This definitely sounds like it’s above the NixOS discourse’s paygrade, in either case, you’re going to have more luck finding someone with specific experience with this kernel module and potential regressions for your hardware upstream.
To be clear, does amdgpu work with the 6.18 driver? If it does, I’d switch course to figuring out what’s wrong with the wifi driver instead, because then upstream has clearly already fixed the amdgpu issue and will probably either backport the fix soon or have decided not to for some reason, and you’ll probably find the answers you’re looking for on the kernel mailing list.
In that case, have you tried the LTS kernel? Do amdgpu and the wifi driver both work on it? Why use _latest at all? I’m not talking about your GPU specifically, but rather the sum of devices in there; it’s not uncommon for a wifi chip to lack support for many years.
To clarify: Wi-Fi was working fine on kernels prior to 6.18. The regression in the Wi-Fi driver only appears starting with 6.18.
As for amdgpu: it does work in the sense that the driver loads and graphics initialize correctly, but the GPU crashes roughly once per minute, producing amdgpu DRM coredumps. So it’s not completely broken, but clearly unstable on newer kernels.
I’ll also try the LTS kernel now and report back whether both amdgpu and Wi-Fi work reliably there.
I’ve tried switching to the LTS kernel as suggested, but the problem remains.
Before any upgrades, the system was working fine on nixos-25.05. After upgrading to 25.11, things started breaking. Rolling back to 25.05 afterwards does not fix it anymore - only booting the old system generation 94 still works reliably.