kernel June 2018

kernel@lists.fedoraproject.org

11 participants
10 discussions

Adding deferred fbcon console takeover to the Fedora kernels
by Hans de Goede 31 Jul '18

31 Jul '18

Hi All, Good news on the patch to make the loglevel for quiet configurable, this has been accepted into -next now. I plan to add this to the Fedora kernels soonish and set the quiet loglevel to 3 as discussed earlier. Today another related patch-set got merged, see the last 3 commits here: https://github.com/bzolnier/linux/commits/ib-fbdev-drm-v4.19-deferred-conso… I would also like to add these 3 patches to the Fedora 4.18 kernel (for F29+). The end goal here is a boot where the firmware shows its boot graphics and these stay in place for a couple of seconds until the GUI loads and the GUI then smoothly takes over the framebuffer without any disruptions. See here for an example of what this looks like on my main workstation: https://fedorapeople.org/~jwrdegoede/flickerfree-videos/workstation-normal.… Shim has already been modified to leave the framebuffer as setup by the firmware intact and patches for grub have been merged, but not yet build for F29+. Combined with the hidden grub menu feature for F29: https://fedoraproject.org/wiki/Changes/HiddenGrubMenu This means that the framebuffer is still showing the boot graphics (e.g. vendor logo) when the kernel loads. Without the "deferred fbcon console takeover" patches the fbcon will takeover from dummycon as the console driver as soon as the efifb registers itself as a fbdev, clearing the screen to black. breaking the desired boot experience. The deferred console takeover patches make the fbcon code delay taking over as the console until the first character is output on the console. I've tested this code with the following scenarios: 1) Remove quiet from the kernel commandline -> fbcon binds right away because messages are logged to the dummycon before efifb loads 2) Mess up the root= kernel argument -> As soon as dracut prints its timeout message for finding the rootfs, fbcon binds and shows the timeout message 3) Detailed view in plymouth mode (press ESC to show boot msg) -> plymouth retains drm master rights on /dev/dri/card? while it tries to show the details. The blocks fbcon accessing the fbdev device registered by the kms driver, so nothing will be shown until plymouth exits (and releases the drm-master rights). This really is a plymouth bug, I've submitted plymouth patches fixing this here: https://bugs.freedesktop.org/show_bug.cgi?id=107047 4) touch /.autorelabel -> autorelabel correctly switches back to text mode and shows the autorelabel status ### TL;DR: I'm working on making the boot look pretty (prettier) for F29 and to complete this we need the 3 patches from here: https://github.com/bzolnier/linux/commits/ib-fbdev-drm-v4.19-deferred-conso… Added as downstream patches to the Fedora kernel for F29+ (and just for 4.18, they are going upstream for 4.19). Are you (the Fedora kernel team) ok with me adding these patches and enabling the new FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER Kconfig option? Regards, Hans

2 4

Looking for x86-related fires
by Jeff Backus 28 Jun '18

28 Jun '18

Hi folks, I'm going to take a whack at triaging x86-related bugs. I see a few listed on the x86 tracker bug and the x86 exclude arch bug, which I'll take a closer look at. Before I start searching for anything i686-related, are there any issues you'd like us to take a look at first? jeff -- Jeff Backus jeff.backus(a)gmail.com http://github.com/jsbackus

1 0

Changing the kernel loglevel associated with "quiet" from 4 to 3.
by Hans de Goede 19 Jun '18

19 Jun '18

Hi All, As some of you have probably heard I'm working on making Fedora be less "chatty" during boot, part of this is: https://fedoraproject.org/wiki/Changes/HiddenGrubMenu But that only makes grub quiet. We've been passing to the kernel for a long time for the same reasons. Unfortunately quiet is not really always quiet. There are simply many false-positive or at least completely harmless messages printed by the kernel with a loglevel of KERN_ERR. Currently we display all these. For at least the last year or so I've been sending patches to the upstream kernel to silence these, but new ones always pop up. So this is an endless and hopeless game of whack-a-mole. Therefor I propose to instead of keep whacking the moles, we change the loglevel associated with "quiet" from 4 to 3, so that only messages with a higher severity then KERN_ERR (CRIT, ALERT, EMERG) get printed on the console. Note all messages will still be available in dmesg and the journal. This is purely about which messages get printed on the console and thus get thrown in the users face. Besides improving the boot experience by not needlessly showing scary messages to end users, this should also help to reduce the amount of bugs we receive about these kind of errors. Here is a quick and in no way complete list of bugs which I believe fall into this category: 1413342 - Linux 4.9.3: ACPI Error: [_OSI] Namespace lookup failure, AE_NOT_FOU 1415853 - ACPI Error: Namespace lookup failure, AE_NOT_FOUND (20160831/psargs- 1514937 - ACPI Error: AE_NOT_FOUND 1527870 - ACPI Error: [\_SB_.PCI0.SAT1] Namespace lookup failure, AE_NOT_FOUND 1552580 - ACPI Error: Method parse/execution failed 1553320 - Kernel errors at bootup -- system runs okay 1556967 - ACPI Error: [SMIC] Namespace lookup failure, AE_ALREADY_EXISTS 1582825 - ACPI Error: Method parse/execution failed https://bugzilla.kernel.org/show_bug.cgi?id=109511 https://bugzilla.kernel.org/show_bug.cgi?id=194687 Esp. the bugzilla.kernel.org ones are interesting and then esp.: https://bugzilla.kernel.org/show_bug.cgi?id=109511 109511 - ACPI error messages caused by undefined object - Dell XPS 13 9350 Which is about a completely harmless ACPI DSDT problem which many machines have, resulting in an AE_NOT_FOUND error. I've done multiple attempts to get the upstream ACPICA people to drop the loglevel of AE_NOT_FOUND errors to KERN_WARNING, also see the 194687 bug. But upstream ACPICA refuses to change this instead insisting that: a) Vendors should fix there DSDTs to be perfect; and b) end-users should then update their BIOS to fix this Neither of which is a realistic expectation in anyway, this just goes to show that getting the kernel to not log harmless errors is a loosing proposition. ### TL;DR: kernel is still too verbose at loglevel 4, lets change quiet to mean 3. To achieve this without needing downstream patches I've posted a patch upstream to make this configurable from Kconfig: https://lkml.org/lkml/2018/6/19/462 My question to the Fedora kernel team now is, are you ok with changing the log-level associated with "quiet" from 4 to 3? I can take care of making the necessary changes. Regards, Hans

3 4

Requests for kernel related quick-docs?
by Laura Abbott 19 Jun '18

19 Jun '18

Hi, If you haven't seen it, Fedora has a new documentation project called quick-docs to move information off the wiki, https://docs.fedoraproject.org/quick-docs/en-US/index.html We've started moving some of the kernel information there. Any requests for kernel related items you'd like documented? You're welcome to write docs yourself as well. Thanks, Laura

1 0

Kernel 4.17 rebase plans
by Justin Forbes 14 Jun '18

14 Jun '18

While the 4.17 kernel was released almost 2 weeks ago, I wanted to get through the 4.17 test day and see how things looked before coming up with a definitive schedule. Things went really well, and I expect F28 will get 4.17.2 or 4.17.3 into updates-testing next week. F27 will follow shortly after, though it should still be in the June timeframe. Thanks, Justin

1 0

[PATCH] fix kexec_file_load failure in case Secure Boot enabled
by Dave Young 14 Jun '18

14 Jun '18

Fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=1470995 With Fedora kernels on Secure Boot enabled machine kexec_file_load fails because kernel can not use any keys other than kernel builtin keyring. verify_pefile_signature() requires caller to pass 1UL as the keyring pointer to use other keyring. Posted a fix in upstream, but no response for long time. Thus going with a Fedora fix same as what the module code does. Latest upstream effort: https://www.spinics.net/lists/kernel/msg2825184.html Signed-off-by: Dave Young <dyoung(a)redhat.com> --- kernel.spec | 3 ++ kexec-bzimage-verify-pe-signature-fix.patch | 32 +++++++++++++++++++++ 2 files changed, 35 insertions(+) create mode 100644 kexec-bzimage-verify-pe-signature-fix.patch diff --git a/kernel.spec b/kernel.spec index d5e16d7f..7a20da1e 100644 --- a/kernel.spec +++ b/kernel.spec @@ -608,6 +608,9 @@ Patch501: Fix-for-module-sig-verification.patch # rhbz 1431375 Patch502: input-rmi4-remove-the-need-for-artifical-IRQ.patch +# rhbz 1470995 +Patch503: kexec-bzimage-verify-pe-signature-fix.patch + # END OF PATCH DEFINITIONS %endif diff --git a/kexec-bzimage-verify-pe-signature-fix.patch b/kexec-bzimage-verify-pe-signature-fix.patch new file mode 100644 index 00000000..866b74b9 --- /dev/null +++ b/kexec-bzimage-verify-pe-signature-fix.patch @@ -0,0 +1,32 @@ +From: Dave Young <dyoung(a)redhat.com> + +Fix kexec_file_load pefile signature verification + +Similar with Fix-for-module-sig-verification.patch, kexec_file syscall also +need pass 1UL to verify_pefile_signature so that secondary keys can be used. + +Fedora bug +https://bugzilla.redhat.com/show_bug.cgi?id=1470995 + +Latest upstream effort is below: +https://www.spinics.net/lists/kernel/msg2825184.html + +Ideally this need an upstream fix, but since nobody response we can workaround +it like the module code did. + +Signed-off-by: Dave Young <dyoung(a)redhat.com> +--- + arch/x86/kernel/kexec-bzimage64.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- linux-x86.orig/arch/x86/kernel/kexec-bzimage64.c ++++ linux-x86/arch/x86/kernel/kexec-bzimage64.c +@@ -533,7 +533,7 @@ static int bzImage64_cleanup(void *loade + static int bzImage64_verify_sig(const char *kernel, unsigned long kernel_len) + { + return verify_pefile_signature(kernel, kernel_len, +- NULL, ++ (void *)1UL, + VERIFYING_KEXEC_PE_SIGNATURE); + } + #endif -- 2.17.0

3 5

hibernate and Secure Boot, redux
by Chris Murphy 04 Jun '18

04 Jun '18

On Fedora 28 Workstation with 4.17.0-0.rc7.git1.1.fc29.x86_64, on a UEFI Secure Boot enabled system, I'm seeing this in the journal following a low power situation. Jun 02 15:11:33 f28h.local systemd[1]: Starting Hybrid Suspend+Hibernate... After configuring a resume=UUID= line for the bootloader, hibernate works (both enter and exit). This was previously inhibited on Secure Boot enabled systems. Is this expected? I'm just doing a double take. Thanks, -- Chris Murphy

2 1

Bluetooth keyboard makes the cursor disappear
by Michael Hill 04 Jun '18

04 Jun '18

Using Rawhide, with kernel Version : 4.17.0 Release : 0.rc6.git3.1.fc29 (also 0.rc6.git2.1.fc29) Architecture: x86_64 and libinput Version : 1.10.901 Release : 1.fc29 my ThinkPad Bluetooth keyboard causes the cursor to disappear or become unresponsive. On Wayland, after activating the shell overview, the cursor vanishes. I can get it back by disabling Bluetooth from the system menu and (seemingly) switching to a console and back. On X, the keyboard works until I touch the trackpoint. The cursor flies to the shell hot corner, lights up Activities without opening the overview, and stays. My laptop trackpoint or a USB mouse can then be used to move the cursor. Here's what dmesg says: [91490.366114] usb 2-7: new full-speed USB device number 7 using xhci_hcd [91490.493583] usb 2-7: New USB device found, idVendor=8087, idProduct=0a2a, bcdDevice= 0.01 [91490.493589] usb 2-7: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [91490.510181] Bluetooth: hci0: read Intel version: 370810011003110e00 [91490.510625] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq [91490.807247] Bluetooth: hci0: Intel firmware patch completed and activated [91491.018110] Bluetooth: hci0: last event is not cmd complete (0x0f) [91508.126555] lenovo 0005:17EF:6048.0008: unknown main item tag 0x0 [91508.127308] input: ThinkPad Compact Bluetooth Keyboard with TrackPoint as /devices/pci0000:00/0000:00:14.0/usb2/2-7/2-7:1.0/bluetooth/hci0/hci0:256/0005:17EF:6048.0008/input/input26 [91508.129208] lenovo 0005:17EF:6048.0008: input,hidraw2: BLUETOOTH HID v3.09 Keyboard [ThinkPad Compact Bluetooth Keyboard with TrackPoint] on a4:02:b9:6d:5e:bf [91589.456678] usb 2-7: USB disconnect, device number 7 Does this sound like a kernel bug? Mike

4 8

Duplicate touchpads on XPS 13
by Timur Kristóf 03 Jun '18

03 Jun '18

Hi, On the XPS 13 9360 and 9370 xinput sees two touchpads instead of one: ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ DELL07E6:00 06CB:76AF Touchpad id=12 [slave pointer (2)] ⎜ ↳ SynPS/2 Synaptics TouchPad id=17 [slave pointer (2)] dmesg also gives me the following: [ 1.429811] psmouse serio1: synaptics: Your touchpad (PNP: DLL07e6 PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input(a)vger.kernel.org. The Dell one is the real touchpad, the other one is an artifact of the psmouse driver. Weird touchpad freezes and jittering issues can be observed when both of these devices are there. The general advice on the web is to blacklist the psmouse driver. (This is also published by Dell as a .deb package which contains a config file doing just this.) However, on Fedora I cannot blacklist the psmouse driver because it is compiled built-in instead of as a module. Could you guys change the Fedora kernel config to compile it as a module instead? Thanks & best regards, Timur

4 9

May bug stats
by Justin Forbes 01 Jun '18

01 Jun '18

Since it was brought up on fedora-devel, I said I would post these monthly: 26 27 28 rawhide open: 0 273 130 195 (598) Since 2018-05-01 opened: 4 33 90 10 (137) closed: 133 33 21 11 (198) If you would like to help improve these stats, https://fedoraproject.org/wiki/KernelBugTriage is a great place to start! Thanks, Justin

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel June 2018