[PATCH 0/2] configs: Rename base-{generic,debug} to configs/fedora/
by Don Zickus
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>
5 years, 4 months
RFC: Moving kernel-tools out of kernel.spec
by Laura Abbott
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 years, 4 months
Fix for rhbz #1409801
by Shaun Assam
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
5 years, 4 months
Current specfile misapplies v4.14.10 stable update for fc26
by Paul Bolle
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 years, 4 months
Re: Fix for rhbz #1409801
by Shaun Assam
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
5 years, 5 months
Changing the default sata link-power-management policy for mobile
chipsets
by Hans de Goede
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-...
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.
5 years, 5 months
Adding virtualbox guest driver to Fedora kernels (revisited)
by Hans de Goede
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
5 years, 5 months
How to enable WARN_ON when building kernels with make
by Bruno Wolff III
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.
5 years, 5 months
Changing the SND_HDA_POWER_SAVE_DEFAULT option from 0 to 1
by Hans de Goede
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
5 years, 5 months
Enabling CONFIG_REGULATOR on x86_64
by Hans de Goede
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
5 years, 5 months