New Kernel

[Grogan]

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

A sizable changelog, assloads of little fixes across the board. I just quickly scrolled, too lazy to go through it in detail lol

I'm just going to wait until probably tomorrow night, for 6.14.0. I'm eager for that one, as I want to try a wine build with ntsync again.

[Grogan]

It's finally released, Linux 6.14. I thought maybe there was going to be a 6.14-rc8 (saw a commit last night that made me think so). I can't post a changelog, for a major release that comes in the form of a git diff between 6.13 and 6.14. You'd have to be looking for changes to specific files for that to be of use.

That's good, now I can get to work. (kernel build, then I'm going to build glibc and friends using the headers, then I'm going to try a proton-tkg upstream wine build with ntsync)

Here's something new. I think I'll say Y to this, though I don't know if it comes with any cost.

Code: Select all

reclaim empty user page table pages (PT_RECLAIM) [Y/n/?] (NEW) ?

CONFIG_PT_RECLAIM:

Try to reclaim empty user page table pages in paths other than munmap
and exit_mmap path.

Note: now only empty user PTE page table pages will be reclaimed.

Of course, this is the new feature I'm most interested in:

Code: Select all

NT synchronization primitive emulation (NTSYNC) [N/m/y/?] (NEW) ?

CONFIG_NTSYNC:

This module provides kernel support for emulation of Windows NT
synchronization primitives. It is not a hardware driver.

To compile this driver as a module, choose M here: the
module will be called ntsync.

If unsure, say N.

I don't think I like the sound of this. I heard about a new DRM logger coming, but the wording of this makes it a big nope.

Code: Select all

Print the kernel boot message on the screen (DRM_CLIENT_LOG) [N/y/?] (NEW) ?

CONFIG_DRM_CLIENT_LOG:

This enable a drm logger, that will print the kernel messages to the
screen until the userspace is ready to take over.

If you only need logs, but no terminal, or if you prefer userspace
terminal, say "Y".

[Grogan]

Well, I was successful in everything I set out to do today. The end result is a proton-tkg built with upstream wine 10.4 with ntsync enabled. (ntsync patches won't work with valve's wine)

Tested Starfield, which is one that benefits from it. I probably won't be able to use it for everything (it didn't work for everything last time) though. I'm also not going to try it on my system wine at this time, though I may try building a wine runner for Lutris.

The ntsync kernel module needs to be manually loaded (modprobe), udev doesn't load it though it does set the permissions with a rule that I created. I'm not even sure the rule is needed anymore, but I created it anyway (I had to last time). Just a simple mode change.

Code: Select all

KERNEL=="ntsync", MODE="0644"

[Zema Bus]

I wondered what happened when it didn't show up by Sunday night.

[Grogan]

With Linux 6.14, they changed something with the audio driver (I have hdaudio, realtek codec) such that Audio Reverb in all the Sniper Elite games (4, 5 and Resistance) stopped working. It was 100% reproducible every time, I could take one shot, but the second would cause garbled audio that persisted for all sounds in game, and caused delay (or inability) of the game to exit. I knew it was the reverb, because I had that same problem on the old computer with Sniper Elite 5 (on by default in that game) years ago and had to turn it off.

At first I thought it was because of using the wine-proton with ntsync, but that was not the case. It was still happening with my regular proton-tkg, and I rebooted in case it was a "stuck" audio device and in that case the ntsync module wasn't even loaded, so couldn't have affected anything.

Well, that won't do, that was working just fine in those games on this machine and I like the effect (though it's not essential). I don't want to go back to 6.13 as I want that ntsync implementation in 6.14 so I went at my pulseaudio configuration. I don't use pipewire, I have it masked out, so the files in /etc/pulse are controlling it.

In /etc/pulse/daemon.conf I tweaked these:

Code: Select all

high-priority = yes
nice-level = -19

(the default is yes and nice level -11, which would have been fine. The priority probably has nothing to do with it)

Due to the nature of it, the problem was likely buffer related. The way I could do one slow motion kill cam shot, then after a second one the buffers are overwhelmed and it's fuct.

Code: Select all

default-sample-rate = 48000
default-fragments = 8
default-fragment-size-msec = 30

The default sample rate is 44100, more samples are better (48000 Hz is the max sample rate of my device). The default-fragments was 4, I doubled it to 8. That is essentially the number of buffer fragments used for sampling. The default-fragment-size-msec was 25, I increased it to 30 for a bit more buffer length.

Between those (I just guessed at what might help lol), the problem is solved and Audio Reverb works correctly in those games now. I don't know what changed in the kernel.

[mlangdn]

I'm on 6.14.0 with the nouveau driver. All is well for my little needs. It is the distro kernel. Just wanted to see if the open source driver would be good. I'm getting lazy also.

[Grogan]

Nouveau should be stable, especially on mature hardware.

I spoke too soon about my audio reverb problem. Sniper Elite Resistance still has the problem. It helped, it went longer without happening, but has crackling during a heavily reverberated slow motion sound. It recovers from it a few times, but ultimately I have to quit the game. It stopped happening in the earlier games, but no variation of those buffer settings fixes it completely in SE Resistance.

I have also tried pre-allocating a buffer in kernel (kconfig setting) for the HD-Audio driver but that didn't seem to help either.

It seems to be the one and only problem I'm having and all I'd have to do is disable that audio reverb in the game, but it bothers me when something isn't right. It might not even be the audio driver itself, but something else in the kernel that has changed. It could even be glibc, as I rebuilt that with Linux 6.14 API headers. That's less likely though.

[Grogan]

The audio reverb issue is most definitely related to the changes in the kernel, I just built a 6.13.7 and tested it, with pulseaudio settings put back to their defaults and it's working perfectly again.

Oh well, back to Linux 6.14 now that I know for sure to be looking into that.

[Grogan]

It's been a while, but there is Linux 6.14.1 now. Very short changelog, some USB fixes, device specific audio fixes, a few network and serial etc. Nothing that really interests me, but I'm going to do it because I want to test drive my new LLVM toolchain, I have yet to build a kernel with it.

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

[Grogan]

Linux 6.14.2 with many hundreds of fixes, across the board. DRM, networking, network daemons, filesystems. It looks like it needs to be done.

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

I scrolled through the whole thing. This looks promising for me:

ALSA: timer: Don't take register_mutex with copy_from/to_user()

[ Upstream commit 3424c8f53bc63c87712a7fc22dc13d0cc85fb0d6 ]

The infamous mmap_lock taken in copy_from/to_user() can be often
problematic when it's called inside another mutex, as they might lead
to deadlocks.

In the case of ALSA timer code, the bad pattern is with
guard(mutex)(&register_mutex) that covers copy_from/to_user() -- which
was mistakenly introduced at converting to guard(), and it had been
carefully worked around in the past.

This patch fixes those pieces simply by moving copy_from/to_user() out
of the register mutex lock again.

P.S. Nope, that didn't fix my reverb audio problem in the Sniper Elite games. I think next I'll try disabling high resolution timer support for the ALSA drivers. It sounds counter-intuitive, but high resolution timers have been hinky on Intel in the past.

[Grogan]

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

Lots of changelog entries. PCI, Memory Management (mm), wifi, ext4, amdgpu, lots of shit.

[Grogan]

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

Big changelog, with lots of fixes pertaining to DRM. I don't see anything ALSA or HD-Audio related.

[Zema Bus]

6.14.5

[Grogan]

Of course there is, because I thought I was done for the night (been working on a lot of shit today on Arch), only to find that today's the day on Gentoo to rebuild 85 things because of upgrading to python 3.13

I guess I'll do this tomorrow. I don't see anything to get excited about in the changelog

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

[Grogan]

I built 6.15.0-rc5 today to see if the reverb audio problem persists in Linux 6.15.

Yes, it does, whatever is causing it is still there. Who fucking knows what needle-in-haystack kernel behaviour is causing it... it's probably not the audio driver itself. I'm getting royally pissed off with some of this rubbish and always fighting with something in this environment. Of course trying to play games outside of their intended environment is less than ideal. I'm getting close to considering a Windows install for games. I'm not there yet, every time I think seriously about it I throw up in my mouth a little, thinking about Windows 11.

[Zema Bus]

So far I've only encountered it in Sniper Elite 4 and 5 but I haven't played many other games lately. Have you experienced it in any other games besides those?

[Grogan]

No, just all of the Sniper Elite games. However, it's uncovering a problem, it won't be the only place it would manifest. (I don't think I have anything else that does that kind of reverb audio)

[Grogan]

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

Fixes for a lot of different things. Nothing that gives me a stiffy. (I'd hate to be using btrfs though)

[Grogan]

Linux 6.14.7 today. It probably took a while because they had to add and test a bunch of new CPU mitigation behaviours.
https://cdn.kernel.org/pub/linux/kernel ... Log-6.14.7

x86/its: FineIBT-paranoid vs ITS

commit e52c1dc7455d32c8a55f9949d300e5e87d011fa6 upstream.

FineIBT-paranoid was using the retpoline bytes for the paranoid check,
disabling retpolines, because all parts that have IBT also have eIBRS
and thus don't need no stinking retpolines.

Except... ITS needs the retpolines for indirect calls must not be in
the first half of a cacheline :-/

Many commits related to Training Solo vulns and this new "Indirect Target Selection" variant.

Not just today, but another thing I've been noticing is that they have really expanded the scope of the xpad driver (which was limited to older XBox controllers not long ago) to support more game controllers.

[Grogan]

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

A bunch of fixes for a bunch of things. ivpu (AI accelerator), dmaengine, btrfs. Most aren't interesting for what I use in the kernel. This one stood out for me though

mm/page_alloc: fix race condition in unaccepted memory handling

commit fefc075182275057ce607effaa3daa9e6e3bdc73 upstream.

The page allocator tracks the number of zones that have unaccepted memory
using static_branch_enc/dec() and uses that static branch in hot paths to
determine if it needs to deal with unaccepted memory.

Borislav and Thomas pointed out that the tracking is racy: operations on
static_branch are not serialized against adding/removing unaccepted pages
to/from the zone.

Sanity checks inside static_branch machinery detects it:

WARNING: CPU: 0 PID: 10 at kernel/jump_label.c:276 __static_key_slow_dec_cpuslocked+0x8e/0xa0

The comment around the WARN() explains the problem:

/*
* Warn about the '-1' case though; since that means a
* decrement is concurrent with a first (0->1) increment. IOW
* people are trying to disable something that wasn't yet fully
* enabled. This suggests an ordering problem on the user side.
*/

The effect of this static_branch optimization is only visible on
microbenchmark.

Instead of adding more complexity around it, remove it altogether.

[Zema Bus]

6.15.0

[Grogan]

Ahh, I was wondering if we were going to get that tonight. I'm game for that, right now.

[Grogan]

So one change that jumped out at me. On x86 64 bit kernel builds, there's no more CPU configuration choice (there's still a Makefile.cpu for 32 bit kernels as processor types are important there). You still choose "supported processor vendors". I only build kernels for myself, so I only enable Intel.

Now, in arch/x86/Makefile the 64 bit kernels get "-march=x86-64 -mtune=generic". It still disables unsafe vector instructions with -mno so should still be safe (although of dubious, immeasurable benefit) to tweak that, as I do.

[Grogan]

Another interesting setting I enabled. I see things like this because of CONFIG_EXPERT. This is under Transparent Huge Page Support options, but it could apply to other things in theory.

Code: Select all

CONFIG_NO_PAGE_MAPCOUNT:
   
  │ Do not maintain per-page mapcounts for pages part of larger
  │ allocations, such as transparent huge pages.
  │                   
  │ When this config option is enabled, some interfaces that relied on
  │ this information will rely on less-precise per-allocation information
  │ instead: for example, using the average per-page mapcount in such
  │ a large allocation instead of the per-page mapcount.
  │                                  
  │ EXPERIMENTAL because the impact of some changes is still unclear.

That looks like something that reduces overhead there, and such things are welcome for me. I've been using this kernel since last night (compiled a bunch of shit, played games etc.) and haven't had any issues, but the warning is noted.

[Zema Bus]

Potentially dangerous power regression in some cases (nosmt) in kernel 6.15:

The Linux 6.15 kernel that shipped as stable last week mistakenly shipped with a nasty CPU power regression for some systems. The issue is now fixed in Linux 6.16 Git and will be fixed shortly in the Linux 6.15 point releases.

In addition to some earlier performance regressions in Linux 6.15 that were ultimately fixed in time for the stable release, a late regression for Linux 6.15 ended up yielding significant CPU power regressions. This is present on Linux v6.15 but should be fixed in time for the next point release to Linux 6.15.

Intel engineer and power management subsystem maintainer Rafael Wysocki is also the one that tackled this regression. He explained in the revert that landed in Linux 6.16 Git at the end of the week:

"Revert commit 96040f7273e2 ("x86/smp: Eliminate mwait_play_dead_cpuid_hint()") because it introduced a significant power regression on systems that start with "nosmt" in the kernel command line.

Namely, on such systems, SMT siblings permanently go offline early, when cpuidle has not been initialized yet, so after the above commit, hlt_play_dead() is called for them. Later on, when the processor attempts to enter a deep package C-state, including PC10 which is requisite for reaching minimum power in suspend-to-idle, it is not able to do that because of the SMT siblings staying in C1 (which they have been put into by HLT).

As a result, the idle power (including power in suspend-to-idle) rises quite dramatically on those systems with all of the possible consequences, which (needless to say) may not be expected by their users.

This issue is hard to debug and potentially dangerous, so it needs to be addressed as soon as possible in a way that will work for 6.15.y, hence the revert.

Of course, after this revert, the issue that commit 96040f7273e2 attempted to address will be back and it will need to be fixed again later."


The regression was introduced by x86/smp: Eliminate mwait_play_dead_cpuid_hint() that was added during Linux 6.16 Git. That original patch intended to address an issue affecting at least Intel Xeon 6 "Sierra Forest" C-states.

In the power management pull request landing the revert, Rafael characterized it as "a nasty power regression on some systems." That pull request also added in new Rust abstractions for CPUFreq, OPP, CLK, and Cpumasks for allowing more Linux power management code to be written in the Rust programming language moving forward.

From phoronix.com

[Grogan]

That wouldn't be dangerous on our PCs (if we were paranoid enough to pass nosmt) but on laptops that could be bad.

I use only the Performance governor anyway (I don't compile any others) so I'd never go into deep C-State. I don't enable suspend or hibernate in my kernels either.

[Grogan]

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

I don't see that smp commit revert in there, maybe they postponed the change for more consideration.

Most of the changes are for arm64, which is very soon to be relevant for me

Ah well, time to get my kernel install scripts in order (I have to use sed on them to change all instances of gentoo to crux). I still intend to build the kernel on Arch for both systems, with my clang.