Mikeserv Support Forum

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

Lots of mm fixes.

This looks promising:
I haven't had a kernel crash since disabling vkd3d-proton's pipeline cache in Veilguard though, while much rarer, the few game crashes I've had have led to successful driver recovery. Wait several seconds when the game freezes, and it crashes out, leaving my X session intact. amdgpu "ring timeout with soft reset".

So... with Linux 6.12.7, Dragon Age Veilguard crashes became fatal again. The first time I thought it was just a fluke because it happened under different circumstance, but subsequent crashes (and it seemed to be back to happening more often) left me completely frozen up with no input and not able to VT switch to see any crash spaghetti. It wasn't grinding to a halt with the audio still working etc. like usual. So I resigned myself to turning off ray tracing. When it happened with ray tracing turned off, that's when I had enough. I also thought Starfield had a bit of a performance regression but that could have just been par for the course. I installed Linux 6.12.6 again and turned ray tracing back on in Veilguard and played. It eventually crashed, but was back to being recoverable without even losing my X session. I can just start the game again. So it was the amdgpu changes in the kernel. Weird how that behaviour is sensitive to driver changes... when it was supposed to fix a crash. My guess would be that the crash is happening at a different level where the driver can't recover... ultimately the game is doing bad things with my shaders.

Since this has no drm/amdgpu changes, I'm going to sit this out and stay with Linux 6.12.6 for now where I am having better behaviour.

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

Mostly fixes for stuff that wouldn't affect us. Lots of btrfs, a few ALSA fixes, bluetooth, IRQ stuff for RISCV. Nothing that jumps out at me today.

I'm on 6.12.7 in Slackware. Also in Arch on my game machine.

The problem is ultimately that game, and vkd3d-proton to some extent. It's the only one I have causing that behaviour... I can't say there aren't others that would hit that, but it wouldn't be commonplace.

6.12.7 was good apart from how the drivers were reacting to it. More frequent crashes, and hard boot every time v.s. 6.12.6 behaviour. When I see relevant commits (drm and/or amdgpu) I'll try again.

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

mptcp fixes (I don't enable that but I heard it needs some work)
more btrfs fixes
nvme-pci fix
mm fixes I'd like to have

However, I see nothing that will fix the regressed driver recovery behaviour in amdgpu, so they can keep this. 6.12.6 is the best one for me at this time. Not only recovery, but game crashes seem less frequent with this kernel. (as in, haven't had one in days... once where I knew it would crash with ray tracing in a certain area of Veilguard and it was recoverable)

Not relevant for me:

drm/amdgpu: use sjt mec fw on gfx943 for sriov

[ Upstream commit 9a4ab400f1fad0e6e8686b8f5fc5376383860ce8 ]

Use second jump table in sriov for live migration or mulitple VF
support so different VF can load different version of MEC as long
as they support sjt

drm/amdgpu: fix backport of commit 73dae652dcac

Commit 73dae652dcac ("drm/amdgpu: rework resume handling for display (v2)")
missed a small code change when it was backported resulting in an automatic
backlight control breakage. Fix the backport.

Note that this patch is not in Linus' tree as it is not required there;
the bug was introduced in the backport.

Linux 6.12.10
https://cdn.kernel.org/pub/linux/kernel ... og-6.12.10

A shit tonne of fixes for the industrial i/o subsystem (iio) for various industrial sensors

A block/bfq fix.

Some USB fixes

Some specific drm/amd/display crash fixes. For multi-plane and multi-display mostly. I don't think there's anything for me.

I'm happiest with Linux 6.12.6 so far (for the amdgpu crash handling behaviour), and since I don't see anything for me here, I'm not going to chance it. My next kernel will be 6.13.0

Looks like 6.13.0 was released today, it's not showing on kernel.org yet but I saw it on Phoronix.

I've been looking for that all day (it was expected today).

There's a release tag snapshot rolled up here now, I think I'll get on it.
https://git.kernel.org/pub/scm/linux/ke ... linux.git/

Lazy Preempt is here now.
I'm not going to use that, as it delays preemption for SCHED_NORMAL tasks, but only works as full preemption for SCHED_RR, SCHED_FIFO and SCHED_DEADLINE tasks (different types of policies used for realtime-like behaviour). I'm sticking with 3, as I have for many years.

They've moved real-time preemption out into it's own config option,
Also, it looks like they've moved split-lock-detection to a config setting. I've been turning that off on the kernel command line (as it may get triggered playing games with Wine). I'll be saying N to this. It's not something that helps you, it throttles the process and complains on the console/logs.

My amdgpu crash recovery behaviour seems to be as good as 6.12.6 now. I turned on ray tracing in Dragon Age Veilguard and went to an area where I knew it would reproduce that game crash during combat (a nice, dark, forboding swampy area with blighted villages and stuff). It just always seems to happen there.

The game freezes, with audio still going. I can VT switch, but I'll just get a blinking line cursor in the top left. After several seconds I get my X session back after the driver recovers with just this:
That would be on the root console, and in my errors.log (I use syslog-ng instead of journald so I can have normal text logs)

Of course since I was out today, Linux 6.13.1 was released

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

Lots of work on the xpad driver, adding new game controllers. While it doesn't affect me (I have an old wired XBox 360 controller that has always worked) I'm glad to see that. I don't like userspace frameworks like xboxdrv and steam input.

I don't see much that would interest us in the changelog. I might not even bother with this one.

Some users have reported issues with 6.13.1. I heard some mention of this the other day but didn't have time to explore it much, I just now read through the Arch thread.

Well, no, flatfaceasspack here, so no fuse issue (and I don't use fuse filesystems anyway)

The common denominator is flatpak and likely something with it's fuse integration: https://gitlab.archlinux.org/archlinux/ ... issues/110

They are saying 6.13.1 because those people wouldn't have run 6.13.0

I didn't bother with .1, but 6.13.2 will probably be out tomorrow(ish) and I'll see if there's anything in it for me.

Linux 6.13.2 is out now

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

btrfs, btrfs, btrfs

a few drm/amd/display commits

usb type c stuff

usb networking adapter related stuff

some networking fixes

net: phy fixes for realtek

Some NFS commits

CIFS and SMB

A KVM commit

iommu stuff for AMD

bpf stuff

tons of perf related commits

Shit for other architectures... lots of ARM and ARM64 stuff

Nothing is bothering me (6.13.0 has been great for me) and there isn't anything really compelling here, but I'm going to do this one tomorrow.

Still on 6.12x series. Nvidia won't compile for me....

You know, for all you do with that card, you could switch to the Nouveau driver and Mesa. You'll have full use of the card, even Vulkan now. It wouldn't be ideal for gaming, but you don't do that.

That would solve that headache and you could use any kernel you want.

You are absolutely correct. The only gaming I do is on old recompiles of Cube, and 2 versions of Saurbraten. I figure I need those drivers for that. ToxRacer and Tuxcart also for the grandkids. But they are getting older...

Those games would probably work fine with nouveau. That's old opengl.

It's been a while in between point releases, but we have Linux 6.13.3 today. I think they are spending more time testing now, they have "rc1" and list a bunch of testers at the top of changelogs nowadays.

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

I'm scrolling through the substantial changelog and there are a lot of little fixes and cleanups, mostly for stuff that wouldn't concern us. A few interesting commits though.

Changes for gcc 15

x86/boot: Use '-std=gnu11' to fix build with GCC 15

commit ee2ab467bddfb2d7f68d996dbab94d7b88f8eaf7 upstream.

GCC 15 changed the default C standard version to C23, which should not
have impacted the kernel because it requests the gnu11 standard via
'-std=' in the main Makefile. However, the x86 compressed boot Makefile
uses its own set of KBUILD_CFLAGS without a '-std=' value (i.e., using
the default), resulting in errors from the kernel's definitions of bool,
true, and false in stddef.h, which are reserved keywords under C23.

./include/linux/stddef.h:11:9: error: expected identifier before ‘false’
11 | false = 0,
./include/linux/types.h:35:33: error: two or more data types in declaration specifiers
35 | typedef _Bool bool;

Set '-std=gnu11' in the x86 compressed boot Makefile to resolve the
error and consistently use the same C standard version for the entire
kernel.

A fix for Clang 19 warnings, well not actually a fix (just not making it break on -Werror). I do compile the kernel with Clang 19.x but this won't bother me because I disable -Werror

kbuild: Move -Wenum-enum-conversion to W=2

commit 8f6629c004b193d23612641c3607e785819e97ab upstream.

-Wenum-enum-conversion was strengthened in clang-19 to warn for C, which
caused the kernel to move it to W=1 in commit 75b5ab134bb5 ("kbuild:
Move -Wenum-{compare-conditional,enum-conversion} into W=1") because
there were numerous instances that would break builds with -Werror.
Unfortunately, this is not a full solution, as more and more developers,
subsystems, and distributors are building with W=1 as well, so they
continue to see the numerous instances of this warning.

Since the move to W=1, there have not been many new instances that have
appeared through various build reports and the ones that have appeared
seem to be following similar existing patterns, suggesting that most
instances of this warning will not be real issues. The only alternatives
for silencing this warning are adding casts (which is generally seen as
an ugly practice) or refactoring the enums to macro defines or a unified
enum (which may be undesirable because of type safety in other parts of
the code).

Move the warning to W=2, where warnings that occur frequently but may be
relevant should reside.

An interesting fix for ACPI APIC parsing order:

x86/acpi: Fix LAPIC/x2APIC parsing order

commit 0141978ae75bd48bac13fca6de131a5071c32011 upstream.

On some systems, the same CPU (with the same APIC ID) is assigned a
different logical CPU id after commit ec9aedb2aa1a ("x86/acpi: Ignore
invalid x2APIC entries").

This means that Linux enumerates the CPUs in a different order, which
violates ACPI specification[1] that states:

"OSPM should initialize processors in the order that they appear in
the MADT"

The problematic commit parses all LAPIC entries before any x2APIC
entries, aiming to ignore x2APIC entries with APIC ID < 255 when valid
LAPIC entries exist. However, it disrupts the CPU enumeration order on
systems where x2APIC entries precede LAPIC entries in the MADT.

Fix this problem by:

1) Parsing LAPIC entries first without registering them in the
topology to evaluate whether valid LAPIC entries exist.

2) Restoring the MADT in order parser which invokes either the LAPIC
or the X2APIC parser function depending on the entry type.

The X2APIC parser still ignores entries < 0xff in case that #1 found
valid LAPIC entries independent of their position in the MADT table.

Most of the amdgpu /display fixes seem to be for GFX12 (8000 series)

Obligatory btrfs fixes.

Enough changelog, time to get at it. I'm also going to upgrade firmware to this month's distribution (linux-firmware-20250211.tar.xz). I don't use much of it (and only copy what I need), just the amdgpu blobs and one for my onboard realtek NIC that I build in the kernel image with the driver.

I've been a little behind on the kernels lately, too many other distractions. I'm also thinking of doing a fresh Slackware install, XFCE only this time, no Plasma since it goes stale on Slackware and doesn't play well with XFCE and some other DE's. I'm not sure which side of the state line I'll do on yet

Plasma is nice, but I just won't do that to my system. It's quite messy and needs assloads of dependencies. I also don't trust big busy frameworks and compositing window managers not to fuck up when I'm doing stuff.

Linux 6.13.4 now, with a substantial changelog.

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

sched-ext fixes (external loadable schedulers). I don't use that, but that went in the kernel in 6.12 so they will still be finding kinks to work out.

btrfs fixes again (I'm glad I don't use that fs)

Some ipv4 RCU (receive copy unit) fixes

A security related fix for amdgpu

drm/amdgpu: avoid buffer overflow attach in smu_sys_set_pp_table()

commit 1abb2648698bf10783d2236a6b4a7ca5e8021699 upstream.

It malicious user provides a small pptable through sysfs and then
a bigger pptable, it may cause buffer overflow attack in function
smu_sys_set_pp_table().

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

Moderate sized changelog, some amdgpu fixes. Mostly for gfx9/vega though. I don't have time to go through it today, I want to do a kernel build anyway. I'm going back to a plain gcc build. Enough of that clang LTO placebo. I've always thought that was just spinning wheels, but it felt like I was doing something cleverer

Grogan wrote: Tue Feb 11, 2025 8:39 pm Those games would probably work fine with nouveau. That's old opengl.

You were right. Those old games do just fine on nouveau as well as the Kpatience games. Probably won't do nvidia drivers until I get a new rig with a much newer card. May give amd a whirl this time.

Excellent, now your life gets easier

Is kpatience ever a nice solitaire game. I might say it's the best one in the world, both in terms of appearance and features. The cost is too high for me though (KDE/Plasma bloat and dependencies). Have you played with the solver? It's so good, you'll never lose a game (as long as it's a solvable game to start with). Whenever it says "the game is no longer winnable" after a move, simply undo and skip that move and look for another. It's interesting a bit later in the game to see why that move causes your game to be unsolvable, too.

I wonder how well Xonotic would run with Nouveau

That's based on old quake engine I think, I'm sure that one would work.

KPatience is a great game. I've won 10,084 games on Freecell. I know there are at least 8 games unsolvable on Freecell, but I haven't ran into them yet. Sometimes, I have found myself trying to find the right path but not quite making it. I rarely use the hint since it seems like cheating a bit. I nearly always figure it out after staring at it a bit. Even played supertuxcart a bit this am.

Linux 6.13.6 today. Lots of stuff, starting with a bunch of fixes for AMD microcode loading, a fix for EFI mokvar table ("machine owner key" certificate store), a fuse revert, and more stuff I don't care about

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

I'm going to do it though, as I want to go back to the Clang LTO builds anyway since my intermittent grub boot problem had nothing to do with the kernel itself (I'm now convinced it was barfing on searching for UUID's).

I'm looking forward to Linux 6.14 where that ntsync primitive for Wine is merged and should be stabilized.

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

Lots of fixes. hdaudio, USB, networking, wifi... typical stuff. It's amazing to think about these fixes in terms of somebody, somewhere hitting all those conditions that we'd never know about if not for changelogs.

I'm actually tempted to get on mainline 6.14-rc6 so I can build a Wine against the stabilized implementation of NTSYNC (ntsync.h kernel interface) but I'll wait until it's final to let wine-tkg patches catch up.