Mikeserv Support Forum

Posted: **Sun Oct 12, 2025 6:50 pm**

Linux 6.17.2
https://cdn.kernel.org/pub/linux/kernel ... Log-6.17.2

Small changelog, a few fixes.

This is an addition:

drm/amdgpu: Enable MES lr_compute_wa by default

commit 1fb710793ce2619223adffaf981b1ff13cd48f17 upstream.

The MES set resources packet has an optional bit 'lr_compute_wa'
which can be used for preventing MES hangs on long compute jobs.

Set this bit by default.

If I gave a shit about GPU computing, that might be nice. Call me old fashioned, but I use graphics cards for... graphics.

Posted: **Sun Oct 12, 2025 7:42 pm**

We were both posting at the same time

Posted: **Thu Oct 16, 2025 9:10 am**

And now 6.17.3

Posted: **Thu Oct 16, 2025 9:27 am**

Again, already. Some fixes that should be had this time though. For example:

drm/amdgpu/vcn: Fix double-free of vcn dump buffer

ext4: fix checks for orphan inodes

ext4: fix potential null deref in ext4_mb_init()

https://cdn.kernel.org/pub/linux/kernel ... Log-6.17.3

I guess I have another 2 minutes to spare to get this done before winding down.

Posted: **Mon Oct 20, 2025 7:50 pm**

Linux 6.17.4 now
https://cdn.kernel.org/pub/linux/kernel ... Log-6.17.4

This should be had for numerous ext4 fixes at least. It's a sizable changelog, I'm only about half way through it and I've got to get on with other things

Posted: **Fri Oct 24, 2025 7:48 am**

6.17.5

Posted: **Fri Oct 24, 2025 9:25 am**

Fuck... I just rebuilt my kernel to change a built in option tonight

Posted: **Fri Oct 24, 2025 9:40 am**

There's a fair bit of changelog, they may have had some shit queued up that didn't make it into .4 or something
https://cdn.kernel.org/pub/linux/kernel ... Log-6.17.5

I'm too spent to finish going through it, I'll have it done in 2 minutes

Posted: **Wed Oct 29, 2025 9:54 pm**

Linux 6.17.6 already
https://cdn.kernel.org/pub/linux/kernel ... Log-6.17.6

Bunch of fixes again, mostly for stuff that we'd never hit, but some of it should be had. For example fixes for xhci, memory, slab allocator and other stuff. I suppose if someone has a lot of displays connected this might interest them:

drm/amd/display: increase max link count and fix link->enc NULL pointer access

commit bec947cbe9a65783adb475a5fb47980d7b4f4796 upstream.

[why]
1.) dc->links[MAX_LINKS] array size smaller than actual requested.
max_connector + max_dpia + 4 virtual = 14.
increase from 12 to 14.

2.) hw_init() access null LINK_ENC for dpia non display_endpoint.

Posted: **Sun Nov 02, 2025 8:21 pm**

I think I liked it better when the point releases had slowed down

Linux 6.17.7
https://cdn.kernel.org/pub/linux/kernel ... Log-6.17.7

Probably more btrfs stuff than anything, but also sched-ext fixes (I don't use external cpu schedulers... the kernel's existing scheduling is fine. I tried others with the cachos patchsets and meh).

Also bug fixes for the bug fixes (retpoline etc.) that I don't use.

Posted: **Fri Nov 14, 2025 1:40 am**

Linux 6.17.8
https://cdn.kernel.org/pub/linux/kernel ... Log-6.17.8

Lots of drm/amdgpu/display related stuff this time. It's a long changelog too, though.

Posted: **Fri Nov 14, 2025 3:37 am**

That kernel 6.17.8 amdgpu (or more likely drm/amd/display) subtly broke with X11, I could no longer operate without a compositor. As soon as I tried to open Steam or Firefox in my beloved Icewm window manager (for gaming) My mouse would freeze (then move a bit, even snap back again lol)... it's those damned dcmub errors again (display micro controller). It wasn't happening in XFCE where it has a compositor so I just got a nasty surprise when I opened Steam. Back when I was having those errors before (probably still would) it was because of display power management. I don't use that in icewm or fluxbox anymore because of it, but this time it was being caused when applications that have compositors themselves (steam, firefox... both composited canvas) were loading.

I tried rebooting, cold booting but it was reproducible every time.

Back to 6.17.7 now and it's working correctly again.

Posted: **Sun Nov 16, 2025 5:21 am**

Arch has gone to 6.17.8 but CachyOS is currently sticking to 6.17.7, usually they move to the latest kernel before Arch does but not in this case.

Posted: **Sun Nov 16, 2025 6:23 am**

This is what happens when things are inappropriately backported. Current Mesa has broken Vulkan video too (which I use in my mpv player), they backported something that shouldn't have been for 25.2 because it lacks other necessary changes. I'm on 25.3 so it didn't affect me, but I held off updating to Mesa 25.2.7 in Crux.

I'm just going to hold out until 6.18 and if I'm still having that problem I'll squawk then.

Posted: **Mon Nov 24, 2025 5:43 pm**

6.17.9 released today, and 6.18 is now at rc7 so maybe it will be released next Sunday.

Posted: **Mon Nov 24, 2025 8:54 pm**

I went through the changelog, there's a bit of amdgpu related stuff. I'm not sure if anything is going to fix my problem (I think it's drm/amd/display rather than amdgpu) but it won't take long to find out.

https://cdn.kernel.org/pub/linux/kernel ... Log-6.17.9

This one looks somewhat promising, though I'm not holding my breath.

drm/amd/display: Add pixel_clock to amd_pp_display_configuration

[ Upstream commit b515dcb0dc4e85d8254f5459cfb32fce88dacbfb ]

This commit adds the pixel_clock field to the display config
struct so that power management (DPM) can use it.

We currently don't have a proper bandwidth calculation on old
GPUs with DCE 6-10 because dce_calcs only supports DCE 11+.
So the power management (DPM) on these GPUs may need to make
ad-hoc decisions for display based on the pixel clock.

Also rename sym_clock to pixel_clock in dm_pp_single_disp_config
to avoid confusion with other code where the sym_clock refers to
the DisplayPort symbol clock.

I'm getting tired of people breaking my shit.

P.S. Nope... and I've had it with this fucking crap. I'm not using Wayland... if X11 won't work then this shit can just fuck off. I'm not interested in being unable to configure things my way because people want to force new shit. I'd probably rather fight with Windows than that... as they destroy everything I like about the Linux environment. Every new version of everything seems to take something away from me now.

Posted: **Mon Nov 24, 2025 9:57 pm**

Ahh... this seems to not occur in Linux 6.18.0-rc7 so it probably is inappropriate backporting. I can live with that, I'll stay on this train for 6.18 now.

Posted: **Mon Nov 24, 2025 11:05 pm**

Shit, now here's something really stupid.

It worked on my first 6.18-rc7 install because I still had my old kernel booted. However, I wasn't happy with the nomenclature (and wanted to change an option anyway) so I redid it.

Kernel module vfat. It's configured with default code page 437 and NLS iso-8859-1. You'd think that "modprobe vfat" would then load nls_cp437 and nls_iso8859_1 but no... it doesn't load those automatically until you go to mount it. Since kernel naming is fucked in a pre-release... it's 6.18-rc7 but the modules directory and actual "uname -r" kernel name is 6.18.0-rc7 that messes up my script. So I did the install manually. I loaded vfat first before deleting the modules directory and found out that I couldn't mount my EFI partition to edit grub.cfg and I had already deleted the old kernel and modules from both systems (Arch and Crux... my script installs for both)

Since I put my kernel in the root directory as /vmlinuz-xxxx I got out of it without having to boot with a rescue disk by simply renaming the kernel image file to what was in grub.cfg. The kernel knows where it's modules tree is, so that worked. Now I can manually fix it so my script works for uninstall/install again for next time (which will be 6.18.0).

That's quite the gotcha, that wouldn't have been as critical if EFI wasn't FAT32. I HATE languages in the filesystem... fucking Microsoft. That's why I will never enable that case folding crap for case insensitive directories with ext4, because it has to put language support in the filesystem.

However, ultimately this is the kernel's fault for not loading the default code page and NLS with the filesystem driver. What's the point of having a default then if it's TBD at mount time? I don't want to build that shit right in, as the only time I use vfat is to mount the EFI to install a kernel. I don't even use vfat on USB sticks anymore. Oh well, now I know.

Posted: **Tue Nov 25, 2025 6:37 am**

Glad that got you past that issue at least

Posted: **Mon Dec 01, 2025 6:42 am**

Linux 6.18 is out now, website updated and everything.

Posted: **Fri Dec 12, 2025 7:48 pm**

Linux 6.18.1 now... non-anal distros should start shipping this now
https://cdn.kernel.org/pub/linux/kernel ... Log-6.18.1

A bunch of fixes for a bunch of things. Nothing exciting. A few ext4 fixes justify it for me.

Posted: **Sat Dec 13, 2025 7:39 am**

Arch should start shipping it now, but that doesn't matter to me anymore since CachyOS shipped 6.18 within the first few days

Posted: **Sat Dec 13, 2025 7:47 am**

Groganarch had it before it even existed

Posted: **Fri Dec 19, 2025 12:53 am**

It's kernel time again... Linux 6.18.2
https://cdn.kernel.org/pub/linux/kernel ... Log-6.18.2

Lots of fixes, nothing really jumps out as affecting me but it only takes 2 minutes.

Posted: **Fri Jan 02, 2026 7:24 pm**

There were no Christmas Day kernels this year (he used to do that to shake people up lol) but today, there's a Linux 6.18.3

Assloads of changelog, fixes, nothing exciting but there are some drm/amd/display fixes which I'm always chasing.

https://cdn.kernel.org/pub/linux/kernel ... Log-6.18.3

Posted: **Thu Jan 08, 2026 9:27 pm**

Linux 6.18.4 now
https://cdn.kernel.org/pub/linux/kernel ... Log-6.18.4

Lots of fixes, but some drm related fixes (including amdgpu). I tend to keep my eye on this kind of stuff:

drm/amdgpu/sdma6: Update SDMA 6.0.3 FW version to include UMQ protected-fence fix

commit c8e7e3c2215e286ebfe66fe828ed426546c519e6 upstream.

On GFX11.0.3, earlier SDMA firmware versions issue the
PROTECTED_FENCE write from the user VMID (e.g. VMID 8) instead of
VMID 0. This causes a GPU VM protection fault when SDMA tries to
write the secure fence location, as seen in the UMQ SDMA test
(cs-sdma-with-IP-DMA-UMQ)

drm/amdgpu: add missing lock to amdgpu_ttm_access_memory_sdma

commit 4fa944255be521b1bbd9780383f77206303a3a5c upstream.

Users of ttm entities need to hold the gtt_window_lock before using them
to guarantee proper ordering of jobs.

drm/amdgpu: Forward VMID reservation errors

commit 8defb4f081a5feccc3ea8372d0c7af3522124e1f upstream.

Otherwise userspace may be fooled into believing it has a reserved VMID
when in reality it doesn't, ultimately leading to GPU hangs when SPM is
used.

Revert "drm/amd: Skip power ungate during suspend for VPE"

commit 3925683515e93844be204381d2d5a1df5de34f31 upstream.

Skipping power ungate exposed some scenarios that will fail
like below:

```
amdgpu: Register(0) [regVPEC_QUEUE_RESET_REQ] failed to reach value 0x00000000 != 0x00000001n
amdgpu 0000:c1:00.0: amdgpu: VPE queue reset failed
...
amdgpu: [drm] *ERROR* wait_for_completion_timeout timeout!
```

The underlying s2idle issue that prompted this commit is going to
be fixed in BIOS.
This reverts commit 2a6c826cfeedd7714611ac115371a959ead55bda.

I sometimes wonder if some of my problems are Mesa hitting kernel bugs.

Posted: **Thu Jan 08, 2026 10:26 pm**

I tried something different today. I like to build all my hardware drivers into the kernel image, except the monstrous amdgpu and its firmware. My rationale on the old computer was to initialize the video card last (interrupts were distributed better that way) but it's all MSI/MSI-X style now (with a few legacy edge reservations like acpi, timer and keyboard etc.) so my only reason now is size/impracticality which is easily dismissed.

So now I'm building amdgpu and all its firmware files right in. Look at the size difference in kilobytes from before and after (I didn't remove my old kernel this time because there was a good chance this one wouldn't boot, or boot to a black screen)

-rw------- 1 root root 5620736 Jan 2 15:00 vmlinuz-6.18.3
-rw------- 1 root root 10249216 Jan 8 17:01 vmlinuz-6.18.4

That's almost twice the size, 5M to 10M but that really doesn't matter, the modules would all need loading anyway (amdgpu + helper modules) and those firmware files would get loaded from disk anyway.

I got all this right the first time, I knew that my NAVI32 didn't actually use any of the "NAVI" files, so I did a search and found that I needed the gc_11_0_3 files. The rest I was able to get from looking up version strings from dmesg and searching around. I already knew what dmcub file I needed because of prior fighting with that.

So this is my kernel config string (in Device Drivers - Generic Driver Options - Firmware loader - CONFIG_EXTRA_FIRMWARE list) with all the firmware files I'm including, so all hardware can be built in. Nothing else of mine uses firmware but the onboard NIC and amdgpu.

Code: Select all

rtl_nic/rtl8125b-2.fw amdgpu/dcn_3_2_0_dmcub.bin amdgpu/gc_11_0_3_imu.bin amdgpu/gc_11_0_3_me.bin amdgpu/gc_11_0_3_mec.bin amdgpu/gc_11_0_3_mes1.bin amdgpu/gc_11_0_3_mes_2.bin amdgpu/gc_11_0_3_pfp.bin amdgpu/gc_11_0_3_rlc.bin amdgpu/psp_13_0_10_sos.bin amdgpu/psp_13_0_10_ta.bin amdgpu/sdma_6_0_3.bin amdgpu/smu_13_0_10.bin amdgpu/vcn_4_0_0.bin

Note that you can't do this with your distro's packaged firmware files, as they will most likely be compressed and this mechanism doesn't support that (only loading from userspace). I maintain my own specific set from the linux-firmware distribution tarballs at kernel.org

Of course this means that when firmware files change (I checksum compare them when new linux-firmware comes out) I'll have to recompile the kernel and include them, but I do that often enough anyway. Worse, is that if I have to change video cards these kernels will be absolutely NFG (I'll have to drop in a new one) but I'm good with that. I may even be able to get to normal VGA if I wait long enough, as it was from prior experience of forgetting to install firmware files when bringing up a LFS system.

I have no errors in dmesg about missing firmware (I renamed my firmware directory to test) and I can see stuff on my screen a fraction of a second sooner (I don't use an initramfs image). My framebuffer console should always work, not relying on udev to load the module. It doesn't boot up perceptibly faster (though it probably would by a few ms) and there's still display mode switching time, just that I see more systemd shit on screen initializing

Posted: **Tue Jan 13, 2026 11:54 pm**

Very small changelog with a few specific fixes, but Linux 6.18.5 is out now.
https://cdn.kernel.org/pub/linux/kernel ... Log-6.18.5

nfs/localio: fix regression due to out-of-order __put_cred
sched/fair: Proportional newidle balance
sched/fair: Small cleanup to update_newidle_cost()
sched/fair: Small cleanup to sched_balance_newidle()
mptcp: ensure context reset on disconnect()

I guess it's easier to just do it than think about whether or not sched/fair.c is still used by the eevdf scheduler or not. (I'm too tired of screwing around right now to care to find out

)

Posted: **Wed Jan 14, 2026 5:37 pm**

And right after I got around to going from 6.18.1 to 6.18.4

Posted: **Mon Jan 19, 2026 8:41 am**

I noticed CachyOS has 6.18.6

Code: Select all

linux-cachyos-6.18.6-2

But it's not on kernel.org yet. It is on git.kernel.org.

Mikeserv Support Forum

New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel

Re: New Kernel