February 2022 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1195118] some kernel modules cannot be loaded if secure boot is enabled
by bugzilla_noreply＠suse.com 09 Feb '22

09 Feb '22

https://bugzilla.suse.com/show_bug.cgi?id=1195118 https://bugzilla.suse.com/show_bug.cgi?id=1195118#c9 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Kernel |Installation Assignee|kernel-bugs(a)opensuse.org |yast2-maintainers(a)suse.de QA Contact|qa-bugs(a)suse.de |jsrain(a)suse.com --- Comment #9 from Takashi Iwai <tiwai(a)suse.com> --- Lukas, the comment 8 looks like a wrong analysis. This bug is in essentially two parts: the real bug that hinders the MOK cert deployment at installation, and the lack of intuitive usage. The package openSUSE-signkey-cert *is* installed as default, so the patterns or whatever choice of package itself works. The actual problem is that the end result is not what we expected due to the bug. The first item, the bug in the installation step, is described in comment 6, and it has to be evaluated by your team, I suppose. This isn't directly related with the kernel itself, but rather how mokutil gets executed at which state. The error indicates some insufficient installation at the mokutil execution time. The rest is rather about the documentation, or some instruction that could be shown in installer or something else. It's an enhancement, and you can take it as a sort of feature request in future products. Again, the kernel plays little role in this regard. So, please take a look at the first problem (comment 6). Once when this gets fixed, we can consider the rest (either more documentation or UI enhancement if really appropriate -- maybe it's better to continue in another bug, though). -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1194345] HP Pavilion Gaming Desktop TG01-2xxx - can only boot with pci=noacpi
by bugzilla_noreply＠suse.com 09 Feb '22

09 Feb '22

https://bugzilla.suse.com/show_bug.cgi?id=1194345 https://bugzilla.suse.com/show_bug.cgi?id=1194345#c18 --- Comment #18 from Gerald Drissner <gerald.drissner(a)gmail.com> --- Unfortunately, yes. I still cannot boot without noapic with kernel 5.16.7 and Nvidia 510.47.03. I will keep trying with every new version. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1195118] some kernel modules cannot be loaded if secure boot is enabled
by bugzilla_noreply＠suse.com 09 Feb '22

09 Feb '22

https://bugzilla.suse.com/show_bug.cgi?id=1195118 https://bugzilla.suse.com/show_bug.cgi?id=1195118#c8 Lukas Ocilka <locilka(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |locilka(a)suse.com Component|Installation |Kernel Assignee|yast2-maintainers(a)suse.de |kernel-bugs(a)opensuse.org QA Contact|jsrain(a)suse.com |qa-bugs(a)suse.de --- Comment #8 from Lukas Ocilka <locilka(a)suse.com> --- From my POV, this is a feature request but with quite some pieces of information missing. Such as: how is this expected to actually work? And moreover what about AutoYaST? There's nobody "in front of the computer". Honestly, it's not very likely that the Installer will contain anything that would stop at the end of installation and ask the user to do something. Most of people want that to "just work" whatever it takes. Maybe the installation proposal could possibly contain something new, but that's in a huge contrast with request to make the installer simpler. Other similar cases, e.g., SSL certificates are solved just by installing the right package, nothing else. Side note: Packages to install are not usually selected by the installer. They depend on the product to install, selected role, requirements coming from user-decisions, etc. So, I believe this should be defined and driven by some Kernel PjM / PO. Reassigning to Kernel for that reason. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1195591] Intel® Wi-Fi 6 AX201 160MHz IwlWifi not include this driver.
by bugzilla_noreply＠suse.com 09 Feb '22

09 Feb '22

https://bugzilla.suse.com/show_bug.cgi?id=1195591 Chenzi Cao <chcao(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Other |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 1193640] [Rocket Lake UHD 730] absent nomodeset, 15.4 alpha installation hard locks at "Starting udev....".
by bugzilla_noreply＠suse.com 09 Feb '22

09 Feb '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1193640 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sweiberg(a)suse.com -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1195706] New: Oops in audit starting with 5.16 due to new openat2 auditing
by bugzilla_noreply＠suse.com 09 Feb '22

09 Feb '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1195706 Bug ID: 1195706 Summary: Oops in audit starting with 5.16 due to new openat2 auditing Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Starting with the first update to 5.16, I started getting Oopses like the following when docker starts up: [ 62.463049] BUG: unable to handle page fault for address: 000000c000b3e9b8 [ 62.463094] #PF: supervisor read access in kernel mode [ 62.463118] #PF: error_code(0x0001) - permissions violation [ 62.463143] PGD 800000011bf99067 P4D 800000011bf99067 PUD 11bf9a067 PMD 800000011d4008e7 [ 62.463179] Oops: 0001 [#1] PREEMPT SMP PTI [ 62.463200] CPU: 1 PID: 4865 Comm: dockerd Kdump: loaded Not tainted 5.16.4-1-default #1 openSUSE Tumbleweed f35df798c13cc3a259a6bf2924380af618948152 [ 62.463260] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014 [ 62.463304] RIP: 0010:audit_filter_rules.constprop.0+0x97e/0x1220 [ 62.463339] Code: 41 21 c5 41 83 7f 18 01 0f 85 5f f7 ff ff e9 65 f9 ff ff 83 f8 05 0f 84 5f 06 00 00 83 f8 06 0f 85 03 02 00 00 49 8b 44 24 40 <48> 8b 00 83 e0 03 0f be 80 c5 5e 65 b6 41 21 c5 eb c7 4d 85 e4 0f [ 62.463409] RSP: 0018:ffffab1b005e7dd0 EFLAGS: 00010246 [ 62.463433] RAX: 000000c000b3e9b8 RBX: 0000000000000001 RCX: 000000000000001f [ 62.463463] RDX: 0000000000000006 RSI: 00000000000001b5 RDI: 00000000c000003e [ 62.463492] RBP: ffff88a306606620 R08: ffff88a301eebaa0 R09: ffff88a30a30c238 [ 62.463522] R10: 0000000040000020 R11: ffff88a301770210 R12: ffff88a31a54c800 [ 62.463551] R13: 000000000000000f R14: 00000000000001b5 R15: ffff88a301eebaa0 [ 62.463580] FS: 00007fd43c94c640(0000) GS:ffff88a37fd00000(0000) knlGS:0000000000000000 [ 62.463613] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 62.463638] CR2: 000000c000b3e9b8 CR3: 000000010f02a002 CR4: 0000000000370ee0 [ 62.463671] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 62.463701] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 62.463730] Call Trace: [ 62.463754] <TASK> [ 62.463775] audit_filter_syscall+0xb0/0x100 [ 62.463799] ? do_sys_openat2+0x81/0x160 [ 62.463820] __audit_syscall_exit+0x69/0xf0 [ 62.463842] syscall_exit_to_user_mode_prepare+0x14d/0x180 [ 62.463870] syscall_exit_to_user_mode+0x9/0x40 [ 62.463903] do_syscall_64+0x69/0x80 [ 62.463926] ? syscall_exit_to_user_mode+0x18/0x40 [ 62.463948] ? do_syscall_64+0x69/0x80 [ 62.463968] ? syscall_exit_to_user_mode+0x18/0x40 [ 62.463991] ? do_syscall_64+0x69/0x80 [ 62.464010] ? do_syscall_64+0x69/0x80 [ 62.464030] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 62.464074] RIP: 0033:0x562f9ebdf64a [ 62.464872] Code: e8 9b 00 fa ff 48 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 4c 8b 54 24 28 4c 8b 44 24 30 4c 8b 4c 24 38 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 40 ff ff ff ff 48 c7 44 24 48 [ 62.466526] RSP: 002b:000000c000b3e8a8 EFLAGS: 00000216 ORIG_RAX: 00000000000001b5 [ 62.467380] RAX: 000000000000000d RBX: 000000c00005e800 RCX: 0000562f9ebdf64a [ 62.468252] RDX: 000000c000b3e9b8 RSI: 000000c000190480 RDI: ffffffffffffff9c [ 62.469104] RBP: 000000c000b3e928 R08: 0000000000000000 R09: 0000000000000000 [ 62.469977] R10: 0000000000000018 R11: 0000000000000216 R12: 0000000000000000 [ 62.470814] R13: 0000000000000001 R14: 0000000000000031 R15: ffffffffffffffff [ 62.471648] </TASK> [ 62.472512] Modules linked in: af_packet iscsi_ibft iscsi_boot_sysfs rfkill snd_hda_codec_generic ledtrig_audio snd_hda_intel intel_rapl_msr intel_rapl_common snd_intel_dspcfg snd_intel_sdw_acpi kvm_intel snd_hda_codec snd_hda_core iTCO_wdt intel_pmc_bxt iTCO_vendor_support snd_hwdep kvm snd_pcm snd_timer qxl irqbypass i2c_i801 snd drm_ttm_helper pcspkr i2c_smbus ttm soundcore lpc_ich virtio_balloon drm_kms_helper tiny_power_button joydev virtio_net net_failover failover cec rc_core button syscopyarea sysfillrect sysimgblt fb_sys_fops drm configfs fuse ip_tables x_tables hid_generic usbhid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd cryptd xhci_pci serio_raw xhci_pci_renesas xhci_hcd usbcore virtio_blk qemu_fw_cfg btrfs blake2b_generic libcrc32c crc32c_intel xor raid6_pq sg virtio_rng [ 62.478895] CR2: 000000c000b3e9b8 After some investigation, I've identified the following commit as the cause: commit 1c30e3af8a79260cdba833a719209b01e6b92300 Author: Richard Guy Briggs <rgb(a)redhat.com> Date: Wed May 19 16:00:21 2021 -0400 audit: add support for the openat2 syscall [...] diff --git a/kernel/auditsc.c b/kernel/auditsc.c index 3f9108101598..8c4335a35274 100644 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@ -63,6 +63,7 @@ #include <linux/fsnotify_backend.h> #include <uapi/linux/limits.h> #include <uapi/linux/netfilter/nf_tables.h> +#include <uapi/linux/openat2.h> #include "audit.h" @@ -183,6 +184,8 @@ static int audit_match_perm(struct audit_context *ctx, int mask) return ((mask & AUDIT_PERM_WRITE) && ctx->argv[0] == SYS_BIND); case AUDITSC_EXECVE: return mask & AUDIT_PERM_EXEC; + case AUDITSC_OPENAT2: + return mask & ACC_MODE((u32)((struct open_how *)ctx->argv[2])->flags); default: return 0; } Where ctx->argv[2] holds a userspace pointer. A small test program using an audit rule of "-w /var/tmp/testfile -k openat2-oops" prints the address of the struct open_how and it matches the faulting address. #include <fcntl.h> #include <linux/openat2.h> #include <sys/syscall.h> #include <unistd.h> #include <stdio.h> long openat2(int dirfd, const char *pathname, struct open_how *how, size_t size) { return syscall(SYS_openat2, dirfd, pathname, how, size); } int main(void) { struct open_how how = { .flags = O_RDONLY|O_DIRECTORY, }; int fd; fprintf(stderr, "&how = %p\n", &how); fd = openat2(AT_FDCWD, "/var/tmp/testfile", &how, sizeof(struct open_how)); perror("openat2"); } $ mkdir /var/tmp/testfile $ ./a.out &how = [address] <crash> I've submitted the report upstream as well. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1188896] "BUG: Bad rss-counter state mm:00000000e555b579 type:MM_FILEPAGES val:-256" during build of cross-epiphany-gcc11-bootstrap
by bugzilla_noreply＠suse.com 08 Feb '22

08 Feb '22

https://bugzilla.suse.com/show_bug.cgi?id=1188896 https://bugzilla.suse.com/show_bug.cgi?id=1188896#c49 --- Comment #49 from LTC BugProxy <bugproxy(a)us.ibm.com> --- ------- Comment From geraldsc(a)de.ibm.com 2022-02-08 14:08 EDT------- (In reply to comment #46) > no, the link is purely internal and the dump was only created using > gdb and the dump-guest-memory script in the qemu repo on a hanging vm that > was stuck for longer. > > will look at the details later for upload if you are interested in that one In the best case, such a dump could at least show the kernel messages, while the rest of it would be useless. However, we previously already had such a dump from a long stuck system, where the kernel log buffer was completely filled with repeating rcu_sched or similar errors, so that it still could not reveal the messages at the time when it all started. It still would be better than nothing, and at least serve as an exercise how to collect and submit a dump :-) The best chance would be the "panic_on_taint=5" kernel parameter approach, although I cannot 100% guarantee that it will work as expected. It was suggested by Fabian in an earlier comment here: "The "bad page state" warning causes a taint, so panic_on_taint=5 should help there. Needs an OBS admin to add that option and get a dump though, or alternatively someone who can reproduce it (somewhat reliably) with osc build --vm-type=kvm." I frankly wasn't aware of that feature myself, but a quick check in the kernel source code seems to confirm that this kernel parameter should trigger a panic on a "bad page state" event (and no other possible kernel taints), at least since kernel 5.8. After that, it should be possible to collect a dump in the same way that you did already. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1188896] "BUG: Bad rss-counter state mm:00000000e555b579 type:MM_FILEPAGES val:-256" during build of cross-epiphany-gcc11-bootstrap
by bugzilla_noreply＠suse.com 08 Feb '22

08 Feb '22

https://bugzilla.suse.com/show_bug.cgi?id=1188896 https://bugzilla.suse.com/show_bug.cgi?id=1188896#c47 --- Comment #47 from Ruediger Oertel <ro(a)suse.com> --- no, the link is purely internal and the dump was only created using gdb and the dump-guest-memory script in the qemu repo on a hanging vm that was stuck for longer. will look at the details later for upload if you are interested in that one -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1188896] "BUG: Bad rss-counter state mm:00000000e555b579 type:MM_FILEPAGES val:-256" during build of cross-epiphany-gcc11-bootstrap
by bugzilla_noreply＠suse.com 08 Feb '22

08 Feb '22

https://bugzilla.suse.com/show_bug.cgi?id=1188896 https://bugzilla.suse.com/show_bug.cgi?id=1188896#c46 --- Comment #46 from LTC BugProxy <bugproxy(a)us.ibm.com> --- ------- Comment From geraldsc(a)de.ibm.com 2022-02-08 12:54 EDT------- (In reply to comment #44) > Thank you for the dump, Rudi! > We have got luck, that nodejs is affected. All with dependencies to > programming languages have got a higher priority at IBM since last year > (because mainframes should also be used for programming stuff). We might be lucky that we finally have a dump, and kernel bug priority is much higher for me than "programming languages". I hope this is a dump triggered by the panic_on_taint=5 setting mentioned earlier, so that it hit right at the "bad page state" warning, and not long after-the-facts. Also, I hope it includes the kernel image with debuginfo, so that it can be analyzed with crash. Otherwise it would probably be pretty useless. > (In reply to Ruediger Oertel from comment #44) > > now the question is just how to get this 610M file out to whoever needs it > There is only Gerald as a kernel developer for SUSE and openSUSE at IBM. > We are sharing our resources. I assume there are defined resources for sharing debug data, however I am not aware of current details. Last time I was told that it works via ftp://support-ftp.us.suse.com/incoming/, would that still be possible? If not, maybe Ihno or Thomas know of other options, but Thomas is on vacation until Feb 18. > I expect, that your referenced link also works via the IBM Bugzilla. > Therefore, this bug report has been the correct place for forwarding this > link. :) That link does not work for me, it gives "Server nor found". -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1194345] HP Pavilion Gaming Desktop TG01-2xxx - can only boot with pci=noacpi
by bugzilla_noreply＠suse.com 08 Feb '22

08 Feb '22

https://bugzilla.suse.com/show_bug.cgi?id=1194345 https://bugzilla.suse.com/show_bug.cgi?id=1194345#c17 --- Comment #17 from Takashi Iwai <tiwai(a)suse.com> --- It seems that kdump can't work in such a case in anyway because the kdump kernel itself isn't reliable. Although we should be able to set up the kdump kernel with a proper option (noapic or whatever), but it's cumbersome. Just to be sure: does the problem persists with the latest 5.16.x kernel? -- You are receiving this mail because: You are the assignee for the bug.

1 0