Adding deferred fbcon console takeover to the Fedora kernels
by Hans de Goede
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-con...
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-norma...
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-con...
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
5 years, 1 month
Looking for x86-related fires
by Jeff Backus
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
5 years, 2 months
Changing the kernel loglevel associated with "quiet" from 4 to 3.
by Hans de Goede
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
5 years, 3 months
Kernel 4.17 rebase plans
by Justin Forbes
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
5 years, 3 months
[PATCH] fix kexec_file_load failure in case Secure Boot enabled
by Dave Young
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
5 years, 3 months
hibernate and Secure Boot, redux
by Chris Murphy
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
5 years, 3 months
Bluetooth keyboard makes the cursor disappear
by Michael Hill
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
5 years, 3 months
Duplicate touchpads on XPS 13
by Timur Kristóf
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
5 years, 3 months
May bug stats
by Justin Forbes
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
5 years, 3 months
