December 2022 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1206287] Kernel BUG fs/ext4/inode.c:3627 and kernel BUG at fs/ext4/super.c:493!
by bugzilla_noreply＠suse.com 14 Dec '22

14 Dec '22

https://bugzilla.suse.com/show_bug.cgi?id=1206287 https://bugzilla.suse.com/show_bug.cgi?id=1206287#c4 --- Comment #4 from Jan Kara <jack(a)suse.com> --- So by the "trace" I think Jiri meant the stacktrace. In particular that: kernel: set_page_dirty_lock+0x2e/0x80 kernel: qp_release_pages+0x65/0xf0 [vmw_vmci 5e22bd5b5c5e7589ba0c625c044e209a9cc6e594] kernel: qp_host_unregister_user_memory+0x23/0x80 [vmw_vmci 5e22bd5b5c5e7589ba0c625c044e209a9cc6e594] kernel: vmci_qp_broker_detach+0x19a/0x3f0 [vmw_vmci 5e22bd5b5c5e7589ba0c625c044e209a9cc6e594] kernel: vmci_host_unlocked_ioctl+0x9b/0xb20 [vmw_vmci 5e22bd5b5c5e7589ba0c625c044e209a9cc6e594] kernel: __x64_sys_ioctl+0x90/0xd0 kernel: do_syscall_64+0x5b/0x80 comes from the vmw_vmci driver. Looking at this trace it is pretty clear VMCI driver is actually hitting the problem describe e.g. here: https://patchwork.kernel.org/project/linux-fsdevel/patch/CA+eFSM0U_i+rZH5PR… The problem is that the driver gets page reference with get_user_pages(), then reclaim attempts to reclaim these pages which strips fs private data from these pages and then when pages get dirtied, the filesystem complains. This does not have anything to do with the data=journal mode. The solution to this problem is twofold: 1) VMCI needs to call pin_user_pages() (instead of get_user_pages()) to properly inform MM that it's going to be accessing page contents with some out-of-band method. It also needs to use unpin_user_page() instead of put_page(). 2) Page reclaim needs to avoid stripping page private data from pinned pages (that is work in progress upstream, I guess I can kick that ball a bit further ;)). -- 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 1206321] New: livepatch test klp_tc_8.sh fails: rmmod: ERROR: Module klp_tc_8_4_livepatch is in use
by bugzilla_noreply＠suse.com 14 Dec '22

14 Dec '22

https://bugzilla.suse.com/show_bug.cgi?id=1206321 Bug ID: 1206321 Summary: livepatch test klp_tc_8.sh fails: rmmod: ERROR: Module klp_tc_8_4_livepatch is in use 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: petr.vorel(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- This looks to be some race (does not fail always) [1]. It has been here at least since build 20221123 [2] which has 6.0.8-1.1 (1579d93) (likely before, but older failed logs cleared, it might be just on 6.0.x stable branch). ppc64le version looks to be OK [3]. I was not able to reproduce it on my laptop (6.1.0-rc8-2.g2fb1790-default), nor in my openQA instance [4] (might be related to o3 setup/infrastructure). Logs from openQA run (./klp_tc_8.sh) [5], nothing obvious in dmesg [6]. [19:26:53] Test Case 8: Patch with replace-all [19:26:53] *** Compiling live patches [19:26:53] make: Entering directory '/usr/src/linux-6.0.12-1-obj/x86_64/default' [19:26:54] CC [M] /tmp/live-patch/tc_8/patch_replace-all_1/klp_tc_8_1_livepatch.o [19:26:55] MODPOST /tmp/live-patch/tc_8/patch_replace-all_1/Module.symvers [19:26:55] CC [M] /tmp/live-patch/tc_8/patch_replace-all_1/klp_tc_8_1_livepatch.mod.o [19:26:55] LD [M] /tmp/live-patch/tc_8/patch_replace-all_1/klp_tc_8_1_livepatch.ko [19:26:55] BTF [M] /tmp/live-patch/tc_8/patch_replace-all_1/klp_tc_8_1_livepatch.ko [19:26:55] Skipping BTF generation for /tmp/live-patch/tc_8/patch_replace-all_1/klp_tc_8_1_livepatch.ko due to unavailability of vmlinux [19:26:55] make: Leaving directory '/usr/src/linux-6.0.12-1-obj/x86_64/default' [19:26:55] make: Entering directory '/usr/src/linux-6.0.12-1-obj/x86_64/default' [19:26:56] CC [M] /tmp/live-patch/tc_8/patch_replace-all_2/klp_tc_8_2_livepatch.o [19:26:56] MODPOST /tmp/live-patch/tc_8/patch_replace-all_2/Module.symvers [19:26:56] CC [M] /tmp/live-patch/tc_8/patch_replace-all_2/klp_tc_8_2_livepatch.mod.o [19:26:57] LD [M] /tmp/live-patch/tc_8/patch_replace-all_2/klp_tc_8_2_livepatch.ko [19:26:57] BTF [M] /tmp/live-patch/tc_8/patch_replace-all_2/klp_tc_8_2_livepatch.ko [19:26:57] Skipping BTF generation for /tmp/live-patch/tc_8/patch_replace-all_2/klp_tc_8_2_livepatch.ko due to unavailability of vmlinux [19:26:57] make: Leaving directory '/usr/src/linux-6.0.12-1-obj/x86_64/default' [19:26:57] make: Entering directory '/usr/src/linux-6.0.12-1-obj/x86_64/default' [19:26:58] CC [M] /tmp/live-patch/tc_8/patch_replace-all_3/klp_tc_8_3_livepatch.o [19:26:58] MODPOST /tmp/live-patch/tc_8/patch_replace-all_3/Module.symvers [19:26:58] CC [M] /tmp/live-patch/tc_8/patch_replace-all_3/klp_tc_8_3_livepatch.mod.o [19:26:58] LD [M] /tmp/live-patch/tc_8/patch_replace-all_3/klp_tc_8_3_livepatch.ko [19:26:58] BTF [M] /tmp/live-patch/tc_8/patch_replace-all_3/klp_tc_8_3_livepatch.ko [19:26:58] Skipping BTF generation for /tmp/live-patch/tc_8/patch_replace-all_3/klp_tc_8_3_livepatch.ko due to unavailability of vmlinux [19:26:58] make: Leaving directory '/usr/src/linux-6.0.12-1-obj/x86_64/default' [19:26:58] make: Entering directory '/usr/src/linux-6.0.12-1-obj/x86_64/default' [19:26:59] CC [M] /tmp/live-patch/tc_8/patch_replace-all_4/klp_tc_8_4_livepatch.o [19:27:00] MODPOST /tmp/live-patch/tc_8/patch_replace-all_4/Module.symvers [19:27:00] CC [M] /tmp/live-patch/tc_8/patch_replace-all_4/klp_tc_8_4_livepatch.mod.o [19:27:00] LD [M] /tmp/live-patch/tc_8/patch_replace-all_4/klp_tc_8_4_livepatch.ko [19:27:00] BTF [M] /tmp/live-patch/tc_8/patch_replace-all_4/klp_tc_8_4_livepatch.ko [19:27:00] Skipping BTF generation for /tmp/live-patch/tc_8/patch_replace-all_4/klp_tc_8_4_livepatch.ko due to unavailability of vmlinux [19:27:00] make: Leaving directory '/usr/src/linux-6.0.12-1-obj/x86_64/default' [19:27:00] make: Entering directory '/usr/src/linux-6.0.12-1-obj/x86_64/default' [19:27:01] CC [M] /tmp/live-patch/tc_8/patch_replace-all_5/klp_tc_8_5_livepatch.o [19:27:01] MODPOST /tmp/live-patch/tc_8/patch_replace-all_5/Module.symvers [19:27:01] CC [M] /tmp/live-patch/tc_8/patch_replace-all_5/klp_tc_8_5_livepatch.mod.o [19:27:01] LD [M] /tmp/live-patch/tc_8/patch_replace-all_5/klp_tc_8_5_livepatch.ko [19:27:01] BTF [M] /tmp/live-patch/tc_8/patch_replace-all_5/klp_tc_8_5_livepatch.ko [19:27:01] Skipping BTF generation for /tmp/live-patch/tc_8/patch_replace-all_5/klp_tc_8_5_livepatch.ko due to unavailability of vmlinux [19:27:01] make: Leaving directory '/usr/src/linux-6.0.12-1-obj/x86_64/default' [19:27:01] *** Inserting getpid patch 1 [19:27:02] *** Wait for completion (klp_tc_8_1_livepatch) [19:27:02] *** Inserting getpid patch 2 [19:27:02] *** Wait for completion (klp_tc_8_2_livepatch) [19:27:02] *** Inserting getpid patch 3 [19:27:02] *** Wait for completion (klp_tc_8_3_livepatch) [19:27:02] *** Inserting getpid patch 4 [19:27:02] *** Wait for completion (klp_tc_8_4_livepatch) [19:27:02] *** Inserting getpid patch 5 [19:27:02] *** Wait for completion (klp_tc_8_5_livepatch) [19:27:02] *** Removing getpid patch 1 [19:27:02] *** Removing getpid patch 2 [19:27:02] *** Removing getpid patch 3 [19:27:02] *** Removing getpid patch 4 [19:27:02] rmmod: ERROR: Module klp_tc_8_4_livepatch is in use [19:27:02] *** Removing patches [19:27:02] TEST FAILED while executing 'rmmod "$PATCH_MOD_NAME"' [1] https://openqa.opensuse.org/tests/2947725#next_previous [2] https://openqa.opensuse.org/tests/2899233 [3] https://openqa.opensuse.org/tests/2948060#next_previous [4] http://quasar.suse.cz/tests/1446#next_previous [5] https://openqa.opensuse.org/tests/2947725/file/serial_terminal.txt [6] https://openqa.opensuse.org/tests/2947725/file/serial0.txt -- You are receiving this mail because: You are the assignee for the bug.

1 11

[Bug 1206288] New: "BIOS-provided physical RAM map" changing each boot, breaks suspend-to-disk
by bugzilla_noreply＠suse.com 14 Dec '22

14 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1206288 Bug ID: 1206288 Summary: "BIOS-provided physical RAM map" changing each boot, breaks suspend-to-disk Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Linux Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: draeath(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I recently updated my kernel to "kernel-default-6.0.10-1.1.x86_64" and since then, suspend-to-disk resumption fails with the following: [ 13.325035] PM: Loading and decompressing image data (1158298 pages)... [ 13.325044] Hibernate inconsistent memory map detected! [ 13.325085] PM: hibernation: Image mismatch: architecture specific data [ 13.325114] PM: hibernation: Read 4633192 kbytes in 0.01 seconds (463319.20 MB/s) [ 13.326883] PM: Error -1 resuming [ 13.326890] PM: hibernation: Failed to load image, recovering. A stab in the dark found that the physical RAM map is changing each boot. I found an old kernel bug from many (6?) years ago where this occurred (redhat's bugzilla) so there is precedent for this causing this sort of problem: https://bugzilla.redhat.com/show_bug.cgi?id=1442601 I performed a diff (with git so it can localize where in the line the changes are) of the RAM map dmesg lines: diff --git a/prior-rammap.txt b/current-rammap.txt index ebd9618..ef28665 100644 --- a/prior-rammap.txt +++ b/current-rammap.txt @@ -12,9 +12,9 @@ BIOS-e820: [mem 0x0000000076953000-0x0000000076953fff] reserved BIOS-e820: [mem 0x0000000076954000-0x0000000076954fff] usable BIOS-e820: [mem 0x0000000076955000-0x00000000803fffff] reserved BIOS-e820: [mem 0x00000000ff610000-0x00000000ff64ffff] reserved BIOS-e820: [mem 0x0000000100000000-0x000000047e8[-2c-]{+4b+}fff] usable BIOS-e820: [mem 0x000000047e8[-2d-]{+4c+}000-0x000000047e8[-2d-]{+4c+}fff] ACPI data BIOS-e820: [mem 0x000000047e8[-2e-]{+4d+}000-0x000000047f800fff] usable BIOS-e820: [mem 0x000000047f801000-0x000000047f802fff] reserved BIOS-e820: [mem 0x000000047f803000-0x000000047f824fff] usable BIOS-e820: [mem 0x000000047f825000-0x000000047f82cfff] ACPI NVS I should note, it's not impossible this is a firmware problem. I updated my machine's firmware around the same time. I'm engaging vendor support regarding that. (System76 Darter Pro "darp8" running coreboot 4.17) -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1206084] pynfs fails in test nfs4.0 on x86-64 and aarch64
by bugzilla_noreply＠suse.com 13 Dec '22

13 Dec '22

https://bugzilla.suse.com/show_bug.cgi?id=1206084 https://bugzilla.suse.com/show_bug.cgi?id=1206084#c5 --- Comment #5 from Yong Sun <yosun(a)suse.com> --- The openqa test script use a single command to test them all. Hard to add code to get client number after each test, I'm updating my local TW machine to have a manually test later. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206358] Complete loss of keyboard function with kernel 6.0.12-1
by bugzilla_noreply＠suse.com 13 Dec '22

13 Dec '22

https://bugzilla.suse.com/show_bug.cgi?id=1206358 https://bugzilla.suse.com/show_bug.cgi?id=1206358#c9 --- Comment #9 from Chris Friedmann <friedmann.christopher(a)gmail.com> --- Can confirm that 6.1 from stable repo has the same issue, and that the same parameter fixes it. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206371] New: Perf trace may display bogus timings
by bugzilla_noreply＠suse.com 13 Dec '22

13 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1206371 Bug ID: 1206371 Summary: Perf trace may display bogus timings Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: grasland(a)lal.in2p3.fr QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 863498 --> http://bugzilla.opensuse.org/attachment.cgi?id=863498&action=edit Reproducer You will find attached a simple C program that sleeps in a loop, meant to mimick the behavior of the slurmctld Slurm daemon on which I actually observed the bug. You can compile it and run it with "gcc -std=c99 sleeper.c && ./a.out". While it's running, monitor clock_nanosleep syscalls with "perf trace -e clock_nanosleep", and if you're like me, you will eventually observe bogus timings (though it may take a few seconds and/or multiple runs) : --- [ ... ] 7615.211 (100.191 ms): slurmctld/2280 clock_nanosleep(which_clock: 0, flags: 0, rqtp: 0x7fff25018b60, rmtp: NULL) = 0 7715.414 (100.213 ms): slurmctld/2280 clock_nanosleep(which_clock: 0, flags: 0, rqtp: 0x7fff25018b60, rmtp: NULL) = 0 7815.640 ( ): slurmctld/2280 clock_nanosleep(which_clock: 0, flags: 0, rqtp: 0x7fff25018b60, rmtp: NULL) ... 7915.876 (18446744073709.516 ms): slurmctld/2280 clock_nanosleep(which_clock: 0, flags: 0, rqtp: 0x7fff25018b60, rmtp: NULL) = 0 7915.876 (100.095 ms): slurmctld/2280 ... [continued]: clock_nanosleep()) = 0 8016.012 (100.073 ms): slurmctld/2280 clock_nanosleep(which_clock: 0, flags: 0, rqtp: 0x7fff25018b60, rmtp: NULL) = 0 [ ... ] --- I cannot reproduce this on another system running Tumbleweed, perhaps it has been fixed on newer kernel/perf releases? Or perhaps this is somehow specific to this Leap system in another, unknown way. If I were to bet on a possible explanation, I would wager that perf trace may not correctly handle task CPU migrations, but this is just an educated guess and advice on rigorously debugging this further is very much welcome. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206358] Complete loss of keyboard function with kernel 6.0.12-1
by bugzilla_noreply＠suse.com 13 Dec '22

13 Dec '22

https://bugzilla.suse.com/show_bug.cgi?id=1206358 https://bugzilla.suse.com/show_bug.cgi?id=1206358#c8 --- Comment #8 from Chris Friedmann <friedmann.christopher(a)gmail.com> --- The command line parameter fixes it, thank you! I've never installed a kernel outside of zypper dup, do I simply download the .rpm and install it as normal, then choose the kernel from e.g yast? And is this the best choice to use: kernel-default-6.1.0-1.1.gc3232e1.x86_64.rpm ? Thanks for your help. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206358] Complete loss of keyboard function with kernel 6.0.12-1
by bugzilla_noreply＠suse.com 13 Dec '22

13 Dec '22

https://bugzilla.suse.com/show_bug.cgi?id=1206358 https://bugzilla.suse.com/show_bug.cgi?id=1206358#c7 --- Comment #7 from Jiri Slaby <jslaby(a)suse.com> --- Also can you test 6.1 from Kernel:stable if it is broken the same way? I.e. without the parameter it doesn't work and with the parameter it does. https://download.opensuse.org/repositories/Kernel:/stable/standard/x86_64/ -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206358] Complete loss of keyboard function with kernel 6.0.12-1
by bugzilla_noreply＠suse.com 13 Dec '22

13 Dec '22

https://bugzilla.suse.com/show_bug.cgi?id=1206358 https://bugzilla.suse.com/show_bug.cgi?id=1206358#c6 Jiri Slaby <jslaby(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(friedmann.christo | |pher(a)gmail.com) --- Comment #6 from Jiri Slaby <jslaby(a)suse.com> --- Does this kernel command line parameter fix it: psmouse.synaptics_intertouch=0 ? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206358] Complete loss of keyboard function with kernel 6.0.12-1
by bugzilla_noreply＠suse.com 13 Dec '22

13 Dec '22

https://bugzilla.suse.com/show_bug.cgi?id=1206358 https://bugzilla.suse.com/show_bug.cgi?id=1206358#c5 --- Comment #5 from Jiri Slaby <jslaby(a)suse.com> --- commit 268d3f4435477c819cfac3d63eb68f846ef98788 Refs: v6.0.10-214-g268d3f443547 Author: Aman Dhoot <amandhoot12(a)gmail.com> AuthorDate: Sat Oct 15 20:41:17 2022 -0700 Commit: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> CommitDate: Fri Dec 2 17:43:13 2022 +0100 Input: synaptics - switch touchpad on HP Laptop 15-da3001TU to RMI mode [ Upstream commit ac5408991ea6b06e29129b4d4861097c4c3e0d59 ] The device works fine in native RMI mode, there is no reason to use legacy PS/2 mode with it. -- You are receiving this mail because: You are the assignee for the bug.

1 0