kernel November 2017

kernel@lists.fedoraproject.org

20 participants
16 discussions

RFC: Moving kernel-tools out of kernel.spec
by Laura Abbott 05 Jan '18

05 Jan '18

Like all good bits of software, the kernel.spec has grown over time. Part of this growth has come from building more of the userspace tools that live under the tools directory of the kernel. I've been experimenting with moving these to a separate spec file. Advantages: - Less stuff in the kernel.spec file (~300 line deletion) - Fewer build deps for things like perf - People building the kernel only get the kernel - Issues with userspace tools don't impact the kernel - Can likely drop most of the debuginfo regex nightmare for the userspace packages Disadvantages: - Would need to manually keep in sync on some cadence. This is mostly an issue for rawhide. Could we actually get away with only re-building on each new kernel version or do we need to resync on each -rc? - Would probably need to rework how tools are tied to kernel versions at the package level - Others added here I've experimented with something at https://pagure.io/kernel-tools-pkggit which is mostly a copy/paste of parts of the kernel.spec file. I'm mostly looking for general feedback about if this a good idea but I'm also interested in specific feedback if you have it. Thanks, Laura

5 14

Changing the SND_HDA_POWER_SAVE_DEFAULT option from 0 to 1
by Hans de Goede 15 Dec '17

15 Dec '17

Hi All, I'm working on trying to improve the OOTB power-consumption of Fedora Workstation on laptops. One of the easy wins here is setting snd_hda_intel.power_save=1, which saves about 0.4W which given that modern laptops idle at around 6-8W is a significant saving. I've asked the upstream kernel devs if there are any downsides to setting SND_HDA_POWER_SAVE_DEFAULT=1 and I got a reply that this should be fine and that OpenSUSE Tumbleweed is already doing this. So unless there are any objections I would like to change this option to 1 starting with 4.14 kernel. Is that ok ? Regards, Hans

6 11

Updating config option layout and scripts
by Don Zickus 12 Dec '17

12 Dec '17

Hi Laura, As per our conversation, here is my pull request for the config changes: https://pagure.io/fedora-kernel-dzickus.git rh_sync As part of an effort to foster better cross collaboration with internal Red Hat kernels, align the configs layout to match that kernel. This will allow Red Hat engineers to provide easier guidance on how to set various config options. In addition, the scripts that process the config options will migrate to the configs/ directory too. Future config workflows will stage all work in the configs/ area. A simple diff between the kernels will easily expose which config options are different. Reading the comments in the file provides guidance to Fedora to determine if that kernel should make a similar change or not. While the RH kernel stays internal, requested changes will be posted publicly for review with said reason. Rename debugconfig -> configs/base-debug Rename baseconfig -> configs/base-generic Rename configs/base-generic/arm/arm64 -> configs/base-generic/arm/aarch64 You can browse the changes here: https://pagure.io/fedora-kernel-dzickus/branch/rh_sync Note: Laura asked me not post the patches as the diffstat for the 'git mv' is obnoxiously large. Instead I am providing the changes on pagure. Cheers, Don

4 9

Move /usr/include/cpuidle.h to kernel-tools-libs-devel from kernel-headers
by Laura Abbott 04 Dec '17

04 Dec '17

While experimenting with some refactoring, I noticed that /usr/include/cpuidle.h was being picked up by the glob for kernel-headers. This is kind of unusual because /usr/include/cpufreq.h exists in kernel-tools-libs-devel yet both come out of install from cpupower tools. This header really belongs in kernel-tools-libs-devel for consistency and I'd like to move it. I don't anticipate there being any problems but if anyone can think of an issue for moving this header from kernel-headers to kernel-tools-libs-devel please let me know. I don't plan on doing anything about this until next week at the earliest (Thanksgiving here in the US). Thanks, Laura

1 1

frozen graphics on wake from suspend with 4.15.0-0.rc1.git0.1.fc28.x86_64
by Chris Murphy 30 Nov '17

30 Nov '17

This is a problem I haven't previously seen on this laptop. So far it won't reproduce with drm.debug, but I've seen it twice without. It can't be reported due to kernel taint resulting from i915.enable_guc_loading=1 i915.enable_guc_submission=1 which I can disable if it's helpful. [20016.975715] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun ... [24380.311647] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [24383.411501] ------------[ cut here ]------------ [24383.411504] DC6 already programmed to be enabled. [24383.411694] WARNING: CPU: 2 PID: 5306 at drivers/gpu/drm/i915/intel_runtime_pm.c:609 skl_enable_dc6+0x9e/0xb0 [i915] Complete dmesg: https://drive.google.com/open?id=113a2TnnbVDcx9kM7hj9hCNgxLopGSIIG Complete journal: https://drive.google.com/open?id=1LuzQI2NZEC__KFjebzOtph_7X3q47VcJ 00:02.0 VGA compatible controller [0300]: Intel Corporation Skylake GT2 [HD Graphics 520] [8086:1916] (rev 07) (prog-if 00 [VGA controller]) -- Chris Murphy

1 0

invalid signature error with 4.15rc1
by Chris Murphy 29 Nov '17

29 Nov '17

4.15.0-0.rc1.git0.1.fc28.x86_64 is in koji and it will not boot with Secure Boot enabled. I get an error from GRUB after choosing the boot entry, that it has an invalid signature and the kernel needs to be loaded first. -- Chris Murphy

3 2

Reviving the hardware census
by Jeremy Cline 28 Nov '17

28 Nov '17

Hey folks, For some time now, Fedora has operated without a database of hardware users have. Smolt, the old hardware database, was retired in 2012[0] and its intended successor[1] was never deployed by Fedora Infrastructure. It would be nice to have a hardware database, so I (and hopefully some others) would like to get Census up and running for Fedora. Before we look at deploying Census, however, it would be good to make sure it has everything we need. Census has client plugins to collect information[2]. At the moment, it has plugins for: * The vendor, device, subsystem_vendor, subsystem_device, and class from each PCI device * The idVendor, idProduct, bcdDevice, and bDeviceClass for USB devices as well as the bInterfaceClass, bInterfaceSubClass, and bInterfaceProtocol for each interface * The contents of /etc/os-release * All the RPMs installed on a system Other than the drivers bound to the PCI and USB devices (which is an open PR[3]), what else would be good to collect? [0] https://fedoraproject.org/wiki/Smolt_retirement [1] https://github.com/npmccallum/census [2] https://github.com/npmccallum/census/blob/master/client/plugins/ [3] https://github.com/npmccallum/census/pull/3 -- Jeremy Cline XMPP: jeremy(a)jcline.org IRC: jcline

10 36

debuginfo sub-packages for the kernel
by Laura Abbott 22 Nov '17

22 Nov '17

Hi, I started playing around with having RPM automatically generate the debuginfo subpackages per https://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo Because the kernel is a continual source of exceptions, the existing code doesn't handle the case where the debuginfo and file may have different names. The kernel modules are compressed at the install stage so foo.ko becomes foo.ko.xz. The debuginfo is generated as foo.ko.debug. The existing code to split debugfiles.list can't detect this so those files end up as unpackaged. A similar problem happens with the vmlinux for the main kernel. Is this an issue that can reasonably be fixed or worked around to support the debuginfo subpackages for the kernel? I want to make sure I'm not digging myself into a hole before I spend more time on this. Thanks, Laura

2 3

The 4.15 kernel restores the virtual consoles to white on black in rawhide
by stan 19 Nov '17

19 Nov '17

The 4.14 kernels brought up the virtual consoles in some weird coloration scheme for the whole series. They would reset to the default white on black when X was started. With the 4.15 kernel they have returned to the behavior of all previous kernels, and now start with white on black. Thanks.

1 0

Re: Deprecating old networking protocols
by Josh Boyer 16 Nov '17

16 Nov '17

On Wed, Nov 15, 2017 at 6:09 PM, R P Herrold <herrold(a)owlriver.com> wrote: > On Tue, 14 Nov 2017, Steven Whitehouse wrote: > >> I think it is probably overdue in the DECnet case, however I >> did get a very happy with it for the most part. Anyway it is >> clear that nobody is maintaining it and it seems sensible >> that it should get removed unless someone with sufficient >> time wants to step forward. That has not happened so far, > > I still have customers with Decnet in production (certain > medical lab equipment 'just works' and uses the transport); > until those units die, there will not be sufficient motivation > on the customers' parts to spend the money to replace it (and > at that time, a technology refresh will happen as well > > eyeglass labs, and colonoscopy testing, primarily > > The 'network' for units are physically isolated, and indeed, > occasionally accessed only via a graphical terminal emulator > such as VNC, facing into a TCP/IP network on a second > interface. No need for updates here Are those units or anything that needs to talk to them over DECNet running Fedora? josh

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel November 2017