November 2023 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1212139] New: [amdgpu]] *ERROR* ring sdma0 timeout
by bugzilla_noreply＠suse.com 24 Dec '23

24 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1212139 Bug ID: 1212139 Summary: [amdgpu]] *ERROR* ring sdma0 timeout Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: monkeyboyted(a)yahoo.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 867453 --> https://bugzilla.suse.com/attachment.cgi?id=867453&action=edit dmesg-mohamed-mehany-steps-reproduce Linux steamdeck.lan 6.4.0-rc5-1.g2cab33e-default #1 SMP PREEMPT_DYNAMIC Sun Jun 4 20:15:10 UTC 2023 (2cab33e) x86_64 x86_64 x86_64 GNU/Linux Step to reproduce. ``` sudo -i echo "low" > /sys/class/drm/card1/device/power_dpm_force_performance_level exit sudo cat /sys/kernel/debug/dri/1/amdgpu_gpu_recover ``` LSB Version: n/a Distributor ID: openSUSE Description: openSUSE Tumbleweed Release: 20230605 Codename: n/a Information for package plasma5-mobile: --------------------------------------- Repository : openSUSE-Tumbleweed-Oss Name : plasma5-mobile Version : 5.27.5-1.1 Arch : x86_64 Vendor : openSUSE Installed Size : 2.3 MiB Installed : Yes Status : out-of-date (version 5.27.4-1.1 installed) Source package : plasma5-mobile-5.27.5-1.1.src Upstream URL : http://www.kde.org/ Summary : Plasma Mobile Description : Plasma shell and components targeted for phones. https://gitlab.freedesktop.org/drm/amd/-/issues/2220#note_1948249 -- You are receiving this mail because: You are the assignee for the bug.

1 12

[Bug 1217344] New: Linux 6.6.1 fails to boot
by bugzilla_noreply＠suse.com 16 Dec '23

16 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1217344 Bug ID: 1217344 Summary: Linux 6.6.1 fails to boot Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: neronio(a)outlook.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- The default 6.6.1 kernel installed on my Tumbleweed system does not boot. Upon selecting it in GRUB, I see: "Loading Linux 6.6.1-1-default ..." "Loading initial ramdisk ..." and the system hangs on this screen forever. My workstation's diagnostic LEDs turn on in a pattern that, according to the service manual, indicates an "other type of failure". The workstation is a Dell T5600. CPU: 2x Intel Xeon E5-2680 (v1) RAM: 8x 8 GB DDR3 1600 MHz GPU: Nvidia NVS510, I'm using nouveau drivers. My kernel cmdline: root=UUID=5136bb35-acaa-4796-b463-8c9ef307025d splash=silent quiet mitigations=auto The latest default 6.5.9 kernel works fine on this machine. I'm available for all kinds of testing/debugging, including kernel recompilation with experimental patches and the like. -- You are receiving this mail because: You are the assignee for the bug.

1 12

[Bug 1213830] New: rather current notebook hw (from 2021) has no deep sleep /sys/power/mem_sleep - desktop hw and really old hw does have it
by bugzilla_noreply＠suse.com 15 Dec '23

15 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1213830 Bug ID: 1213830 Summary: rather current notebook hw (from 2021) has no deep sleep /sys/power/mem_sleep - desktop hw and really old hw does have it Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: x86-64 OS: openSUSE Leap 15.5 Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: abittner(a)opensuse.org QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Hello Opensuse Kernel team, how come that my rather new notebook hardware (hp probook with amd apu, from 2021) does not sleep properly and eats up the battery all the time. barely any difference between when leaving an idle desktop (KDE) sitting around and blanking the screen and when only s2idle sleeping it (lid close, or kde function: sleep) i have tried to make sense of all of this, also reading about the linux folks over at framework-laptop e.g. <https://community.frame.work/t/responded-linux-deep-sleep/2491> all i can find is the value: cat /sys/power/mem_sleep [s2idle] cat /sys/power/state freeze mem disk also added the kernel boot parameter mem_sleep_default=deep command line via yast2 to grub2 or something: ---------- sudo dmesg -e | grep mem_sleep [ +0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.55.7-default root=/dev/mapper/system-root splash=silent resume=/dev/system/swap preempt=full quiet security=apparmor mem_sleep_default=deep mitigations=auto [ +0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.55.7-default root=/dev/mapper/system-root splash=silent resume=/dev/system/swap preempt=full quiet security=apparmor mem_sleep_default=deep mitigations=auto --------------- to sum it up, the system eats away the battery/power at high rates even when sleeping, lid closed etc. how to make this work on leap 15.5 with proper (deep?) memory sleep states and all? is this maybe incompatible with FDE, secureboot? this kernel lockdown stuff? i am not understanding much of this i guess. i am wondering why a really old system and other also older desktop systems just instantly show deep mem_sleep feature activated and working? this system: UEFI ans secureboot system [ +0.109168] smpboot: CPU0: AMD Ryzen 7 5800U with Radeon Graphics (family: 0x19, model: 0x50, stepping: 0x0) full disk encryption on single nvme drive thanks for helping. -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 1212839] New: LTP test cve-2021-22555 setsockopt08.c fails with ENOENT
by bugzilla_noreply＠suse.com 12 Dec '23

12 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1212839 Bug ID: 1212839 Summary: LTP test cve-2021-22555 setsockopt08.c fails with ENOENT 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: petr.vorel(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- LTP test cve-2021-22555 setsockopt08.c fails with ENOENT [1], but it expects EINVAL on mostly all archs on Tumbleweed (all but s390x, i.e. aarch64, ppc64le, x86_64 and x86_64 compiled as 32bit). The test has been failing for very long time (our history goes to 6.3.2 20230517, but it's failing on my VM with 6.2.12-1-default 20230502). When test run more times (200x with -i200 [3]) it fails only on first time, the rest happily have EINVAL. And indeed, when verifying manually on VM, only first run fails dmesg on affected archs contains: [ 1514.789118][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.792200][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.795209][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.798209][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.801190][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.804092][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.807159][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.810210][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.813257][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.816227][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 But when running manually I see on first (failing): [ 208.455124] bpfilter: Loaded bpfilter_umh pid 1223 [ 208.456650] Started bpfilter (this is also in openQA jobs, but earlier, triggered by setsockopt03.c, which runs earlier). And x_tables run is reported on later (successful run): [ 221.292549] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 => Maybe there is a problem with loading x_tables on these 3 archs Interestingly x_tables is loaded on all archs, including s390x (which does not fail) and the same dmesg [4] FYI we stop and disable firewall in openQA install_ltp job (this qcow is then used for LTP tests) [5]: systemctl --no-pager disable firewalld Removed "/etc/systemd/system/multi-user.target.wants/firewalld.service". Removed "/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service". systemctl --no-pager stop firewalld [1] https://openqa.opensuse.org/tests/3390125#step/setsockopt08/7 [2] https://github.com/linux-test-project/ltp/blob/a564d3e1672e9cd7ac302d597ffa… [3] https://openqa.opensuse.org/tests/3391862#step/cve-2021-22555/7 [4] https://openqa.opensuse.org/tests/3380876/file/shutdown_ltp-dmesg.txt [5] https://openqa.opensuse.org/tests/3391842/file/serial_terminal.txt -- You are receiving this mail because: You are the assignee for the bug.

1 11

[Bug 1217512] New: [RPi4] kernel: vc4_hdmi fef00700.hdmi: Could not register PCM component: -517
by bugzilla_noreply＠suse.com 11 Dec '23

11 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1217512 Bug ID: 1217512 Summary: [RPi4] kernel: vc4_hdmi fef00700.hdmi: Could not register PCM component: -517 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 URL: https://openqa.opensuse.org/tests/3760808/modules/jour nal_check/steps/11 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: guillaume.gardet(a)arm.com QA Contact: qa-bugs(a)suse.de CC: ivan.ivanov(a)suse.com Target Milestone: --- Found By: openQA Blocker: Yes ## Observation openQA test in scenario opensuse-Tumbleweed-JeOS-for-RPi-aarch64-jeos@RPi4 fails in [journal_check](https://openqa.opensuse.org/tests/3760808/modules/journal_ch… On Raspberry Pi 4, with latest updates, we now have the following kernel trace in journal: kernel: vc4_hdmi fef00700.hdmi: Could not register PCM component: -517 Related updates: raspberrypi-firmware (2023.04.25 -> 2023.11.21) raspberrypi-firmware-config (2023.04.25 -> 2023.11.21) raspberrypi-firmware-dt (2023.05.02 -> 2023.11.21) ## Test suite description Maintainer: fvogt, mnowak Start JeOS from the HDD image, configure it using the firstboot wizard and then run basic tests. console=tty0 added as needed for aarch64. ## Reproducible Fails since (at least) Build [20231123](https://openqa.opensuse.org/tests/3754946) ## Expected result Last good: [20231122](https://openqa.opensuse.org/tests/3750512) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=aarch64&distri=opensu… -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 1216841] New: [ build 28.1] openQA test fails in fanotify16 (LTP)
by bugzilla_noreply＠suse.com 05 Dec '23

05 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1216841 Bug ID: 1216841 Summary: [ build 28.1] openQA test fails in fanotify16 (LTP) Classification: SUSE Linux Enterprise Server Product: SUSE Linux Enterprise Server 15 SP6 Version: unspecified Hardware: x86-64 URL: https://openqa.opensuse.org/tests/2353240/modules/fano tify16/steps/7 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)suse.de Reporter: wegao(a)suse.com CC: guillaume.gardet(a)arm.com, kernel-bugs(a)opensuse.org, petr.vorel(a)gmail.com, qa-bugs(a)suse.de Depends on: 1199618 Target Milestone: --- Group: SUSE Enterprise Partner Found By: openQA Blocker: Yes I clone issue to 15sp6 since i found this issue not exist on Tumbleweed now, but still exist on latest result for 15sp6, see following openqa job, i suppose some fix need backport to sle15sp6. https://openqa.suse.de/tests/12752058#step/fanotify16/7 +++ This bug was initially created as a clone of Bug #1199618 +++ ## Observation openQA test in scenario opensuse-Tumbleweed-JeOS-for-AArch64-aarch64-jeos-ltp-syscalls@aarch64-HD24G fails in [fanotify16](https://openqa.opensuse.org/tests/2353240/modules/fanotify16/st… Error log: fanotify.h:336: TBROK: fanotify_mark (3, FAN_MARK_ADD, ..., AT_FDCWD, ".") failed: EXDEV (18) Test process returned unkown none zero value (2). Test took approximately 0.581575272008195 seconds Some test output could not be parsed: 9 lines were ignored. ## Test suite description ## Reproducible Fails since (at least) Build [20220302](https://openqa.opensuse.org/tests/2224057) ## Expected result Last good: (unknown) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=aarch64&distri=opensu… -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 1196438] Consider switching to 300HZ default
by bugzilla_noreply＠suse.com 30 Nov '23

30 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1196438 https://bugzilla.suse.com/show_bug.cgi?id=1196438#c19 --- Comment #19 from Dirk Mueller <dmueller(a)suse.com> --- (In reply to Yousaf Kaukab from comment #17) > So for SLE the consensus is to keep CONFIG_HZ=250. I assume you mean SLE15 here? I think the discussion should be open ended with SLE16. > Cyril recommended to keep CONFIG_HZ=250 citing the bug fixed by commit c7fcb99877f9 and Mel > recommended to keep SLE and ALP aligned which implies CONFIG_HZ=250 for ALP > as well. I'm sorry, but that means there can be no progress of anything anywhere ever. But the matter of fact is that we are improving the config continuously based on feedback. > So I agree we should revert the change. Objections? Well, what about the original suggestion to use a value that is evenly divisible for the user space metrics? I checked again, and RHEL9/10 is going with 100 HZ. So if your concern is that the number of tick interrupts is causing performance issues, why not go to the *same* value across all architectures, and pick a value that is evenly divisible by 100 (the userspace HZ)? Like 100? (or 300, for that matter) I picked 300 because it was closest to the original 250 which I thought is the least concern overall. There were no conclusive benchmarks showing it would be a problem. Why can we not run with that to see partner and customer feedback prior release? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196438] Consider switching to 300HZ default
by bugzilla_noreply＠suse.com 30 Nov '23

30 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1196438 https://bugzilla.suse.com/show_bug.cgi?id=1196438#c18 --- Comment #18 from Jiri Slaby <jslaby(a)suse.com> --- (In reply to Yousaf Kaukab from comment #17) > Objections? Just setting a timeout: If not, let me revert TW to 250 after 8th Dec (next Fri). -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196438] Consider switching to 300HZ default
by bugzilla_noreply＠suse.com 29 Nov '23

29 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1196438 https://bugzilla.suse.com/show_bug.cgi?id=1196438#c17 --- Comment #17 from Yousaf Kaukab <yousaf.kaukab(a)suse.com> --- (In reply to Jiri Slaby from comment #11) > So at last, neither ALP nor Leap will adopt 300. So I think we should switch > the TW back to 250 to be consistent with all our other distros. So for SLE the consensus is to keep CONFIG_HZ=250. Cyril recommended to keep CONFIG_HZ=250 citing the bug fixed by commit c7fcb99877f9 and Mel recommended to keep SLE and ALP aligned which implies CONFIG_HZ=250 for ALP as well. So I agree we should revert the change. Objections? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196438] Consider switching to 300HZ default
by bugzilla_noreply＠suse.com 29 Nov '23

29 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1196438 https://bugzilla.suse.com/show_bug.cgi?id=1196438#c16 Yousaf Kaukab <yousaf.kaukab(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |yousaf.kaukab(a)suse.com --- Comment #16 from Yousaf Kaukab <yousaf.kaukab(a)suse.com> --- For the for the sake of completeness I am adding response from Takashi in <87jzt4g3s6.wl-tiwai(a)suse.de> to the internal kernel ML: On 9/5/23 15:15, Takashi Iwai wrote: > FYI, the switch to HZ=300 was done on TW via bsc#1196438. > There were no major performance degrade, but yes, there can be hidden > corner cases like that, so switching HZ is likely no-go for SLE. But > the question is about ALP. If we rather want to be conservative, > HZ=250 can be used as well. OTOH, there are inconsistent HZ values > among all archs on SLE, and that's another point to consider. -- You are receiving this mail because: You are the assignee for the bug.

1 0