Upcoming Fedora kernel workflow changes
by Jeremy Cline
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
3 years, 7 months
Getting a null pointer dereference error at end of dnf update with
kernel 5.6 in F31
by stan
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?
3 years, 8 months
CONFIG_TCP_CONG_BBR not set on, in fc32 kernel confg
by Joel Wirāmu Pauling
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 years, 8 months
nvidia kernel is tainted following updates
by Chris Murphy
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...
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 years, 8 months
Intel SOF firmware
by Jaroslav Kysela
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-Janua...
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.
3 years, 9 months
Have the 5.6 kernels dropped support for user input of entropy to
the kernel?
by stan
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.
3 years, 9 months
[PATCH 0/7] Backported eDP backlight fixes for i915 (README)
by Lyude Paul
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
3 years, 9 months
cgroup support in f31
by Steve Dickson
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.
3 years, 9 months
compiling and installing a custom kernel (5.5.7)
by Michael J. Baars
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.
3 years, 9 months
