New Kernel

[Zema Bus]

6.7.5 was released today.

[Grogan]

Yeah, I didn't get to post that today. I did it on both setups. A lot of networking fixes, stuff that could lead to oopses and stuff if certain circumstances are hit. It also looks like that bcachefs got some serious bug fixes. One I do use, ntfs3, got a fix like that.

[Grogan]

Linux 6.7.7 today
https://cdn.kernel.org/pub/linux/kernel ... eLog-6.7.7

Anyone using zswap (swap file with compressed pages in RAM) would want this kernel. There are a few fixes for zswap but this one is serious

Code: Select all

mm/zswap: invalidate duplicate entry when !zswap_enabled
    
    commit 678e54d4bb9a4822f8ae99690ac131c5d490cdb1 upstream.
    
    We have to invalidate any duplicate entry even when !zswap_enabled since
    zswap can be disabled anytime.  If the folio store success before, then
    got dirtied again but zswap disabled, we won't invalidate the old
    duplicate entry in the zswap_store().  So later lru writeback may
    overwrite the new data in swapfile.

Null pointer dereferences and memory leaks fixed in amdgpu/display (in some circumstances)

[Zema Bus]

I'll do this one this weekend, I've gotten behind on them.

[Grogan]

Linux 6.7.8 now
https://cdn.kernel.org/pub/linux/kernel ... eLog-6.7.8

ONE change, in a driver I use, but wouldn't affect me because I wouldn't hit that config scenario (no build failure)

Code: Select all

fs/ntfs3: fix build without CONFIG_NTFS3_LZX_XPRESS
    
    commit c8e314624a1666ed2eec28549713021a8ec801e9 upstream.
    
    When CONFIG_NTFS3_LZX_XPRESS is not set then we get the following build
    error:
    
      fs/ntfs3/frecord.c:2460:16: error: unused variable ‘i_size’

So most people would not need to do this release (I'm not going to).

[Zema Bus]

6.7.9 is out now.

[Grogan]

Linux 6.7.9 now
https://cdn.kernel.org/pub/linux/kernel ... eLog-6.7.9

I see a fix for something nasty for the nouveau driver.

Some fixes for KVM.

NFS: Fix data corruption caused by congestion.

I'm going to have to set up a NFS mount to get my dev directories, with all my source trees, patches, notes, PKGBUILDs, arch sources (probably 40,000 directories with little files... it's awful to even access it in a file manager because as soon as you go to the same directory level they try to read ahead for file magic. I don't intend to connect any SATA/mechanical drives, and I don't want to tar that up for transport (e.g. for ftp/sftp), and NFS is the least overhead for mountable shares and can use system accounts so that the ownership/permissions jibe. I always make sure my user and group are the same. There's also "root squash" where if you're root on this machine, you're root on the NFS share.

They are doing a lot of work on mptcp (a.k.a. mtcp... multipath), I've been seeing that a lot in this cycle's changelogs.

x86/cpu/intel: Detect TME keyid bits before setting MTRR mask registers

I don't know about that, but in general with a newer CPU, some of the changelog entries I might have ignored (like for CPU features I don't have and don't enable) might be applicable.

efivarfs: Request at most 512 bytes for variable names

EFI related stuff will be relevant now too

[Grogan]

Ahh, beat me to it

[Zema Bus]

Ahh, beat me to it

lol!

[Grogan]

I got mine done, I had to enable NFS server support anyway. I'm setting that up on Arch, as I'm abandoning my LFS for now (I'll be creating a partition for it on the new computer and adjusting it to work. Probably not much, it'll be grub that's different on the new machine)

Would you believe, for once, systemd actually makes something easier... All I have to do is start the nfsd service. On my LFS I'd have to set up portmap and a bunch of shit.

[Zema Bus]

I did a kernel compile time comparison between my Intel system (i9 12900KF) and my AMD system in my main machine (Ryzen 9 5900X). My Intel system compiled kernel 6.7.9 (using the "huge" kernel config) in 1 min, 50 secs. My AMD system compiled the same kernel and same config in 2 mins, 20 secs. Both have 24 threads but the 5900X has 12 regular cores with hyperthreading while the 12900KF has 8P cores with hyperthreading and 8E without hyperthreading. I'm considering swapping them around.

[Zema Bus]

Sounds like 6.8 has been released today, it's not on kernel.org yet but here's what Linus wrote:

So it took a bit longer for the commit counts to come down this
release than I tend to prefer, but a lot of that seemed to be about
various selftest updates (networking in particular) rather than any
actual real sign of problems. And the last two weeks have been pretty
quiet, so I feel there's no real reason to delay 6.8. We always have
some straggling work, and we'll end up having some of it pushed to
stable rather than hold up the new code. Nothing worrisome enough to
keep the regular release schedule from happening.

As usual, the shortlog below is just for the last week since rc7, the
overall changes in 6.8 are obviously much much bigger. This is not the
historically big release that 6.7 was - we seem to be back to a fairly
average release size for the last few years. You can see it in the
overall diffstats too - this looks like an average release in pretty
much all respects, and we don't have (for example) any obvious big new
filesystems or architectures. I think the biggest single new thing in
6.8 is probably the new Xe drm driver, but honestly, the big bulk of
changes are just various random updates and fixes all over.

Just as it should be.

In a sea of normality, one thing that stands out is a bit of random
git numerology. This is the last mainline kernel to have less than
ten million git objects. In fact, we're at 9.996 million objects, so
we got really close to crossing that not-milestone if it hadn't been
for the nice calming down in the last couple of weeks. Other trees -
notably linux-next - obviously are already comfortably over that
limit.

Of course, there is absolutely nothing special about it apart from a
nice round number. Git doesn't care.

Anyway, this all obviously means that tomorrow the merge window for
6.9 opens, and I already have several pull requests pending. Thanks to
everybody who sent in early pull requests, you know who you are. But
before that excitement commences, please do spend a bit of time with
the now boring old status quo and give 6.8 a good test, ok?

Linus

From the kernel mailing list.

[Grogan]

Shit, I just rebuilt my 6.7.9 a little while ago (fine tuning config)

[Grogan]

It's live on kernel.org now (I had to refresh my browser to see it)

I guess I'll do that right now.

[Grogan]

New kernel option:

Code: Select all

Allow writing to mounted block devices (BLK_DEV_WRITE_MOUNTED) [Y/n/?] (NEW)

Definitely need to say Y here, or things like fsck at boot time wouldn't be able to work.

[Grogan]

Huh, I was getting a nasty oops type warning (kernel tainting) like RIP: 0010:prefill_possible_map on CPU0 with a bunch of call trace oops spaghetti. It was during initializing CPUs, but it went on to do the right thing after, enabling 24 CPUs (only 8 of mine have hyperthreading) so I was pretty sure it was harmless (and I still think so, but we can't have that.) A quick search confirmed it was related to NR_CPUS (number of CPUs... default 32). So I set it to 24 and recompiled and now the oops is gone with Linux 6.8

I always used to set that to 8, but with the new CPU I just went back to the default of 32 (only 8 more... infinitesimal overhead). It seems limiting it to the actual number was good practice all along. (though that's a kernel bug... I just wouldn't have hit it)

[Zema Bus]

My temps while compiling 6.8.0:

Code: Select all

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +89.0°C  (high = +80.0°C, crit = +100.0°C)
Core 0:        +82.0°C  (high = +80.0°C, crit = +100.0°C)
Core 4:        +83.0°C  (high = +80.0°C, crit = +100.0°C)
Core 8:        +85.0°C  (high = +80.0°C, crit = +100.0°C)
Core 12:       +88.0°C  (high = +80.0°C, crit = +100.0°C)
Core 16:       +83.0°C  (high = +80.0°C, crit = +100.0°C)
Core 20:       +88.0°C  (high = +80.0°C, crit = +100.0°C)
Core 24:       +79.0°C  (high = +80.0°C, crit = +100.0°C)
Core 28:       +89.0°C  (high = +80.0°C, crit = +100.0°C)
Core 32:       +70.0°C  (high = +80.0°C, crit = +100.0°C)
Core 33:       +70.0°C  (high = +80.0°C, crit = +100.0°C)
Core 34:       +70.0°C  (high = +80.0°C, crit = +100.0°C)
Core 35:       +70.0°C  (high = +80.0°C, crit = +100.0°C)
Core 36:       +72.0°C  (high = +80.0°C, crit = +100.0°C)
Core 37:       +72.0°C  (high = +80.0°C, crit = +100.0°C)
Core 38:       +71.0°C  (high = +80.0°C, crit = +100.0°C)
Core 39:       +71.0°C  (high = +80.0°C, crit = +100.0°C)

nvme-pci-0900
Adapter: PCI adapter
Composite:    +36.9°C  (low  =  -0.1°C, high = +76.8°C)
                       (crit = +79.8°C)

[Grogan]

That's a bit better than mine, but still pretty toasty. How many jobs did you start?

[Zema Bus]

I went 24.

[Grogan]

That's probably about as good as you're going to get with air, from what I was reading.

[Zema Bus]

That's a big increase from my idle temps:

Code: Select all

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +32.0°C  (high = +80.0°C, crit = +100.0°C)
Core 0:        +24.0°C  (high = +80.0°C, crit = +100.0°C)
Core 4:        +27.0°C  (high = +80.0°C, crit = +100.0°C)
Core 8:        +27.0°C  (high = +80.0°C, crit = +100.0°C)
Core 12:       +29.0°C  (high = +80.0°C, crit = +100.0°C)
Core 16:       +25.0°C  (high = +80.0°C, crit = +100.0°C)
Core 20:       +24.0°C  (high = +80.0°C, crit = +100.0°C)
Core 24:       +27.0°C  (high = +80.0°C, crit = +100.0°C)
Core 28:       +25.0°C  (high = +80.0°C, crit = +100.0°C)
Core 32:       +24.0°C  (high = +80.0°C, crit = +100.0°C)
Core 33:       +24.0°C  (high = +80.0°C, crit = +100.0°C)
Core 34:       +24.0°C  (high = +80.0°C, crit = +100.0°C)
Core 35:       +24.0°C  (high = +80.0°C, crit = +100.0°C)
Core 36:       +28.0°C  (high = +80.0°C, crit = +100.0°C)
Core 37:       +28.0°C  (high = +80.0°C, crit = +100.0°C)
Core 38:       +28.0°C  (high = +80.0°C, crit = +100.0°C)
Core 39:       +28.0°C  (high = +80.0°C, crit = +100.0°C)

Once I get the replacement power supply in my Ryzen 5900X I'll see how it's temps compare.

[Grogan]

Linux 6.8.1 released
https://cdn.kernel.org/pub/linux/kernel ... eLog-6.8.1

It mostly consists of CPU mitigations for KVM to pass to guests, and another that might let userspace read stale data from floating point registers.

Yipee.

[Grogan]

Linux 6.8.2 is out, after a nice quiet period
https://cdn.kernel.org/pub/linux/kernel ... eLog-6.8.2

Miscellaneous fixes for a lot of things, should be had

[Grogan]

It's kernel time... Linux 6.8.3. We're not worthy (it's been a while)
https://cdn.kernel.org/pub/linux/kernel ... eLog-6.8.3

Code: Select all

drm/sched: fix null-ptr-deref in init entity
    
    commit f34e8bb7d6c6626933fe993e03ed59ae85e16abb upstream.
    
    The bug can be triggered by sending an amdgpu_cs_wait_ioctl
    to the AMDGPU DRM driver on any ASICs with valid context.

Code: Select all

drm/amdgpu: fix use-after-free bug
    
    commit 22207fd5c80177b860279653d017474b2812af5e upstream.
    
    The bug can be triggered by sending a single amdgpu_gem_userptr_ioctl
    to the AMDGPU DRM driver on any ASICs with an invalid address and size.

Code: Select all

drm/amdgpu: fix deadlock while reading mqd from debugfs
    
    commit 8678b1060ae2b75feb60b87e5b75e17374e3c1c5 upstream.
    
    An errant disk backup on my desktop got into debugfs and triggered the
    following deadlock scenario in the amdgpu debugfs files. The machine
    also hard-resets immediately after those lines are printed

Power management related fixes for amdgpu/display

Lots of specific USB fixes

Mitigations for Zen CPUs

I'm sure there's something for everybody in this one.

Enough reading

[Grogan]

For today's kernel build, I took the opportunity to remove some legacy cruft that I'm just never going to use anymore.

Removed PS/2 port, keyboard and mouse support (my keyboard doesn't expose any PS/2 logic to the OS anymore, it's the USB converter device now) and the ps/2 driver library. Removed serial port support and line disciplines (no longer needed with just HID input devices etc. now)

Removed support for SATA chipsets, except AHCI (IF I ever connect a SATA device, that's the only driver I'll be using) and I built that as a module now since I'm unlikely to use it (and not for booting). On the next boot I'll disable that in BIOS so the modules don't load. I've always disabled things I'm not using, why expose them and load drivers and assign resources. PATA disabled completely, I won't be accessing IDE drives anymore (don't have the facility for it on board)

All my USB devices (even "low speed" in the case of my keyboard adapter) are using XHCI so I've relegated UHCI and EHCI support to modules (and they don't load... I think all my USB ports are USB 3, even the "black" ones. I do have USB2 headers on the motherboard, but they aren't connected to anything because the Corsair case just has USB 3 (and C, which I don't have) ports on front. It's all the same USB controller probably, that's why it's "XHCI" only. (and that EHCI doesn't bind to anything on the chipset corroborates that)

To put it in perspective, even ALL THAT was just about 250kb savings on the bzImage. Just under 5 Mb, compared to about 5.2something before today.

5080064 Apr 3 17:21 vmlinuz-6.8.3

P.S. Can't disable the SATA controller in BIOS, moreover, I seem to have lost the ability to change the SATA controller mode at all, the "SATA Configuration" is greyed out, above the Intel VMD RAID settings ("volume management device" which I have disabled). My SATA controller is in AHCI mode and that's that. I had that setting with my original BIOS. I think I put it in AHCI mode originally, if I recall. It's possible they removed other SATA modes. You'd not be able to install an OS on here old enough to not support AHCI anyway. I don't recall if I ever was able to disable the SATA controller though.

[Zema Bus]

I just got 6.8.3 done, and updated Slackware.

Here's the size of my big fat kernel lol! 14213632 Apr 4 01:28 vmlinuz-6.8.3

[Grogan]

That's because you're using the fat distro config lol

We need to get you sorted out on how to build a modern kernel for yourself (when you get time and are feeling better etc.)

I thought 5 megs was big, but a lot of that code is monolithic to support a lot of different hardware and conditions. Not only drivers, but driver libraries. You see it more when it's modules, but that shit would be in kernel otherwise. That's not all the logic either, there's also the SCSI subsystem and SCSI disk support for SATA. I forgot that I could relegate the SCSI back end to modules now too (NVME doesn't use that). I really only need that for usbstorage/uas if not for the SATA support.

Just binding AHCI to a SATA controller uses all this shit (as well as other built in kernel subsystems of course too). That's why this shit is so big now. I remember the days of 500k kernels and you could make a 'zImage' if you were careful (fit in memory differently, used less). The last kernel I was able to do that with was Linux 2.4 (and even that was impractical).

Code: Select all

ahci                   40960  0
libahci                32768  1 ahci
libata                126976  2 libahci,ahci
scsi_mod              106496  1 libata
scsi_common            12288  2 scsi_mod,libata

There would also be "sd", scsi disk support if I actually had any drives connected (or plug in a thumb drive) but there's no call for that module yet. The "sg" (scsi generic) module also might get loaded in that stack.

I shaved another 70k off my kernel image by relegating the scsi support to modules. Not much point, it's using the same memory anyway, but I might see what happens if I blacklist AHCI. (that doesn't mean you can't load them, just that udev won't load it or its dependencies which aren't explicitly disabled, so, say, usbstorage would still load the scsi subsystem etc.))

By the way, no, you can't disable the native SATA controller on most boards. They are hardwired to PCI-E lanes and would require sophisticated switching in order to be turned off with software. Blacklisting the modules still leaves dangling resources that can't be used too, even though there is no driver binding, so even it is pointless. I'm just a minimalist. Also stubborn to do things my way.

[Grogan]

Heh...

Code: Select all

blacklist ahci
blacklist kvm_intel
blacklist fuse
blacklist dm_mod

(in /etc/modprobe.d/whatever.conf)

That takes care of all unnecessary modules (and their dependencies). I'll load those manually (in whatever scripts I use to initiate things that would use them anyway) if I need them. Using this method, when explicitly loaded, they'll load dependencies, for example if I load fuse it would load dm_mod (device mapper). I had to blacklist dm_mod too because it implicitly loads at systemd time when it probes for LVM and RAID etc.

My system, my kernel, my modules. I should be able to compile modules for occasional, or future use without dumbass udev loading them for no reason.

[Grogan]

Linux 6.8.4
https://cdn.kernel.org/pub/linux/kernel ... eLog-6.8.4

All reverts to backported workqueue patches that caused regressions.

P.S. I found a bugzilla report for this, it can cause the kernel to be unable to unhook things to hibernate and stuff. Stuck work queues etc. That could be why I had to hard boot last night instead of being able to recover from that VRAM page fault error.

[Zema Bus]

Glad that's all it was.

I should have waited one more night lol! Well I got 6.8.4 done now.