October 2018 - kernel - Fedora Mailing-Lists

[PATCH] Enable CONFIG_PROC_VMCORE_DEVICE_DUMP

by Kairui Song

In order to collect necessary logs for drivers in event of a kernel crash, we have to enable CONFIG_PROC_VMCORE_DEVICE_DUMP so that device hardware/firmware logs could be collected to vmcore dump. Currently only Chelsio drivers use this kernel API, but more driver could use this new feature in the future. Signed-off-by: Kairui Song <kasong(a)redhat.com> --- configs/fedora/generic/CONFIG_PROC_VMCORE_DEVICE_DUMP | 2 +- kernel-aarch64-debug.config | 2 +- kernel-aarch64.config | 2 +- kernel-armv7hl-debug.config | 2 +- kernel-armv7hl-lpae-debug.config | 2 +- kernel-armv7hl-lpae.config | 2 +- kernel-armv7hl.config | 2 +- kernel-i686-debug.config | 2 +- kernel-i686.config | 2 +- kernel-ppc64le-debug.config | 2 +- kernel-ppc64le.config | 2 +- kernel-s390x-debug.config | 2 +- kernel-s390x.config | 2 +- kernel-x86_64-debug.config | 2 +- kernel-x86_64.config | 2 +- 15 files changed, 15 insertions(+), 15 deletions(-) diff --git a/configs/fedora/generic/CONFIG_PROC_VMCORE_DEVICE_DUMP b/configs/fedora/generic/CONFIG_PROC_VMCORE_DEVICE_DUMP index fdcc41f6..1a63c6ae 100644 --- a/configs/fedora/generic/CONFIG_PROC_VMCORE_DEVICE_DUMP +++ b/configs/fedora/generic/CONFIG_PROC_VMCORE_DEVICE_DUMP @@ -1 +1 @@ -# CONFIG_PROC_VMCORE_DEVICE_DUMP is not set +CONFIG_PROC_VMCORE_DEVICE_DUMP=y diff --git a/kernel-aarch64-debug.config b/kernel-aarch64-debug.config index 23f34cdb..b84063a6 100644 --- a/kernel-aarch64-debug.config +++ b/kernel-aarch64-debug.config @@ -4619,7 +4619,7 @@ CONFIG_PROC_EVENTS=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_PID_CPUSET=y -# CONFIG_PROC_VMCORE_DEVICE_DUMP is not set +CONFIG_PROC_VMCORE_DEVICE_DUMP=y CONFIG_PROC_VMCORE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set CONFIG_PROFILING=y diff --git a/kernel-aarch64.config b/kernel-aarch64.config index 902f3c89..269c07b8 100644 --- a/kernel-aarch64.config +++ b/kernel-aarch64.config @@ -4597,7 +4597,7 @@ CONFIG_PROC_EVENTS=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_PID_CPUSET=y -# CONFIG_PROC_VMCORE_DEVICE_DUMP is not set +CONFIG_PROC_VMCORE_DEVICE_DUMP=y CONFIG_PROC_VMCORE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set CONFIG_PROFILING=y diff --git a/kernel-armv7hl-debug.config b/kernel-armv7hl-debug.config index d140e0a8..b036dda3 100644 --- a/kernel-armv7hl-debug.config +++ b/kernel-armv7hl-debug.config @@ -4882,7 +4882,7 @@ CONFIG_PROC_EVENTS=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_PID_CPUSET=y -# CONFIG_PROC_VMCORE_DEVICE_DUMP is not set +CONFIG_PROC_VMCORE_DEVICE_DUMP=y CONFIG_PROC_VMCORE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set CONFIG_PROFILING=y diff --git a/kernel-armv7hl-lpae-debug.config b/kernel-armv7hl-lpae-debug.config index 5a6a1a2f..0c945780 100644 --- a/kernel-armv7hl-lpae-debug.config +++ b/kernel-armv7hl-lpae-debug.config @@ -4639,7 +4639,7 @@ CONFIG_PROC_EVENTS=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_PID_CPUSET=y -# CONFIG_PROC_VMCORE_DEVICE_DUMP is not set +CONFIG_PROC_VMCORE_DEVICE_DUMP=y CONFIG_PROC_VMCORE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set CONFIG_PROFILING=y diff --git a/kernel-armv7hl-lpae.config b/kernel-armv7hl-lpae.config index fdeec238..ba4ac813 100644 --- a/kernel-armv7hl-lpae.config +++ b/kernel-armv7hl-lpae.config @@ -4617,7 +4617,7 @@ CONFIG_PROC_EVENTS=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_PID_CPUSET=y -# CONFIG_PROC_VMCORE_DEVICE_DUMP is not set +CONFIG_PROC_VMCORE_DEVICE_DUMP=y CONFIG_PROC_VMCORE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set CONFIG_PROFILING=y diff --git a/kernel-armv7hl.config b/kernel-armv7hl.config index 61b0a9d2..f38ae3f1 100644 --- a/kernel-armv7hl.config +++ b/kernel-armv7hl.config @@ -4860,7 +4860,7 @@ CONFIG_PROC_EVENTS=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_PID_CPUSET=y -# CONFIG_PROC_VMCORE_DEVICE_DUMP is not set +CONFIG_PROC_VMCORE_DEVICE_DUMP=y CONFIG_PROC_VMCORE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set CONFIG_PROFILING=y diff --git a/kernel-i686-debug.config b/kernel-i686-debug.config index edf23139..43f57626 100644 --- a/kernel-i686-debug.config +++ b/kernel-i686-debug.config @@ -4408,7 +4408,7 @@ CONFIG_PROC_EVENTS=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_PID_CPUSET=y -# CONFIG_PROC_VMCORE_DEVICE_DUMP is not set +CONFIG_PROC_VMCORE_DEVICE_DUMP=y CONFIG_PROC_VMCORE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set CONFIG_PROFILING=y diff --git a/kernel-i686.config b/kernel-i686.config index 3764b1fe..8af915c8 100644 --- a/kernel-i686.config +++ b/kernel-i686.config @@ -4385,7 +4385,7 @@ CONFIG_PROC_EVENTS=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_PID_CPUSET=y -# CONFIG_PROC_VMCORE_DEVICE_DUMP is not set +CONFIG_PROC_VMCORE_DEVICE_DUMP=y CONFIG_PROC_VMCORE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set CONFIG_PROFILING=y diff --git a/kernel-ppc64le-debug.config b/kernel-ppc64le-debug.config index 17a7aec5..5a2ea877 100644 --- a/kernel-ppc64le-debug.config +++ b/kernel-ppc64le-debug.config @@ -4152,7 +4152,7 @@ CONFIG_PROC_EVENTS=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_PID_CPUSET=y -# CONFIG_PROC_VMCORE_DEVICE_DUMP is not set +CONFIG_PROC_VMCORE_DEVICE_DUMP=y CONFIG_PROC_VMCORE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set CONFIG_PROFILING=y diff --git a/kernel-ppc64le.config b/kernel-ppc64le.config index 10f195f7..35dded69 100644 --- a/kernel-ppc64le.config +++ b/kernel-ppc64le.config @@ -4127,7 +4127,7 @@ CONFIG_PROC_EVENTS=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_PID_CPUSET=y -# CONFIG_PROC_VMCORE_DEVICE_DUMP is not set +CONFIG_PROC_VMCORE_DEVICE_DUMP=y CONFIG_PROC_VMCORE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set CONFIG_PROFILING=y diff --git a/kernel-s390x-debug.config b/kernel-s390x-debug.config index 6d715134..2148b26c 100644 --- a/kernel-s390x-debug.config +++ b/kernel-s390x-debug.config @@ -4040,7 +4040,7 @@ CONFIG_PROC_EVENTS=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_PID_CPUSET=y -# CONFIG_PROC_VMCORE_DEVICE_DUMP is not set +CONFIG_PROC_VMCORE_DEVICE_DUMP=y CONFIG_PROC_VMCORE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set CONFIG_PROFILING=y diff --git a/kernel-s390x.config b/kernel-s390x.config index 621c2c99..523e4a22 100644 --- a/kernel-s390x.config +++ b/kernel-s390x.config @@ -4015,7 +4015,7 @@ CONFIG_PROC_EVENTS=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_PID_CPUSET=y -# CONFIG_PROC_VMCORE_DEVICE_DUMP is not set +CONFIG_PROC_VMCORE_DEVICE_DUMP=y CONFIG_PROC_VMCORE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set CONFIG_PROFILING=y diff --git a/kernel-x86_64-debug.config b/kernel-x86_64-debug.config index 2dfd8914..6d96b637 100644 --- a/kernel-x86_64-debug.config +++ b/kernel-x86_64-debug.config @@ -4448,7 +4448,7 @@ CONFIG_PROC_EVENTS=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_PID_CPUSET=y -# CONFIG_PROC_VMCORE_DEVICE_DUMP is not set +CONFIG_PROC_VMCORE_DEVICE_DUMP=y CONFIG_PROC_VMCORE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set CONFIG_PROFILING=y diff --git a/kernel-x86_64.config b/kernel-x86_64.config index 195d0314..f2f5d4b9 100644 --- a/kernel-x86_64.config +++ b/kernel-x86_64.config @@ -4425,7 +4425,7 @@ CONFIG_PROC_EVENTS=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_PID_CPUSET=y -# CONFIG_PROC_VMCORE_DEVICE_DUMP is not set +CONFIG_PROC_VMCORE_DEVICE_DUMP=y CONFIG_PROC_VMCORE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set CONFIG_PROFILING=y -- 2.17.1

5 years, 1 month

2
2
0 / 0

4.19 rebase plans

by Jeremy Cline

Hi folks, 4.19 was released at the beginning of this week so stable Fedora releases will be rebased in the coming weeks once a couple stable updates have been released. Fedora 29 will be rebased first, followed by Fedora 28. It's likely this will happen early in November. Given that Fedora 27 will reach end of life at the end of November, it's unlikely that it will be rebased to 4.19. As always, we'll keep you updated on any new developments. Regards, Jeremy

5 years, 1 month

1
0
0 / 0

[PATCH] Fix cross kernel headers location - rhbz#1642037

by Nicolas Chauvet

Cross compiled kernel headers are installed into /usr/*-linux-gnu/include/ instead of /usr/*-linux-gnu/sys-root/usr/include/ where they can be found by default by the Fedora cross compiler toolchain. Because the kernel-cross-headers package can be installed without the cross glibc-* binutils-* gcc-* counterparts, it has to own the sysroot directory. Signed-off-by: Nicolas Chauvet <kwizart(a)gmail.com> --- kernel.spec | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/kernel.spec b/kernel.spec index f6d1e2b2a..1ff196b81 100644 --- a/kernel.spec +++ b/kernel.spec @@ -1681,9 +1681,9 @@ find $RPM_BUILD_ROOT/usr/tmp-headers/include \ # Copy all the architectures we care about to their respective asm directories for arch in arm arm64 powerpc s390 x86 ; do -mkdir -p $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/include -mv $RPM_BUILD_ROOT/usr/tmp-headers/include/arch-${arch}/asm $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/include/ -cp -a $RPM_BUILD_ROOT/usr/tmp-headers/include/asm-generic $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/include/. +mkdir -p $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/sys-root%{_includedir} +mv $RPM_BUILD_ROOT/usr/tmp-headers/include/arch-${arch}/asm $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/sys-root%{_includedir} +cp -a $RPM_BUILD_ROOT/usr/tmp-headers/include/asm-generic $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/sys-root%{_includedir}. done # Remove the rest of the architectures @@ -1692,7 +1692,7 @@ rm -rf $RPM_BUILD_ROOT/usr/tmp-headers/include/asm-* # Copy the rest of the headers over for arch in arm arm64 powerpc s390 x86 ; do -cp -a $RPM_BUILD_ROOT/usr/tmp-headers/include/* $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/include/. +cp -a $RPM_BUILD_ROOT/usr/tmp-headers/include/* $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/sys-root%{_includedir}/. done rm -rf $RPM_BUILD_ROOT/usr/tmp-headers @@ -1817,7 +1817,7 @@ fi %if %{with_cross_headers} %files cross-headers -/usr/*-linux-gnu/include/* +/usr/*-linux-gnu/sysroot %endif # empty meta-package -- 2.17.2

5 years, 1 month

2
4
0 / 0

[PATCH] Sign the aarch64 kernel

by Jeremy Linton

The aarch64 kernel is a gzip'ed EFI image, this means that pesign needs to sign the original image and then zip it for grub to be able to validate the kernel image. Signed-off-by: Jeremy Linton <jeremy.linton(a)arm.com> --- kernel.spec | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/kernel.spec b/kernel.spec index 25e4676a..e6601758 100644 --- a/kernel.spec +++ b/kernel.spec @@ -10,7 +10,7 @@ Summary: The Linux kernel # Sign modules on x86. Make sure the config files match this setting if more # architectures are added. -%ifarch %{ix86} x86_64 +%ifarch %{ix86} x86_64 aarch64 %global signkernel 1 %global signmodules 1 %global zipmodules 1 @@ -1288,13 +1288,26 @@ BuildKernel() { cp arch/$Arch/boot/zImage.stub $RPM_BUILD_ROOT/lib/modules/$KernelVer/zImage.stub-$KernelVer || : fi %if %{signkernel} + # aarch64 kernels are gziped EFI images + KernelExtension=${KernelImage##*.} + if [ "$KernelExtension" == "gz" ]; then + SignImage=${KernelImage%.*} + else + SignImage=$KernelImage + fi + # Sign the image if we're using EFI - %pesign -s -i $KernelImage -o vmlinuz.signed + %pesign -s -i $SignImage -o vmlinuz.signed if [ ! -s vmlinuz.signed ]; then echo "pesigning failed" exit 1 fi - mv vmlinuz.signed $KernelImage + mv vmlinuz.signed $SignImage + + if [ "$KernelExtension" == "gz" ]; then + gzip -f9 $SignImage + fi + %endif $CopyKernel $KernelImage \ $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer -- 2.19.1

5 years, 1 month

2
1
0 / 0

[PATCH 0/2] Important i915 eDP fixes for F28/29

by Lyude Paul

Some nasty regressions regarding DP fallback retraining made it into the kernel that have been breaking some people's laptops by making it so the eDP display doesn't come up. These are the commits to fix such issues, and they're already on their way to linux-stable. See: https://bugs.freedesktop.org/show_bug.cgi?id=108083 Dhinakaran Pandiyan (2): drm/i915/dp: Fix link retraining comment in intel_dp_long_pulse() drm/i915/dp: Restrict link retrain workaround to external monitors drivers/gpu/drm/i915/intel_dp.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) -- 2.17.2

5 years, 1 month

1
2
0 / 0

[PATCH] mmc: dw_mmc-k3: Add clk and reset softdep

by Jeremy Linton

From: Jeremy Linton <lintonrjeremy(a)gmail.com> The mmc/k3 driver is dependent on a number of other linux modules which must be built into the initrd in order to use the mmc/sd as a boot device for initrd/module based distros. Normally this would be taken care of with linux's modules.deps based on symbolic dependencies but the dwmmc drivers have particularly complex relationships that are based on soft callback APIs. The result is that dracut and other initrd builders are unable to determine the module dependencies directly. To solve this problem linux has MODULE_SOFTDEP() so lets softdep the hisi clock and reset drivers associated with the k3 implementation. Signed-off-by: Jeremy Linton <lintonrjeremy(a)gmail.com> --- drivers/mmc/host/dw_mmc-k3.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mmc/host/dw_mmc-k3.c b/drivers/mmc/host/dw_mmc-k3.c index 89cdb3d533bb..cd8f545fa30d 100644 --- a/drivers/mmc/host/dw_mmc-k3.c +++ b/drivers/mmc/host/dw_mmc-k3.c @@ -487,3 +487,4 @@ module_platform_driver(dw_mci_k3_pltfm_driver); MODULE_DESCRIPTION("K3 Specific DW-MSHC Driver Extension"); MODULE_LICENSE("GPL v2"); MODULE_ALIAS("platform:dwmmc_k3"); +MODULE_SOFTDEP("pre: hi6220_reset clk_hi655x"); -- 2.13.6

5 years, 1 month

1
0
0 / 0

Make kernel.spec friendlier to el7

by Pablo Sebastián Greco

We rebuild the Fedora kernel for CentOS with only a few changes (mainly for armhfp). Some of those changes may be part of Fedora, since they don't affect the build process. disable_headers_fedora_only.patch: Fedora builds kernel-headers separately, do this only for fedora. make_buildflags_optional.patch: build_cflags and build_ldflags are not available in el7, make them optional. Thanks. Pablo

5 years, 1 month

5
8
0 / 0

F28 kernels should not have CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER set

by Hans de Goede

Hi, I just noticed: https://bugzilla.redhat.com/show_bug.cgi?id=1637547 getting filed. I'm suspicious that this may be caused by the new deferred fbcon takeover stuff. So I double checked the settings in the fedpkg f28 branch and I noticed that CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER is still set there, which was not the intention (FWIW I did add a note about this to rebase-notes.txt). Rather then dropping it myself I'm sending this mail so that you (Fedora kernel team) are aware of this in case similar bugs come in. I'll leave it up to you to disable this I do think it is best to disable this for F28. Regards, Hans

5 years, 1 month

3
4
0 / 0

Disabling kernel's hibernate support by default, allow re-enabling it with a kernel cmdline option

by Hans de Goede

Hello Fedora kernel team, On the Fedora desktop list there has been a discussion about systemd now offering a new suspend-then-hibernate option and gnome-settings-daemon's media-keys plugin using this when the power-button gets pressed and systemd saying this is available on the system. What this does is suspend the system normally and set a RTC wakeup 3 hours in the future, then when the RTC wake happens it hibernates the system. As discussed on the desktop list this is not really desirable as default behavior for F29 (and later) since the hibernate code is not really something which gets used enough to be well tested and is really not something which we can support. So after that the discussion has gone in the direction of how to disable the new suspend-then-hibernate behavior. Lennart made a really interesting observation here, systemd is just proxying if "cat /sys/power/disk" indicates that hibernate is supported. So if we really don't want to support hibernation as a normal option, while still allowing adventurous user to use it, what really should happen is for the kernel to stop advertising hibernate support. Thinking about this I agree, if we say that we cannot support it, the kernel really should not be advertising support for it by default. So Bastien suggested to change the nohibernate setting in kernel/power/hibernate.c which can be set from the kernel commandline to default to 1, and allow setting it back to 0 by adding "hibernate=yes" to the kernel commandline. I kinda like this idea and I'm willing to spend some time to write a patch for this and submit it upstream, which allows selecting nohibernate=1 as the default through Kconfig. But before I spend (some) time on this, I wonder what the kernel team's opinion on this is ? My own 2 cents on this are: Pro: Not advertising hibernate by default means users will not accidentally try to use it (through e.g gnome-tweaks) and if they do use it by specifying the kernel commandline option we can easily explain that using that commandline option is not supported by Fedora and kindly request them to file bugs upstream. TL;DR: less kernel issues for Fedora to deal with, good. Against: Currently we do have some users using hibernation without adding any options to the kernel commandline. These users will have to now add "hibernate=yes" to their kernel commandline. I'm thinking that yes we want this, but maybe this needs to go through the change process for proper communication, so for F29 we need another fix, and we can do this for F30? Regards, Hans

5 years, 2 months

10
27
0 / 1

Re: Disabling kernel's hibernate support by default, allow re-enabling it with a kernel cmdline option

by Zbigniew Jędrzejewski-Szmek

On Tue, Oct 02, 2018 at 07:05:45PM +0200, Benjamin Berg wrote: > Hi > > On Tue, 2018-10-02 at 14:34 +0200, Hans de Goede wrote: > > On 02-10-18 14:26, Justin Forbes wrote: > > > On Tue, Oct 2, 2018 at 5:53 AM, Hans de Goede <hdegoede(a)redhat.com> wrote: > > > > Hi Justin, > > > > > > > > On 01-10-18 16:14, Justin Forbes wrote: > > > > > On Sun, Sep 30, 2018 at 1:52 PM, Hans de Goede <hdegoede(a)redhat.com> > > > > > wrote: > > > > > > Hello Fedora kernel team, > > > > > > > > > > > > On the Fedora desktop list there has been a discussion about > > > > > > systemd now offering a new suspend-then-hibernate option and > > > > > > gnome-settings-daemon's media-keys plugin using this when > > > > > > the power-button gets pressed and systemd saying this is > > > > > > available on the system. > > > > > > > > > > > > What this does is suspend the system normally and set > > > > > > a RTC wakeup 3 hours in the future, then when the RTC wake > > > > > > happens it hibernates the system. > > > > > > > > > > > > As discussed on the desktop list this is not really desirable > > > > > > as default behavior for F29 (and later) since the hibernate > > > > > > code is not really something which gets used enough to be > > > > > > well tested and is really not something which we can support. > > > > > > > > > > > > So after that the discussion has gone in the direction of > > > > > > how to disable the new suspend-then-hibernate behavior. > > > > > > > > > > > > Lennart made a really interesting observation here, systemd > > > > > > is just proxying if "cat /sys/power/disk" indicates that > > > > > > hibernate is supported. > > > > > > > > > > > > > > > > No, that is not what systemd is doing. The kernel provides a > > > > > mechanism, it does absolutely nothing with that mechanism unless told > > > > > to do so. What systemd is actually doing is creating a policy around > > > > > that mechanism. > > > > > > > > systemd is really *not* creating policy here, it has a DBUS API > > > > call called CanHibernate which really just proxies what the kernel > > > > advertises. > > > > > > > > What is new is that GNOME (g-s-d) now uses it be default through > > > > by choosing suspend-then-hibernate as suspend action when > > > > hibernation is available. > > > > > > > > > > Right, so systemd really is just proxying, and Gnome is now creating a > > > policy. It does not change the underlying issue, we shouldn't cripple > > > a mechanism because someone wants to introduce a new undesirable > > > policy on top of it. Especially when the thing introducing that > > > policy is not the only user of the mechanism. > > > > > > > > > So if we really don't want to support hibernation as a normal > > > > > > option, while still allowing adventurous user to use it, what > > > > > > really should happen is for the kernel to stop advertising > > > > > > hibernate support. Thinking about this I agree, if we say > > > > > > that we cannot support it, the kernel really should not be > > > > > > advertising support for it by default. > > > > > > > > > > > > > > > > "We have decided that the policy created is not desirable, so we want > > > > > to disable the mechanism" > > > > > > > > Default to off is a different thing then disabling this. > > > > > > > > > > There is a difference between a "policy default to off", and "turning > > > off the mechanism". I would expect a new policy defaulting to off > > > would actually default to whatever is currently there. When a user > > > upgrades from F28 to F30, it seems wrong that their power > > > configuration would change in a way that is unexpected, and frankly > > > more difficult to manage. A regular user can run gnome-tweaks and > > > decide on lid behavior. A regular user cannot edit the kernel command > > > line once a system is booted. Now, it requires root. And we are > > > making it harder for people to edit it as a system boots with other > > > planned changes. > > > > > > > TBH I'm a bit surprised about your objections against this: > > > > > > > > 1) We all seem to agree that this is something which may or > > > > may not work, but is not something which we want to advertise > > > > as a "supported" Fedora feature > > > > > > > > 2) Given 1) we also all agree that we should not use it > > > > by default > > > > > > > > 3) If we should not use it by default then shouldn't the > > > > feature default to off ? That is all what is being suggested, > > > > basically the equivalent of adding "nohibernate" to the > > > > kernel commandline by default. > > > > > > > > > > And this is the problem, there is no reason anyone should have to edit > > > the kernel command line for choosing a power policy setting. Gnome is > > > certainly not the only desktop in use, practically all of the > > > documentation out there explains how to enable or disable hibernate > > > with common tools. We are invalidating all of that documentation just > > > so that gnome can implement a bad default policy. Agreeing that we > > > should not use it by default doesn't mean we should make it any harder > > > to use than it already is. We certainly have no motivation to > > > discourage people for giving it a try, they just have to know that > > > they are hibernating, and have chosen to do so. I would be just fine > > > with it being easier to access in gnome than installing gnome-tweaks, > > > hibernate, if supported by the system, could be easily selected under > > > the power menu in settings. > > > > > > > I expect the kernel changes for this to be about 3 lines of > > > > actual code (+a 15 lines or so Kconfig addition) and I expect > > > > this to go upstream without much issues as this seems like > > > > an entirely reasonable thing to do. > > > > > > > > Reading further along the discussion you say that if this > > > > were a new feature you would likely agree to defaulting it > > > > to off. But since this has been there for years we should > > > > not change it ? That seems like a weak argument to me, we > > > > have always been doing this in a sub-optimal way so lets > > > > continue doing this in a sub-optimal way ? > > > > > > > I don't agree that the way we have been doing this is sub-optimal at > > > all. In fact, I think this proposed patch is the sub-optimal way. My > > > point is, new features, particularly with possible undesirable > > > results, are often defaulted to off under a "tech preview" model. The > > > mechanism in the kernel is not new. it may not work for everyone, but > > > it has been working fairly well for those who it does work for. Why > > > would we change them when a piece of userspace (that some of them > > > might never even use) wants to create a poor default policy? > > > > > > > I agree that we should not change it in the middle of a > > > > Fedora cycle. Hence I wrote: > > > > > > > > > > Against: > > > > > > > > > > > > Currently we do have some users using hibernation without > > > > > > adding any options to the kernel commandline. These users > > > > > > will have to now add "hibernate=yes" to their kernel commandline. > > > > > > > > > > > > I'm thinking that yes we want this, but maybe this needs to > > > > > > go through the change process for proper communication, so for > > > > > > F29 we need another fix, and we can do this for F30? > > > > > > > > I believe that if we put this through the change process, > > > > we can make sure that we properly communicate the need to add > > > > "hinernate=yes" to the kernel commandline for people who use > > > > it and want to keep using it. > > > > > > > > I also expect this to, if anything, lower the load for the Fedora > > > > kernel team, since it avoids users enabling hibernation without > > > > really knowing what they are doing and then filing bugs as a result > > > > of this. E.g.: > > > > * ATM in F28 hibernation is a simple click in gnome-tweaks away. > > > > * Even if we revert the GNOME change which triggered this discussion > > > > many other DEs will still advertise hibernate support in some way. > > > > > > > > Can you please elaborate a bit on your objections against this? > > > > > > > > > > It really is simple. You don't cripple a mechanism so that you can > > > install a bad default policy. The kernel is providing a plain and > > > neutral mechanism here. If people agree that the default policy is > > > wrong, it is the policy that should change. While I strongly feel > > > that the default power behavior should not be hibernate, I also fee > > > pretty strongly that it should be very easy to people to change. > > > > Ok fair enough. Keeping it easy for users to try out hibernate is > > a valid argument. > > > > So that puts the ball back into the court of the GNOME devs, adding > > Benjamin (g-s-d co-maintainer) to the Cc and I'll also ping him > > on IRC about this. > > So, it still looks like we are at a bit of a dead end with this > discussion. We know we need to disable the use of hibernation by > default but where depends on how you look at the issue (is it a policy > issue or are features falsely advertised). > > From a GNOME Settings Daemon perspective I am tempted to simply remove > the feature again. There are two main reasons for considering this: > > 1. It would solve the pressing issue for F29. > 2. The current implementation is incomplete and causes > inconsistencies for users. > > I only realised the issue with 2. when looking into it more because of > this discussion. We currently have at least 6 reasons to suspend with > different components creating the policy: > > * lid action: > - systemd-logind > - gsd-power inhibits in some cases > > * power button: > - gsd-media-keys: power-button-action > gsd-power settings keys > > * soft button: > - gnome-shell: hardcoded to suspend (logind call) > > * user is idle > - gsd-power: sleep-inactive-ac-type, sleep-inactive-battery-type > gsd-power settings keys > > * battery critical: > - upower: /etc/UPower/UPower.conf (defaults to hybrid suspend) > > * screen blanking: > - gsd-power: hardcoded to suspend on tablets > > The patches that introduced the policy only made the change for the > "power button" and "user is idle" cases (and "screen blanking"). In > particular the "soft button" and "lid" cases are not covered, meaning > that in many cases users will not actually suspend-then-hibernate[1]. Yeah, that seems quite inconsistent. I'd say "power button" > "lid" > "user is idle", in the sense that events on the right should use lighter suspend modes. > So, my proposal from the g-s-d side is: > 1. For the *stable* release cycle, hide the new "feature" behind a > compile time switch, disable it by default and announce properly > in the release notes. +1, even though a hidden setting key would be even nicer > 2. For the unstable release cycle plan on finding a more consistent > solution to control the policy. > Whether this is user configurable or not could still be something > to discuss. That'd be great too. > I would be happy if the underlying CanSuspendThenHibernate and > CanSuspend calls would not be advertising features that are unusable. Working on it ;) > My personal view is that it would be good if these calls were only > advertising the feature if it actually works, but I also see how this > can be hard or impossible to detect. Yes, this is impossible in the general case. > If systemd (or the kernel) is adjusted, then g-s-d may not need a > change. But even then it may still make sense to allow disabling the > new behaviour just to avoid the policy inconsistencies in the short > term. Yes, I think g-s-d should change too, even if systemd improves, since it's g-s-d and/or user that sets the policy. Zbyszek

5 years, 2 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel October 2018