kernel December 2017

kernel@lists.fedoraproject.org

14 participants
14 discussions

[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

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

Fix for rhbz #1409801
by Shaun Assam 04 Jan '18

04 Jan '18

Hello Kernel Maintainers, I would like to submit a fix for bug #1409801 regarding the ethernet adapter not working on Dell Latitude 3350 (https://bugzilla.redhat.com/ show_bug.cgi?id=1409801). This issue is only related to the Fedora kernels from 4.4+, and does not affect the upstream kernels used by other distributions like Ubuntu or Arch. This issue can be resolved by turning on the ACPI_REV_OVERRIDE option in the kernel config files for i686 and x86_64. Currently the configuration is set to: # CONFIG_ACPI_REV_OVERRIDE_POSSIBLE is not set By changing it to: CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y The following boot errors no longer occur: [ 1.972457] pci 0000:00:1c.2: Error enabling bridge (-16), continuing [ 1.973304] r8169 0000:03:00.0 (unnamed net_device) (uninitialized): enable failure In addition to fixing the ethernet issue, it also fixes an issue with the Bluetooth device on the laptop automatically switching on after shutdown/reboot (not when resuming from sleep/hibernate). The Bluetooth icon would appear in the GNOME System Menu and would have to manually be turned off. Since applying the ACPI_REV fix, this is no longer a problem. I have been testing this change for the last three days and have not encountered any issues resulting from this fix. The issue regarding this bug has been patched in the upstream kernel for sometime and is already included in the code for current versions of the Fedora kernel (see drivers/acpi/blacklist.c for details -- the code applies to Dell laptops/computers). I would like to request this fix be included in future Fedora kernel releases so we may close this bug and possibly fix other, opened, bugs related to this configuration. I have attached the config files to this email for your convenience (around line 75). Regards, Shaun Assam

3 4

Current specfile misapplies v4.14.10 stable update for fc26
by Paul Bolle 02 Jan '18

02 Jan '18

0) The v4.14.10 stable updates adds a new executable (tools/objtool/sync- check.sh). Somehow this was added non-executable during my local build of v4.14.10 (on fc26, that is). This made the build fail: [...] + make -s ARCH=x86_64 V=1 -j4 bzImage make[2]: execvp: ./sync-check.sh: Permission denied make[2]: *** [Makefile:49: [...]/BUILD/kernel-4.14.fc26/linux-4.14.10-1.local0.fc26.x86_64/tools/objtool/objtool] Error 127 make[1]: *** [Makefile:62: objtool] Error 2 make: *** [Makefile:1623: tools/objtool] Error 2 make: *** Waiting for unfinished jobs.... error: Bad exit status from /var/tmp/rpm-tmp.fTUkoT (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.fTUkoT (%build) Anybody else seeing this? 1) Switching the specfile from patch to "git apply" seems to do the right thing. This is what I tried: diff --git a/kernel.spec b/kernel.spec index 965345c2a26e..b2a1ffbe843d 100644 --- a/kernel.spec +++ b/kernel.spec @@ -1267,8 +1267,9 @@ fi # released_kernel with possible stable updates %if 0%{?stable_base} # This is special because the kernel spec is hell and nothing is consistent -xzcat %{SOURCE5000} | patch -p1 -F1 -s -git commit -a -m "Stable update" +xzcat %{SOURCE5000} | git apply - +git add -A +git commit -m "Stable update" %endif # Drop some necessary files from the source dir into the buildroot 2) Would it make sense to further gitify the specfile and move from patch to "git apply" here (and a few other places)? Or should we expect patch to do the right thing? (In the latter case I guess I might have to report a bug against patch.) Thanks, Paul Bolle

5 15

Re: Fix for rhbz #1409801
by Shaun Assam 27 Dec '17

27 Dec '17

Sounds great. Thanks Hans. Regards, Shaun Assam From: Shaun Assam Sent: Wednesday, December 27, 12:10 PM Subject: Re: Fix for rhbz #1409801 To: Hans de Goede Sounds great. Thanks Hans. Regards, Shaun Assam From: Hans de Goede <hdegoede(a)redhat.com> Sent: Wednesday, December 27, 2017 11:49:54 AM To: Shaun Assam; kernel(a)lists.fedoraproject.org Subject: Re: Fix for rhbz #1409801 Hi, On 26-12-17 19:11, Shaun Assam wrote: > Hello Kernel Maintainers, > > I would like to submit a fix for bug #1409801 regarding the ethernet > adapter not working on Dell Latitude 3350 (https://bugzilla.redhat.com/ > show_bug.cgi?id=1409801). This issue is only related to the Fedora > kernels from 4.4+, and does not affect the upstream kernels used by > other distributions like Ubuntu or Arch. > > This issue can be resolved by turning on the ACPI_REV_OVERRIDE option > in the kernel config files for i686 and x86_64. Currently the > configuration is set to: > > # CONFIG_ACPI_REV_OVERRIDE_POSSIBLE is not set > > By changing it to: > > CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y > > The following boot errors no longer occur: > > [ 1.972457] pci 0000:00:1c.2: Error enabling bridge (-16), > continuing > [ 1.973304] r8169 0000:03:00.0 (unnamed net_device) (uninitialized): > enable failure > > In addition to fixing the ethernet issue, it also fixes an issue with > the Bluetooth device on the laptop automatically switching on after > shutdown/reboot (not when resuming from sleep/hibernate). The Bluetooth > icon would appear in the GNOME System Menu and would have to manually > be turned off. Since applying the ACPI_REV fix, this is no longer a > problem. I have been testing this change for the last three days and > have not encountered any issues resulting from this fix. > > The issue regarding this bug has been patched in the upstream kernel > for sometime and is already included in the code for current versions > of the Fedora kernel (see drivers/acpi/blacklist.c for details -- the > code applies to Dell laptops/computers). > > I would like to request this fix be included in future Fedora kernel > releases so we may close this bug and possibly fix other, opened, bugs > related to this configuration. I have attached the config files to this > email for your convenience (around line 75). Thank you for tracking this down. I've just looked at the source-code implementing this and by default enabling this does not change anything except for a couple of (Dell) systems in a DMI quirk list or when someone explicitly asks for this on the kernel cmdline, so turning this on seems safe to me. But the ultimate decision on this is up to the Fedora kernel team (when they get back from their holidays). Regards, Hans

1 0

Changing the default sata link-power-management policy for mobile chipsets
by Hans de Goede 22 Dec '17

22 Dec '17

Hi All, As part of: https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife I've been working on some kernel patches to allow configuring the default sata link-power-management policy for mobile chipsets. Before this the kernel would always default to leaving things as setup by the BIOS. These patches have been accepted upstream and are queued for merging into 4.16: https://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git/log/?h=for-4.… I would like to add these patches to the Fedora 4.15 kernels *and* set the new CONFIG_SATA_MOBILE_LPM_POLICY Kconfig option to "3" which translates to "med_power_with_dipm". The last bit, setting the default for mobile chipsets to "med_power_with_dipm" is the important bit here. On most laptops with a SATA disk / SSD this leads to power-savings of 1.0 - 1.5 Watts (when idle). Modern ultrabooks idle around 6W (at 50% screen brightness), 1.0 - 1.5W is a significant chunk of this. But this change is not entirely uncontroversial, enabling LPM by default is not entirely without risk of regressions. At least min_power is known to cause issues with some disks, including some reports of data corruption. med_power_with_dipm option which mirrors the Intel RST Windows drivers defaults and as such should be pretty safe, but the proof is in the pudding. I've done a blog-post a while ago to ask users to test this: https://hansdegoede.livejournal.com/18412.html Test results from this can be found here: https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife#How_To_Test All testing so far has shown that the med_power_with_dipm option seems to be safe, even with SSDs which are known to corrupt data with the min_power setting! Note that the patches provide a ahci.mobile_lpm_policy kernel cmdline option, so for debugging disk issues users can simply pass ahci.mobile_lpm_policy=0 on the kernel commandline. Summarizing: I would like the Fedora kernel's team permission to enable med_power_with_dipm SATA LPM policy by default for mobile chipsets, this is not entirely without risk but I believe it is safe and the power-savings to be had are simply to good to leave them on the table. I hereby promise that the Fedora kernel team can re-assing any SATA related bugs to me for the F28 cycle and I will take care of them ASAP. Regards, Hans p.s. 1) Note that these power-savings have been laying on the table since 2015: https://mjg59.dreamwidth.org/34868.html I really believe that we should not leave these on the table for another 2+ years. 2) This clearly is a rawhide / F28 only thing and should not be carried over to F27 / F26 once 4.15 gets into the stabilization branch.

2 2

Adding virtualbox guest driver to Fedora kernels (revisited)
by Hans de Goede 19 Dec '17

19 Dec '17

Hi All, Good news, the vboxguest driver has been queued for upstream merging in char-misc-next. This just happened so I want to wait for a couple of days to make sure they stick and they do not get reverted for some reason. Then I would like to add them as downstream patches to the rawhide kernels for now, they can be dropped once we rebase to 4.16. So as always when making non trivial changes, my question to the Fedora kernel team is, is adding these as downstream patches ok? Regards, Hans

4 4

How to enable WARN_ON when building kernels with make
by Bruno Wolff III 16 Dec '17

16 Dec '17

I need to get some WARN_ON output to help a developer figure out a regression in 4.15. When I test the problem with kernels from Fedora built rpms I get the output from WARN_ON, but they don't have a debugging patch from the developer applied. When I build using make (both Linus' tree and Boyer's tree) I don't get that output. I'm guessing there is a config setting that isn't in the normal Fedora config file or I need to force a gcc option or something. But I thought someone here might just know what a need to know. Otherwise I'll try to figure it out from the spec file, but my memory of the kernel spec file is that it is complicated and it might not be easy to figure out what I'm looking for. Thanks.

2 2

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

Enabling CONFIG_REGULATOR on x86_64
by Hans de Goede 15 Dec '17

15 Dec '17

Hi All, I would like to enable CONFIG_REGULATOR on x86_64, to fix USB PD negotiating (and charging with more the 0.5 A in general) and battery monitoring on Intel Cherry Trail devices which use an Intel PMIC + FUSB302 Type-C controller to enable USB-PD charging. Since the USB-PD negotiation in this case is handled by the kernel rather then by firmware in the Alpine Ridge controller, the kernel also needs to enable/disable the 5V boost converter feeding 5v to the Type-C port when it is in host / power-source mode and this is modeled as a regulator. One of the drivers for the complex of 4 ICs which implement the Type-C and battery charging monitoring on these devices has a Kconfig dep on CONFIG_REGULATOR because of this and without this driver these devices are limited to charging (or rather slowly discharging) at 5V 0.5A rather then charging at up to 12V 3A, also without this battery monitoring will not work and the kernel will be unable to make the port provide 5V when a Type-C to USB-A-receptacle cable gets plugged in. Downside of this is a slightly bigger kernel (the regulator framework is tiny) and some messages like these when some drivers load: [ 19.955279] rt5645 i2c-10EC5645:00: i2c-10EC5645:00 supply avdd not found, using dummy regulator [ 19.955331] rt5645 i2c-10EC5645:00: i2c-10EC5645:00 supply cpvdd not found, using dummy regulator As these drivers now actually call into the regulator framework which prints these messages, rather then calling empty stubs. These are printed at "warning" level so will not show up on the console. So if there are no objections I will push a commit enabling CONFIG_REGULATOR on x86_64 one of the coming days. Regards, Hans

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel December 2017