November 2024 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1230062] New: RISC-V: virtio-console sometimes gets stuck in set_termios.part.0
by bugzilla_noreply＠suse.com 08 Jan '25

08 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1230062 Bug ID: 1230062 Summary: RISC-V: virtio-console sometimes gets stuck in set_termios.part.0 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: RISC-V OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 877101 --> https://bugzilla.suse.com/attachment.cgi?id=877101&action=edit /proc/*/task/*/stack + strace of bash openQA types in commands to the serial console, sends a newline and then waits until the prompt appears. Running this in a loop causes it to get stuck sometimes: https://openqa.opensuse.org/tests/4445068#step/http_srv/16 In the QEMU chardev log it appears like this: # systemctl --no-pager is-active apache2; echo hjhkw-$?- active hjhkw-0- echo Lorem ipsum dolor sit amet > /srv/www/htdocs/index.html openQA sends 'systemctl --no-pager is-active apache2; echo hjhkw-$?-\n', receives 'active\nhjhkw-0-\n', then sends 'echo Lorem ipsum dolor sit amet > /srv/www/htdocs/index.html\n' and waits for '# '. That does not arrive however and the wait times out. In most cases that's just ignored by openQA and it moves on to the next command. When it sends that ("curl -f ..." here), the missing part suddenly appears: # echo Lorem ipsum dolor sit amet > /srv/www/htdocs/index.html # curl -f http://localhost/ | grep 'Lorem ipsum dolor sit amet'; echo _Z5Xg-$?- This issue appears to happen on riscv64 only, I have not observed it anywhere else so far. Thankfully the arbitrarily long delay of the prompt allows to debug this. I created a testcase that exercises the serial terminal in a loop and so far it always gets stuck before the 20th attempt. I logged onto the graphical console and collected some info. The /bin/bash process on the console is stuck in the kernel: /proc/1624/task/1624/stack:[<0>] set_termios.part.0+0x130/0x206 /proc/1624/task/1624/stack:[<0>] tty_mode_ioctl+0x46e/0x576 /proc/1624/task/1624/stack:[<0>] n_tty_ioctl_helper+0x2a/0xe4 /proc/1624/task/1624/stack:[<0>] n_tty_ioctl+0x9a/0x148 /proc/1624/task/1624/stack:[<0>] tty_ioctl+0x170/0x64e /proc/1624/task/1624/stack:[<0>] __riscv_sys_ioctl+0x82/0xaa /proc/1624/task/1624/stack:[<0>] do_trap_ecall_u+0x200/0x212 /proc/1624/task/1624/stack:[<0>] handle_exception+0xde/0xde FWICT this is inside the "retry_write_wait" loop: https://github.com/torvalds/linux/blob/67784a74e258a467225f0e68335df77acd67… No other process trace has any related tty call pending. When I attached to the process with strace, it immediately continued and the missing output appeared on the serial console. /proc/*/task/*/stack and strace log are attached. The first syscall that strace reports is rt_sigprocmask(SIG_BLOCK, ...), which usually follows ioctl(0, TCSETSW, ...), so it was probably stuck in that ioctl. As it helps to provide more input or attach with strace, it appears like some wakeup signal is missing or got lost that would notify the wait that the write has completed. -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 1229042] New: Enable kernel-default-livepatch-devel for TW since it's already enabled on Leap
by bugzilla_noreply＠suse.com 08 Jan '25

08 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1229042 Bug ID: 1229042 Summary: Enable kernel-default-livepatch-devel for TW since it's already enabled on Leap 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: mpdesouza(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Remove the condition that currently only applies to openSUSE Tumbleweed. -- You are receiving this mail because: You are the assignee for the bug.

1 27

[Bug 1211761] New: vtty[1-6] nouveau framebuffers produce vast snow/raster on right and bottom border areas on the larger resolution of two displays, in the absence of both plymouth and video= on linu lines
by bugzilla_noreply＠suse.com 02 Jan '25

02 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1211761 Bug ID: 1211761 Summary: vtty[1-6] nouveau framebuffers produce vast snow/raster on right and bottom border areas on the larger resolution of two displays, in the absence of both plymouth and video= on linu lines Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 URL: https://bugzilla.kernel.org/show_bug.cgi?id=217479 ; https://gitlab.freedesktop.org/drm/nouveau/-/issues/21 4 OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: mrmazda(a)earthlink.net QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Original Summary: vtty[1-6] nouveau framebuffers produce vast snow/raster on right and bottom border areas on the larger resolution of two displays, in the absence of both plymouth and video= on linu lines FTR: Upstream bugs: https://bugzilla.kernel.org/show_bug.cgi?id=217479 (includes most detail, w/ dmesg) https://gitlab.freedesktop.org/drm/nouveau/-/issues/214 To reproduce: 1-connect two unequal native resolution displays to a Tesla or Firmi GPU 2-don't have plymouth in use (I don't ever have it installed, so don't know whether it impacts) 3-don't include e.g. video=1440x900@60 directive on Grub's linu lines 4-boot TW 5-switch to a vtty, e.g. Ctrl-Alt-F3 Actual behavior: 1-Both displays utilize the resolution (same pixel grid) of the lower resolution display 2-Lower resolution display behaves as expected (light text on black background) 3-Higher resolution display uses same pixels as lower resolution display, with light text on black background, leaving right side and bottom raster instead of black Expected behavior: 1-Both displays utilize the resolution (same pixel grid) of the lower resolution display 2-Lower resolution display behaves as expected 3-Entire higher resolution display's background is black instead of portions in raster Workaround: add e.g. video=1440x900@60 to Grub's linu lines, which causes both displays to use the same nominal mode on the full display space. Occurs with TW 6.3.2, 6.2.12 & 6.2.4 kernel-default, and with 6.2.15 on Fedora 38 and Mageia 9. Does not occur with TW 6.1.12 kernel-default on NVidia, or with AMD Caicos (Terascale2) GPU, or with Intel Eaglelake GPU. Tested only on legacy booting (no UEFI support). Others might describe what I call "raster" as multicolored snow. nosimplefb=1 doesn't change anything. -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 1227749] New: Orange PI 5 Plus limited functionality
by bugzilla_noreply＠suse.com 02 Jan '25

02 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1227749 Bug ID: 1227749 Summary: Orange PI 5 Plus limited functionality Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: aaron.w2(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 876046 --> https://bugzilla.suse.com/attachment.cgi?id=876046&action=edit idbloader for Orange PI 5 Plus I managed to get U-Boot running on the Orange PI 5 Plus with a couple of key SUSE patches to the point where it is booting into OpenSUSE AARCH64 Rockchip version. Currently only the following are working: - PCIe - NVME - eMMC/SD - Serial port The following are not working: - USB - Realtek RTL8125 2.5G Ethernet drivers (seen on PCIe bus) - Realtek RTL8852BE (seen on PCIe bus, not driver seems to be available) Note that in U-Boot that USB also does not work and the network cards are not supported (as of 7/15). I am attaching my U-Boot and idbloader for this board which should allow it to boot, use the usual offset 64 for the idbloader and offset 16384 for U-Boot. -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 1222902] New: Monitor detection fails after hard reset
by bugzilla_noreply＠suse.com 02 Jan '25

02 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1222902 Bug ID: 1222902 Summary: Monitor detection fails after hard reset 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: david.mulder(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- After a hard reset (laptop locked up when I tried to suspend it), my external monitors are no longer detected. I've seen this happen 3 times in as many weeks (on several recent versions of TW), and the only solution I've found is reinstalling TW. > sudo hwinfo --monitor 45: None 00.0: 10002 LCD Monitor [Created at monitor.125] Unique ID: rdCR.iVNqLoWlvi7 Parent ID: _Znp.TcrQYGYoBS2 Hardware Class: monitor Model: "BOE CQ LCD Monitor" Vendor: BOE "BOE CQ" Device: eisa 0x0a7d Serial ID: "0" Resolution: 1920x1200@60Hz Size: 345x215 mm Year of Manufacture: 2021 Week of Manufacture: 27 Detailed Timings #0: Resolution: 1920x1200 Horizontal: 1920 1968 2000 2140 (+48 +80 +220) -hsync Vertical: 1200 1203 1209 1260 (+3 +9 +60) +vsync Frequencies: 161.79 MHz, 75.60 kHz, 60.00 Hz Driver Info #0: Max. Resolution: 1920x1200 Vert. Sync Range: 40-60 Hz Hor. Sync Range: 76-76 kHz Bandwidth: 161 MHz Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #39 (VGA compatible controller) -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1219522] New: Kernel panic with 6.7.x version
by bugzilla_noreply＠suse.com 30 Dec '24

30 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1219522 Bug ID: 1219522 Summary: Kernel panic with 6.7.x version 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: e.kleinmentink(a)zonnet.nl QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 872422 --> https://bugzilla.suse.com/attachment.cgi?id=872422&action=edit dmesg 6.6.11-1 kernel I get a kernel panic since the 6.7.x kernels. The capslock key is flickering and if i use the "recovery mode" i usually see: [T8] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.16, id: 0x1e2b1, caps: 0xf01fa3/0x940300/0x12e800/0x400000, board id: 3276, fw id: 2700068 [T8] psmouse serio1: synaptics: serio: Synaptics pass-through port at isa0060/serio1/input0 [T8] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input2 I have no idea how to debug this. No error message. In the past i applied a kernel bisect (for debian i think) but i could not find a guide for Tumbleweed. Hardware: Lenovo T580 Grub menu contains: * 6.7.2-1 * 6.7.1-2 * 6.6.11-1 Included a "dmesg" output of a normal boot with the "6.6.11-1" kernel. -- You are receiving this mail because: You are the assignee for the bug.

1 25

[Bug 1220119] New: Some tests on o3 triggers dmesg "clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large:"
by bugzilla_noreply＠suse.com 27 Dec '24

27 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1220119 Bug ID: 1220119 Summary: Some tests on o3 triggers dmesg "clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large:" 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 CC: jwiesner(a)suse.com Target Milestone: --- Found By: --- Blocker: --- Some tests running on o3 (openQA instance on https://openqa.opensuse.org/) triggers in dmesg. All tests run in VM via qemu. This is on x86_64 on my private openQA worker by ltp_net_tcp_cmds, triggered for 2 tests: arp and host (both tests did not fail): OpenQA::run_ltp.pm: Starting ipneigh01_arp [ 410.818828][ C0] clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large: [ 410.820365][ C0] clocksource: 'kvm-clock' wd_nsec: 506724586 wd_now: 610448443a wd_last: 60e6144350 mask: ffffffffffffffff [ 410.821824][ C0] clocksource: 'tsc' cs_nsec: 49302930542 cs_now: 17c1364ba0a cs_last: 153fdc32526 mask: ffffffffffffffff [ 410.823293][ C0] clocksource: Clocksource 'tsc' skewed 48796205956 ns (48796 ms) over watchdog 'kvm-clock' interval of 506724586 ns (506 ms) [ 410.824843][ C0] clocksource: 'kvm-clock' (not 'tsc') is current clocksource. [ 410.825707][ C0] tsc: Marking TSC unstable due to clocksource watchdog [ 411.109710][T28135] Initializing XFRM netlink socket OpenQA::run_ltp.pm: Starting ipneigh01_ip OpenQA::run_ltp.pm: Starting arping01 OpenQA::run_ltp.pm: Starting clockdiff01 OpenQA::run_ltp.pm: Starting ftp OpenQA::run_ltp.pm: Starting host [ 410.818845][ C0] clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large: [ 410.820687][ C0] clocksource: 'kvm-clock' wd_nsec: 506741379 wd_now: 61044885d3 wd_last: 60e6144350 mask: ffffffffffffffff [ 410.821794][ C0] clocksource: 'tsc' cs_nsec: 804834172 cs_now: 154a546a082 cs_last: 153fdc32526 mask: ffffffffffffffff [ 410.822919][ C0] clocksource: Clocksource 'tsc' skewed 298092793 ns (298 ms) over watchdog 'kvm-clock' interval of 506741379 ns (506 ms) [ 410.824088][ C0] clocksource: 'kvm-clock' (not 'tsc') is current clocksource. [ 410.824768][ C0] tsc: Marking TSC unstable due to clocksource watchdog [ 411.126759][T28138] Initializing XFRM netlink socket Also, originally I noted this on ltp_net_tcp_cmds running on ppc64le on o3 (kernel tests in https://openqa.opensuse.org/group_overview/32) where host test keeps failing (but arp test is working), I don't see it on ltp_net_tcp_cmds on x86_64 on o3. I was not able to trigger this on VM on my laptop (x86_64). Others found that systemd-networkd test on Tumbleweed on x86_64 (https://openqa.opensuse.org/group_overview/1) [ 570.754611][ C0] Showing busy workqueues and worker pools: [ 570.755654][ C0] workqueue events: flags=0x0 [ 570.756580][ C0] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 [ 570.756586][ C0] pending: drm_fb_helper_damage_work [ 570.759551][ C0] sysrq: Show Blocked State zDBFr-0- [ 311.682306][ C0] clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large: [ 311.684482][ C0] clocksource: 'kvm-clock' wd_nsec: 621509306 wd_now: 49d9caac63 wd_last: 49b4bf31a9 mask: ffffffffffffffff [ 311.686513][ C0] clocksource: 'tsc' cs_nsec: 952336665 cs_now: a3a422af12 cs_last: a327415f8e mask: ffffffffffffffff [ 311.688559][ C0] clocksource: Clocksource 'tsc' skewed 330827359 ns (330 ms) over watchdog 'kvm-clock' interval of 621509306 ns (621 ms) [ 311.690452][ C0] clocksource: 'kvm-clock' (not 'tsc') is current clocksource. [ 311.691559][ C0] tsc: Marking TSC unstable due to clocksource watchdog Test runs also on aarch64, but error is not there. Is it a problem of openQA setup? There are other bugs. -- You are receiving this mail because: You are the assignee for the bug.

1 37

[Bug 1233803] New: kernel: ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed
by bugzilla_noreply＠suse.com 22 Dec '24

22 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1233803 Bug ID: 1233803 Summary: kernel: ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed 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: suse.junky(a)t-online.de QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- In the journal of my system I found this error reported: Nov 27 07:14:17 kernel: ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed My system is a Clevo NS70AU laptop with Operating System: openSUSE Tumbleweed 20241125 KDE Plasma Version: 6.2.3 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.0 Kernel Version: 6.11.8-1-default (64-bit) Graphics Platform: X11 Processors: 16 × 13th Gen Intel® Core™ i7-1360P Memory: 62.5 GiB of RAM Graphics Processor: Mesa Intel® Iris® Xe Graphics 1 x USB-A 2.0 1 x USB-A 3.2 Gen2 1 x USB-C 3.2 Gen2 1 x Thunderbolt 4 (USB-C) I could not detect any malfunction so far. If more information is needed please let me know. -- You are receiving this mail because: You are the assignee for the bug.

1 10

[Bug 1212877] New: [RPi4] cannot wake up after suspend triggered
by bugzilla_noreply＠suse.com 17 Dec '24

17 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1212877 Bug ID: 1212877 Summary: [RPi4] cannot wake up after suspend triggered Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: zluo(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 867900 --> https://bugzilla.suse.com/attachment.cgi?id=867900&action=edit yast2 logs ssh to my RPi 4 Model B, later I see following -- p200300ea3707b36b055205817bcf9853:~ # Broadcast message from root@localhost (Fri 2023-06-30 06:03:37 UTC): The system will suspend now! -- then I try to wake it up by hitting keyboard and click on mouse, nothing happened on screen. attache yast2logs. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1233752] New: [Build E.84.3] openQA test fails in trup_smoke
by bugzilla_noreply＠suse.com 09 Dec '24

09 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1233752 Bug ID: 1233752 Summary: [Build E.84.3] openQA test fails in trup_smoke Classification: openSUSE Product: openSUSE Distribution Version: Leap 16.0 Hardware: Other URL: https://openqa.opensuse.org/tests/4657304/modules/trup _smoke/steps/26 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: jslaby(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: openQA Blocker: Yes ## Observation openQA test in scenario microos-Staging:E-Staging-MicroOS-Image-sdboot-x86_64-microos-wizard-tpm@uefi-staging fails in [trup_smoke](https://openqa.opensuse.org/tests/4657304/modules/trup_smoke/st… ## Test suite description Like MicroOS, but use neither combustion nor ignition for the intial configuration, so jeos-firstboot runs. ## Reproducible Fails since (at least) Build [E.84.3](https://openqa.opensuse.org/tests/4657304) (current job) ## Expected result Last good: [E.83.16](https://openqa.opensuse.org/tests/4648526) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=microos… -- You are receiving this mail because: You are the assignee for the bug.

1 37