March 2023 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1200983] mouse & keyboard not available after a reboot (needs replug the devices)
by bugzilla_noreply＠suse.com 08 Mar '23

08 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1200983 https://bugzilla.suse.com/show_bug.cgi?id=1200983#c12 --- Comment #12 from Michael Hirmke <opensuse(a)mike.franken.de> --- (In reply to Stefan Dirsch from comment #10) > Thanks for testing. Indeed this makes it a kernel issue. You could also test > the mouse on the Linux console via 'evtest /dev/input/eventXX', but this is > a bit complicated to figure out the right device. So I only wanted to > mention keyboard here. Keyboard and mouse both have problems one the console, too. The keyboard vanishes after a few seconds and returns, as soon as a key is pressed, but the first keypress is not shown. The mouse never works on the console - no events are shown. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209006] Document how to secureboot-sign manually-built kernel modules on TW kernel >= 6.2.1
by bugzilla_noreply＠suse.com 08 Mar '23

08 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c16 --- Comment #16 from Martin Wilck <martin.wilck(a)suse.com> --- (In reply to Martin Wilck from comment #15) > (In reply to Joey Lee from comment #9) > > Base on v6.2 kernel, keys in .machine keyring still must be trusted(signed) > > by key in built-in/secondary keyring. It applies restrict_link_to_ima and > > depends on CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY. > > [...] > > So keys could be added from the machine keyring to the secondary keyring > without being trusted by the secondary keyring beforehand, but such keys > could never have been added to the machine keyring in the first place. > > That looks like an upstream bug to me. Sorry, no. I was wrong. https://elixir.bootlin.com/linux/v6.2/source/security/integrity/digsig.c#L1… shows that there is no restriction at all for keys in the machine and platform key rings. But now I fail to see why MoK keys don't make it into the secondary keyring... -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1209006] Document how to secureboot-sign manually-built kernel modules on TW kernel >= 6.2.1
by bugzilla_noreply＠suse.com 08 Mar '23

08 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c15 Martin Wilck <martin.wilck(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(jlee(a)suse.com) --- Comment #15 from Martin Wilck <martin.wilck(a)suse.com> --- (In reply to Joey Lee from comment #9) > > In upstream the MOK keys are loaded into machine keyring which then should > > get loaded into secondary keyring. > > Looks it's not. > > Base on v6.2 kernel, keys in .machine keyring still must be trusted(signed) > by key in built-in/secondary keyring. It applies restrict_link_to_ima and > depends on CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY. system_trusted_keyring_init() uses get_builtin_and_secondary_restriction() as restriction for the secondary keyring. This resolves to restrict_link_by_builtin_secondary_and_machine() if CONFIG_INTEGRITY_MACHINE_KEYRING is set, (and restrict_link_by_builtin_and_secondary_trusted otherwise). But machine_keyring_init() -> integrity_init_keyring() -> _integrity_init_keyring() uses restrict_link_to_ima, which resolves to restrict_link_by_builtin_and_secondary_trusted(). So keys could be added from the machine keyring to the secondary keyring without being trusted by the secondary keyring beforehand, but such keys could never have been added to the machine keyring in the first place. That looks like an upstream bug to me. TBH, I fail to understand the entire concept. A users's key will always be self-signed, or at best signed by the user's own CA. How would the user be able to have it signed by any key in the builtin or secondary keyrings, without compiling the kernel with her own key? (Side note, off-topic: I also fail to understand why the kernel doesn't accept pre-boot keys for signing modules. In the past it was possible to have hardware vendor keys (such in Dell) in the EFI db and use them for verifying vendor-provided 3rd party modules. Which was not a bad idea, IMHO. I sounds hypocritical to me not to trust the db keys. If those were compromised, the entire enviroment the kernel was running in would be compromised already). > So, currently the .machine keyring is NOT useful for loading a MOK-signed > kernel module. I think all MOKs will be loaded to .platform keyring. Unless > Eric Snowberg's MOK CA patch be accepted: Not sure what that patch would change in this respect, except placing additional restrictions on the keys that would be accepted. Can you explain how the CA restriction is supposed to work (assuming the issue above is fixed somehow) ? Only CA certs from the MoK will be added to the machine and secondary keyrings. But how will the user sign the modules then? In the strictest form, the CA certs are not permitted to have the "digitalSigature" usage flag set. Thus AFAIK they can't be used to sign kernel modules. An intermediate cert would be needed which would be signed by the CA, and then used to sign the modules. But how would that intermediate cert be loaded into the kernel? IIUC it would end up in the .platform keyring which is _not_ used to verify modules... > Kernel will check the existence of MokListTrustedRT. So we need to run > "mokutil --trust-mok", otherwise all MOK will go to .platform keyring. This seems weird to me too. Why would a user put a key in the MoK if she didn't want the kernel to trust it? It just adds extra inconvenience (having to run "mokutil --trust-mok"), but zero extra security, AFAICT. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1208944] Kernel 6.2.0-1-default does not boot on tumbleweed
by bugzilla_noreply＠suse.com 08 Mar '23

08 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208944 https://bugzilla.suse.com/show_bug.cgi?id=1208944#c12 --- Comment #12 from Pieter Terpstra <kesang.neljor(a)yahoo.com> --- Adding pci=nommconf to the kernel line gives a normal boot (uninterrupted) with the 6.1.8-1-default Would you like to have the dmesg of that one too? #lspci -vnn 0000:00:00.0 Host bridge [0600]: Intel Corporation 11th Gen Core Processor Host Bridge/DRAM Registers [8086:9a14] (rev 01) Subsystem: Dell Device [1028:0ab0] Flags: bus master, fast devsel, latency 0 Capabilities: [e0] Vendor Specific Information: Len=14 <?> Kernel modules: igen6_edac 0000:00:02.0 VGA compatible controller [0300]: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) (prog-if 00 [VGA controller]) Subsystem: Dell Device [1028:0ab0] Flags: bus master, fast devsel, latency 0, IRQ 143 Memory at 6002000000 (64-bit, non-prefetchable) [size=16M] Memory at 4000000000 (64-bit, prefetchable) [size=256M] I/O ports at 4000 [size=64] Expansion ROM at 000c0000 [virtual] [disabled] [size=128K] Capabilities: [40] Vendor Specific Information: Len=0c <?> Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable+ 64bit- Capabilities: [d0] Power Management version 2 Kernel driver in use: i915 Kernel modules: i915 0000:00:04.0 Signal processing controller [1180]: Intel Corporation TigerLake-LP Dynamic Tuning Processor Participant [8086:9a03] (rev 01) Subsystem: Dell Device [1028:0ab0] Flags: fast devsel, IRQ 16 Memory at 6003200000 (64-bit, non-prefetchable) [size=128K] Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 3 Capabilities: [e0] Vendor Specific Information: Len=0c <?> Kernel driver in use: proc_thermal Kernel modules: processor_thermal_device_pci_legacy 0000:00:0a.0 Signal processing controller [1180]: Intel Corporation Tigerlake Telemetry Aggregator Driver [8086:9a0d] (rev 01) Subsystem: Dell Device [1028:0ab0] Flags: fast devsel Memory at 6003230000 (64-bit, non-prefetchable) [size=32K] Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [d0] Power Management version 3 Kernel modules: intel_vsec 0000:00:0e.0 RAID bus controller [0104]: Intel Corporation Volume Management Device NVMe RAID Controller [8086:9a0b] Subsystem: Dell Device [1028:0ab0] Flags: bus master, fast devsel, latency 0 Memory at 6000000000 (64-bit, non-prefetchable) [size=32M] Memory at 72000000 (32-bit, non-prefetchable) [size=32M] Memory at 6003100000 (64-bit, non-prefetchable) [size=1M] Capabilities: [80] MSI-X: Enable+ Count=19 Masked- Capabilities: [90] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [e0] Power Management version 3 Kernel driver in use: vmd Kernel modules: vmd 0000:00:14.0 USB controller [0c03]: Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller [8086:a0ed] (rev 20) (prog-if 30 [XHCI]) Subsystem: Dell Device [1028:0ab0] Flags: bus master, medium devsel, latency 0, IRQ 142 Memory at 6003220000 (64-bit, non-prefetchable) [size=64K] Capabilities: [70] Power Management version 2 Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+ Capabilities: [90] Vendor Specific Information: Len=14 <?> Capabilities: [b0] Vendor Specific Information: Len=00 <?> Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 0000:00:14.2 RAM memory [0500]: Intel Corporation Tiger Lake-LP Shared SRAM [8086:a0ef] (rev 20) Subsystem: Dell Device [1028:0ab0] Flags: fast devsel Memory at 600323c000 (64-bit, non-prefetchable) [disabled] [size=16K] Memory at 6003244000 (64-bit, non-prefetchable) [disabled] [size=4K] Capabilities: [80] Power Management version 3 0000:00:15.0 Serial bus controller [0c80]: Intel Corporation Tiger Lake-LP Serial IO I2C Controller #0 [8086:a0e8] (rev 20) Subsystem: Dell Device [1028:0ab0] Flags: bus master, fast devsel, latency 0, IRQ 27 Memory at 4010000000 (64-bit, non-prefetchable) [size=4K] Capabilities: [80] Power Management version 3 Capabilities: [90] Vendor Specific Information: Len=14 <?> Kernel driver in use: intel-lpss Kernel modules: intel_lpss_pci 0000:00:15.1 Serial bus controller [0c80]: Intel Corporation Tiger Lake-LP Serial IO I2C Controller #1 [8086:a0e9] (rev 20) Subsystem: Dell Device [1028:0ab0] Flags: bus master, fast devsel, latency 0, IRQ 40 Memory at 4010001000 (64-bit, non-prefetchable) [size=4K] Capabilities: [80] Power Management version 3 Capabilities: [90] Vendor Specific Information: Len=14 <?> Kernel driver in use: intel-lpss Kernel modules: intel_lpss_pci 0000:00:16.0 Communication controller [0780]: Intel Corporation Tiger Lake-LP Management Engine Interface [8086:a0e0] (rev 20) Subsystem: Dell Device [1028:0ab0] Flags: bus master, fast devsel, latency 0, IRQ 156 Memory at 6003241000 (64-bit, non-prefetchable) [size=4K] Capabilities: [50] Power Management version 3 Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [a4] Vendor Specific Information: Len=14 <?> Kernel driver in use: mei_me Kernel modules: mei_me 0000:00:17.0 System peripheral [0880]: Intel Corporation RST VMD Managed Controller [8086:09ab] Flags: fast devsel 0000:00:1d.0 PCI bridge [0604]: Intel Corporation Device [8086:a0b1] (rev 20) (prog-if 00 [Normal decode]) Subsystem: Dell Device [1028:0ab0] Flags: bus master, fast devsel, latency 0, IRQ 122 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 3000-3fff [size=4K] [16-bit] Memory behind bridge: 74000000-740fffff [size=1M] [32-bit] Prefetchable memory behind bridge: [disabled] [64-bit] Capabilities: [40] Express Root Port (Slot+), MSI 00 Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [90] Subsystem: Dell Device [1028:0ab0] Capabilities: [a0] Power Management version 3 Kernel driver in use: pcieport 0000:00:1f.0 ISA bridge [0601]: Intel Corporation Tiger Lake-LP LPC Controller [8086:a082] (rev 20) Subsystem: Dell Device [1028:0ab0] Flags: bus master, fast devsel, latency 0 0000:00:1f.3 Audio device [0403]: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller [8086:a0c8] (rev 20) (prog-if 80) Subsystem: Dell Device [1028:0ab0] Flags: bus master, fast devsel, latency 64, IRQ 157 Memory at 6003238000 (64-bit, non-prefetchable) [size=16K] Memory at 6003000000 (64-bit, non-prefetchable) [size=1M] Capabilities: [50] Power Management version 3 Capabilities: [80] Vendor Specific Information: Len=14 <?> Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+ Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel, snd_sof_pci_intel_tgl 0000:00:1f.4 SMBus [0c05]: Intel Corporation Tiger Lake-LP SMBus Controller [8086:a0a3] (rev 20) Subsystem: Dell Device [1028:0ab0] Flags: medium devsel, IRQ 16 Memory at 6003240000 (64-bit, non-prefetchable) [size=256] I/O ports at efa0 [size=32] Kernel driver in use: i801_smbus Kernel modules: i2c_i801 0000:00:1f.5 Serial bus controller [0c80]: Intel Corporation Tiger Lake-LP SPI Controller [8086:a0a4] (rev 20) Subsystem: Dell Device [1028:0ab0] Flags: fast devsel Memory at 70800000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: intel-spi Kernel modules: spi_intel_pci 0000:01:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8821CE 802.11ac PCIe Wireless Network Adapter [10ec:c821] Subsystem: Realtek Semiconductor Co., Ltd. Device [10ec:c828] Flags: bus master, fast devsel, latency 0, IRQ 158 I/O ports at 3000 [size=256] Memory at 74000000 (64-bit, non-prefetchable) [size=64K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 00 Kernel driver in use: rtw_8821ce Kernel modules: rtw88_8821ce 10000:e0:17.0 SATA controller [0106]: Intel Corporation Tiger Lake-LP SATA Controller [8086:a0d3] (rev 20) (prog-if 01 [AHCI 1.0]) Subsystem: Dell Device [1028:0ab0] Flags: bus master, 66MHz, medium devsel, latency 0 Memory at 72100000 (32-bit, non-prefetchable) [size=8K] Memory at 72102800 (32-bit, non-prefetchable) [size=256] Memory at 72102000 (32-bit, non-prefetchable) [size=2K] Capabilities: [d0] MSI-X: Enable+ Count=1 Masked- Capabilities: [70] Power Management version 3 Capabilities: [a8] SATA HBA v1.0 Kernel driver in use: ahci 10000:e0:1c.0 System peripheral [0880]: Intel Corporation RST VMD Managed Controller [8086:09ab] Flags: fast devsel 10000:e0:1c.4 PCI bridge [0604]: Intel Corporation Device [8086:a0bc] (rev 20) (prog-if 00 [Normal decode]) Subsystem: Dell Device [1028:0ab0] Flags: bus master, fast devsel, latency 0, IRQ 145 Bus: primary=00, secondary=e1, subordinate=e1, sec-latency=0 I/O behind bridge: [disabled] [16-bit] Memory behind bridge: 72000000-720fffff [size=1M] [32-bit] Prefetchable memory behind bridge: [disabled] [64-bit] Capabilities: [40] Express Root Port (Slot+), MSI 00 Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [90] Subsystem: Dell Device [1028:0ab0] Capabilities: [a0] Power Management version 3 Capabilities: [100] Advanced Error Reporting Capabilities: [220] Access Control Services Capabilities: [150] Precision Time Measurement Capabilities: [200] L1 PM Substates Capabilities: [a30] Secondary PCI Express Capabilities: [a00] Downstream Port Containment Kernel driver in use: pcieport 10000:e1:00.0 Non-Volatile memory controller [0108]: Sandisk Corp Device [15b7:5007] (rev 01) (prog-if 02 [NVM Express]) Subsystem: Sandisk Corp Device [15b7:5007] Flags: bus master, fast devsel, latency 0, NUMA node 0 Memory at 72000000 (64-bit, non-prefetchable) [size=16K] Memory at 72004000 (64-bit, non-prefetchable) [size=256] Capabilities: [80] Power Management version 3 Capabilities: [90] MSI: Enable- Count=1/32 Maskable- 64bit+ Capabilities: [b0] MSI-X: Enable+ Count=17 Masked- Capabilities: [c0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [150] Device Serial Number 00-00-00-00-00-00-00-00 Capabilities: [1b8] Latency Tolerance Reporting Capabilities: [300] Secondary PCI Express Capabilities: [900] L1 PM Substates Kernel driver in use: nvme Kernel modules: nvme -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208990] intel: UHD630 (Kabylake) support broken?
by bugzilla_noreply＠suse.com 08 Mar '23

08 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c9 --- Comment #9 from Andreas <opendreas(a)gmail.com> --- Created attachment 865372 --> http://bugzilla.opensuse.org/attachment.cgi?id=865372&action=edit hwinfo (In reply to Takashi Iwai from comment #8) > Not sure what's going on there. Can you boot the already installed Leap > 15.5 system without nomodeset, and see whether the native graphics can start > up? > > In anyway, please give hwinfo output from the installed system. Yes, I can boot installed Leap 15.5 without nomodeset. I can't run Leap 15.5 DVD image on USB flash without nomodeset. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208990] intel: UHD630 (Kabylake) support broken?
by bugzilla_noreply＠suse.com 08 Mar '23

08 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c8 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(opendreas(a)gmail.c | |om) --- Comment #8 from Takashi Iwai <tiwai(a)suse.com> --- Not sure what's going on there. Can you boot the already installed Leap 15.5 system without nomodeset, and see whether the native graphics can start up? In anyway, please give hwinfo output from the installed system. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208990] intel: UHD630 (Kabylake) support broken?
by bugzilla_noreply＠suse.com 08 Mar '23

08 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 Stefan Dirsch <sndirsch(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Leap 15.5 won't load Yast |intel: UHD630 (Kabylake) |on boot |support broken? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208990] Leap 15.5 won't load Yast on boot
by bugzilla_noreply＠suse.com 08 Mar '23

08 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c7 Stefan Dirsch <sndirsch(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|X.Org |Kernel Assignee|gfx-bugs(a)suse.de |kernel-bugs(a)opensuse.org QA Contact|gfx-bugs(a)suse.de |qa-bugs(a)suse.de Flags|needinfo?(opendreas(a)gmail.c | |om) | --- Comment #7 from Stefan Dirsch <sndirsch(a)suse.com> --- Ok. Thanks. So looks like intel kernel driver doesn't work. In a way that modeset X driver cannot work and fbdev driver neither, since generic framebuffer was already replaced with the native kernel driver. Reassiging to kernel component. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209006] Document how to secureboot-sign manually-built kernel modules on TW kernel >= 6.2.1
by bugzilla_noreply＠suse.com 08 Mar '23

08 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c14 --- Comment #14 from Stefan Dirsch <sndirsch(a)suse.com> --- (In reply to Joey Lee from comment #12) > (In reply to Stefan Dirsch from comment #11) > > Tried "mokutil --trust-mok". After enrolling. Didn't help. Deleted the key > > from Mok. Then re-enrolling it again. Didn't help either. > > I am porting > patches.suse/KEYS-Make-use-of-platform-keyring-for-module-signatu.patch to > openSUSE Tumbleweed kernel. We need it for Nvidia driver. Thanks for taking care of this. > But we will need to change the rpm scripts of Nvidia driver again when Eric > Snowberg's patch set be merged on mainline if we want to follow upstream's > approach. Ok. But I need to know in which way. And I would like to have the time to prepare this beforehand ... -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1209006] Document how to secureboot-sign manually-built kernel modules on TW kernel >= 6.2.1
by bugzilla_noreply＠suse.com 08 Mar '23

08 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c13 Stefan Dirsch <sndirsch(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P1 - Urgent CC| |kernel-bugs(a)opensuse.org Assignee|kernel-bugs(a)opensuse.org |jslaby(a)suse.com --- Comment #13 from Stefan Dirsch <sndirsch(a)suse.com> --- For me this looks like we are't prepared at all for supporting 3rd party kernel modules signed with their own MOK certificates with this kernel update with lockdown patches enabled. So I suggest to revert this and work on how to support this for a later kernel update with lockdown patches re-enabled. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

1 0

[Bug 1209006] Document how to secureboot-sign manually-built kernel modules on TW kernel >= 6.2.1
by bugzilla_noreply＠suse.com 08 Mar '23

08 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c11 --- Comment #11 from Stefan Dirsch <sndirsch(a)suse.com> --- Tried "mokutil --trust-mok". After enrolling. Didn't help. Deleted the key from Mok. Then re-enrolling it again. Didn't help either. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208239] Driver for Intel Alder Lake-UP3 GT2 [UHD Graphics] -- HDMI not properly recognized
by bugzilla_noreply＠suse.com 08 Mar '23

08 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208239 http://bugzilla.opensuse.org/show_bug.cgi?id=1208239#c17 --- Comment #17 from Luca Bastianelli <bastiabrn(a)gmail.com> --- Created attachment 865363 --> http://bugzilla.opensuse.org/attachment.cgi?id=865363&action=edit output of some commands Dear Patrick, thanks for your support! I updated the OS (Leap 15.5) to the last version with latest update/upgrade. Attached I reported some commands' output. I tried also with glmark2; when it was running all applications in that desktop went very very slow... whereas if I switch the desktop everything it's ok. Regarding the ACER monitor I solved that issue... after several attempt with many PCs I changed the HDMI cable and now it works... :) It's quite strange because it is the same model I replaced it with. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206316] New: [RKL] add_drivers+=" i915 " included in /etc/dracut.d/*, cause drm/dri issue(s) that delay initial X startup ~90 seconds
by bugzilla_noreply＠suse.com 08 Mar '23

08 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1206316 Bug ID: 1206316 Summary: [RKL] add_drivers+=" i915 " included in /etc/dracut.d/*, cause drm/dri issue(s) that delay initial X startup ~90 seconds Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: mrmazda(a)earthlink.net QA Contact: qa-bugs(a)suse.de CC: sndirsch(a)suse.com, tzimmermann(a)suse.com Found By: --- Blocker: --- Created attachment 863458 --> http://bugzilla.opensuse.org/attachment.cgi?id=863458&action=edit .tgz of Xorg.0.log + journalctl -b (with drm.debug=0x1e log_buf_len=1M) Initial summary: [RKL] add_drivers+=" i915 " included in /etc/dracut.d/*, cause drm/dri issue(s) that delay initial X startup ~90 seconds To reproduce: 1-include add_drivers+=" i915 " in /etc/dracut.d/local.conf 2-dracut -f 3-reboot Actual behavior: 1-~90 seconds between shell prompt appearance on tty1 and TDM greeter appearance on tty7 2-Grep of /dev/dri/card from the attachment: [ 93.509] (II) xfree86: Adding drm device (/dev/dri/card1) [ 93.575] (II) modeset(0): using drv /dev/dri/card1 Dec 12 03:57:11 ab560 systemd[1]: Timed out waiting for device /dev/dri/card0. 3-# dmesg | grep -i Faile [ 2.410971] simple-framebuffer simple-framebuffer.0: [drm:drm_atomic_helper_check_planes] [CRTC:34:crtc-0] atomic driver check failed [ 2.410979] simple-framebuffer simple-framebuffer.0: [drm:drm_atomic_check_only] atomic driver check for 000000008eb548ce failed: -22 [ 2.548403] i915 0000:00:02.0: [drm:intel_hdmi_set_edid [i915]] HDMI GMBUS EDID read failed, retry using GPIO bit-banging [ 2.738080] i915 0000:00:02.0: [drm:intel_hdmi_set_edid [i915]] HDMI GMBUS EDID read failed, retry using GPIO bit-banging [ 2.814605] i915 0000:00:02.0: [drm:intel_hdmi_set_edid [i915]] HDMI GMBUS EDID read failed, retry using GPIO bit-banging [ 3.640125] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 3.640127] cfg80211: failed to load regulatory.db [ 3.870867] asus_wmi: fan_curve_get_factory_default (0x00110024) failed: -61 [ 3.870938] asus_wmi: fan_curve_get_factory_default (0x00110025) failed: -61 [ 93.481800] i915 0000:00:02.0: [drm:i915_perf_remove_config_ioctl [i915]] Failed to remove unknown OA config [ 93.554205] i915 0000:00:02.0: [drm:intel_hdmi_set_edid [i915]] HDMI GMBUS EDID read failed, retry using GPIO bit-banging [ 93.626006] i915 0000:00:02.0: [drm:intel_hdmi_set_edid [i915]] HDMI GMBUS EDID read failed, retry using GPIO bit-banging 4-in the attachment Expected behavior: 1-# systemd-analyze critical-chain (kernel 6.0.10 without including driver i915 in initrd) .... graphical.target @3.640s ��multi-user.target @3.640s ��kbdsettings.service @1.564s +2.075s ��basic.target @1.560s ��sockets.target @1.560s ��telnet.socket @1.560s ��sysinit.target @1.558s ��systemd-timesyncd.service @1.538s +20ms ��systemd-tmpfiles-setup.service @1.528s +9ms ��local-fs.target @1.527s ��run-credentials-systemd\x2dtmpfiles\x2dsetup.service.mount @1.529s ��local-fs-pre.target @514ms ��lvm2-monitor.service @378ms +135ms ��dm-event.socket @315ms ��system.slice ��-.slice 2-Xorg.0.log begins at ~[ 4.7s] 3-Nice, fast boot to greeter # inxi -CSGz System: Kernel: 6.0.10-1-default arch: x86_64 bits: 64 Desktop: Trinity v: R14.0.13 Distro: openSUSE Tumbleweed 20221210 CPU: Info: 6-core model: 11th Gen Intel Core i5-11400 bits: 64 type: MT MCP cache: L2: 3 MiB Speed (MHz): avg: 2600 min/max: 800/4400 cores: 1: 2600 2: 2600 3: 2600 4: 2600 5: 2600 6: 2600 7: 2600 8: 2600 9: 2600 10: 2600 11: 2600 12: 2600 Graphics: Device-1: Intel RocketLake-S GT1 [UHD Graphics 730] driver: i915 v: kernel Display: x11 server: X.Org v: 21.1.4 driver: X: loaded: modesetting unloaded: fbdev,vesa dri: iris gpu: i915 resolution: 1: 2560x1440~60Hz 2: 1920x1200~60Hz 3: 1680x1050~60Hz API: OpenGL v: 4.6 Mesa 22.2.4 renderer: Mesa Intel Graphics (RKL GT1) -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 1208944] Kernel 6.2.0-1-default does not boot on tumbleweed
by bugzilla_noreply＠suse.com 08 Mar '23

08 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208944 https://bugzilla.suse.com/show_bug.cgi?id=1208944#c11 --- Comment #11 from Jiri Slaby <jslaby(a)suse.com> --- And also attach output of lspci -vnn. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208944] Kernel 6.2.0-1-default does not boot on tumbleweed
by bugzilla_noreply＠suse.com 08 Mar '23

08 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208944 https://bugzilla.suse.com/show_bug.cgi?id=1208944#c10 --- Comment #10 from Jiri Slaby <jslaby(a)suse.com> --- (In reply to Jiri Slaby from comment #9) > Is 6.1.x broken the same way if you artificially disable mmconfig using > nommconf kernel parameter? pci=nommconf that is. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208944] Kernel 6.2.0-1-default does not boot on tumbleweed
by bugzilla_noreply＠suse.com 08 Mar '23

08 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208944 https://bugzilla.suse.com/show_bug.cgi?id=1208944#c9 Jiri Slaby <jslaby(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(kesang.neljor@yah | |oo.com) --- Comment #9 from Jiri Slaby <jslaby(a)suse.com> --- Other than mmconfig disabled and lockdown changes, I see nothing obvious: +efi: Remove mem92: MMIO range=[0xc0000000-0xcfffffff] (256MB) from e820 map +e820: remove [mem 0xc0000000-0xcfffffff] reserved -LSM: Security Framework initializing +LSM: initializing lsm=lockdown,capability,integrity,apparmor -PCI: MMCONFIG at [mem 0xc0000000-0xce0fffff] reserved in E820 +PCI: not using MMCONFIG -ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) +ata1: SATA link down (SStatus 4 SControl 300) But lockdown was enabled only with 6.2.1 and this failed for you in 6.2.0 already. Is 6.1.x broken the same way if you artificially disable mmconfig using nommconf kernel parameter? There could be also a scsi/block layer bug, of course. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208944] Kernel 6.2.0-1-default does not boot on tumbleweed
by bugzilla_noreply＠suse.com 08 Mar '23

08 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208944 https://bugzilla.suse.com/show_bug.cgi?id=1208944#c8 --- Comment #8 from Jiri Slaby <jslaby(a)suse.com> --- Created attachment 865355 --> https://bugzilla.suse.com/attachment.cgi?id=865355&action=edit dmesg 6.2.1 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208944] Kernel 6.2.0-1-default does not boot on tumbleweed
by bugzilla_noreply＠suse.com 08 Mar '23

08 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208944 https://bugzilla.suse.com/show_bug.cgi?id=1208944#c7 Jiri Slaby <jslaby(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(kesang.neljor@yah | |oo.com) | --- Comment #7 from Jiri Slaby <jslaby(a)suse.com> --- Created attachment 865354 --> https://bugzilla.suse.com/attachment.cgi?id=865354&action=edit dmesg 6.1.8 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209032] New: Keychron K8 kearboard kernel warning: unknown main item tag 0x0
by bugzilla_noreply＠suse.com 08 Mar '23

08 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1209032 Bug ID: 1209032 Summary: Keychron K8 kearboard kernel warning: unknown main item tag 0x0 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Minor Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: mpdesouza(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I'm using a Keychron K8 keyboard connected via Bluetooth using the "Windows compatibility mode", and started seeing this on dmesg: [100376.456869] apple 0005:05AC:024F.001B: unknown main item tag 0x0 [100376.457182] apple 0005:05AC:024F.001B: Non-apple keyboard detected; function keys will default to fnmode=2 behavior [100376.457264] input: Keychron K8 as /devices/pci0000:00/0000:00:14.0/usb2/2-10/2-10:1.0/bluetooth/hci0/hci0:768/0005:05AC:024F.001B/input/input64 [100376.462635] apple 0005:05AC:024F.001B: input,hidraw7: BLUETOOTH HID v1.07 Keyboard [Keychron K8] on d4:54:8b:88:20:42 I'm running an updates TW system, kernel 6.2.1-1-default. I started to check the hid-core, on hid_parser_main: ... switch (item->tag) { case HID_MAIN_ITEM_TAG_BEGIN_COLLECTION: ret = open_collection(parser, data & 0xff); break; case HID_MAIN_ITEM_TAG_END_COLLECTION: ret = close_collection(parser); break; case HID_MAIN_ITEM_TAG_INPUT: ret = hid_add_field(parser, HID_INPUT_REPORT, data); break; case HID_MAIN_ITEM_TAG_OUTPUT: ret = hid_add_field(parser, HID_OUTPUT_REPORT, data); break; case HID_MAIN_ITEM_TAG_FEATURE: ret = hid_add_field(parser, HID_FEATURE_REPORT, data); break; default: hid_warn(parser->device, "unknown main item tag 0x%x\n", item->tag); ret = 0; } ... But I don't know the HID protocols in order to detect what is the issue. I can only check that, all these case statements search for a value that is bigger than 0, actually values from 8 to 12. Please let me know if I can provide more information to understand what's going on. Thanks -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1209006] Document how to secureboot-sign manually-built kernel modules on TW kernel >= 6.2.1
by bugzilla_noreply＠suse.com 07 Mar '23

07 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c8 Stefan Dirsch <sndirsch(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |epistemepromeneur(a)free.fr --- Comment #8 from Stefan Dirsch <sndirsch(a)suse.com> --- *** Bug 1208939 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209006] Document how to secureboot-sign manually-built kernel modules on TW kernel >= 6.2.1
by bugzilla_noreply＠suse.com 07 Mar '23

07 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c7 Stefan Dirsch <sndirsch(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |brunopitrus(a)hotmail.com --- Comment #7 from Stefan Dirsch <sndirsch(a)suse.com> --- *** Bug 1208966 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209006] Document how to secureboot-sign manually-built kernel modules on TW kernel >= 6.2.1
by bugzilla_noreply＠suse.com 07 Mar '23

07 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c6 --- Comment #6 from Michal Suchanek <msuchanek(a)suse.com> --- On Leap we don't need the secondary keyring at all, we have a downstream patch that loads the MOK keys into platform keyring, and verifies modules with platform keyring. In upstream the MOK keys are loaded into machine keyring which then should get loaded into secondary keyring. This option is for loading additional keys (which the name does not reflect) in a specific way different from the default (which the name does not reflect) and is incompatible with machine keyring (which would have to be patched out to enable it). Does not seem to work for me, anyway: cat /proc/keys | grep machine 31db47ec I------ 1 perm 1f0b0000 0 0 keyring .machine: empty -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209006] Document how to secureboot-sign manually-built kernel modules on TW kernel >= 6.2.1
by bugzilla_noreply＠suse.com 07 Mar '23

07 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c5 --- Comment #5 from Stefan Dirsch <sndirsch(a)suse.com> --- At least on Leap 15.4, where signed kernel modules work, it's set. 15.4 $ zcat /proc/config.gz |grep CONFIG_IMA_KEY CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y whereas on TW it's not. TW $ zcat /proc/config.gz |grep CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY # CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY is not set -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209006] Document how to secureboot-sign manually-built kernel modules on TW kernel >= 6.2.1
by bugzilla_noreply＠suse.com 07 Mar '23

07 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c4 --- Comment #4 from Stefan Dirsch <sndirsch(a)suse.com> --- Michal Suchanek just wrote in the email thread on factory ML --- Shouldn't this be set: config/x86_64/default:# CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY is not set The MOK keys get added to th secondary keyring, not primary. --- Could this be the issue here? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209024] file terminated with sigsys
by bugzilla_noreply＠suse.com 07 Mar '23

07 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209024 https://bugzilla.suse.com/show_bug.cgi?id=1209024#c3 Michal Suchanek <msuchanek(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Michal Suchanek <msuchanek(a)suse.com> --- Works with later kernel: Linux jostaberry-5 6.3.0-rc1-1-kvmsmall+ #1 SMP Tue Mar 7 18:47:04 CET 2023 ppc64le ppc64le ppc64le GNU/Linux file /etc/uefi/certs/1F673297.crt /etc/uefi/certs/1F673297.crt: Certificate, Version=3, Serial=00fabed8bf409a5e65, Issuer=openSUSE Secure Boot CA -- You are receiving this mail because: You are the assignee for the bug.

1 0