The Latest Kernel Release.

3rensho · 06-09-2022, 04:48 AM

5.18.3 et al. have arrived

kjhambrick · 06-09-2022, 04:53 AM

all --

Generic Kernel Version 5.15.46.kjh is running fine on Slackware64 15.0 + Multilib here.

-- kjh

Code:

uname -a ...: Linux kjhlt7.kjh.home 5.15.46.kjh #1 SMP PREEMPT Thu Jun 9 04:28:04 CDT 2022 x86_64 11th Gen Intel(R) Core(TM) i9-11900K @ 3.50GHz GenuineIntel GNU/Linux
firmware ...: kernel-firmware-20220531_eaee2da-noarch-1
NVidia Blob : NVIDIA-Linux-x86_64-515.48.07.run
VMWare Blob : VMware-Workstation-Full-16.2.3-19376536.x86_64.bundle

3rensho · 06-09-2022, 06:22 AM

5.18.3 built fine with gcc-12.1. Offered one change to .config and I accepted default. Comparing the 5.18.3 .config to the previous version the following changes were seen -

Code:

Additions:

CONFIG_CC_HAS_ASM_GOTO_TIED_OUTPUT=y
# CONFIG_EFI_FAKE_MEMMAP is not set

and changed CONFIG_RADIO_ADAPTERS from y to m

Logs look OK.

cwizardone · 06-09-2022, 06:25 AM

Kernel updates 5.18.3, 5.17.14, 5.15.46 and 5.10.121 are now available at, https://www.kernel.org/

The change logs,

https://cdn.kernel.org/pub/linux/ker...angeLog-5.18.3

https://cdn.kernel.org/pub/linux/ker...ngeLog-5.17.14

https://cdn.kernel.org/pub/linux/ker...ngeLog-5.15.46

https://cdn.kernel.org/pub/linux/ker...geLog-5.10.121

cwizardone · 06-10-2022, 09:16 PM

The 5.18.x kernel has been moved into -current from -current/testing.

Quote:

Sat Jun 11 01:56:19 UTC 2022
...................
a/kernel-generic-5.18.3-x86_64-1.txz: Upgraded.
a/kernel-huge-5.18.3-x86_64-1.txz: Upgraded.
a/kernel-modules-5.18.3-x86_64-1.txz: Upgraded.
d/kernel-headers-5.18.3-x86-1.txz: Upgraded.
k/kernel-source-5.18.3-noarch-1.txz: Upgraded.

Ditto gcc-12.1.0.

Aeterna · 06-10-2022, 11:02 PM

Quote:

Originally Posted by 3rensho

5.18.3 built fine with gcc-12.1. Offered one change to .config and I accepted default. Comparing the 5.18.3 .config to the previous version the following changes were seen -

Code:

Additions:

CONFIG_CC_HAS_ASM_GOTO_TIED_OUTPUT=y
# CONFIG_EFI_FAKE_MEMMAP is not set

and changed CONFIG_RADIO_ADAPTERS from y to m

Logs look OK.

hmm I had CONFIG_EFI_FAKE_MEMMAP disabled long time ago (earliest config that I still have is 5.13.x), I never had CONFIG_RADIO_ADAPTERS enabled either.

my understanding is that CONFIG_CC_HAS_ASM_GOTO_TIED_OUTPUT detects buggy clang, if so, not really needed.

cwizardone · 06-11-2022, 09:20 AM

Quote:

Originally Posted by marav

06-09-22. It's been a while, here too, since I've seen a kernel running so well from the first release

Quote:

Originally Posted by cwizardone

06-09-22. Let's hope one (or more) of the 879 patches in 5.18.3 doesn't spoil the party.

So, far, so good.

Still haven't found a solution to the WINE problem (slow starting) that began with the 21 May updates.

cwizardone · 06-11-2022, 02:24 PM

Just had one heck of a scare!
I was about to shut the machine down, but before doing so told Thunderbird to check for e-mail. It replied there wasn't enough hard disk space for new mail. There is plenty of space!
The next thing I know I'm out of X and back at the prompt (init3).
I typed, "startx" and Xfce opens, but I'm using KDE4 (in up to the moment -current). I checked my user directory and it is fresh, as if I'm a brand new user, that is, my /home/username directory had been deleted.
After restoring my backup, I was looking at the system with Midnight Commander and noticed that in /home was a new directory named, Home (note the capital H). Turns out that was my user directory. It, somehow, was renamed to, Home.
I have no idea how any of this happened. NONE. I never have had a problem sleep walking

, so I really don't have clue as to what is going on.
The panic is over, but I had already returned to gcc-11.3.0 and the 5.18.2 kernel before restoring the backup and I think I'll stay with them for the time being.

LuckyCyborg · 06-12-2022, 04:19 AM

Simply reusing the -current's generic .config for building the 5.18.3 kernel on Slackware 15.0 resulted in 4,6GB space occupied by the kernel modules.

WTF?

PS. I've just used "make tarxz-pkg" and I do NOT think this influenced any way.

ponce · 06-12-2022, 04:21 AM

Quote:

Originally Posted by LuckyCyborg

Simply reusing the -current's generic .config for building the 5.18.3 kernel on Slackware 15.0 resulted in 4,6GB space occupied by the kernel modules.

WTF?

PS. I've just used "make tarxz-pkg" and I do NOT think this influenced any way.

https://www.linuxquestions.org/quest....php?p=6360302

LuckyCyborg · 06-12-2022, 04:43 AM

Quote:

Originally Posted by ponce

https://www.linuxquestions.org/quest....php?p=6360302

This CONFIG_DEBUG_INFO_BTF_MODULES is not set, anyway and programmatically stripping the debug info works only when you build a package.

I for one, I use "make tarxz-pkg" which uses the built in routines.

LuckyCyborg · 06-12-2022, 05:18 AM

Hmm...

Looks like we got "CONFIG_DEBUG_INFO=y" in the brand new .config file for 5.18.3 and the debug data is stripped latter into SlackBuild.

While previously, there was used "CONFIG_DEBUG_INFO_NONE=y" and its friends.

In fact, the entire properly config section for 5.18.3 looks like this:

Code:

#
# Compile-time checks and compiler options
#
CONFIG_DEBUG_INFO_NONE=y
# CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT is not set
# CONFIG_DEBUG_INFO_DWARF4 is not set
# CONFIG_DEBUG_INFO_DWARF5 is not set
CONFIG_FRAME_WARN=0
CONFIG_STRIP_ASM_SYMS=y
# CONFIG_READABLE_ASM is not set
# CONFIG_HEADERS_INSTALL is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_SECTION_MISMATCH_WARN_ONLY=y
# CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B is not set
CONFIG_STACK_VALIDATION=y
# CONFIG_VMLINUX_MAP is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# end of Compile-time checks and compiler options

I just imagine someone giving a malefic laugh, while the unsuspecting users tries to reuse the stock config and ends seeing more than 20GB of their space gone while getting XXXL modules...

Dear BDFL, I've appreciated well this joke, BUT you can fix your config please?

Now that we have found it out, isn't amusing anymore...

Jan K. · 06-12-2022, 08:10 AM

It was only a check to see if you were awake, Lucky!

Nice catch, btw.

3rensho · 06-12-2022, 08:34 AM

Read post wrong

LuckyCyborg · 06-12-2022, 10:39 AM

Quote:

Originally Posted by ponce

https://www.linuxquestions.org/quest....php?p=6360302

Quote:

Originally Posted by ponce

please see the related changes in kernel-modules.SlackBuild

https://git.slackware.nl/current/dif...d31327e01829cd

Code:

The CONFIG_DEBUG_INFO_BTF_MODULES option adds a huge amount of debugging
data to the modules which we don't actually need. We'll strip debugging
information from kernel modules by default. If you are building a debug
kernel and wish to retain this data, export the variable below set to "NO".

in my custom kernels I just use a line from that after building and before packaging

Code:

find $PKG -name "*.ko" -exec strip --strip-debug "{}" \;

(obviously $PKG should point to the already built modules tree)

In practice, from my own experience this means that building a kernel with the stock generic config requires over 20GB of space temporary wasted - this building with debug information sent a system of mine with 35GB free space in low space danger.

So, with all respect, permit me to say this: it's done in a freaking wrong way!

And for WHAT? To delete/strip all this over 20GB debug data by default? There isn't even the excuse of shipping debug packages for the kernels!

Assuming that there is a stray kernel developer who uses Slackware (which I sincerely doubt), permit me to bet that the kernel developers knows how to build their kernels with debug data.

So, this kernel config (with full debug enabled) shipped in rather decent sized kernel package(s) is nothing more than a storage space bomb - just like was long time ago those zip bombs, that 10KB zip archives which contains one or more 100GB files.

In the end, IF our BDFL really cares that much about the kernel developers wellness, he can just use a dedicated config file with all fancy debug enabled, selected by SlackBuild on choice.