kernel February 2020

kernel@lists.fedoraproject.org

16 participants
13 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

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

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

5.6-rc3: changed COPYING can lead to a file conflict
by Thorsten Leemhuis 24 Feb '20

24 Feb '20

Hi! TWIMC just a quick heads up for the rc3 kernel rebase in rawhide, as I noticed a problem during my kernel vanilla builds that afaics will hit Fedora also and can easily be missed during the update afaics: The COPYING changed Friday night (see below), which will result in a RPM file conflict if not worked around (sorry, German error message, but I guess you'll get the idea): Datei /usr/share/licenses/kernel-core/COPYING-5.6.0 aus der Installation von kernel-core-5.6.0-0.rc3.git0.1.vanilla.knurd.1.fc33.x86_64 kollidiert mit der Datei aus dem Paket kernel-core -5.6.0-0.rc2.git3.1.fc33.x86_64 CU, knurd P.S.: Ohh, BTW: 0001-x86-Don-t-declare-__force_order-in-kaslr_64.c.patch can be dropped, as a fix was merged upstream (that's more obvious, but I thought I just mentioned it anyway just in case it makes somebodys life easier) -------- Weitergeleitete Nachricht -------- Betreff: COPYING: state that all contributions really are covered by this file Datum: Fri, 21 Feb 2020 21:06:46 +0000 Antwort an: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> An: git-commits-head(a)vger.kernel.org Web: https://git.kernel.org/torvalds/c/74835c7db0322b6eddf091b8b062f127b8999a0a Author: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> AuthorDate: Thu Feb 6 16:48:00 2020 +0100 Committer: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> CommitDate: Mon Feb 10 13:32:20 2020 -0800 COPYING: state that all contributions really are covered by this file Explicitly state that all contributions to the kernel source tree really are covered under this COPYING file in case someone thought otherwise. Lawyers love to be pedantic, even more so than software engineers at times, and this sentence makes them sleep easier. Reviewed-by: Thomas Gleixner <tglx(a)linutronix.de> Acked-by: Gustavo A. R. Silva <gustavo(a)embeddedor.com> Link: https://lore.kernel.org/r/20200206154800.GA3754085@kroah.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- COPYING | 2 ++ 1 file changed, 2 insertions(+) diff --git a/COPYING b/COPYING index da4cb28febe6..a635a38ef940 100644 --- a/COPYING +++ b/COPYING @@ -16,3 +16,5 @@ In addition, other licenses may also apply. Please see: Documentation/process/license-rules.rst for more details. + +All contributions to the Linux Kernel are subject to this COPYING file.

2 1

Backporting 5.6 vboxsf to Fedora 5.5 kernels ?
by Hans de Goede 21 Feb '20

21 Feb '20

Hi Fedora kernel-team, The vboxsf file-system driver for accessing folders shared by a vbox host from a (Fedora) guest has finally been merged upstream in 5.6-rc1. I've discussed how to move forward with this with Sergio (in the Cc) who currently maintains a kmod for this in rpmfusion. Sergio's preference is to switch to the in tree version ASAP. As such I would like to backport the 5.6 patch to 5.5 and at it to the stabilization branch, if this is ok with you ? This will be a single patch adding a new fs/vboxsf directory and a single new Kconfig option, the fs-driver is fully self contained and this patch can be dropped when we switch to the 5.6 kernels. Regards, Hans

3 3

Testing AMD Sensors Fusion HUB
by Luya Tshimbalanga 12 Feb '20

12 Feb '20

Hello team, I set up a COPR [1] for testing kernel with enabled AMD Sensors Fusion HUB (AMD_SFH_HID) [2] straight from the patchwork and also did a scratch build (https://koji.fedoraproject.org/koji/taskinfo?taskID=41333949) . After reboot, it seems the amd_sfh_hid driver failed to get detected. Is there a way to make it work? The SRPM is on the COPR repository. References --------------- [1] https://copr.fedorainfracloud.org/coprs/luya/kernel-amdsfh/ [2] https://patchwork.kernel.org/project/linux-iio/list/?submitter=175589

2 7

[PATCH] configs: clean up a few trivial editing mistakes
by Paul Bolle 12 Feb '20

12 Feb '20

Signed-off-by: Paul Bolle <pebolle(a)tiscali.nl> --- .../generic/x86/CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC~ | 1 - .../generic/x86/CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH | 1 - .../generic/x86/CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH~ | 1 - .../generic/x86/CONFIG_SND_SOC_SOF_HDA_ALWAYS_ENABLE_DMI_L1~ | 1 - 4 files changed, 4 deletions(-) delete mode 100644 configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC~ delete mode 100644 configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH~ delete mode 100644 configs/fedora/generic/x86/CONFIG_SND_SOC_SOF_HDA_ALWAYS_ENABLE_DMI_L1~ diff --git a/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC~ b/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC~ deleted file mode 100644 index 4181a1dd2e53..000000000000 --- a/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC~ +++ /dev/null @@ -1 +0,0 @@ -CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC=n diff --git a/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH b/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH index c1358057017d..7cc6669fd1f8 100644 --- a/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH +++ b/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH @@ -1,2 +1 @@ CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH=m - diff --git a/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH~ b/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH~ deleted file mode 100644 index bad67ba0e62d..000000000000 --- a/configs/fedora/generic/x86/CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH~ +++ /dev/null @@ -1 +0,0 @@ -# CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH is not set diff --git a/configs/fedora/generic/x86/CONFIG_SND_SOC_SOF_HDA_ALWAYS_ENABLE_DMI_L1~ b/configs/fedora/generic/x86/CONFIG_SND_SOC_SOF_HDA_ALWAYS_ENABLE_DMI_L1~ deleted file mode 100644 index df1d44aef2f2..000000000000 --- a/configs/fedora/generic/x86/CONFIG_SND_SOC_SOF_HDA_ALWAYS_ENABLE_DMI_L1~ +++ /dev/null @@ -1 +0,0 @@ -CONFIG_SND_SOC_SOF_HDA_ALWAYS_ENABLE_DMI_L1=n -- 2.21.0

2 2

Disabling CONFIG_SFI option ?
by Hans de Goede 10 Feb '20

10 Feb '20

Hi, I tought that we decided to disable CONFIG_SFI a long time ago already? This is only necessary for quite exotic and old 32 bit x86 hardware, so we certainly should not have this enabled on x86_64. Is there any reason why we still have this enabled ? Regards, Hans

2 1

[kernel-tests] branch master updated: skip paxtest for now
by pagure＠pagure.io 10 Feb '20

10 Feb '20

This is an automated email from the git hooks/post-receive script. jforbes pushed a commit to branch master in repository kernel-tests. The following commit(s) were added to refs/heads/master by this push: new 4f3679b skip paxtest for now 4f3679b is described below commit 4f3679b8407259c315569d82f30dac5602c80887 Author: Justin M. Forbes <jforbes(a)fedoraproject.org> AuthorDate: Mon Feb 10 09:05:17 2020 -0600 skip paxtest for now --- default/paxtest/runtest.sh | 3 +++ 1 file changed, 3 insertions(+) diff --git a/default/paxtest/runtest.sh b/default/paxtest/runtest.sh index 8aa3b4e..36d0ff2 100755 --- a/default/paxtest/runtest.sh +++ b/default/paxtest/runtest.sh @@ -2,6 +2,9 @@ # # Licensed under the terms of the GNU GPL License version 2 +# Skip by default for now, things need updating +exit 3 + check_kill() { str="$*" -- To stop receiving notification emails like this one, please contact the administrator of this repository.

1 0

[Test Day] Fedora Kernel 5.5 Test Week is under way. Participate today!
by Sumantro Mukherjee 10 Feb '20

10 Feb '20

Hey All, I would like to invite all of you to participate in the Kernel 5.5 Test week which is happening from 2020-02-10 to 2019-02-17. It's fairly simple, head over to the wiki [0] and read in details about the test week and simply run the test case mentioned in[1] and enter your results. Do let me know if you have any questions [0] https://fedoraproject.org/wiki/Test_Day:2020-02-10_Kernel_5.5_Test_Week [1] http://testdays.fedorainfracloud.org/events/75 As usual, we hang out at #fedora-test-day for questions and generally queries! Thanks -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED <https://redhat.com/trusted>

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel February 2020