kernel March 2020

kernel@lists.fedoraproject.org

20 participants
10 discussions

Erase i686 from the kernel package's repository?
by Paul Bolle 22 Apr '21

22 Apr '21

Hi Justin, Fedora 31's release is imminent. This means that some time ago Fedora passed the point where (F31 and later) i686 releases were still possible, doesn't it? If so, could we please clean the kernel package's repository of all the things that are only relevant for i686? Because that would make my plans for the config generation [1] just a bit easier. Thanks, Paul Bolle [1] See https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.or…

4 16

Upcoming Fedora kernel workflow changes
by Jeremy Cline 17 Apr '20

17 Apr '20

Hi folks, This should come as no surprise to those who have been following the kernel list and/or saw Laura's Flock talk last summer, but there are some changes to the way the Fedora kernel is maintained coming in the next couple of weeks. For those folks who aren't committing directly to the kernel dist-git, this change won't really impact you, although contributing might be easier. We're planning to switch from maintaining the kernel directly in the dist-git to using a kernel source tree along with a set of scripts to turn the source tree into something that can be automatically checked into the dist-git. This means anything committed directly to the dist- git repository will get overwritten on the next update. The git repository is currently hosted at https://gitlab.com/cki-project/kernel-ark/. Documentation (still very rough) for common tasks is at https://gitlab.com/cki-project/kernel-ark/-/wikis/home. There are a few outstanding merge requests to get the tree fully synced up with the current state of the dist-git repository, so if you decide to jump in and try things out, be aware things might not work. As part of this, we're going to start bridging merge requests to this list as emailed patch series for those who prefer email, and turn any emailed patches to the list into merge requests, so the list is going to get quite a bit more traffic. Regards, Jeremy

10 42

Getting a null pointer dereference error at end of dnf update with kernel 5.6 in F31
by stan 24 Mar '20

24 Mar '20

I compile a local kernel from the src.rpm, optimized for my hardware. Twice now since I started running 5.6 I've seen a null dereference error. I looked in bugzilla and didn't see this, though there were lots of null dereference bugzillas. The error has only occurred at the end of a dnf update, after the scriptlets are run. So, it could be an error in dnf, I suppose. The strange thing is, it seems to be bfq causing the problem. And it only hangs one core; after a while, another core sends an nmi to the guilty core, and my system then becomes responsive for a brief time. I can switch from the virtual consoles to X, and even move around in X, but eventually the system hangs, and I have to reset it. I expect that the mess isn't being cleaned up, and eventually the guilty core is rescheduled for a task, and bam! Is this a known issue? Is it worth opening a bugzilla?

1 0

CONFIG_TCP_CONG_BBR not set on, in fc32 kernel confg
by Joel Wirāmu Pauling 17 Mar '20

17 Mar '20

Hi there; I noticed that the kernel builds on the branched fedora32 kernels do not have CONFIG_TCP_CONG_BBR set ; meaning no shiny. -- root@kuriiti network-scripts]# sysctl net.ipv4.tcp_available_congestion_control net.ipv4.tcp_available_congestion_control = reno cubic [root@kuriiti network-scripts]# uname -a Linux kuriiti.example.com 5.6.0-0.rc5.git0.2.fc32.x86_64 #1 SMP Tue Mar 10 19:09:42 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux [root@kuriiti network-scripts]# -- Apologies if this has been discussed previously, but this I believe is an omission. -- Joel Wirāmu Pauling Senior Solutions Architect Mobile: (+64) 223608671 Email: jwp(a)redhat.com <jpauling(a)redhat.com>

3 4

nvidia kernel is tainted following updates
by Chris Murphy 17 Mar '20

17 Mar '20

User reports a kernel taint message following updating to kernel 5.5.5. Has anything changed in kernel 5.5 that explains this? This is the message they're seeing: https://ask.fedoraproject.org/t/kernel-tainted-after-running-updates/5487/4… My understanding of these messages is: 1. the proprietary nvidia driver is being loaded and used 2. since the module is not signed, the kernel is tainted But I'm not sure what else I can infer about kernel taint. Are all the other lockdowns still in place? Ideally the user would register a key using mokutil, and sign the module. But if they don't do that, they are still better off than if they disable UEFI Secure Boot to avoid getting the kernel taint message, correct? Thanks, -- Chris Murphy

3 4

Intel SOF firmware
by Jaroslav Kysela 13 Mar '20

13 Mar '20

Hi all, I would like you to introduce the situation with the Intel's Sound Open Firmware. We have finally a stable version of the driver in the Fedora kernel (5.5.7), so it's time to discuss this. The issue is that Intel need to deal with three type of files. The first file is the firmware (binary instruction blob which is executed in DSP, suffix .ri). The second file is the topology and configuration for the ALSA's ASoC core / SOF driver (suffix .tplg). Those both files are loaded via the firmware load calls from the kernel. The names for those files are determined using the hardware probe. The .ri files are platform (Broadwell etc.) dependent. The topology files might differ more (HDMI configuration, codec configuration etc.). The third file is not loaded via the firmware call, it contains the debug strings (SOF firmware is stripped, thus only pointers are returned through the trace interface and there's utility sof-logger which converts those pointers back to the strings using those .ldc files). It's just for the debugging purposes and for the normal operation, it is not used at all. The last piece is the signing. Intel has a secure mechanism which is activated in DSP, so DSP doesn't accept the unsigned firmware, if the hardware vendor wants (and they usually wants this security). So, although, the SOF firmware is being developed as open source, we cannot do own modifications, because we don't have the signing keys. Of course, there is open hardware where the public keys are used (like UP^2 or some Chromebooks). But Lenovo, Dell and others requires firmware signed by Intel. Personally, I'm trying to convince Intel's people to release the stable signed firmware files to linux-firmware, but so far, I have not been successful so far. My opinion is that the tested and verified binary topology files should belong to the linux-firmware, too. Intel do not agree on this (distributions should compile the topology binaries from the sources). Unfortunately, the topology sources are not distributed separately from the SOF firmware, so we need to deal with the whole SOF tree. For Fedora, I'm packaging the SOF firmware, topology and debug (.ldc) bundle (https://www.alsa-project.org/files/pub/misc/sof/) via the alsa-firmware package for now (this package is not installed by default which causes another bug iteration 'install this package' for users). Note that this is not in the upstream alsa-firmware tar ball. It's an extra thing. The last activity from the Intel is the sof-bin repository: https://github.com/thesofproject/sof-bin/tree/stable-v1.4.2 . It's probably a good step forward to have this reference, but it's outside the linux-firmware repository. I don't know if they want to mirror this to linux-firmware. The objective: Fedora/RHEL users should have sound available after the initial installation, thus we need to find the way to add those files to linux-firmware or install alsa-firmware package by default. Maybe, the best way will be to create another alsa-sof-bin package for the Intel's sof-bin releases and install it by default like iwl*-firmware files for their WiFi chips. I would like to hear your comments or proposals. Upstream discussions: https://mailman.alsa-project.org/pipermail/sound-open-firmware/2020-January… https://github.com/thesofproject/sof/issues/2200 https://github.com/thesofproject/sof-bin/pull/2 [Discussion] Thank you, Jaroslav -- Jaroslav Kysela <jkysela(a)redhat.com> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

6 18

Have the 5.6 kernels dropped support for user input of entropy to the kernel?
by stan 11 Mar '20

11 Mar '20

I built my first 5.6 custom kernel from the src.rpm yesterday in F31. And my patch to enable the use of a daemon I run to gather entropy from an rtl2832 (atmospheric) and put it into the kernel to keep the entropy pool full failed. This has happened in the past, that's why I have to patch, but the interface was never removed before. If it has been removed, can you point me to the discussion that led to that decision. I have to determine how secure it will be to modify random.c again in order to continue feeding entropy to the kernel. On another note, an observation. There seem to be pretty frequent major revisions in the kernel PRNG generator. In some ways this is a good thing, because it indicates that people are paying attention to it. But it also means that past versions have been deemed unsuitable, which decreases confidence that the current version is suitable. So, I would be appreciative if you could also point me to the discussion surrounding the latest major change. Thanks.

4 13

[PATCH 0/7] Backported eDP backlight fixes for i915 (README)
by Lyude Paul 10 Mar '20

10 Mar '20

Hi! These are the backported versions of the eDP backlight fixes for i915 that Lenovo asked me to try getting into the Fedora kernel in time for beta. Note that these are pending upstream in intel's drm-intel-next-queued tree, and will make it into the kernel come next merge window. NOTE!!! While the exception for this was really only requested by Lenovo, there's a couple of additional laptop panels that got added upstream from Dell. Since the only extra work required to support them is just adding some IDs into a quirk list I figured it'd be harmless to include here as well. Feel free to drop them if you don't think including them is a good idea. Upstream patch series: * https://patchwork.freedesktop.org/series/69914/ (one patch in ^ this series was reverted later, so it's been omitted) * https://patchwork.freedesktop.org/series/72991/ Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1811850 Lyude Paul (7): drm/i915: Fix eDP DPCD aux max backlight calculations drm/i915: Assume 100% brightness when not in DPCD control mode drm/i915: Fix DPCD register order in intel_dp_aux_enable_backlight() drm/i915: Auto detect DPCD backlight support by default drm/dp: Introduce EDID-based quirks drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K AMOLED panel drm/i915: Force DPCD backlight mode for some Dell CML 2020 panels drivers/gpu/drm/drm_dp_helper.c | 79 ++++++++ drivers/gpu/drm/drm_dp_mst_topology.c | 3 +- .../drm/i915/display/intel_display_types.h | 4 + drivers/gpu/drm/i915/display/intel_dp.c | 11 +- .../drm/i915/display/intel_dp_aux_backlight.c | 183 +++++++++++++----- drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +- drivers/gpu/drm/i915/display/intel_psr.c | 2 +- drivers/gpu/drm/i915/i915_params.c | 2 +- drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/i915_utils.c | 1 - drivers/gpu/drm/i915/i915_utils.h | 2 + include/drm/drm_dp_helper.h | 21 +- 12 files changed, 247 insertions(+), 65 deletions(-) -- 2.24.1

2 8

cgroup support in f31
by Steve Dickson 03 Mar '20

03 Mar '20

Hello, I'm trying to start the docker service on F31 (5.5.7-200.fc31.x86_64) and I'm getting the following error ? docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled; vendor preset: disabled) Active: failed (Result: exit-code) since Tue 2020-03-03 11:36:19 EST; 1min 37s ago Docs: http://docs.docker.com Process: 6855 ExecStart=/usr/bin/dockerd-current --add-runtime oci=/usr/libexec/docker/docker-runc-current --default-runtime=oci --authorization-plugin=rhel-push-plugin --containerd /run/containerd.sock --exec-opt native.cgroupdriver=systemd --userland-proxy-path=/usr/libexec/docker/docker-proxy-current --init-path=/usr/libexec/docker/docker-init-current --seccomp-profile=/etc/docker/seccomp.json $OPTIONS $DOCKER_STORAGE_OPTIONS $DOCKER_NETWORK_OPTIONS $ADD_REGISTRY $BLOCK_REGISTRY $INSECURE_REGISTRY $REGISTRIES (code=exited, status=1/FAILURE) Main PID: 6855 (code=exited, status=1/FAILURE) CPU: 124ms time="2020-03-03T11:36:19.140274478-05:00" level=info msg="Graph migration to content-addressability took 0.00 seconds" time="2020-03-03T11:36:19.141106888-05:00" level=warning msg="Your kernel does not support cgroup memory limit" time="2020-03-03T11:36:19.141141530-05:00" level=warning msg="Unable to find cpu cgroup in mounts" time="2020-03-03T11:36:19.141158734-05:00" level=warning msg="Unable to find blkio cgroup in mounts" time="2020-03-03T11:36:19.141175193-05:00" level=warning msg="Unable to find cpuset cgroup in mounts" time="2020-03-03T11:36:19.141249230-05:00" level=warning msg="mountpoint for pids not found" Error starting daemon: Devices cgroup isn't mounted docker.service: Main process exited, code=exited, status=1/FAILURE docker.service: Failed with result 'exit-code'. Failed to start Docker Application Container Engine. Is there no cgroup support in the current f31 kernel? tia, steved.

2 2

compiling and installing a custom kernel (5.5.7)
by Michael J. Baars 03 Mar '20

03 Mar '20

Hi, Since I've upgraded to Fedora 31, I'm having trouble compiling and installing custom kernels. This never happened with Fedora 30, so some things must have changed that I'm unaware of. 'dnf info kernel-5.5.7' shows that the Fedora team is successful in compiling and installing the new kernels where I'm not. Help would be appreciated. After downloading the most recent kernel from the kernel archives I run this sequence of commands as usual: make menuconfig O=../linux-5.5.7-build make modules_install O=../linux-5.5.7-build make install O=../linux-5.5.7-build The first two commands run without error. The third one, it seems is not looking for the grub bootloader, but for the lilo bootloader, and exits with an error. This is only since I use Fedora 31. What am I doing wrong??? Have I forgotten to install a dependency of some sort? Also, I found this link: https://docs.fedoraproject.org/en-US/quick-docs/kernel/build-custom-kernel/ which seems a little outdated. It is not of any use to me in its current state. Best regards, Mischa Baars.

5 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel March 2020