New Kernel

[Grogan]

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

Tons of fixes that matter to somebody. A lot of wifi and specific wifi adapter fixes. Some fixes for drm/v3d, now relevant, for the Broadcom graphics driver on our raspberry pi.

They aren't coming as often lately, but when they do they have a lot of fixes.

[Grogan]

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

A lot of little fixes for a lot of drivers and things. WiFi, a lot of filesystem fixes (including ext4). Much of this stuff is discovered by instrumentation.

Here's an interesting issue, low powered mode in AHCI SATA causing screen corruption. If not for timely bisecting, this would have had that person chasing their tail for sure with seemingly unrelated symptoms.

ata: ahci: Disallow LPM for ASUSPRO-D840SA motherboard

commit b5acc3628898baa63658bc4125f9525f9b3dd4f3 upstream.

A user has bisected a regression which causes graphical corruptions on his
screen to commit 7627a0edef54 ("ata: ahci: Drop low power policy board
type").

Simply reverting commit 7627a0edef54 ("ata: ahci: Drop low power policy
board type") makes the graphical corruptions on his screen to go away.
(Note: there are no visible messages in dmesg that indicates a problem
with AHCI.)

The user also reports that the problem occurs regardless if there is an
HDD or an SSD connected via AHCI, so the problem is not device related.

The devices also work fine on other motherboards, so it seems specific to
the ASUSPRO-D840SA motherboard.

While enabling low power modes for AHCI is not supposed to affect
completely unrelated hardware, like a graphics card, it does however
allow the system to enter deeper PC-states, which could expose ACPI issues
that were previously not visible (because the system never entered these
lower power states before).

There are previous examples where enabling LPM exposed serious BIOS/ACPI
bugs, see e.g. commit 240630e61870 ("ahci: Disable LPM on Lenovo 50 series
laptops with a too old BIOS").

Since there hasn't been any BIOS update in years for the ASUSPRO-D840SA
motherboard, disable LPM for this board, in order to avoid entering lower
PC-states, which triggers graphical corruptions.

[Grogan]

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

Seems to be mostly drm related fixes, including several drm/amd/display fixes related to brightness level curves. Another for mpv video corruption using the Weston compositor. Other (relevant) misc fixes like nvme atomic operations

[Grogan]

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

Probably the main thing is new AMD processor TSA vulnerabilities, but many other fixes as well.

[Grogan]

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

Misc fixes that should be had, nothing jumped out as interesting to list.

[Grogan]

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

Lots of fixes, amdgpu, some nvme fixes that look like they should be had, etc.

[Zema Bus]

I was about to do 6.15.8 and then remembered 6.16.0 will probably release tomorrow. So I went ahead and did it anyway Also cleaned out all my old kernels and modules except for 6.15.7.

[Grogan]

I only keep one (and I install it on both OSes at the same time), so I'd have to boot from USB and fix it if I ever fuck it up

I'd be more likely to make a typo in grub.cfg than have a non booting kernel, though.

[Grogan]

It looks like Linux 6.16.0 is released now:

https://git.kernel.org/pub/scm/linux/ke ... linux.git/

The linux-6.16.tar.gz snapshot is available there. I might as well get on it.

P.S. New settings of interest:

Build and optimize for local/native CPU (X86_NATIVE_CPU) [N/y/?] (NEW)

As expected, that simply passes -march=native. This does not tune it for your processor, you get generic x86_64. So basically you're getting everything potentially "bad" (which could break the binary on other processors) but not tuning it for that processor. With the kernel, you're not even getting the advanced instruction sets because they have to turn off vector instructions anyway. So basically they are throwing people a bone.

[Zema Bus]

I just got it done

[Grogan]

It's been weeks, but Linux 6.16.1 is out. The changelog is substantial, but not as long as I was expecting for such an interval

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

Some memory management and swap fixes and lots of other stuff that looks like it should be had.

[Zema Bus]

Something to do this weekend

[Grogan]

We have a Linux 6.16.2 already, there must have been more stuff queued up. I'm not finished going through this yet, it's a shit tonne of shit. Lots of ext4 fixes, amdgpu

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

[Zema Bus]

And now we have 6.16.3 already

[Grogan]

Wow, it's solely a bunch of ext4 fixes. I guess I won't wait until after I get up.

[Grogan]

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

It contains a bunch of block layer fixes, among other things.

[Grogan]

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

There are some amdgpu changes that bump minimum firmware requirements (I've got the latest, probably so does Arch and most non-anal distros)

drm/amdgpu/gfx12: set MQD as appriopriate for queue types

commit 29f155c5e82fe35ff85b1f13612cb8c2dbe1dca3 upstream.

Set the MQD as appropriate for the kernel vs user queues.

drm/amdgpu/gfx11: set MQD as appriopriate for queue types

commit 27f5e0c1321ee280189cea16044de2e157dc4bb9 upstream.

Set the MQD as appropriate for the kernel vs user queues.

drm/amdgpu: update firmware version checks for user queue support

commit ee38ea0ae4ed13fe33e033dc98d11e76bc7167cd upstream.

The minimum firmware versions required for user queue functionality
have been increased to address an issue where the queue privilege
state was lost during queue connect operations.

The problem occurred because the privilege state was being restored
to its initial value at the beginning of the function, overwriting
the state that was properly set during the queue connect case.

This commit updates the minimum version requirements:
- ME firmware from 2390 to 2420
- PFP firmware from 2530 to 2580
- MEC firmware from 2600 to 2650
- MES firmware remains at 120

These updated firmware versions contain the necessary fixes to
properly maintain queue privilege state throughout connect operations.

[Zema Bus]

6.16.6 now, sort of reminds me of last December's 6.6.6

[Grogan]

I don't see a lot that affects me in here, nothing Satanic

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

There's a fair bit for the riscv arch

[Grogan]

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

It's related to vmscape spectre mitigations (host-guest isolation breaking in virtual machines)

x86/vmscape: Add conditional IBPB mitigation

Commit 2f8f173413f1cbf52660d04df92d0069c4306d25 upstream.

VMSCAPE is a vulnerability that exploits insufficient branch predictor
isolation between a guest and a userspace hypervisor (like QEMU). Existing
mitigations already protect kernel/KVM from a malicious guest. Userspace
can additionally be protected by flushing the branch predictors after a
VMexit.

Since it is the userspace that consumes the poisoned branch predictors,
conditionally issue an IBPB after a VMexit and before returning to
userspace. Workloads that frequently switch between hypervisor and
userspace will incur the most overhead from the new IBPB.

This new IBPB is not integrated with the existing IBPB sites. For
instance, a task can use the existing speculation control prctl() to
get an IBPB at context switch time. With this implementation, the
IBPB is doubled up: one at context switch and another before running
userspace.

The intent is to integrate and optimize these cases post-embargo.x86/vmscape: Enable the mitigation

Commit 556c1ad666ad90c50ec8fccb930dd5046cfbecfb upstream.

Enable the previously added mitigation for VMscape. Add the cmdline
vmscape={off|ibpb|force} and sysfs reporting.

[Grogan]

Ahh, shit... I thought I was done for the day, but there's a kernel update too
https://cdn.kernel.org/pub/linux/kernel ... Log-6.16.8

Fixes for network PHY's, netfilter, dmaengine (we don't use that... generally embedded SoC's), erofs, various USB device fixes, a few for drm/amd/display and seemingly as always, btrfs.

(I noticed when installing Manjaro on my nephew's laptop, if we'd have gone with default partitioning (e.g. "take entire disk") we'd have ended up with btrfs as the default. When I did "manual partitioning" I had to change that to ext4. That's foolish... it reminds me of distros making reiserfs the default in the 2000s)

[Zema Bus]

Fedora seems to be getting on that bandwagon too, I checked out the beta of Fedora 43 and it now defaults to btrfs.

[Zema Bus]

6.16.9

[Grogan]

Ahh good, more work to do

(I'm starting to get behind, as this botnet shit has been consuming my soul)

[Zema Bus]

And now it's time for 6.17.0 It's not up on kernel.org yet.

[Grogan]

Ahh, cool. I'll get on that after supper.

[Grogan]

The configuration for HD-Audio has gotten more fine grained in Linux 6.17. Not only the "codecs" for the brands, but they've split out Realtek hd-audio into a separate sub-menu with individual realtek chip codecs.

Code: Select all

 --- Realtek HD-audio codec support
<*>   Build Realtek ALC260 HD-audio codec support
<*>   Build Realtek ALC262 HD-audio codec support
<*>   Build Realtek ALC268 HD-audio codec support
<*>   Build Realtek ALC269 HD-audio codecs support
<*>   Build Realtek ALC662 HD-audio codecs support
<*>   Build Realtek ALC680 HD-audio codecs support
<*>   Build Realtek ALC861 HD-audio codecs support
<*>   Build Realtek ALC861-VD HD-audio codecs support
<*>   Build Realtek ALC880 HD-audio codecs support
<*>   Build Realtek ALC882 HD-audio codecs support

I build my hardware drivers right in the kernel image and I had to re-roll it because I got that wrong. There isn't a specific choice for my ALC897 so I just selected the ALC800's and none of them had it. I booted up and looked at dmesg and it was configuring it as generic. It has to be one of the other ones. I enabled them all and my audio device is correctly detected. I'm going to have to pore over the source to find exactly which one I need, for the ALC897.

Also, in hd-audio HDMI audio, there's an individual "AMD/ATI HDMI/DisplayPort HD-audio codec support" now.

The driver has also been split off into "HD-Audio PCI" and "HD-Audio ACPI" (for the old "Azalia" onboard... like on my old nehalem rig's motherboard) but I think that was in 6.16.

[Grogan]

A few seconds with grep, and my realtek codec that supports ALC897 is alc662.c. Go figure.

Code: Select all

static const struct hda_device_id snd_hda_id_alc662[] = {
	HDA_CODEC_ID(0x10ec0272, "ALC272"),
	HDA_CODEC_ID_REV(0x10ec0662, 0x100101, "ALC662 rev1"),
	HDA_CODEC_ID_REV(0x10ec0662, 0x100300, "ALC662 rev3"),
	HDA_CODEC_ID(0x10ec0663, "ALC663"),
	HDA_CODEC_ID(0x10ec0665, "ALC665"),
	HDA_CODEC_ID(0x10ec0667, "ALC667"),
	HDA_CODEC_ID(0x10ec0668, "ALC668"),
	HDA_CODEC_ID(0x10ec0670, "ALC670"),
	HDA_CODEC_ID(0x10ec0671, "ALC671"),
	HDA_CODEC_ID(0x10ec0867, "ALC891"),
	HDA_CODEC_ID(0x10ec0892, "ALC892"),
	HDA_CODEC_ID(0x10ec0897, "ALC897"),
	{} /* terminator */
};

Now I can save a whole 2 kb (or something lol)

P.S. Cleaning up the hdaudio driver of all unnecessary parts reduced my kernel image by about 30 kb

[Grogan]

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

Not a very big changelog but there are a few significant little fixes, for example:

mm: swap: check for stable address space before operating on the VMA

commit 1367da7eb875d01102d2ed18654b24d261ff5393 upstream.

It is possible to hit a zero entry while traversing the vmas in unuse_mm()
called from swapoff path and accessing it causes the OOPS:

[Zema Bus]

6.17.2