kernel November 2016

kernel@lists.fedoraproject.org

16 participants
10 discussions

Kernel configurations for Fedora -- a proposal
by Laura Abbott 07 Dec '16

07 Dec '16

Hi, As a follow up to the previous discussion about kernel configuration in Fedora (https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.or…) I have a prototype of what a method of keeping each configuration file in a separate file would look like. This method takes care of several of my gripes of the current version (and found a few errors in the existing config files). The biggest question I have is if this will scale for how frequently Fedora adjusts configuration options. Some of that could possibly be solved with more scripting improvements. The repo is at https://pagure.io/fedora-kernel-labbott/branch/split_configs Thanks, Laura

5 10

[PATCH] config: Enable CONFIG_MODVERSIONS
by Don Zickus 01 Dec '16

01 Dec '16

Hi, I noticed that CONFIG_MODVERSIONS was not enabled in Fedora. I do not know the history and would be curious to know if someone knew. Otherwise, I would like to propose enabling it. Traditionally this option helps 3rd party drivers update to newer kernel versions if the symbol checksums match from the symbol list the driver needs in the kernel. Fedora normally is not interested in 3rd party drivers. I am not going to ask Fedora to start being interested either. :-) My reason for enabling this is really to help with RHEL technology. RHEL does support 3rd party drivers for business reasons. Having better support in Fedora for 3rd party drivers helps us iron out some of our technology in this area. As a bonus, it does help make sure existing Fedora 3rd party drivers don't accidentally get loaded with the wrong kernel version. This gets blocked at load time and can help prevent various panics. Though Fedora traditionally closes such bugs anyway. Signed-off-by: Don Zickus <dzickus(a)redhat.com> diff --git a/config-generic b/config-generic index 7444895..e0e9387 100644 --- a/config-generic +++ b/config-generic @@ -91,7 +91,7 @@ CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_LOAD is not set # -- MODULE_FORCE_UNLOAD is controlled by config-debug/nodebug -# CONFIG_MODVERSIONS is not set +CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_PCI=y

6 13

arm64: F26 vs F25 kernel config for 4.9 (48-bit VA)
by Jon Masters 22 Nov '16

22 Nov '16

Hi Folks, A quick reminder that, while 48-bit VA is enabled in rawhide/26: commit c0f22caded1d549e532d2ab3ce767f8f3d2206f8 Author: Peter Robinson <pbrobinson(a)gmail.com> Date: Mon Oct 31 15:45:58 2016 +0000 arm64: Enable 48bit VA Care should be taken to ensure this doesn't get accidentally pulled in when F25 rebases later on. Userspace isn't ready for it there. Folks know this, but we're on an internal RH call and someone asked that we specifically call this out to make sure everyone knows. Thanks, Jon. -- Computer Architect | Sent from my Fedora powered laptop

2 1

loading early microcode in every core?
by Felix Miata 22 Nov '16

22 Nov '16

I ask about this on account of boot delays reported in the following: http://www.spinics.net/lists/linux-initramfs/msg04173.html http://www.spinics.net/lists/linux-initramfs/msg04175.html http://www.spinics.net/lists/linux-initramfs/msg04275.html I was looking at early portions of dmesg for anything resembling clues and noticed that early microcode messages are not always reported for every core present. Here are examples of 'dmesg | grep croco', all taken from machines with two cpu cores. Notice that some refer to two different cores, while others make no mention of the existence of more than one core: Linux big31 4.7.4-200.fc24.x86_64 #1 SMP Thu Sep 15 18:42:09 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [ 0.000000] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28 [ 0.835393] microcode: CPU0 sig=0x1067a, pf=0x1, revision=0xa0b [ 0.840090] microcode: CPU1 sig=0x1067a, pf=0x1, revision=0xa0b Linux big31 4.8.8-200.fc24.x86_64 #1 SMP Tue Nov 15 19:41:51 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [ 0.000000] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28 [ 0.851345] microcode: sig=0x1067a, pf=0x1, revision=0xa0b Linux big31 4.8.0-0.rc8.git0.1.fc25.x86_64 #1 SMP Mon Sep 26 17:12:24 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [ 0.000000] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28 [ 0.830256] microcode: sig=0x1067a, pf=0x1, revision=0xa0b Linux big31 4.8.8-300.fc25.x86_64 #1 SMP Tue Nov 15 18:10:06 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [ 0.000000] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28 [ 0.601683] microcode: sig=0x1067a, pf=0x1, revision=0xa0b Linux big31 4.8.0-0.rc1.git3.1.fc26.x86_64 #1 SMP Thu Aug 11 01:00:58 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [ 0.000000] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28 [ 1.157172] microcode: sig=0x1067a, pf=0x1, revision=0xa0b Linux big31 4.8.0-0.rc8.git1.1.fc26.x86_64 #1 SMP Wed Sep 28 23:21:40 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [ 0.000000] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28 [ 0.965454] microcode: sig=0x1067a, pf=0x1, revision=0xa0b Linux big31 4.9.0-0.rc5.git4.1.fc26.x86_64 #1 SMP Fri Nov 18 17:52:58 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [ 0.000000] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28 [ 1.146158] microcode: sig=0x1067a, pf=0x1, revision=0xa0b Linux big41 4.6.5-300.fc24.x86_64 #1 SMP Thu Jul 28 01:10:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [ 0.000000] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28 [ 0.716008] microcode: CPU0 sig=0x1067a, pf=0x1, revision=0xa0b [ 0.716801] microcode: CPU1 sig=0x1067a, pf=0x1, revision=0xa0b Linux big41 4.8.7-200.fc24.x86_64 #1 SMP Fri Nov 11 15:44:18 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [ 0.000000] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28 [ 0.617156] microcode: sig=0x1067a, pf=0x1, revision=0xa0b Is it possible that the varying reference or not to CPUx is indicative of some kind of installation mishandling lurking in microcode installation, possibly causing microcode to be installed in only one of the two cores, which could be at root of or affecting the boot initialization delay described in my linux-initramfs posts? If so, should I file a bug? If yes, in which tracker, and against which component (kernel? dracut? microcode_ctl? other?). -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/

3 2

power management VT / versus GUI
by Reindl Harald 21 Nov '16

21 Nov '16

CTRL+ALT+F2 and the message below appears every 5 seconds on the VT and in the syslog while when running the dsiplaymanager or GUI all is fine over days *what* does the kernel here? nobody is taking away the mouse and it's working perfect on the GUI Nov 21 08:59:47 srv-rhsoft kernel: usb 1-1.6: USB disconnect, device number 9 Nov 21 08:59:49 srv-rhsoft kernel: usb 1-1.6: new low-speed USB device number 13 using ehci-pci Nov 21 08:59:49 srv-rhsoft kernel: usb 1-1.6: New USB device found, idVendor=046d, idProduct=c077 Nov 21 08:59:49 srv-rhsoft kernel: usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Nov 21 08:59:49 srv-rhsoft kernel: usb 1-1.6: Product: USB Optical Mouse Nov 21 08:59:49 srv-rhsoft kernel: usb 1-1.6: Manufacturer: Logitech Nov 21 08:59:49 srv-rhsoft kernel: input: Logitech USB Optical Mouse as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/0003:046D:C077.0009/input/input19 Nov 21 08:59:49 srv-rhsoft kernel: hid-generic 0003:046D:C077.0009: input,hidraw0: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-0000:00:1a.0-1.6/input0 Nov 21 08:59:49 srv-rhsoft mtp-probe: checking bus 1, device 13: "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6" Nov 21 08:59:49 srv-rhsoft mtp-probe: bus: 1, device: 13 was not an MTP device

1 0

[PATCH 0/2] Add support for tablet mode on the X1 Yoga (2016)
by Lyude 16 Nov '16

16 Nov '16

Backport of some patches currently waiting to get accepted upstream, adds support for detecting tablet mode properly on the X1 Yoga. Lyude (2): thinkpad_acpi: Move tablet detection into separate function thinkpad_acpi: Add support for X1 Yoga (2016) Tablet Mode Documentation/laptops/thinkpad-acpi.txt | 1 + drivers/platform/x86/thinkpad_acpi.c | 89 ++++++++++++++++++++++++++------- 2 files changed, 72 insertions(+), 18 deletions(-) -- 2.7.4

1 2

[PATCH] set z10 as minimum architecture level for s390x
by Dan Horák 15 Nov '16

15 Nov '16

--- config-s390x | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/config-s390x b/config-s390x index 5368c01..8923379 100644 --- a/config-s390x +++ b/config-s390x @@ -1,7 +1,5 @@ CONFIG_64BIT=y -# CONFIG_MARCH_Z900 is not set -CONFIG_MARCH_Z9_109=y -# CONFIG_MARCH_Z990 is not set +CONFIG_MARCH_Z10=y CONFIG_NR_CPUS=64 CONFIG_COMPAT=y -- 2.7.4

2 2

[PATCH 0/5] Cleanups of kernel.spec
by Paul Bolle 15 Nov '16

15 Nov '16

This small series contains five cleanups to kernel.spec. The basic theme is the way we run "make *config" targets on our .config files. (There was talk, recently, of generating these .config files differently. I do not know what happenend there. But this series only touches kernel.spec once we already have .config files, so that's another stage in our build.) This was only tested for x64_64 on a branch based of f24. It does apply cleanly to master. A run on the build farms (of which I know nothing) might uncover bugs in areas my testing didn't cover. I hope it doesn't. Paul Bolle (5): Run oldnoconfig make targets silently Run make listnewconfig only if listnewconfig_fail is set Only run listnewconfig and oldnoconfig for one arch Replace 'all_x86' with 'x86_32' Remove references to (31 bits) s390 kernel.spec | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) -- 2.7.4

5 22

[PATCH] Enable flex file support in the NFS server
by Steve Dickson 07 Nov '16

07 Nov '16

The upstream commit 9b9960a0c introduced simple flex file server which enables the testing of the flex client. This patch enables the support to be on by default but the 'pnfs' exports option is still needed to active the code. Signed-off-by: Steve Dickson <steved(a)redhat.com> --- config-generic | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/config-generic b/config-generic index 42b48fc..e127a40 100644 --- a/config-generic +++ b/config-generic @@ -4780,8 +4780,7 @@ CONFIG_NFSD_PNFS=y CONFIG_NFSD_BLOCKLAYOUT=y CONFIG_NFSD_SCSILAYOUT=y CONFIG_NFSD_V4_SECURITY_LABEL=y -# This is labeled as 'bare minimum' and 'not for production' -# CONFIG_NFSD_FLEXFILELAYOUT is not set +CONFIG_NFSD_FLEXFILELAYOUT=y CONFIG_NFS_FSCACHE=y # CONFIG_NFS_USE_LEGACY_DNS is not set CONFIG_PNFS_OBJLAYOUT=m -- 2.7.4

3 2

[PATCH] NFSv4.1 Server BUGs out.
by Steve Dickson 07 Nov '16

07 Nov '16

This patch is needed to stop the rawhide NFS server from oopsing on v4.1 mounts. Found during the flex file layout work but the oops happens on all v4.1 mounts. The patch is making its way upstream J. Bruce Fields (1): sunrpc: don't pass on-stack memory to sg_set_buf net/sunrpc/auth_gss/auth_gss.c | 13 ++++-- net/sunrpc/auth_gss/gss_krb5_crypto.c | 82 +++++++++++++++++++-------------- net/sunrpc/auth_gss/svcauth_gss.c | 21 ++++++--- 3 files changed, 71 insertions(+), 45 deletions(-)

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel November 2016