March 2023 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1207948] Lenovo T14s Gen3 AMD resume from hibernation ends in kernel panic
by bugzilla_noreply＠suse.com 15 Mar '23

15 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1207948 https://bugzilla.suse.com/show_bug.cgi?id=1207948#c35 --- Comment #35 from Takashi Iwai <tiwai(a)suse.com> --- Created attachment 865551 --> https://bugzilla.suse.com/attachment.cgi?id=865551&action=edit A workaround script, put to /usr/lib/systemd/system-sleep/ -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1207948] Lenovo T14s Gen3 AMD resume from hibernation ends in kernel panic
by bugzilla_noreply＠suse.com 15 Mar '23

15 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1207948 https://bugzilla.suse.com/show_bug.cgi?id=1207948#c34 --- Comment #34 from Takashi Iwai <tiwai(a)suse.com> --- The hibernation problem seems known for the upstream devs, but the feature hasn't been implemented properly yet. I took a quick look now, as we've received a test machine here, too; it's not trivial to fix this, unfortunately. ath11k driver has a complex layer, communicating from a PCI device over MHI bus via Qualcomm SoC. And the hibernation code is missing at many places in those pictures. Let's hope that the upstream devs will fix it eventually later. Meanwhile, we can put a patch to reduce the default timeout from 90 seconds to a smaller one, e.g. 5 seconds, for avoiding a kernel panic. And, a simple workaround for this is just to unload and reload at hibernation/resume. You can put a script like below to /usr/lib/systemd/system-sleep directory (with exec bit set). -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209294] New Thinkpad T14s GPU reset/crash with openSUSE Tumbleweed
by bugzilla_noreply＠suse.com 15 Mar '23

15 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1209294 http://bugzilla.opensuse.org/show_bug.cgi?id=1209294#c2 --- Comment #2 from Martin Li��ka <martin.liska(a)suse.com> --- (In reply to Takashi Iwai from comment #1) > Could you verify whether the problem persists with the latest 6.3-rc kernel, > e.g. with the kernel in OBS Kernel:HEAD repo? Heh :) I'm not willing to install an RC kernel on my laptop, so we would need to wait for a proper v6.3 release. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209294] New Thinkpad T14s GPU reset/crash with openSUSE Tumbleweed
by bugzilla_noreply＠suse.com 15 Mar '23

15 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1209294 http://bugzilla.opensuse.org/show_bug.cgi?id=1209294#c1 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.liska(a)suse.com Flags| |needinfo?(martin.liska@suse | |.com) --- Comment #1 from Takashi Iwai <tiwai(a)suse.com> --- Could you verify whether the problem persists with the latest 6.3-rc kernel, e.g. with the kernel in OBS Kernel:HEAD repo? If yes, at best, we should report the issue to the upstream, e.g. gitlab.freedestkop.org Issues. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209294] New Thinkpad T14s GPU reset/crash with openSUSE Tumbleweed
by bugzilla_noreply＠suse.com 15 Mar '23

15 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1209294 Stefan Dirsch <sndirsch(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|sndirsch(a)suse.com |patrik.jakobsson(a)suse.com, | |tiwai(a)suse.com Component|Basesystem |Kernel Assignee|screening-team-bugs(a)suse.de |kernel-bugs(a)opensuse.org -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209221] Leap 15.4, Leap 15.5 and Tumbleweed are not working without attached power supply
by bugzilla_noreply＠suse.com 15 Mar '23

15 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1209221 http://bugzilla.opensuse.org/show_bug.cgi?id=1209221#c8 --- Comment #8 from Volker Hilgert <v.hilgert(a)gmx.net> --- Created attachment 865546 --> http://bugzilla.opensuse.org/attachment.cgi?id=865546&action=edit messages.zip -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209221] Leap 15.4, Leap 15.5 and Tumbleweed are not working without attached power supply
by bugzilla_noreply＠suse.com 15 Mar '23

15 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1209221 http://bugzilla.opensuse.org/show_bug.cgi?id=1209221#c7 --- Comment #7 from Volker Hilgert <v.hilgert(a)gmx.net> --- messages.zip -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209221] Leap 15.4, Leap 15.5 and Tumbleweed are not working without attached power supply
by bugzilla_noreply＠suse.com 15 Mar '23

15 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1209221 http://bugzilla.opensuse.org/show_bug.cgi?id=1209221#c6 --- Comment #6 from Volker Hilgert <v.hilgert(a)gmx.net> --- Created attachment 865545 --> http://bugzilla.opensuse.org/attachment.cgi?id=865545&action=edit hwinfo.zip -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209221] Leap 15.4, Leap 15.5 and Tumbleweed are not working without attached power supply
by bugzilla_noreply＠suse.com 15 Mar '23

15 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1209221 http://bugzilla.opensuse.org/show_bug.cgi?id=1209221#c5 Volker Hilgert <v.hilgert(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS --- Comment #5 from Volker Hilgert <v.hilgert(a)gmx.net> --- Two files attached: messages.zip and hwinfo.zip Test case - Starts Leap 15.5 without connected power supply. Boot process stops. - Plug in the power supply, SDDM appears. Logged in as "normal" user - Disconnect the power supply, USB mouse stops. Touch pad is still working. I installed already the kernel "kernel-default-6.1.12-lp154.2.1.g373f017.x86_64.rpm" during my tests. I will install your proposed kernel version later then. Regards -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208938] Boot fails with kernel 6.2.1-1-default
by bugzilla_noreply＠suse.com 15 Mar '23

15 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208938 https://bugzilla.suse.com/show_bug.cgi?id=1208938#c12 --- Comment #12 from Jiri Slaby <jslaby(a)suse.com> --- May I ask you to test Kernel:HEAD [1] to see if it's upstream or backports-to-6.2 problem? [1] https://download.opensuse.org/repositories/Kernel:/HEAD/standard/ -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1207900] Thinkpad P16 Gen 1 freezes when put into Dockingstation
by bugzilla_noreply＠suse.com 14 Mar '23

14 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1207900 https://bugzilla.suse.com/show_bug.cgi?id=1207900#c12 --- Comment #12 from Michael Vetter <mvetter(a)suse.com> --- I updated today, and with kernel 6.2.2 this notebook doesn't boot at all anymore. A light on the caps lock key is blinking. I booted the previous btrfs snapshot now. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208938] Boot fails with kernel 6.2.1-1-default
by bugzilla_noreply＠suse.com 14 Mar '23

14 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208938 https://bugzilla.suse.com/show_bug.cgi?id=1208938#c10 --- Comment #10 from Martti Laaksonen <martti.laaksonen(a)sci.fi> --- Tested with kernel-default-6.2.6-1.1.gfa1a4c6 from Kernel:stable repo. Seems to work ok without amd_iommu=off kernel parameter. However, with 6.2.6 kernel I did notice this error(?) in the kernel boot messages: [ 9.413585] bender kernel: kfd kfd: amdgpu: Allocated 3969056 bytes on gart [ 9.413642] bender kernel: amdgpu: sdma_bitmap: 3 [ 9.443769] bender kernel: memmap_init_zone_device initialised 524288 pages in 4ms [ 9.443784] bender kernel: amdgpu: HMM registered 2048MB device memory [ 9.443872] bender kernel: kfd kfd: amdgpu: Failed to resume IOMMU for device 1002:15d8 [ 9.444071] bender kernel: kfd kfd: amdgpu: device 1002:15d8 NOT added due to errors With 6.1.12 kernel that error is not present: [ 8.604973] bender kernel: kfd kfd: amdgpu: Allocated 3969056 bytes on gart [ 8.605032] bender kernel: amdgpu: sdma_bitmap: 3 [ 8.632249] bender kernel: memmap_init_zone_device initialised 524288 pages in 4ms [ 8.632266] bender kernel: amdgpu: HMM registered 2048MB device memory [ 8.632419] bender kernel: amdgpu: Topology: Add APU node [0x15d8:0x1002] [ 8.632425] bender kernel: kfd kfd: amdgpu: added device 1002:15d8 -- 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 14 Mar '23

14 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c32 --- Comment #32 from Martin Wilck <martin.wilck(a)suse.com> --- (In reply to Joey Lee from comment #30) > I agree that the upstream solution is complex, and I do not fully understood > the Imputed or Transitive concept in their theory. But I think that those > certificates in db/mok must be differentiated based on functionality > purpose. The trust is not spread from a purpose to other purposes. I agree. Especially the distinction between CA keys and code-signing keys and other "low-level" purposes makes sense (although AFAIK the main reason for making the distinction is that it allows the certificates lower in the chain to be invalidated while the CA remains intact). But I still hold that it the db certificates aren't trusted, you can't trust anything in the system. A malware-infected firmware could have injected false certs, keys, and checksums into the kernel before it even starts. Intel TXT had that concept of a "dynamic root of trust", but TXT wasn't successful, so we're left with the static root of trust, which is the UEFI db, like it or not. Or am I missing something? Do modern TPMs provide us with a way to create a trust relationship which doesn't depend on trusting the firmware? > Using usage extension in certificates to separate different purposes is a > strategy. IMA maintainer uses CA in BasicConstraints, digitalSignature and > keyCertSign to identify CA MOK. And NIAP PPOS certification uses codeSign > extend key usage. That makes sense. But it does not make sense to me that only the CA certs can be loaded into the machine keyring. Normally you provide the full chain of certificates that's necessary to verify any given signature. And the full chain in our case would comprise the code-signing certs as well. > I have applied Eric Snowberg's patch set on v6.2 kernel and tested. I used > the following kernel config, and I got a kernel behavior that is similar > with our downstream patch for modsign: > > ... > > For kernel module sign: > No difference with our downstream patch, all MOKs be add to .machine keyring > and link to .secondary_trusted_keys. So all MOKs can be used to verify > kernel modules. > > For .ima/.evm > All MOKs can be used to verify keys that will go to .ima/.evm keyrings. That sounds good. So we could actually use this setup, at least as long as upstream doesn't enforce CONFIG_INTEGRITY_CA_MACHINE_KEYRING=y. That said, I still fail to understand what MokListTrustedRT is good for. And if we "enable it by default", we might as well just shred it, no? -- 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 14 Mar '23

14 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c31 --- Comment #31 from Michal Suchanek <msuchanek(a)suse.com> --- (In reply to Joey Lee from comment #30) > I agree that the upstream solution is complex, and I do not fully understood > the Imputed or Transitive concept in their theory. But I think that those > certificates in db/mok must be differentiated based on functionality > purpose. The trust is not spread from a purpose to other purposes. And the x509 has purpose flags but the kernel trashes all of them except the CA flag. If it wants to differentiate purposes it needs to store those purpose flags. > > Using usage extension in certificates to separate different purposes is a > strategy. IMA maintainer uses CA in BasicConstraints, digitalSignature and > keyCertSign to identify CA MOK. And NIAP PPOS certification uses codeSign > extend key usage. Which applies to both kexec and module loading, these are both code. Loaded into the same security context even. Yet kernel upstream inexplicably insists on using different keys for these making their scheme unusable for us. If it wants to differentiate kexec and module loading, or modules by different vendors it needs to invent new extension for that. Until such certificate extension exists both kernel and modules are code. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1208938] Boot fails with kernel 6.2.1-1-default
by bugzilla_noreply＠suse.com 14 Mar '23

14 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208938 https://bugzilla.suse.com/show_bug.cgi?id=1208938#c9 --- Comment #9 from Jiri Slaby <jslaby(a)suse.com> --- (In reply to Jiri Slaby from comment #8) > I believe this is: > https://bugzilla.kernel.org/show_bug.cgi?id=216865 > > And it was fixed already. Namely in 6.2.3. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208938] Boot fails with kernel 6.2.1-1-default
by bugzilla_noreply＠suse.com 14 Mar '23

14 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208938 https://bugzilla.suse.com/show_bug.cgi?id=1208938#c8 --- Comment #8 from Jiri Slaby <jslaby(a)suse.com> --- I believe this is: https://bugzilla.kernel.org/show_bug.cgi?id=216865 And it was fixed already. Could you guys retry with the latest kernel? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209221] Leap 15.4, Leap 15.5 and Tumbleweed are not working without attached power supply
by bugzilla_noreply＠suse.com 14 Mar '23

14 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209221 https://bugzilla.suse.com/show_bug.cgi?id=1209221#c4 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai(a)suse.com, | |v.hilgert(a)gmx.net Flags| |needinfo?(v.hilgert(a)gmx.net | |) --- Comment #4 from Takashi Iwai <tiwai(a)suse.com> --- Is Leap 15.x installed on the system? If yes, could you try to install the old Leap 15.4 GM kernel and check whether the behavior is seen? That is, download Leap 15.4 kernel-default, kernel-default-extra and kernel-default-optional packages from http://download.opensuse.org/distribution/leap/15.4/repo/oss/x86_64/ and install them with zypper install --oldpackage option, boot with it and retest. In anyway, please give the hwinfo output. Also the dmesg outputs containing the errors you mentioned. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209221] Leap 15.4, Leap 15.5 and Tumbleweed are not working without attached power supply
by bugzilla_noreply＠suse.com 14 Mar '23

14 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1209221 http://bugzilla.opensuse.org/show_bug.cgi?id=1209221#c3 --- Comment #3 from Andreas Stieger <Andreas.Stieger(a)gmx.de> --- HP have weird behavior on low remaining battery capacity (not the current charge, but detected unreliability). So could be a power management or storage driver/controller issue -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208071] SELinux: restricting kernel_t causes issues for the way we setup Micro
by bugzilla_noreply＠suse.com 14 Mar '23

14 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208071 Johannes Segitz <jsegitz(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|kernel-bugs(a)opensuse.org |jsegitz(a)suse.com -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209221] Leap 15.4, Leap 15.5 and Tumbleweed are not working without attached power supply
by bugzilla_noreply＠suse.com 14 Mar '23

14 Mar '23

1 0

[Bug 1208071] SELinux: restricting kernel_t causes issues for the way we setup Micro
by bugzilla_noreply＠suse.com 14 Mar '23

14 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208071 Chenzi Cao <chcao(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|screening-team-bugs(a)suse.de |kernel-bugs(a)opensuse.org -- 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 13 Mar '23

13 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208944 http://bugzilla.opensuse.org/show_bug.cgi?id=1208944#c17 --- Comment #17 from Pieter Terpstra <kesang.neljor(a)yahoo.com> --- It works on 6.2.5-1.g72ee280-default, meaning booting with both disks! Just had to find out how to dismantle the secure moktil/secureboot layers and turn it of in the BIOS, for some reason this was in the same moment. Thank you so much! -- 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 13 Mar '23

13 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208944 http://bugzilla.opensuse.org/show_bug.cgi?id=1208944#c16 --- Comment #16 from Pieter Terpstra <kesang.neljor(a)yahoo.com> --- Just booted with kernel-default-6.2.2-1.1.x86_64 and it still has the same problem as before. Two day's ago i booted with the kernel-default-6.2.4-1.1.g0532a55.x86_64 from the Kernel:Stable repository and that did not wanted to boot either for a different reason (started with a BIOS or shim screen and than said that it could not load the kernel). -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208362] nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10
by bugzilla_noreply＠suse.com 13 Mar '23

13 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208362 Chenzi Cao <chcao(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Basesystem |Kernel Assignee|screening-team-bugs(a)suse.de |kernel-bugs(a)opensuse.org -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1207915] amdgpu 0000:00:01.0: amdgpu: GPU fault detected: 147 0x00422002 for process sddm-greeter pid 2186 thread sddm-greet:cs0 pid 2193
by bugzilla_noreply＠suse.com 13 Mar '23

13 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1207915 Chenzi Cao <chcao(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|screening-team-bugs(a)suse.de |kernel-bugs(a)opensuse.org -- 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 13 Mar '23

13 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c29 --- Comment #29 from Joey Lee <jlee(a)suse.com> --- (In reply to Jiri Slaby from comment #17) > (In reply to Stefan Dirsch from comment #14) > > > 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 ... > > Ok, this is enough. > > commit 44ca817f15b215421a4c788790dd5351c186d1df (HEAD -> stable, > origin/users/jslaby/stable/for-next) > Author: Jiri Slaby <jslaby(a)suse.cz> > Date: Thu Mar 9 07:01:29 2023 +0100 > > Disable lockdown. (bsc#1209006) > > This somehow doesn't play good wrt to external modules. > > When all is ready again, we can revert this revert. > > > master still have the patchset enabled, we can tune there... I have sent new change to master/for-next. I port the KEYS-Make-use-of-platform-keyring-for-module-signatu.patch patch, and also set CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT=y to detect secure boot. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1189826] New: Severe screen flickering with kernel 5.13.12-1-default and i915
by bugzilla_noreply＠suse.com 12 Mar '23

12 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1189826 Bug ID: 1189826 Summary: Severe screen flickering with kernel 5.13.12-1-default and i915 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: javier(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- My laptop's screen flickers so much with 5.13.12 that it renders my laptop unusable. One workaround is to close and open the lid. After resuming, it works fine - there is no flickering. Booting up from the KDE Live image works fine. I have used the same Tumbleweed version (20210820) as the one I have installed on my laptop. The only difference is that I have an encrypted /home partition on my laptop's SSD. Tested kernels: 5.10.16-1.3: OK 5.11.4-1.3: NON-OK 5.12.12-1: NON-OK 5.13.12-1: NON-OK KDE Plasma 5.22.4 KDE Frameworks 5.85.0 Qt 5.15.2 See the attachments for more details. -- You are receiving this mail because: You are the assignee for the bug.

1 18

[Bug 1209174] New: xhci_hcd errors with kernel 6.2.2
by bugzilla_noreply＠suse.com 12 Mar '23

12 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209174 Bug ID: 1209174 Summary: xhci_hcd errors with kernel 6.2.2 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: opensuse(a)mike.franken.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Today's kernel update to 6.2.2 causes a few xhci_hcd errors on boot: kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Write NO_PASID] Request device [3d:00.0] fault addr 0x0 [fault reason 0x05] PTE Write access is not set kernel: xhci_hcd 0000:3d:00.0: No xhci virt device for slot_id 4 kernel: xhci_hcd 0000:3d:00.0: ERROR Invalid Transfer event kernel: xhci_hcd 0000:3d:00.0: @00000000ffffd000 507d2b50 00000000 24000040 04038001 kernel: xhci_hcd 0000:3d:00.0: No xhci virt device for slot_id 4 kernel: xhci_hcd 0000:3d:00.0: ERROR Invalid Transfer event kernel: xhci_hcd 0000:3d:00.0: @00000000ffffd010 507d3b50 00000000 24000008 04058001 Not sure, if they cause any trouble, but I want to let you know - just in case. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1207837] New: amdgpu: externals displays don't work when booting with plugged in docking station
by bugzilla_noreply＠suse.com 11 Mar '23

11 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1207837 Bug ID: 1207837 Summary: amdgpu: externals displays don't work when booting with plugged in docking station Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: jirib79(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 864672 --> http://bugzilla.opensuse.org/attachment.cgi?id=864672&action=edit dmesg - one with plugged in, other without 6.1.8-3.gbddbb73-default #1 openSUSE Tumbleweed (unreleased) ec01a7011546b1865e0ba429f47535b0e2fbc5e1, but also usual latest TW kernel - Lenovo T14s gen1 - FW: 0.1.42 (latest for 2023-02-01) - no idea if docking statin FW exists and can be updated When Lenonvo T14s Gen1 boots with plugged in USB-C connecting it with 'ThinkPad Hybrid USB-C with USB-A Dock (40AF)' (??) the externals monitors never work. The OS has to be booted with docking station unplugged, then when plugged again external monitors work. But..., after than when suspend is done, after resume the monitors are not active anymore - although visible in `xrandr' output. Steps to reproduce: - the docking station - external monitors (i have two SAMSUNG LF22T450F, HDMI and DP connected) - boot with usb-c cable between the docking station and Lenovo T14s gen1 plugged in Is this related? ---%>--- # tac /root/dmesg.txt | grep -m1 -A 20 -B 40 'Call Trace:' | tac Feb 01 17:47:35 t14s kernel: usb 5-1.1: SerialNumber: 301000001 Feb 01 17:47:35 t14s kernel: amdgpu: [VBLANK]:crtc:0, vupdate-vrr:0, planes:1 Feb 01 17:47:35 t14s kernel: amdgpu: [VBLANK]:crtc:0, vupdate-vrr:0, planes:1 Feb 01 17:47:35 t14s kernel: ------------[ cut here ]------------ Feb 01 17:47:35 t14s kernel: WARNING: CPU: 6 PID: 161 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:3533 update_mst_stream_alloc_table+0x150/0x160 [amdgpu] Feb 01 17:47:35 t14s kernel: Modules linked in: dm_crypt essiv authenc trusted asn1_encoder tee hid_generic usbhid amdgpu crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic gf128mul drm_ttm_helper ttm iommu_v2 ghash_clmulni_intel gpu_sched ehci_pci xhci_pci sha512_ssse3 rtsx_pci_sdmmc xhci_pci_renesas drm_buddy mmc_core drm_display_helper xhci_hcd ehci_hcd aesni_intel ucsi_acpi nvme crypto_simd typec_ucsi cryptd cec usbcore roles nvme_core ccp rtsx_pci sp5100_tco rc_core typec video battery wmi serio_raw btrfs blake2b_generic libcrc32c crc32c_intel xor raid6_pq dm_mirror dm_region_hash dm_log sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua ledtrig_timer msr efivarfs Feb 01 17:47:35 t14s kernel: CPU: 6 PID: 161 Comm: kworker/6:1 Tainted: G W 6.1.8-3.gbddbb73-default #1 openSUSE Tumbleweed (unreleased) ec01a7011546b1865e0ba429f47535b0e2fbc5e1 Feb 01 17:47:35 t14s kernel: Hardware name: LENOVO 20UJS2B901/20UJS2B901, BIOS R1CET73W(1.42 ) 12/09/2022 Feb 01 17:47:35 t14s kernel: Workqueue: events_long drm_dp_mst_link_probe_work [drm_display_helper] Feb 01 17:47:35 t14s kernel: RIP: 0010:update_mst_stream_alloc_table+0x150/0x160 [amdgpu] Feb 01 17:47:35 t14s kernel: Code: 00 00 75 2d 48 81 c4 98 00 00 00 5b 5d 41 5c e9 16 da ad d5 41 0f b7 40 04 4d 89 19 49 89 59 08 66 41 89 41 10 e9 71 ff ff ff <0f> 0b e9 fe fe ff ff e8 c4 01 83 d5 0f 1f 40 00 0f 1f 44 00 00 55 Feb 01 17:47:35 t14s kernel: RSP: 0018:ffffb7ce0073f678 EFLAGS: 00010202 Feb 01 17:47:35 t14s kernel: RAX: 0000000000000002 RBX: 0000000000000000 RCX: 0000000000000000 Feb 01 17:47:35 t14s kernel: RDX: 0000000000000000 RSI: ffffb7ce0073f678 RDI: ffffb7ce0073f708 Feb 01 17:47:35 t14s kernel: RBP: ffff9826d5e00aa0 R08: ffffb7ce0073f738 R09: ffffb7ce0073f480 Feb 01 17:47:35 t14s kernel: R10: ffff9826c7edb000 R11: ffff9826dd3037e0 R12: 0000000000000002 Feb 01 17:47:35 t14s kernel: R13: ffff9826d8701000 R14: ffffffffc188d8e0 R15: 0000000000000000 Feb 01 17:47:35 t14s kernel: FS: 0000000000000000(0000) GS:ffff9829bf980000(0000) knlGS:0000000000000000 Feb 01 17:47:35 t14s kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Feb 01 17:47:35 t14s kernel: CR2: 00007effc2b12440 CR3: 0000000295010000 CR4: 0000000000350ee0 Feb 01 17:47:35 t14s kernel: Call Trace: Feb 01 17:47:35 t14s kernel: <TASK> Feb 01 17:47:35 t14s kernel: dc_link_allocate_mst_payload+0x95/0x290 [amdgpu 94e1b47238533e7ef69a131fcfbdc0d3832eb584] Feb 01 17:47:35 t14s kernel: core_link_enable_stream+0x7cc/0x980 [amdgpu 94e1b47238533e7ef69a131fcfbdc0d3832eb584] Feb 01 17:47:35 t14s kernel: ? optc1_set_drr+0x136/0x1e0 [amdgpu 94e1b47238533e7ef69a131fcfbdc0d3832eb584] Feb 01 17:47:35 t14s kernel: dce110_apply_ctx_to_hw+0x652/0x700 [amdgpu 94e1b47238533e7ef69a131fcfbdc0d3832eb584] Feb 01 17:47:35 t14s kernel: dc_commit_state_no_check+0x38c/0xc90 [amdgpu 94e1b47238533e7ef69a131fcfbdc0d3832eb584] Feb 01 17:47:35 t14s kernel: dc_commit_state+0x92/0x110 [amdgpu 94e1b47238533e7ef69a131fcfbdc0d3832eb584] Feb 01 17:47:35 t14s kernel: amdgpu_dm_atomic_commit_tail+0x4a0/0x2a80 [amdgpu 94e1b47238533e7ef69a131fcfbdc0d3832eb584] Feb 01 17:47:35 t14s kernel: ? get_page_from_freelist+0x4d9/0x1590 Feb 01 17:47:35 t14s kernel: ? dcn21_fast_validate_bw+0x3be/0x490 [amdgpu 94e1b47238533e7ef69a131fcfbdc0d3832eb584] Feb 01 17:47:35 t14s kernel: ? dcn21_validate_bandwidth_fp+0x101/0x6d0 [amdgpu 94e1b47238533e7ef69a131fcfbdc0d3832eb584] Feb 01 17:47:35 t14s kernel: ? __alloc_pages+0xec/0x240 Feb 01 17:47:35 t14s kernel: ? __get_random_u32_below+0x12/0x60 Feb 01 17:47:35 t14s kernel: ? allocate_slab+0x255/0x490 Feb 01 17:47:35 t14s kernel: ? drm_atomic_helper_setup_commit+0x4c7/0x840 Feb 01 17:47:35 t14s kernel: ? dma_resv_iter_first_unlocked+0x62/0x70 Feb 01 17:47:35 t14s kernel: ? dma_resv_get_fences+0x52/0x210 Feb 01 17:47:35 t14s kernel: ? wait_for_completion_timeout+0x112/0x140 Feb 01 17:47:35 t14s kernel: commit_tail+0x94/0x130 Feb 01 17:47:35 t14s kernel: drm_atomic_helper_commit+0x112/0x140 Feb 01 17:47:35 t14s kernel: drm_atomic_commit+0x77/0xf0 Feb 01 17:47:35 t14s kernel: ? drm_plane_get_damage_clips.cold+0x1c/0x1c Feb 01 17:47:35 t14s kernel: drm_client_modeset_commit_atomic+0x1e7/0x230 Feb 01 17:47:35 t14s kernel: drm_client_modeset_commit_locked+0x56/0x160 Feb 01 17:47:35 t14s kernel: drm_client_modeset_commit+0x21/0x40 Feb 01 17:47:35 t14s kernel: drm_fb_helper_set_par+0x9e/0xe0 Feb 01 17:47:35 t14s kernel: drm_fb_helper_hotplug_event+0x9f/0xe0 Feb 01 17:47:35 t14s kernel: drm_kms_helper_hotplug_event+0x26/0x30 Feb 01 17:47:35 t14s kernel: process_one_work+0x20f/0x3d0 Feb 01 17:47:35 t14s kernel: worker_thread+0x4a/0x3b0 Feb 01 17:47:35 t14s kernel: ? process_one_work+0x3d0/0x3d0 Feb 01 17:47:35 t14s kernel: kthread+0xda/0x100 Feb 01 17:47:35 t14s kernel: ? kthread_complete_and_exit+0x20/0x20 Feb 01 17:47:35 t14s kernel: ret_from_fork+0x22/0x30 Feb 01 17:47:35 t14s kernel: </TASK> Feb 01 17:47:35 t14s kernel: ---[ end trace 0000000000000000 ]--- Feb 01 17:47:35 t14s kernel: amdgpu: [VBLANK]:crtc:0, vupdate-vrr:0, planes:1 Feb 01 17:47:35 t14s kernel: amdgpu: [VBLANK]:crtc:0, vupdate-vrr:0, planes:1 Feb 01 17:47:36 t14s kernel: [HDCP_TOP]: Feb 01 17:47:36 t14s kernel: [HDCP_TOP]:[Link 0] mod_hdcp_add_display display 4 ---%<--- -- You are receiving this mail because: You are the assignee for the bug.

1 9

[Bug 1206995] system fails to boot to gui with USB-C dock with all kernels > 6.1.0
by bugzilla_noreply＠suse.com 11 Mar '23

11 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1206995 https://bugzilla.suse.com/show_bug.cgi?id=1206995#c11 Sebastian Turza��ski <dpbasti(a)wp.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Sebastian Turza��ski <dpbasti(a)wp.pl> --- works fine with 6.2.1 kernel -- 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 10 Mar '23

10 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208944 http://bugzilla.opensuse.org/show_bug.cgi?id=1208944#c15 --- Comment #15 from Pieter Terpstra <kesang.neljor(a)yahoo.com> --- Thanks! -- 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 10 Mar '23

10 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208944 http://bugzilla.opensuse.org/show_bug.cgi?id=1208944#c14 --- Comment #14 from Felix Miata <mrmazda(a)earthlink.net> --- Kernel 6.2.2 is coming to TW repos soon, but you needn't wait. It's available from http://download.opensuse.org/repositories/Kernel:/stable/standard/x86_64/ by putting http://download.opensuse.org/repositories/Kernel:/stable/standard/Kernel:st… into /etc/zypp/repos.d/, or simply downloading the rpm and installing with zypper or rpm. -- 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 10 Mar '23

10 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208944 https://bugzilla.suse.com/show_bug.cgi?id=1208944#c13 --- Comment #13 from Pieter Terpstra <kesang.neljor(a)yahoo.com> --- If there is any more information i can provide or or anything i can do to solve this bug, please let me know. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208444] 20230216-0 release hardlock
by bugzilla_noreply＠suse.com 10 Mar '23

10 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208444 http://bugzilla.opensuse.org/show_bug.cgi?id=1208444#c11 Scott Bradnick <scott.bradnick(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Scott Bradnick <scott.bradnick(a)suse.com> --- (In reply to Takashi Iwai from comment #10) > The lockdown is (will be) reverted on 6.2.2 kernel. Once after that, with > 6.2.x kernel, the original issue is gone, right? Giving kernel-default-6.2.2-4.1.g3a7e162 a try and everything seems back to normal; I can build nvidia_drm from the .run file as well as the 8852au network module and both load fine. Since my end goal is to use the NVIDIA T1000 card, I'm not going to mess around any more with `prime-select intel` or anything like that to test for those same lockups but it does feel like bbswitch causes this Dell Precision 5540 issue(s) regardless of iGPU or dGPU, but that's for another day. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1207900] Thinkpad P16 Gen 1 freezes when put into Dockingstation
by bugzilla_noreply＠suse.com 10 Mar '23

10 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1207900 https://bugzilla.suse.com/show_bug.cgi?id=1207900#c11 --- Comment #11 from Michael Vetter <mvetter(a)suse.com> --- With kernel 6.2.1-1-default and TW snapshot 20230308 my system doesn't freeze anymore. However it seems to fail to detect the external monitor correctly once I plug in the docking station. Keyboard and mouse work fine. Only notebook monitor is working. When I go to "Displays" in the GNOME settings I can see "unknown device" (or similar) for the external monitor. But not the name as I usually see it. And also I can't active it. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208438] On some i7-8650U Dell Laptops get kernel panic when gui is running.
by bugzilla_noreply＠suse.com 10 Mar '23

10 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208438 https://bugzilla.suse.com/show_bug.cgi?id=1208438#c11 --- Comment #11 from Larry Rainey <llrainey15(a)gmail.com> --- No easy way. The bug was in the CPU mask and effects about 25% of the 7th and 8th gen CPU's. Per intel the GPU is supposed to have 4 power states and one of them is supposed to go to low power and fails to come back to full running fast enough and drops commands - thus Kernel Panic. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1207554] openSUSE Tumbleweed 20230123 doesn't boot after installation on Intel RST VMD volume
by bugzilla_noreply＠suse.com 10 Mar '23

10 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1207554 Chenzi Cao <chcao(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|screening-team-bugs(a)suse.de |kernel-bugs(a)opensuse.org -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209136] [Build 20230309] yast2-bootloader: unexpected situation found
by bugzilla_noreply＠suse.com 10 Mar '23

10 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209136 Arvin Schnell <aschnell(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Kernel |Basesystem Assignee|kernel-bugs(a)opensuse.org |screening-team-bugs(a)suse.de -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209136] [Build 20230309] yast2-bootloader: unexpected situation found
by bugzilla_noreply＠suse.com 10 Mar '23

10 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209136 Arvin Schnell <aschnell(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|YaST2 |Kernel Assignee|yast2-maintainers(a)suse.de |kernel-bugs(a)opensuse.org QA Contact|jsrain(a)suse.com |qa-bugs(a)suse.de -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208438] On some i7-8650U Dell Laptops get kernel panic when gui is running.
by bugzilla_noreply＠suse.com 10 Mar '23

10 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208438 https://bugzilla.suse.com/show_bug.cgi?id=1208438#c10 --- Comment #10 from Olaf Hering <ohering(a)suse.com> --- Did you find a way to distinguish a variant of a 7490 which works, vs. a variant of a 7490 which fails? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208444] 20230216-0 release hardlock
by bugzilla_noreply＠suse.com 10 Mar '23

10 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208444 https://bugzilla.suse.com/show_bug.cgi?id=1208444#c10 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai(a)suse.com --- Comment #10 from Takashi Iwai <tiwai(a)suse.com> --- The lockdown is (will be) reverted on 6.2.2 kernel. Once after that, with 6.2.x kernel, the original issue is gone, right? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208728] Thinkpad X1 Carbon Gen 10 won't enter S3 sleep on kernel 6
by bugzilla_noreply＠suse.com 10 Mar '23

10 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208728 https://bugzilla.suse.com/show_bug.cgi?id=1208728#c1 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai(a)suse.com, | |victorfuga(a)gmail.com Flags| |needinfo?(victorfuga@gmail. | |com) --- Comment #1 from Takashi Iwai <tiwai(a)suse.com> --- Could you check with the latest 6.2 kernel? IIRC, some Dell machines had a similar problem and they had to be switched rather to "Windows" instead of "Linux", but it was addressed some time later recently. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206995] system fails to boot to gui with USB-C dock with all kernels > 6.1.0
by bugzilla_noreply＠suse.com 10 Mar '23

10 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1206995 https://bugzilla.suse.com/show_bug.cgi?id=1206995#c10 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dpbasti(a)wp.pl, | |tiwai(a)suse.com Flags| |needinfo?(dpbasti(a)wp.pl) --- Comment #10 from Takashi Iwai <tiwai(a)suse.com> --- Does the problem persist with 6.2 kernel? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206995] system fails to boot to gui with USB-C dock with all kernels > 6.1.0
by bugzilla_noreply＠suse.com 10 Mar '23

10 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1206995 Chenzi Cao <chcao(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Basesystem |Kernel Assignee|screening-team-bugs(a)suse.de |kernel-bugs(a)opensuse.org -- 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 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c24 --- Comment #24 from Andreas <opendreas(a)gmail.com> --- (In reply to Stefan Dirsch from comment #23) > It only affects the installer. It's the config file from installation which > is broken (that's what I wanted to test with "Xorg -config > /etc/X11/xorg.conf.install"). We need to update the install media, but this > didn't happen yet for Leap 15.5 Beta obviously. I dond't know the Leap 15.5 > Beta schedule. I can't find any information on this right now. Thank you for the explanation. -- 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 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c23 --- Comment #23 from Stefan Dirsch <sndirsch(a)suse.com> --- It only affects the installer. It's the config file from installation which is broken (that's what I wanted to test with "Xorg -config /etc/X11/xorg.conf.install"). We need to update the install media, but this didn't happen yet for Leap 15.5 Beta obviously. I dond't know the Leap 15.5 Beta schedule. I can't find any information on this right now. -- 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 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c28 --- Comment #28 from Michal Suchanek <msuchanek(a)suse.com> --- If you need those modules loaded in ramdisk then yes. Then again loading the keys is not done at all. Presumably whatever looks up and loads the key on the system could be packed into ramdisk as well if such tool existed. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

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

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c22 Andreas <opendreas(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo? --- Comment #22 from Andreas <opendreas(a)gmail.com> --- (In reply to Stefan Dirsch from comment #21) > Ok. This has already been fixed for current images of sle15sp5, but > apparently not for Leap 15.5 Beta. :-( > > *** This bug has been marked as a duplicate of bug 1207516 *** I didn't quite get it, does this error only affect the installer or does the installed system also have an error? Can you please explain. -- 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 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c27 --- Comment #27 from Martin Wilck <martin.wilck(a)suse.com> --- So dracut would need to support loading such keys with keyctl from the initrd before any modules can be loaded? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1207372] suspend/hibernate broken on Lenovo X1 Extreme Gen5 because of
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1207372 https://bugzilla.suse.com/show_bug.cgi?id=1207372#c3 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |p.heinlein@heinlein-support | |.de, tiwai(a)suse.com Flags| |needinfo?(p.heinlein@heinle | |in-support.de) --- Comment #3 from Takashi Iwai <tiwai(a)suse.com> --- Does the problem persist with the latest 6.2.x kernel? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1207372] suspend/hibernate broken on Lenovo X1 Extreme Gen5 because of
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1207372 Chenzi Cao <chcao(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Basesystem |Kernel Assignee|screening-team-bugs(a)suse.de |kernel-bugs(a)opensuse.org -- 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 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c21 Stefan Dirsch <sndirsch(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Comment #19 is|1 |0 private| | Status|IN_PROGRESS |RESOLVED Resolution|--- |DUPLICATE Flags|needinfo?(opendreas(a)gmail.c | |om) | --- Comment #21 from Stefan Dirsch <sndirsch(a)suse.com> --- Ok. This has already been fixed for current images of sle15sp5, but apparently not for Leap 15.5 Beta. :-( *** This bug has been marked as a duplicate of bug 1207516 *** -- 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 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c20 --- Comment #20 from Andreas <opendreas(a)gmail.com> --- Created attachment 865416 --> http://bugzilla.opensuse.org/attachment.cgi?id=865416&action=edit Xorg.99.log (In reply to Stefan Dirsch from comment #18) > Ok. There is already running one. Please try again with > > Xorg -config /etc/X11/xorg.conf.install -retro :99 > > Then attach /var/log/Xorg.99.log X.Org X Server 1.21.1.4 X Protocol Version 11, Revision 0 Current Operating System: Linux precision 5.14.21-150500.43-default #1 SMP PREEMPT_DYNAMIC Wed Mar 1 05:38:55 UTC 2023 (11cbfa2) x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.43-default root=UUID=3084deeb-b3e4-40cc-a328-20df3960a04e splash=silent preempt=full quiet loglevel=3 security=apparmor mitigations=auto Current version of pixman: 0.40.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.99.log", Time: Thu Mar 9 17:06:17 2023 (++) Using config file: "/etc/X11/xorg.conf.install" (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory "/usr/share/X11/xorg.conf.d" xf86EnableIO: failed to enable I/O ports 0000-03ff (Operation not permitted) MESA-LOADER: failed to open nouveau: /usr/lib64/dri/nouveau_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib64/dri, suffix _dri) failed to load driver: nouveau (EE) (EE) Backtrace: (EE) 0: Xorg (xorg_backtrace+0x65) [0x561218599815] (EE) 1: Xorg (0x5612183d5000+0x1c84e9) [0x56121859d4e9] (EE) 2: /lib64/libpthread.so.0 (0x7fda53fd9000+0x168c0) [0x7fda53fef8c0] (EE) 3: Xorg (InitOutput+0x4be) [0x561218476e3e] (EE) 4: Xorg (0x5612183d5000+0x63d25) [0x561218438d25] (EE) 5: /lib64/libc.so.6 (__libc_start_main+0xef) [0x7fda53c1929d] (EE) 6: Xorg (_start+0x2a) [0x5612184227ca] (EE) (EE) Segmentation fault at address 0x8e (EE) Fatal server error: (EE) Caught signal 11 (Segmentation fault). Server aborting (EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/var/log/Xorg.99.log" for additional information. (EE) (EE) Server terminated with error (1). Closing log file. Abgebrochen -- 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 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 Stefan Dirsch <sndirsch(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |snwint(a)suse.com -- 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 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c18 --- Comment #18 from Stefan Dirsch <sndirsch(a)suse.com> --- Ok. There is already running one. Please try again with Xorg -config /etc/X11/xorg.conf.install -retro :99 Then attach /var/log/Xorg.99.log -- 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 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c17 --- Comment #17 from Andreas <opendreas(a)gmail.com> --- Created attachment 865414 --> http://bugzilla.opensuse.org/attachment.cgi?id=865414&action=edit xorg.conf.install -- 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 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c16 --- Comment #16 from Andreas <opendreas(a)gmail.com> --- Created attachment 865413 --> http://bugzilla.opensuse.org/attachment.cgi?id=865413&action=edit Xorg.0.log (In reply to Stefan Dirsch from comment #14) > Ok. Could you try this in the *installed* sytem, please? > > Xorg -config /etc/X11/xorg.conf.install -retro > Xorg -config /etc/X11/xorg.conf.install -retro _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed _XSERVTransMakeAllCOTSServerListeners: server already running (EE) Fatal server error: (EE) Cannot establish any listening sockets - Make sure an X server isn't already running(EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/home/andreas/.local/share/xorg/Xorg.0.log" for additional information. (EE) (EE) Server terminated with error (1). Closing log file. > Does this crash the Xserver as well? Please attach then /var/log/Xorg.0.log > and /etc/X11/xorg.conf.install No, nothing crashed -- 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 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c15 --- Comment #15 from Andreas <opendreas(a)gmail.com> --- (In reply to Takashi Iwai from comment #13) > (In reply to Andreas from comment #11) > > > Just to be sure, can you check whether you can start the fallback (icewm) > > > session (selected at login on display manager) with the same monitor > > > configuration you've seen the problems on the installer? > > I don't have IceWM installed because I unchecked it before installing Leap. > > It doesn't work well with a 4K display > > Do you mean that icewm can't be started, or it's practically unusable > because of the resolution (too small fonts, etc)? > I asked it just because YaST graphical mode uses icewm without decoration. Yes, because IceWM is unusable. I just tested IceWM on a Leap 15.5 Live image and it works. -- 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 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c14 --- Comment #14 from Stefan Dirsch <sndirsch(a)suse.com> --- Ok. Could you try this in the *installed* sytem, please? Xorg -config /etc/X11/xorg.conf.install -retro Does this crash the Xserver as well? Please attach then /var/log/Xorg.0.log and /etc/X11/xorg.conf.install -- 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 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c13 --- Comment #13 from Takashi Iwai <tiwai(a)suse.com> --- (In reply to Andreas from comment #11) > > Just to be sure, can you check whether you can start the fallback (icewm) > > session (selected at login on display manager) with the same monitor > > configuration you've seen the problems on the installer? > I don't have IceWM installed because I unchecked it before installing Leap. > It doesn't work well with a 4K display Do you mean that icewm can't be started, or it's practically unusable because of the resolution (too small fonts, etc)? I asked it just because YaST graphical mode uses icewm without decoration. > > If this works on the installed system while not on the installer, something > > must be missing in the installer. > Yes, after loading drivers Yast GUI installer fails to start > https://bugzilla.opensuse.org/attachment.cgi?id=865313 > It failback to text mode, but you can only see it on external monitor. > https://bugzilla.opensuse.org/attachment.cgi?id=865315 > After clicking on "OK", Yast appears in text mode, very small with 4K > resolution. This shows the crash of X, core dumped. Something for Stefan, I guess. -- 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 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c12 --- Comment #12 from Andreas <opendreas(a)gmail.com> --- Yast fails to start after an error /usr/lib/Yast2/startup/YaST2.call: line 33: 4009 Aborted This video does not have this error at the 30th second. https://youtu.be/pohDXspaMuE?t=30 -- 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 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c11 --- Comment #11 from Andreas <opendreas(a)gmail.com> --- (In reply to Takashi Iwai from comment #10) > And you're running X11, not Wayland, right? Leap 15.5 with Gnome on X11 and Wayland works well. > Just to be sure, can you check whether you can start the fallback (icewm) > session (selected at login on display manager) with the same monitor > configuration you've seen the problems on the installer? I don't have IceWM installed because I unchecked it before installing Leap. It doesn't work well with a 4K display > If this works on the installed system while not on the installer, something > must be missing in the installer. Yes, after loading drivers Yast GUI installer fails to start https://bugzilla.opensuse.org/attachment.cgi?id=865313 It failback to text mode, but you can only see it on external monitor. https://bugzilla.opensuse.org/attachment.cgi?id=865315 After clicking on "OK", Yast appears in text mode, very small with 4K resolution. At 30 seconds you can see this place with a error in the photo above, but in the video Yast is starting. https://youtu.be/pohDXspaMuE?t=30 > Judging from hwinfo, nouveau is still used. So that should be same as on > installer, at least... Yes, right now I can't use the proprietary nvidia driver on Leap 15.5 https://bugzilla.opensuse.org/show_bug.cgi?id=1209067 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209102] New: Regressions in gitsource between 6.1 and 6.2
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209102 Bug ID: 1209102 Summary: Regressions in gitsource between 6.1 and 6.2 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: jack(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Our performance testing infrastructure has noticed that gitsource benchmark has regressed between 6.1 and 6.2 upstream kernel versions on some machines. It has bisected the regression to commit f1a7941243c1 ("mm: convert mm's rss stats into percpu_counter"). The regression was detected on many machines in our performance testing grid. On pumbaa the difference is very visible: before (9cd6ffa6025) after (f1a7941243c1) Amean User 471.12 * 0.30%* 481.77 * -1.96%* Amean System 244.47 * 0.90%* 269.13 * -9.09%* Amean Elapsed 709.22 * 0.45%* 742.27 * -4.19%* Amean CPU 100.00 ( 0.20%) 101.00 * -0.80%* We can see the biggest difference in the "System time" and still noticeable difference in the "Elapsed time". The benchmark runs 'make test' in a checked-out sources of git (fixed to a particular version) so it is effectively heavily exercising shell scripting and spawning lots of shortlived tasks. So I suspect the setup cost of the percpu counters may be playing role here. -- You are receiving this mail because: You are the assignee for the bug.

1 2

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

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c26 --- Comment #26 from Michal Suchanek <msuchanek(a)suse.com> --- (In reply to Martin Wilck from comment #24) > From > https://lore.kernel.org/all/20220928055900.GT4909@linux-l9pv.suse/t/ > #m3ce7e451f1855d9c432965bb896cb7ce0f89e009: > > > The end-user will now need to enroll two keys. First the CA Key into the MOK and then the leaf cert into the secondary trusted keyring. > > HOW would the user add this leaf cert? I am not getting it. From the PDF At runtime, presumably with keyctl. This is not used in (open)SUSE at all but should be so that you can load official KMPs when running non-official kernel. -- 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 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c25 Stefan Dirsch <sndirsch(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|jslaby(a)suse.com |jlee(a)suse.com --- Comment #25 from Stefan Dirsch <sndirsch(a)suse.com> --- Now that we reverted the lockdown patches, I think we can reassign this to Joey, so he can work on this ... I will be happy to give a test kernel a try with my nvidia KMPs once things are implemented. :-) -- 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 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c24 --- Comment #24 from Martin Wilck <martin.wilck(a)suse.com> --- From https://lore.kernel.org/all/20220928055900.GT4909@linux-l9pv.suse/t/#m3ce7e…: > The end-user will now need to enroll two keys. First the CA Key into the MOK and then the leaf cert into the secondary trusted keyring. HOW would the user add this leaf cert? I am not getting it. From the PDF slides I got the impression that the "Root user" would play a role here, but I couldn't figure out how this would work, in particular how the root user's cert would be added to the kernel. Wrt the general mind set, I agree with Michal. IMO the biggest issue is that IMA is disabled as soon as a .machine keyring is populated. That looks like a political movement of upstream with the intention to deter people from using MoK (and thus, 3rd party modules). Most of the main actors behind the current changes seem be IBM employees, plus the Oracle guy. I guess their intention is to find an upstream-accepted framework that would keep IMA functional while allowing a root of trust outside the kernel itself. If they succeed without breaking the current, _relatively_ easy-to-use way to combine 3rd party modules with distro kernels, we might be able to drop our downstream patches, which would be a good thing. But AFAICS their approach would be harder to use, unless some additonal tooling is invented or incorporated in mokutil. MokListTrustedRT ist just an annoyance. -- 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 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c23 --- Comment #23 from Michal Suchanek <msuchanek(a)suse.com> --- I think that upstream as failing to understand that the transitivity of trust goes both ways. If MS verifies SUSE shim, and SUSE shim accepts enrollment of Joe Users' key then MS transitively verifies enrollment of Joe Users' key. But if Joe User trusts SUSE shim with his key, and MS to verify that SUSE shim Joe User also transitively trusts that MS key. You could enforce some baroque policies that only allow specific keys to be used for verification of specific things but the kernel does not have infrastructure for storing such key purpose information. Until such infrastructure exists key trust is just binary. -- 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 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c22 --- Comment #22 from Michal Suchanek <msuchanek(a)suse.com> --- (In reply to Joey Lee from comment #21) > For reference, kernel upstream's plan of .platform and .machine keyrings is > here: > > keyrings, key usage, and trust models > https://lore.kernel.org/all/20220928055900.GT4909@linux-l9pv.suse/t/ > #m3ce7e451f1855d9c432965bb896cb7ce0f89e009 So there are only questions, no answers. It has been pointed out that the scheme proposed by upstream is inconsistent and broken, and there has been no reply. Upstream is not willing to concern itself with distribution kernel needs, and if we want to use MOK we need to patch the kernel downstream so that using MOK is possible. -- 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 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c20 --- Comment #20 from Martin Wilck <martin.wilck(a)suse.com> --- (In reply to Michal Suchanek from comment #19) > Or just verify everything with the platform keyring. It's trusted for kernel > verification, anyway. Why that distinction? I agree. As noted above, I fail to understand what additional security upstream's MokListTrustedRT buys us. Repeating my previous question, why would anyone put keys into MoK which they don't trust? And while it's somewhat understandable that some people might not want to trust Microsoft's keys in the db (because of general contempt for Microsoft or what not), doing so doesn't provide any extra security, either. After all the firmware has already been verified by just these keys. -- 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 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c19 --- Comment #19 from Michal Suchanek <msuchanek(a)suse.com> --- (In reply to Joey Lee from comment #18) > Hi Martin, > > (In reply to Martin Wilck from comment #16) > > (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 right! I missed the above code when tracing. I have tested .machine > keyring and confirmed that .machine keyring be linked to .secondary keyring > and can be used to verify kernel module. > > First we need run "mokutil --trust-mok" command to request shim to create > MokListTrustedRT for linking .machine keyring to .secondary keying. > > Unfortunately we need shim-15.5 to support MokListTrustedRT, but we only > have Microsoft signed shim-15.4 now. Our shim-15.6 and shim 15.7 is waiting > shim usptream review and Microsoft signing. Or patch this requirement out of the kernel. What's the point anyway? Or just verify everything with the platform keyring. It's trusted for kernel verification, anyway. Why that distinction? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1206224] Dell notebook drains battery during sleep
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1206224 https://bugzilla.suse.com/show_bug.cgi?id=1206224#c44 --- Comment #44 from Michal Svec <msvec(a)suse.com> --- FTR I've been running with 6.1.12-lp154.2.g373f017-default for some time and it seems to work fine. Also 5.14.21-150500.75.ged939b6-default IIRC worked fine. I haven't tried any more recent kernel, though. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206224] Dell notebook drains battery during sleep
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1206224 https://bugzilla.suse.com/show_bug.cgi?id=1206224#c43 --- Comment #43 from Takashi Iwai <tiwai(a)suse.com> --- (In reply to Jan-Marten Br�ggemann from comment #42) > After the Test of your custom kernel (comment 18) didn't fix the problem, > I've tried this with Leap 15.5 beta, hoping that there will be a newer > kernel. But sadly it is a 15.4 kernel, too. Nevertheless I tried standby > over night and lost 74% charge. Leap 15.5 kernel is not Leap 15.4 kernel. Please make sure that you've tested with the right kernel. At best, check the latest build from OBS Kernel:SLE15-SP5 repo. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206224] Dell notebook drains battery during sleep
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1206224 https://bugzilla.suse.com/show_bug.cgi?id=1206224#c42 Jan-Marten Br�ggemann <fussel(a)fusselkater.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(msvec(a)suse.com) | --- Comment #42 from Jan-Marten Br�ggemann <fussel(a)fusselkater.org> --- After the Test of your custom kernel (comment 18) didn't fix the problem, I've tried this with Leap 15.5 beta, hoping that there will be a newer kernel. But sadly it is a 15.4 kernel, too. Nevertheless I tried standby over night and lost 74% charge. -- 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 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c10 --- Comment #10 from Takashi Iwai <tiwai(a)suse.com> --- And you're running X11, not Wayland, right? Just to be sure, can you check whether you can start the fallback (icewm) session (selected at login on display manager) with the same monitor configuration you've seen the problems on the installer? If this works on the installed system while not on the installer, something must be missing in the installer. Judging from hwinfo, nouveau is still used. So that should be same as on installer, at least... -- 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 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c17 --- Comment #17 from Jiri Slaby <jslaby(a)suse.com> --- (In reply to Stefan Dirsch from comment #14) > > 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 ... Ok, this is enough. commit 44ca817f15b215421a4c788790dd5351c186d1df (HEAD -> stable, origin/users/jslaby/stable/for-next) Author: Jiri Slaby <jslaby(a)suse.cz> Date: Thu Mar 9 07:01:29 2023 +0100 Disable lockdown. (bsc#1209006) This somehow doesn't play good wrt to external modules. When all is ready again, we can revert this revert. master still have the patchset enabled, we can tune there... -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[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