Page 9 of 10

Re: New Kernel

Posted: Mon Jan 19, 2026 9:31 am
by Grogan
Ahh, yet another 2 minute job to chip away at my soul :lol:

(just kidding, I love building kernels. My script takes all the work out of installing them too)

I'll probably wait until after I get up, there will be a changelog and .tar.xz by then. (valid excuses are how I cope with procrastination lol)

P.S. Longer changelog for 6.18.6
https://cdn.kernel.org/pub/linux/kernel ... Log-6.18.6

Re: New Kernel

Posted: Mon Jan 19, 2026 8:43 pm
by Grogan
Part of the reason I wanted to wait for official tarball is that I made new scripts that automate as much of it as I can (and wanted to test the build script).

There are things that simply have to be specified, and I still want to run menuconfig to check over/change the config, so it has to be a bit interactive.

Code: Select all

#! /bin/bash

VER=$VER

wget -c https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-$VER.tar.xz || exit 1
tar xf linux-$VER.tar.xz || exit 1
cd linux-$VER
make mrproper
cp ../.config . || exit 1
make LLVM=1 oldconfig
make LLVM=1 menuconfig
cp .config ../
cp .config ../config-$VER-clangthin
cp .config ../../config-$VER-clangthin
make LLVM=1 -j24 V=1
if [ $? == 0 ] ; then
  echo "############"
  echo "Starting install"
  echo "############"
  su -c installkern_clang
else
  echo "###### Kernel build failed! ######"
  exit 1
fi
I make two copies of my config, as I clean out the working directory once in a while, yet keep a permanent copy of every config in the directory above it. I never want to lose that.

The final command prompts for root password (su -c) and hands off to my install script, to install the kernel on both Arch and Crux. I wrapped it in a convoluted condition check (check status of last command) because I couldn't figure out a way to get "|| echo "Kernel build failed!" ; exit 1" to work. I wanted both an echo message and exit 1. I tried round brackets, square brackets but exit 1 only applied to the OR condition in the command, which was "echo" in that context (and with improper use of square brackets exited my shell which closed the terminal lol!), not the script itself that I want to abort, when written like that. Similar with using the shebang "#! /bin/bash -e" (same as set -e) it doesn't abort the whole script when the condition check is written like that. The above works, I tested it by making the kernel build fail.

This is the install script, installkern_clang. It's a bit more serious so I have rigorous condition checks. I don't want to make any changes (like removing the old kernel first) if anything goes wrong.

Code: Select all

#! /bin/bash

if [ -f "arch/x86/boot/bzImage" ]; then
  read -p "Enter OLDVER or leave blank to skip uninstall: " OLDVER
  read -p "Enter NEWVER: " NEWVER
else
  echo "You're in the wrong dir or your kernel isn't built"
  exit 1
fi

if [ -z "$NEWVER" ]; then
  echo "That was silly of you"
  exit 1
else
  echo "Mounting filesystems CTRL+C to abort 5s"
  sleep 5
  mount -t vfat -o umask=077 /dev/nvme1n1p1 /boot || exit 1
  mount -t ext4 -o noatime /dev/nvme1n1p4 /mnt/crux || exit 1
fi

if [ -z "$OLDVER" ]; then
  echo "Not removing old kernel"
else
  echo "Removing old kernel"
  rm /vmlinuz-"$OLDVER"
  rm /mnt/crux/vmlinuz-"$OLDVER"
  rm -r /lib/modules/"$OLDVER"
  rm -r /mnt/crux/lib/modules/"$OLDVER"
fi

echo "Installing Linux $NEWVER"
install -m 600 -o root arch/x86/boot/bzImage /vmlinuz-"$NEWVER" || exit 1
install -m 600 -o root arch/x86/boot/bzImage /mnt/crux/vmlinuz-"$NEWVER" || exit 1
make LLVM=1 modules_install
make LLVM=1 INSTALL_MOD_PATH=/mnt/crux modules_install
echo "Opening editor for grub.cfg"
vi /boot/grub/grub.cfg
sleep 1
sync
umount /boot || exit 1
umount /mnt/crux || exit 1
echo "/boot and /mnt/crux unmounted"
echo "Linux $NEWVER is installed"

The whole thing is started with:

Code: Select all

VER=6.18.6 buildkern
(The scripts are in /usr/local/bin)

Re: New Kernel

Posted: Fri Jan 23, 2026 8:11 pm
by Grogan
Linux 6.18.7 today... it gives me an excuse to play with my scripts anyway :-)

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

Things like this shouldn't be going in point releases, but this looks nice for reducing somebody's overhead (reducing tlb flushes). I don't think I'd enable it for my simple uses (and I also reduce that pressure by using transparent hugepages anyway).
mm: introduce deferred freeing for kernel page tables

commit 5ba2f0a1556479638ac11a3c201421f5515e89f5 upstream.

This introduces a conditional asynchronous mechanism, enabled by
CONFIG_ASYNC_KERNEL_PGTABLE_FREE. When enabled, this mechanism defers the
freeing of pages that are used as page tables for kernel address mappings.
These pages are now queued to a work struct instead of being freed
immediately.

This deferred freeing allows for batch-freeing of page tables, providing a
safe context for performing a single expensive operation (TLB flush) for a
batch of kernel page tables instead of performing that expensive operation
for each page table.
P.S. I don't think this is completely implemented, I wasn't prompted for it with oldconfig and there's no new option for it in memory management. It's probably something that has to be added manually to .config (CONFIG_ASYNC_KERNEL_PGTABLE_FREE=y) at this time.

P.S. Oh... it's just not a user facing config option, it's just automatically enabled like many other options based on detected arch etc. I guess I'll take it then. To disable it you'd have to manually set that to N if you know what you're doing and have a reason to.

Code: Select all

[grogan@nicetry archkern]$ grep -n CONFIG_ASYNC_KERNEL_PGTABLE_FREE .config
1023:CONFIG_ASYNC_KERNEL_PGTABLE_FREE=y
(line 1023 is in there with the other mm config options in my file)

Re: New Kernel

Posted: Fri Jan 30, 2026 9:25 pm
by Grogan
It's Linux 6.18.8 time
https://cdn.kernel.org/pub/linux/kernel ... Log-6.18.8

Lots of mm related fixes in there, a few graphics driver fixes and other miscellaneous stuff. As usual, much of it would be inapplicable to an individual.

Re: New Kernel

Posted: Fri Feb 06, 2026 8:50 pm
by Grogan
Linux 6.18.9 today
https://cdn.kernel.org/pub/linux/kernel ... Log-6.18.9

Lots of drm/amdgpu fixes

Re: New Kernel

Posted: Mon Feb 09, 2026 7:32 am
by Zema Bus
6.19, time to get busy :)

Re: New Kernel

Posted: Mon Feb 09, 2026 8:24 am
by Grogan
Ahh, might as well get on it now. I'm going to have to make my script rename the directory for my scripts to work out (despite being versioned as 6.19.0 internally, these mainline releases are named as 6.19 in tarball and the directory they unpack to) though, I hate that they do that with these :lol:

Re: New Kernel

Posted: Mon Feb 09, 2026 10:41 am
by Grogan
There were some new options for Transparent Huge Page Support. I use THP, so I said why not and said always for SHM and tmpfs mounts.

Well... with no games, no anything (just a small X11 window manager), I've got 674M "shared memory" (SHM and tempfs mounts and there's very little in /tmp and stuff). I can't see that being of benefit, and I can't see using all that memory instead of like 10M, so I have disabled those. (So it's now like it was pre-6.19)

Code: Select all

 --- Transparent Hugepage Support
        Transparent Hugepage Support sysfs defaults (always)  --->
        Shmem hugepage allocation defaults (never)  --->
        Tmpfs hugepage allocation defaults (never)  --->
[*]    Read-only THP for filesystems (EXPERIMENTAL)
[*]    No per-page mapcount (EXPERIMENTAL)

Re: New Kernel

Posted: Mon Feb 16, 2026 11:40 am
by Grogan
Linux 6.19.1 now
https://cdn.kernel.org/pub/linux/kernel ... Log-6.19.1

Lots of smb related fixes in there. I haven't used that in ages (don't connect to anything with windows networking anymore)

Re: New Kernel

Posted: Mon Feb 16, 2026 5:29 pm
by Zema Bus
And now it's 6.19.2 :)

Re: New Kernel

Posted: Mon Feb 16, 2026 7:42 pm
by Grogan
Ahh, I'm glad I didn't do it yet. One serious revert:
Revert "driver core: enforce device_lock for driver_match_device()"

This reverts commit bc82e5f4d7dc8237ae8cabc73aa46fc93c85d98c which is
commit dc23806a7c47ec5f1293aba407fb69519f976ee0 upstream.

It causes boot regressions on some systems as all of the "fixes" for
drivers are not properly backported yet. Once that is completed, only
then can this be applied, if really necessary given the potential for
explosions, perhaps we might want to wait a few -rc releases first...

Re: New Kernel

Posted: Thu Feb 19, 2026 8:27 pm
by Grogan
Linux 6.19.3 already
https://cdn.kernel.org/pub/linux/kernel ... Log-6.19.3

Mostly fixes for f2fs filesystem. Another one of those filesystems that few use. (developed by Samsung for flash memory, I'm sure it's superior, but we have FAT32! :roll: )

Re: New Kernel

Posted: Mon Feb 23, 2026 1:15 am
by Grogan
It wasn't certain whether it was going to be "6.20" or "7.0" but 7.0-rc1 is out on kernel.org now. There will be too many shit tonnes of changes for a changelog (just git commit history with terse description etc.) :-)

Re: New Kernel

Posted: Fri Feb 27, 2026 10:20 pm
by Grogan
It's a bird, it's a plane, it's Linux 6.19.4 (go out for supplies and come back).... no, it's Linux 6.19.5 :lol:

Linux 6.19.5
https://cdn.kernel.org/pub/linux/kernel ... Log-6.19.5
netfilter: nf_tables: add .abort_skip_removal flag for set types

commit f175b46d9134f708358b5404730c6dfa200fbf3c upstream.

The pipapo set backend is the only user of the .abort interface so far.
To speed up pipapo abort path, removals are skipped.

The follow up patch updates the rbtree to use to build an array of
ordered elements, then use binary search. This needs a new .abort
interface but, unlike pipapo, it also need to undo/remove elements.

Add a flag and use it from the pipapo set backend.
It must be considered something important that was missed. (I was expecting this to be an emergency revert or something)

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

ata/libata/libata-scsi fixes that look significant.
Various driver additions/fixes (e.g. stuff like "fix mic on this laptop" etc. )

Re: New Kernel

Posted: Sat Feb 28, 2026 7:10 am
by Zema Bus
So now I'm really behind lol!

Re: New Kernel

Posted: Wed Mar 04, 2026 9:13 pm
by Grogan
Linux 6.19.6
https://cdn.kernel.org/pub/linux/kernel ... Log-6.19.6

It's a substantial changelog, lots of fixes for various things.

A fairly significant looking amdgpu fix:
drm/amdgpu: Refactor amdgpu_gem_va_ioctl for Handling Last Fence Update and Timeline Management v7

[ Upstream commit efdc66fe12b07e7b7d28650bd8d4f7e3bb92c5d4 ]

When GPU memory mappings are updated, the driver returns a fence so
userspace knows when the update is finished.

The previous refactor could pick the wrong fence or rely on checks that
are not safe for GPU mappings that stay valid even when memory is
missing. In some cases this could return an invalid fence or cause fence
reference counting problems.

Fix this by (v5,v6, per Christian):
- Starting from the VM’s existing last update fence, so a valid and
meaningful fence is always returned even when no new work is required.
- Selecting the VM-level fence only for always-valid / PRT mappings using
the required combined bo_va + bo guard.
- Using the per-BO page table update fence for normal MAP and REPLACE
operations.
- For UNMAP and CLEAR, returning the fence provided by
amdgpu_vm_clear_freed(), which may remain unchanged when nothing needs
clearing.
- Keeping fence reference counting balanced.

v7: Drop the extra bo_va/bo NULL guard since
amdgpu_vm_is_bo_always_valid() handles NULL BOs correctly (including
PRT). (Christian)

This makes VM timeline fences correct and prevents crashes caused by
incorrect fence handling.
XFS users will want this:
xfs: fix copy-paste error in previous fix

[ Upstream commit e764dd439d68cfc16724e469db390d779ab49521 ]

Chris Mason noticed that there is a copy-paste error in a recent change
to xrep_dir_teardown that nulls out pointers after freeing the
resources.
Power management fuckery (I'm glad I don't use it)
Revert "ACPI: processor: Update cpuidle driver check in __acpi_processor_start()"

This reverts commit 0089ce1c056aee547115bdc25c223f8f88c08498 which is
upstream commit 6cfed39c2ce64ac024bbde458a9727105e0b8c66.

This commit is causing a suspend regression on systems such as the Asus
Zephyrus G14 (GA402RJ) with Ryzen 7 6700H: when suspending, the display
turns off but the device fails to fully power down. This is not seen
with v7.0-rc1 which indicates that there are changes missing. Therefore,
revert this change.
I'm not sure I like this... I prefer hardware to initialize properly (I don't use "fast boot" in bios, though this is driver side). If that shit was disabled for my hardware all this time, I'd probably prefer it to stay that way.
drm/amd/display: Correct logic check error for fastboot

[ Upstream commit b6a65009e7ce3f0cc72da18f186adb60717b51a0 ]

[Why]
Fix fastboot broken in driver.
This is caused by an open source backport change 7495962c.

from the comment, the intended check is to disable fastboot
for pre-DCN10. but the logic check is reversed, and causes
fastboot to be disabled on all DCN10 and after.

fastboot is for driver trying to pick up bios used hw setting
and bypass reprogramming the hw if dc_validate_boot_timing()
condition meets.
I'm pretty sure that's a typo and the author meant Graphics Core, "GC10" (there is no DCN, "display core new", version 10, moreover, this doesn't have anything to do with display interface). GC 10.x is the 5000XT'ish to 6800XT'ish cards. Actually here's a pretty good chart I just found:

https://www.kernel.org/doc/html/next/gp ... -info.html

Mine is GC 11.0.3 (not listed specifically on that chart, same one as 7800XT... but I know it because it's the GC firmware version my card uses, gc_11_0_3_*.bin)

Re: New Kernel

Posted: Wed Mar 11, 2026 11:50 pm
by Grogan
New linux-firmware-20260309 archive today, and amdgpu firmware files have changed. Not very often for mine, but the GC 11.0.3 have all changed. I checksum the files I install every time there's a new linux-firmware tarball. If unchanged, I need do nothing. (my onboard realtek nic firmware hasn't changed either, probably never). Since I build my amdgpu and firmware right into the kernel now, I rebuilt with the new firmware included.

I'm back to building with gcc now too. The clang/LTO is an unnecessary risk for subtle breakage, somewhere. There's no way I'd ever be able to qualify, or quantify any improvement by doing so with the kernel code anyway. Likely, if the kernel devs actually approved of it they'd tool up a LTO build for gcc too, if there was any worthwhile benefit.

I've learned my lesson with LTO, there are very few things I let that get turned on for (and my Arch makepkg defaults has !lto). Only if the project intends it. For example gcc has actual build switches for it... bootstrap-lto. Firefox also tools it up themselves and it's meant to be compiled that way, detrimental without it. etc.

Re: New Kernel

Posted: Thu Mar 12, 2026 9:15 pm
by Grogan
Linux 6.19.7 now
https://cdn.kernel.org/pub/linux/kernel ... Log-6.19.7

Oooh, look... an AI discovered fix for an important subsystem (well, its exception handling)
ata: libata-eh: Fix detection of deferred qc timeouts

[ Upstream commit ee0e6e69a772d601e152e5368a1da25d656122a8 ]

If the ata_qc_for_each_raw() loop finishes without finding a matching SCSI
command for any QC, the variable qc will hold a pointer to the last element
examined, which has the tag i == ATA_MAX_QUEUE - 1. This qc can match the
port deferred QC (ap->deferred_qc).

If that happens, the condition qc == ap->deferred_qc evaluates to true
despite the loop not breaking with a match on the SCSI command for this QC.
In that case, the error handler mistakenly intercepts a command that has
not been issued yet and that has not timed out, and thus erroneously
returning a timeout error.

Fix the problem by checking for i < ATA_MAX_QUEUE in addition to
qc == ap->deferred_qc.

The problem was found by an experimental code review agent based on
gemini-3.1-pro while reviewing backports into v6.18.y.
Another interesting one:
nvme: fix memory allocation in nvme_pr_read_keys()

[ Upstream commit c3320153769f05fd7fe9d840cb555dd3080ae424 ]

nvme_pr_read_keys() takes num_keys from userspace and uses it to
calculate the allocation size for rse via struct_size(). The upper
limit is PR_KEYS_MAX (64K).

A malicious or buggy userspace can pass a large num_keys value that
results in a 4MB allocation attempt at most, causing a warning in
the page allocator when the order exceeds MAX_PAGE_ORDER.

To fix this, use kvzalloc() instead of kzalloc().

Re: New Kernel

Posted: Fri Mar 13, 2026 9:40 pm
by Grogan
It's a fucking cat and mouse game. Linux 6.19.8 already
https://cdn.kernel.org/pub/linux/kernel ... Log-6.19.8

Mostly alot of apparmor fixes... I hate that poxy thing, I don't build it (I disable all security models except normal "unix discretionary access controls"). A few net/sched fixes too though, so I guess I'm in.

Re: New Kernel

Posted: Thu Mar 19, 2026 9:25 pm
by Grogan
Well, just when you thought you were all fuckin set, Linux 6.19.9 now :lol:
https://cdn.kernel.org/pub/linux/kernel ... Log-6.19.9

Actually they HAVE taken steps to prevent that CXL NVDIMM dependency misconfiguration issue from happening:
cxl/acpi: Fix CXL_ACPI and CXL_PMEM Kconfig tristate mismatch

commit 93d0fcdddc9e7be9d4f42acbe57bc90dbb0fe75d upstream.

Commit e7e222ad73d9 ("cxl: Move devm_cxl_add_nvdimm_bridge() to
cxl_pmem.ko") moves devm_cxl_add_nvdimm_bridge() into the cxl_pmem file,
which has independent config compile options for built-in or module. The
call from cxl_acpi_probe() is guarded by IS_ENABLED(CONFIG_CXL_PMEM),
which evaluates to true for both =y and =m.

When CONFIG_CXL_PMEM=m, a built-in cxl_acpi attempts to reference a
symbol exported by a module, which fails to link. CXL_PMEM cannot simply
be promoted to =y in this configuration because it depends on LIBNVDIMM,
which may itself be =m.

Add a Kconfig dependency to prevent CXL_ACPI from being built-in when
CXL_PMEM is a module. This contrains CXL_ACPI to =m when CXL_PMEM=m,
while still allowing CXL_ACPI to be freely configured when CXL_PMEM is
either built-in or disabled.

Re: New Kernel

Posted: Fri Mar 20, 2026 6:55 am
by Zema Bus
I had a feeling there'd be another one soon lol! But this time I don't mind :)

Re: New Kernel

Posted: Wed Mar 25, 2026 8:28 pm
by Grogan
It's kernel time again, Linux 6.19.10 (and 7.0 has been at -rc5 for a few days, so that's likely winding down for release soon too)
https://cdn.kernel.org/pub/linux/kernel ... og-6.19.10

Various fixes, drm/graphics drivers, network, bootconfig (kernel commandline parameter parsing etc.)

Re: New Kernel

Posted: Wed Apr 01, 2026 7:21 am
by Zema Bus
Running 7.0.0-rc6 :)

kernel7.0.0-rc6.jpg

Re: New Kernel

Posted: Wed Apr 01, 2026 8:29 am
by Grogan
I'm going to wait for 7.0.0, probably. I did it last time only because they broke something in the later point releases and it wasn't broke in -rc7 of the next. (I can't remember the details, I'm sure I complained about it somewhere here lol)

I'm sure it will be fine though. I just don't want to be second guessing it. I also have system headers to consider too, I'll at least wait until 7.0.0 to use the kernel headers.

Re: New Kernel

Posted: Thu Apr 02, 2026 5:48 pm
by Grogan
Linux 6.19.11
https://cdn.kernel.org/pub/linux/kernel ... og-6.19.11

A metric shit tonnes of ext4 fixes, some probably backported from 7.0 (maybe I should wait to see if any get reverted lol)

Re: New Kernel

Posted: Mon Apr 06, 2026 2:16 am
by Zema Bus
No 7.0 release today, it's now at 7.0-rc7.

Re: New Kernel

Posted: Mon Apr 06, 2026 9:15 am
by Grogan
That wasn't expected yet, was it? It'll be getting close though, probably next week if it's -rc7

Re: New Kernel

Posted: Sat Apr 11, 2026 6:31 pm
by Grogan
Linux 6.19.12
https://cdn.kernel.org/pub/linux/kernel ... og-6.19.12

Lots of fixes, probably backporting from 7.0

Re: New Kernel

Posted: Sat Apr 11, 2026 11:54 pm
by Zema Bus
Think I'll holdout for 7.0, as I continue to run 7.0-rc7 :)

Re: New Kernel

Posted: Mon Apr 13, 2026 3:27 am
by Grogan
I was kind of expecting this tonight, and was not disappointed. The site isn't updated, but the linux-7.0.tar.gz snapshot is here:
https://git.kernel.org/pub/scm/linux/ke ... linux.git/

So now it's time :clap: