kernel January 2018

kernel@lists.fedoraproject.org

19 participants
17 discussions

Kernel 4.15 rebase plans
by Laura Abbott 09 Feb '18

09 Feb '18

Hi, 4.15 was released on Sunday. Fedora will be following the same rebase procedure that we have in the past: After a few stable releases, typically 4.15.2 or 4.15.3, F27 will be rebased to 4.15 with F26 rebased shortly there after. I would expect this to happen by the end of February. Note this was a tricky kernel release because of all the Spectre/ Meltdown work but that should be settled at this point. More testing is always appreciated though. Thanks, Laura

2 4

Options for Coffee Lake machines running F27?
by Jason L Tibbitts III 29 Jan '18

29 Jan '18

I have a number of machines with i7-8700K CPUs and am relying on the onboard graphics, which means that 4.14 is right out. Currently I'm just setting up the rawhide-kernel-nodebug repo and using that, which is great but I'm not sure what I should do once 4.15 is released. Will the repo then start following the 4.16 merge window? Or will it stick with 4.15 releases until F28 branches? My concern is that the repo will immediately move on to tracking the 4.16 merge window which I don't really want to try to use on a user desktop. And since F27 probably isn't going to jump straight to 4.15 releases, I won't have a stable release to follow which also has functioning graphics. I can of course just build my own packages at that point but it does take a bit of effort and I'm wondering if I need to plan for it. I'm certainly not asking for anyone to build kernels for me or alter release plans or anything like that. Thanks! - J<

3 3

[PATCH] Fix misnamed CONFIG files
by Don Zickus 25 Jan '18

25 Jan '18

A couple of CONFIG file names were misnamed during their creation. Fix them up. configs/fedora/generic/CONFIG_DEBUG_VM_RB revisit this if performance isn't horrible -> configs/fedora/generic/CONFIG_DEBUG_VM_RB and configs/fedora/generic/CONFIG_DPM_WATCHDOG revisit this in debug -> configs/fedora/generic/CONFIG_DPM_WATCHDOG --- .../CONFIG_DEBUG_VM_RB revisit this if performance isn't horrible | 1 - configs/fedora/generic/CONFIG_DPM_WATCHDOG | 1 + configs/fedora/generic/CONFIG_DPM_WATCHDOG revisit this in debug | 1 - 3 files changed, 1 insertion(+), 2 deletions(-) delete mode 100644 configs/fedora/generic/CONFIG_DEBUG_VM_RB revisit this if performance isn't horrible create mode 100644 configs/fedora/generic/CONFIG_DPM_WATCHDOG delete mode 100644 configs/fedora/generic/CONFIG_DPM_WATCHDOG revisit this in debug diff --git a/configs/fedora/generic/CONFIG_DEBUG_VM_RB revisit this if performance isn't horrible b/configs/fedora/generic/CONFIG_DEBUG_VM_RB revisit this if performance isn't horrible deleted file mode 100644 index fbc8aaef..00000000 --- a/configs/fedora/generic/CONFIG_DEBUG_VM_RB revisit this if performance isn't horrible +++ /dev/null @@ -1 +0,0 @@ -# CONFIG_DEBUG_VM_RB is not set # revisit this if performance isn't horrible diff --git a/configs/fedora/generic/CONFIG_DPM_WATCHDOG b/configs/fedora/generic/CONFIG_DPM_WATCHDOG new file mode 100644 index 00000000..c12b35c4 --- /dev/null +++ b/configs/fedora/generic/CONFIG_DPM_WATCHDOG @@ -0,0 +1 @@ +# CONFIG_DPM_WATCHDOG is not set # revisit this in debug diff --git a/configs/fedora/generic/CONFIG_DPM_WATCHDOG revisit this in debug b/configs/fedora/generic/CONFIG_DPM_WATCHDOG revisit this in debug deleted file mode 100644 index c12b35c4..00000000 --- a/configs/fedora/generic/CONFIG_DPM_WATCHDOG revisit this in debug +++ /dev/null @@ -1 +0,0 @@ -# CONFIG_DPM_WATCHDOG is not set # revisit this in debug -- 2.14.3

2 1

CONFIG name typos?
by Don Zickus 24 Jan '18

24 Jan '18

Hi Laura, Justin, I stumbled upon these CONFIG names today. I assume they are wrong? (full file name in quotes) configs/fedora/generic/'CONFIG_DEBUG_VM_RB revisit this if performance isn't horrible' configs/fedora/generic/'CONFIG_DPM_WATCHDOG revisit this in debug' Cheers, Don

2 2

DOA kernel-4.15.0-0.rc8.git2.1.fc28.x86_64
by Chris Murphy 23 Jan '18

23 Jan '18

Two x86_64 UEFI computers (different CPUs and firmware OEMs) won't boot this kernel. On one computer, it reboots shortly after I see EFI stub: UEFI secure boot enabled. On another computer, I just get a hang with an underscore and it never recovers. kernel-4.15.0-0.rc8.git1.1.fc28.x86_64 works fine on both. -- Chris Murphy

4 5

kernel-4.14.14-200.fc26 and GCC / retpoline
by Reindl Harald 19 Jan '18

19 Jan '18

does the running build https://koji.fedoraproject.org/koji/buildinfo?buildID=1019102 already use GCC 7.2.1-7 build (https://koji.fedoraproject.org/koji/buildinfo?buildID=1017750) which is needed to get the full retpoline support in the kernel build? * Wed Jan 17 2018 Jakub Jelinek <jakub(a)redhat.com> 7.2.1-7 - x86 retpoline support

3 2

Re: Can't capture vmcore?
by Josh Boyer 16 Jan '18

16 Jan '18

On Tue, Jan 9, 2018 at 1:51 PM, Maxim Burgerhout <maxim(a)wzzrd.com> wrote: > I'm getting kernel panics in a VM that functions as a hypervisor, the moment > I spin up the nested guest (on AMD ThreadRipper / Fedora 27). That is > annoying, of course, so I try to be a good citizen and file a bug. > > For some reason though, I cannot get the core dumped. I get a core fine with > sysrq, but not with this actual panic. I've followed [1] to set up kdump and > crash, but everytime I trigger the crash and see my VM reboot, I see an > empty /var/crash afterwards. > > As was able to get the vmcore written to /var/crash on in a RHEL7 guest, I'm > starting to suspect a bug, but I'm unsure. > > Any pointers on how to debug this? > > [1] https://fedoraproject.org/wiki/How_to_use_kdump_to_debug_kernel_crashes Adding the Fedora kernel list. Kdump isn't automatically tested in Fedora and while it can work, it can often be broken as well. There might be someone on the kernel list that is more familiar with the current state of kdump support in Fedora, or alternative methods for getting the kernel backtrace. josh

3 3

/proc/sys/net/core/optmem_max on armv7l
by Björn 'besser82' Esser 15 Jan '18

15 Jan '18

Hello together, I just noticed, there is a difference in the default value of `/proc/sys/net/core/optmem_max` on armv7l: On all arches it is 20480, but on armv7l it is 10240. Is there any specific reason for limiting the maximum ancillary buffer size allowed per socket on this arch? Cheers, Björn

4 4

[PATCH 0/2] configs: Rename base-{generic,debug} to configs/fedora/
by Don Zickus 15 Jan '18

15 Jan '18

This patchset renames the configs/base-{generic,debug} to configs/fedora/{generic,debug} and updates the scripts to reflect that. Because the configs rename patch is huge and Laura prefers not to have it on the list, I am purposely excluding the content of that particular patch. The script changes are attached for public review. The code can be reviewed here: https://pagure.io/fedora-kernel-dzickus.git rh_sync2 Don Zickus (2): configs: Move base-debug and base-generic to configs/fedora configs: Update config generation script to use configs/fedora configs/build_configs.sh | 62 +++++++++++----------- configs/config_generation | 5 ++ <snipped giant configs rename>

4 9

Re: "MODSIGN: Couldn't get UEFI db list" errors are still happening
by Peter Jones 11 Jan '18

11 Jan '18

Ccing dhowells and kernel(a)lists.fp.o so they all know what's going on. On Wed, Dec 27, 2017 at 05:07:45PM +0100, Hans de Goede wrote: > Hi Peter, > > Various users (including me) are still seeing: > https://bugzilla.redhat.com/show_bug.cgi?id=1497559 > happening. > > Do the patches you've attached there need more work, > or can I add those to the kernel pkg so that they get > picked up the next build? I think the status here is that I sent them to dhowells for review and he got real busy with something else and never got around to reviewing them. As far as I'm concerned they're still correct. David, the patches I've pushed are still intended for your MODSIGN patch series as well. I've made sure they still work as far as "fedpkg prep" on f26, f27, and rawhide, and pushed them to dist-git for those branches. So they'll be in the next build. > Also where can I find the latest version of these > patches? Nothing has changed any. > Note: I can take care of this, I just need your input > on if it is ok to take the patches and put them in the > Fedora kernels. I already had it staged, modulo a git rebase for newer commits, so I just went ahead and pushed it. Thanks though. -- Peter

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel January 2018