- openSUSE Kernel

rpmlint related build fails in KMP
by Hans-Peter Jansen 07 Sep '21

07 Sep '21

FYI, latest rpmlint fails KMP builds, where their preamble doesn't contain something like: Supplements: (kernel-%1 and %name) BuildRequires: kernel-syms BuildRequires: modutils Before, usually just this was required (if I'm not mistaken): Requires: kernel-%1 As a result, more or less any KMP, that I build, failed to build now. I leave it up to the reader to decide whether this is a good or bad thing. Cheers, Pete

2 3

kernel packages sysctl values
by Ludwig Nussel 24 Aug '21

24 Aug '21

Hi, Following up on a discussion in bug 1184804 I took a look at the sysctl values each kernel ships in a separate file. vm.dirty_ratio is set to 20 on pae and x86_64 default kernels. AFAICS this is the builtin default of the kernel so can be dropped. kernel.hung_task_timeout_secs is set to zero. There's also a DEFAULT_HUNG_TASK_TIMEOUT kconfig setting. So I think this would be better set as kconfig option. That leaves some IPC settings that were set in 2006 due to bug 146656: | Name | where | setting | default | |---------------+-------+--------------------+--------------------+ | kernel.msgmax | all | 65536 | 8192 | | kernel.msgmnb | all | 65536 | 16384 | | kernel.shmmax | 32bit | 0xffffffff | 0xfeffffff | | kernel.shmall | 32bit | 0xffffffff | 0xfeffffff | | kernel.shmmax | 64bit | 0x0fffffffffffff00 | 0xfffffffffeffffff | | kernel.shmall | 64bit | 0x0fffffffffffff00 | 0xfffffffffeffffff | All of them were supposed to be higher than the default. The shmmax and shmall on 64bit systems are actually lower though if I calculate correctly (upstream default is ULONG_MAX - (1UL << 24)). So I guess those two can be dropped on 64bit systems? Is the 32bit limit relevant? If not, shm* wouldn't need to be set at all via sysctl. Then we'd only have msgmax and msgmnb left. In the bug the upstream defaults were called "totally useless". Maybe makes sense to take the change upstream then? :-) In any case the setting is not kernel version or flavor dependent. So even if not for upstream, we could set msgmax and msgmnb in aaa_base instead. It already ships distro defaults: https://github.com/openSUSE/aaa_base/blob/master/files/usr/lib/sysctl.d/50-… Thoughts? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)

1 0

Looking for the patch file for the fix described in Support document #000019780
by Derek P 10 Aug '21

10 Aug '21

https://www.suse.com/support/kb/doc/?id=000019780 I found this report from last year that seems to match a problem encountered on one of our non-opensuse servers. I dropped by irc://libera.chat/opensuse to see if I could find the bug and patch to check the source of our CIFS module to see if it was missing. They told me to ask the kernel list. Can you help? Thanks.

1 1

Re: kernel head coops since config: re-modularize CRYPTO_{CTS,ECB,HMAC,SHA512,XTS} (bsc#1189034).
by Jeff Mahoney 09 Aug '21

09 Aug '21

On 8/9/21 4:35 AM, Cristian Rodríguez wrote: > I believe this change caudses the following oops on my system: > > * Tue Aug 03 2021 jeffm(a)jeffm.io > - config: re-modularize CRYPTO_{CTS,ECB,HMAC,SHA512,XTS} (bsc#1189034). > Now that FS_ENCRYPTION_ALGS is modular, the crypto modules it utilizes > can be modular as well. CRYPTO_AES and CRYPTO_CBC are used by > ENCRYPTED_KEYS and must remain built-in. > - commit 5f8b914 I've updated the bug report for this. TL;DR there was a regression introduced in 5.14-rc1. The root cause is that DRBG now tests sha512 on startup and does so before the initramfs is loaded. The commit that made that change didn't add it to the Kconfig option to select it as a built-in. BTW, not an oops, just a warning -- but it would've been a full panic if the system was booted in FIPS mode. I would've CC'd you to the bug but our Bugzilla doesn't do searching for users anymore (yay GDPR) and it's not the same as your email here. Thanks for the report, -Jeff > 0.238360] wait_for_initramfs() called before rootfs_initcalls > [ 0.250353] DRBG: could not allocate digest TFM handle: hmac(sha512) > [ 0.250353] alg: drbg: Failed to reset rng > [ 0.250353] alg: drbg: Test 0 failed for drbg_nopr_hmac_sha512 > [ 0.250353] ------------[ cut here ]------------ > [ 0.250353] alg: self-tests for drbg_nopr_hmac_sha512 (stdrng) > failed (rc=-22) > [ 0.250353] WARNING: CPU: 0 PID: 130 at crypto/testmgr.c:5652 > alg_test+0x357/0x540 > [ 0.250353] Modules linked in: > [ 0.250353] CPU: 0 PID: 130 Comm: cryptomgr_test Not tainted > 5.14.0-rc5-1.g1838496-default #1 openSUSE Tumbleweed (unreleased) > 31a1ab2de085eb8c788832590628680dfc173760 > [ 0.250353] Hardware name: Microsoft Corporation Virtual > Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 11/01/2019 > [ 0.250353] RIP: 0010:alg_test+0x357/0x540 > [ 0.250353] Code: 01 00 00 80 3d 22 4a fe 01 00 0f 85 c9 01 00 00 > 44 89 c1 4c 89 ea 48 89 ee 48 c7 c7 18 1d b9 84 44 89 44 24 08 e8 0a > f4 55 00 <0f> 0b 44 8b 44 24 08 48 8b 84 24 a0 00 00 00 65 48 2b 04 25 > 28 00 > [ 0.250353] RSP: 0000:ffffaf2a0089be28 EFLAGS: 00010282 > [ 0.250353] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000ffffbfff > [ 0.250353] RDX: 0000000000000000 RSI: 00000000ffffffea RDI: 0000000000000001 > [ 0.250353] RBP: ffff94dd40b3e600 R08: ffff94de47f5a068 R09: 00000000ffffbfff > [ 0.250353] R10: ffff94de3faa0000 R11: ffff94de3faa0000 R12: 000000000000000c > [ 0.250353] R13: ffff94dd40b3e680 R14: 0000000000000053 R15: 00000000000014c0 > [ 0.250353] FS: 0000000000000000(0000) GS:ffff94de3fc00000(0000) > knlGS:0000000000000000 > [ 0.250353] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 0.250353] CR2: 0000000000000000 CR3: 00000001eb210001 CR4: 00000000003706f0 > [ 0.250353] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 0.250353] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > [ 0.250353] Call Trace: > [ 0.250353] ? __schedule+0x32d/0x1530 > [ 0.250353] ? ttwu_do_wakeup+0x17/0x150 > [ 0.250353] ? _raw_spin_unlock_irqrestore+0xa/0x20 > [ 0.250353] ? try_to_wake_up+0x1d1/0x4f0 > [ 0.250353] ? __cond_resched+0x16/0x40 > [ 0.250353] ? crypto_acomp_scomp_free_ctx+0x30/0x30 > [ 0.250353] cryptomgr_test+0x27/0x50 > [ 0.250353] kthread+0x124/0x150 > [ 0.250353] ? set_kthread_struct+0x40/0x40 > [ 0.250353] ret_from_fork+0x1f/0x30 > [ 0.250353] ---[ end trace c2ebd3efee6d0c0e ]--- > > > Just FYI..thanks. > -- Jeff Mahoney Director, SUSE Labs Data & Performance

1 0

missing kernel-default-{extra,optional} after upgrade from 15.2 to 15.3
by Michal Kubecek 27 Jul '21

27 Jul '21

Hello, earlier today, I upgraded my workstation in the office from Leap 15.2 to 15.3 with "zypper dup". Unlike my workstation at home where the upgrade worked nicely, this machine failed to boot after the upgrade; I ended up with "give root password for maintenance" prompt and while things looked fine and most filesystems mounted, an attempt to setup networking failed due to missing D-Bus. After some experiments, I learned that the boot succeeds completely with leftover 15.2 kernel which hinted me to check if kernel-default-extra and kernel-default-optional are installed. They were not and installing them resolved the issue. After a successful boot, I checked loaded modules and found two which were not in kernel-default: jfs (JFS filesystem) sp5100_tco (TCO timer driver for SP5100/SB800 chipset) As I'm remote again, I don't want to confirm it with an experiment but my prime suspect is jfs module as the machine has one JFS filesystem mounted by default for historical reasons. Also, the sp5100_tco module has refcount of zero. But it does not really matter which module was missing, the important question is: is this outcome expected? It is IMHO rather unfortunate if a system fails to boot after an upgrade due to a missing kernel subpackage. So perhaps even more important question: can we do something about it? Michal

2 3

Why CRYPTO_ECDSA=y?
by Jean Delvare 25 Jun '21

25 Jun '21

Hi Michal, Is there a specific reason why you set CRYPTO_ECDSA=y in the kernel config, instead of making it a module? I think we want do make things modular whenever possible so that the base kernel isn't too heavy to load? Thanks, -- Jean Delvare SUSE L3 Support

2 1

kernel-firmware-20210609-35.1.noarch - kernel says: no suitable firmware found!
by Manfred Hollstein 23 Jun '21

23 Jun '21

Hi there, I'm pretty sure this is a result of the UsrMerge thing. I normally use kernel-default and kernel-firmware from Kernel:stable on all of my systems. While kernel-default-5.12.12-2.1.g43254cf.x86_64 works flawlessly, it fails to locate the firmware files from the latest package kernel-firmware-20210609-35.1.noarch. Here are the symptoms: iwlwifi 0000:06:00.0: Direct firmware load for iwlwifi-3160-17.ucode failed with error -2 iwlwifi 0000:06:00.0: no suitable firmware found! iwlwifi 0000:06:00.0: check git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git i915 0000:00:02.0: Direct firmware load for i915/kbl_dmc_ver1_04.bin failed with error -2 i915 0000:00:02.0: [drm] Failed to load DMC firmware i915/kbl_dmc_ver1_04.bin. Disabling runtime power management. i915 0000:00:02.0: [drm] DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git… And indeed, the files used to live at /lib/firmware before, but are now located at /usr/lib/firmware, however dracut does not look there when creating the initrd. This is on Leap 15.3 and 15.2. Shall I put this into Bugzilla? Cheers. l8er manfred

2 2

Getting the kernel out of /boot
by Ludwig Nussel 22 Jun '21

22 Jun '21

Hi, One of the motivations for UsrMerge is to have all read-only parts of the operating system in /usr. The kernel packages install files in /boot though which isn't in line with that idea. Looking at Fedora they install files like vmlinuz that used to be named /boot/$name-$kver as (/usr)/lib/modules/$kver/$name instead. They include /boot/$name-$kver as %ghost. Since all necessary information is passed to /usr/lib/bootloader/bootloader_entry in %post, that script could create links or copies in /boot if needed. Does anyone have a better idea or can we just follow Fedora's approach here? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)

16 75

Request for low latency kernel CONFIG_HZ at 1000 Hz
by Thomas Hartwig 16 Jun '21

16 Jun '21

I am wondering if there is any kernel available by default which offers kernel interrupt timer (CONFIG_HZ) at 1000 Hz. I checked preempt in 15.2 but there it is 250 Hz. Why this is kept at 250 Hz there? My use case is very special: my environment is dealing with high speed cameras and the low frequency is needed to be able to manage high frame speed at several thousand frames per second. Right now I am using a special desktop kernel from a foreign source however I am wondering if there is any chance to have this into mainline LEAP distro available? I know my use case is very special and I should be able to maintain my own kernel for this, however I am wondering if this would be a nice benefit of the LEAP distribution in general and why the preempt kernel is kept at lower frequency still... Thanks Thomas

5 13

Re: Pluggable SATA disk not detected on recent kernels
by Manfred Hollstein 14 Jun '21

14 Jun '21

Hi there, On Sun, 13 Jun 2021, 13:26:48 +0200, Manfred Hollstein wrote: > Hi there, > > I'm not sure when it started, but noticed it around 5.12.9 - have to > admit though, that I was probably very lazy when doing backups during > the last months... Anyway, when plugging a SATA disk into some disk > tray, the kernel doesn't detect a new device. This used to work > perfectly some months before, and it actually still does on Leap's > default kernel (both 15.2 and 15.3). The following kernels both show > this bug: > > kernel-default-5.12.10-2.1.gb92eaf7.x86_64 > kernel-vanilla-5.12.10-2.1.gb92eaf7.x86_64 > > <https://bugzilla.opensuse.org/show_bug.cgi?id=1187252> strange thing, really! Just found the culprit: somehow the "Hot Plug" bit for the SATA port connected to the tray box got disabled in the BIOS. Really don't know how this could have happened, but I guess it must have been during a BIOS update as the misbehaviour could be reproduced on two otherwise identical systems. Cheers. l8er manfred

1 0