December 2024 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1234623] New: DPC: RP PIO log size 0 is invalid (quirk needs to be added)
by bugzilla_noreply＠suse.com 20 Jan '25

20 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1234623 Bug ID: 1234623 Summary: DPC: RP PIO log size 0 is invalid (quirk needs to be added) 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: bjorn.lie(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 879176 --> https://bugzilla.suse.com/attachment.cgi?id=879176&action=edit dmesg Hi Kernel people, this bug is mainly a "cosmetic" one that causes a "blip" during boot with plymouth, it has no real impact, but would be nice to have it fix in any case (device id added to quirk list). Kernel 6.11.8-1-default -- ASUSTeK COMPUTER INC. Zenbook UX3402VA_UX3402VA (CPU 13th Gen Intel(R) Core(TM) i5-1340P Raptor Lake) des. 15 11:21:37 localhost kernel: pci 0000:00:07.0: Overriding RP PIO Log Size to 4 des. 15 11:21:37 localhost kernel: pci 0000:00:07.2: DPC: RP PIO log size 0 is invalid Please see closed upstream bug https://bugzilla.kernel.org/show_bug.cgi?id=209943 Closing comment is that new bugs should be filed for "new devices". --- lspci -nn 0000:00:00.0 Host bridge [0600]: Intel Corporation Raptor Lake-P/U 4p+8e cores Host Bridge/DRAM Controller [8086:a707] 0000:00:02.0 VGA compatible controller [0300]: Intel Corporation Raptor Lake-P [Iris Xe Graphics] [8086:a7a0] (rev 04) 0000:00:04.0 Signal processing controller [1180]: Intel Corporation Raptor Lake Dynamic Platform and Thermal Framework Processor Participant [8086:a71d] 0000:00:06.0 System peripheral [0880]: Intel Corporation RST VMD Managed Controller [8086:09ab] 0000:00:07.0 PCI bridge [0604]: Intel Corporation Raptor Lake-P Thunderbolt 4 PCI Express Root Port #0 [8086:a76e] 0000:00:07.2 PCI bridge [0604]: Intel Corporation Raptor Lake-P Thunderbolt 4 PCI Express Root Port #2 [8086:a72f] 0000:00:08.0 System peripheral [0880]: Intel Corporation GNA Scoring Accelerator module [8086:a74f] 0000:00:0a.0 Signal processing controller [1180]: Intel Corporation Raptor Lake Crashlog and Telemetry [8086:a77d] (rev 01) 0000:00:0d.0 USB controller [0c03]: Intel Corporation Raptor Lake-P Thunderbolt 4 USB Controller [8086:a71e] 0000:00:0d.2 USB controller [0c03]: Intel Corporation Raptor Lake-P Thunderbolt 4 NHI #0 [8086:a73e] 0000:00:0d.3 USB controller [0c03]: Intel Corporation Raptor Lake-P Thunderbolt 4 NHI #1 [8086:a76d] 0000:00:0e.0 RAID bus controller [0104]: Intel Corporation Volume Management Device NVMe RAID Controller Intel Corporation [8086:a77f] 0000:00:14.0 USB controller [0c03]: Intel Corporation Alder Lake PCH USB 3.2 xHCI Host Controller [8086:51ed] (rev 01) 0000:00:14.2 RAM memory [0500]: Intel Corporation Alder Lake PCH Shared SRAM [8086:51ef] (rev 01) 0000:00:14.3 Network controller [0280]: Intel Corporation Raptor Lake PCH CNVi WiFi [8086:51f1] (rev 01) 0000:00:15.0 Serial bus controller [0c80]: Intel Corporation Alder Lake PCH Serial IO I2C Controller #0 [8086:51e8] (rev 01) 0000:00:15.1 Serial bus controller [0c80]: Intel Corporation Alder Lake PCH Serial IO I2C Controller #1 [8086:51e9] (rev 01) 0000:00:16.0 Communication controller [0780]: Intel Corporation Alder Lake PCH HECI Controller [8086:51e0] (rev 01) 0000:00:1c.0 PCI bridge [0604]: Intel Corporation Alder Lake PCH-P PCI Express Root Port #9 [8086:51bf] (rev 01) 0000:00:1e.0 Communication controller [0780]: Intel Corporation Alder Lake PCH UART #0 [8086:51a8] (rev 01) 0000:00:1e.2 Serial bus controller [0c80]: Intel Corporation Alder Lake SPI Controller [8086:51aa] (rev 01) 0000:00:1f.0 ISA bridge [0601]: Intel Corporation Raptor Lake LPC/eSPI Controller [8086:519d] (rev 01) 0000:00:1f.3 Multimedia audio controller [0401]: Intel Corporation Raptor Lake-P/U/H cAVS [8086:51ca] (rev 01) 0000:00:1f.4 SMBus [0c05]: Intel Corporation Alder Lake PCH-P SMBus Host Controller [8086:51a3] (rev 01) 0000:00:1f.5 Serial bus controller [0c80]: Intel Corporation Alder Lake-P PCH SPI Controller [8086:51a4] (rev 01) 0000:55:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS525A PCI Express Card Reader [10ec:525a] (rev 01) 10000:e0:06.0 PCI bridge [0604]: Intel Corporation Raptor Lake PCIe 4.0 Graphics Port [8086:a74d] 10000:e1:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller PM9B1 (DRAM-less) [144d:a80b] (rev 02) -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 1233381] New: Tumbleweed won’t recover from sleep. Force shutdown required
by bugzilla_noreply＠suse.com 16 Jan '25

16 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1233381 Bug ID: 1233381 Summary: Tumbleweed won’t recover from sleep. Force shutdown required 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: kosimo(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Once the computer enters sleep it won’t wake up anymore. I have to force a shut down and power it up again. Blank screen, not even cap loks light on the keyboard. ---------------- JJJJJJ =JJJJJJJ OS: openSUSE Tumbleweed x86_64 JJJJ =JJJ JJJJ Kernel: 6.11.7-1-default JJJ =JJJ JJJ Uptime: 1 hour, 1 min JJJJ =JJJ JJJ Packages: 42 (pip), 2744 (rpm), 12 (steam), 6 (flatpak-system) JJJJJJJJJJJJJJJ JJJJ Shell: bash 5.2.37 JJJJJJJJJJJJJJ JJJJ Resolution: 3840x2160 JJJJ JJJJ DE: Plasma 6.2.3 [KF 6.8.0] [Qt 6.8.0] (wayland) JJJJJ= JJJJ WM: kwin_wayland_wr JJJJJJJJJJJJJJJJJJJJJJJJJJJJJ= Theme: Breeze-Dark [GTK2/3] =JJJJJJJJJJJJJJJJJJJJJJJJJJJJJ Icons: breeze-dark [GTK2/3] JJJJ =JJJJJJ Terminal: konsole JJJJ =JJJJ CPU: AMD Ryzen 7 7800X3D (8) @ 5.050GHz JJJJ JJJJJJJJJJJJJJ GPU: AMD ATI TUF Gaming Radeon RX 7900 XTX OC JJJJ JJJJJJJJJJJJJJJ GPU: AMD ATI Raphael JJJJ JJJJ JJJJ Memory: 5884.57 MiB / 63432.22 MiB ----------------------- KDE 6.2.3 Frameworks: 6.8.0 QT: 6.8.0 -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 1231416] New: ZSWAP config cleanup
by bugzilla_noreply＠suse.com 16 Jan '25

16 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1231416 Bug ID: 1231416 Summary: ZSWAP config cleanup 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: jslaby(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Following: commit 13a488ad6c85976074f78f80a06414914890703c Author: Yosry Ahmed <yosryahmed(a)google.com> Date: Mon Oct 7 19:21:16 2024 +0000 mm: z3fold: deprecate CONFIG_Z3FOLD The z3fold compressed pages allocator is rarely used, most users use zsmalloc. The only disadvantage of zsmalloc in comparison is the dependency on MMU, and zbud is a more common option for !MMU as it was the default zswap allocator for a long time. Historically, zsmalloc had worse latency than zbud and z3fold but offered better memory savings. This is no longer the case as shown by a simple recent analysis [1]. That analysis showed that z3fold does not have any advantage over zsmalloc or zbud considering both performance and memory usage. In a kernel build test on tmpfs in a limited cgroup, z3fold took 3% more time and used 1.8% more memory. The latency of zswap_load() was 7% higher, and that of zswap_store() was 10% higher. Zsmalloc is better in all metrics. Moreover, z3fold apparently has latent bugs, which was made noticeable by a recent soft lockup bug report with z3fold [2]. Switching to zsmalloc not only fixed the problem, but also reduced the swap usage from 6~8G to 1~2G. Other users have also reported being bitten by mistakenly enabling z3fold. Other than hurting users, z3fold is repeatedly causing wasted engineering effort. Apart from investigating the above bug, it came up in multiple development discussions (e.g. [3]) as something we need to handle, when there aren't any legit users (at least not intentionally). The natural course of action is to deprecate z3fold, and remove in a few cycles if no objections are raised from active users. Next on the list should be zbud, as it offers marginal latency gains at the cost of huge memory waste when compared to zsmalloc. That one will need to wait until zsmalloc does not depend on MMU. We should likely: * set CONFIG_ZSWAP_ZPOOL_DEFAULT_Z3FOLD_DEPRECATED=n * set CONFIG_ZSWAP_ZPOOL_DEFAULT_ZSMALLOC=y and CONFIG_ZSWAP_ZPOOL_DEFAULT_ZBUD=n -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 1234860] New: Regression: Lenovo T14s Gen 2 AMD crashes on resume from suspend on kernel 6.12
by bugzilla_noreply＠suse.com 15 Jan '25

15 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1234860 Bug ID: 1234860 Summary: Regression: Lenovo T14s Gen 2 AMD crashes on resume from suspend on kernel 6.12 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: dheidler(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- The laptop comes up far enough from suspend to show the open applications on the desktop but the mouse doesn't react. The applications are NOT frozen - journalctl shows something (even though redirecting it into a file didn't show any content in that file after going into suspend. Then something really strange happens: - The display brightness goes through all the possible brightness steps - When reaching the full brightness it goes back to dark and starts over again - This process repeats faster and faster - Finally the screen goes completely dark -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 1234055] New: Unable to reach dual monitor resolution with 2x 4k UHD side by side to 7680x2160
by bugzilla_noreply＠suse.com 12 Jan '25

12 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1234055 Bug ID: 1234055 Summary: Unable to reach dual monitor resolution with 2x 4k UHD side by side to 7680x2160 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: x86-64 OS: openSUSE Leap 15.5 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: otrebor(a)hispeed.ch QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 878829 --> https://bugzilla.suse.com/attachment.cgi?id=878829&action=edit xrandr log Hi I have a recently bought Lenovo X1 Carbon Gen 12 with an Intel Core Ultra 7 Processor 165U and 64Gig Memory. This Notebook is attached to a Lenovo ThinkPad Universal Thunderbolt 4 Smart Dock via a TB4 cable. Plugged into the dock there are two EIZO FlexScan EV2740X Displays. Both attached via DisplayPort. The NB runs OpenSuse Leap 15.6 all patches applied. Also all available firmware updates have been installed via fwupdmgr. The problem is, that this setup does not run with both EIZO displays set to 4k UHD resolution side-by-side. (in 7680x2160 resolution setup). This fails with or without having the internal NB display active or not. Another NB running Win11 with an Nvidia Graphics card attached to the same dock runs both display just fine at 4k UHD resolution. So, i guess the problem lies with the Lenovo X1 Carbon and its Intel i915 graphics driver. According to the intel specs here this should work: https://www.intel.com/content/www/us/en/products/sku/237329/intel-core-ultr… The setup runs fine when i set the resolution on both EIZOS to the lower 2560x1440 and arrange them side by side. I'm a bit puzzled, as is this limited by design or is there something wrong with the drivers. In single display config both displays run fine at 4k UHD (3840x2160) mode. I have attached a number of log files. If you wouldn't mind helping me on this, I'd be grateful. I'm no hardware or kernel geek. Thanks -- You are receiving this mail because: You are the assignee for the bug.

1 28

[Bug 1234732] New: System Freeze with AMD Vega GPUs After Mesa 24.3.x Update & Kernel Logs Reveal Multiple AMD Driver Issues
by bugzilla_noreply＠suse.com 11 Jan '25

11 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1234732 Bug ID: 1234732 Summary: System Freeze with AMD Vega GPUs After Mesa 24.3.x Update & Kernel Logs Reveal Multiple AMD Driver Issues Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Critical Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: dacia.mountable282(a)aleeas.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Environment: Distribution: OpenSUSE TW GPU: AMD Vega (Picasso architecture) DE/WM: KDE Plasma (Wayland) Detailed Problem Description: I am experiencing critical system stability issues with my AMD graphics card after updating to Mesa 24.3.x (specifically, Mesa 24.3.0 and above). The system completely freezes after just a few minutes of use, rendering the computer unresponsive. I am unable to interact with the system, and the only solution is to perform a hard reboot. This issue is consistent across both X11 and Wayland environments and primarily affects Chromium-based browsers. Symptoms: The system experiences a complete freeze after a short period of use, typically within minutes, especially when using Chromium-based browsers. No apparent trigger or consistent pattern for the freeze. The system becomes unresponsive, requiring a hard reboot to recover. Driver and GPU Information: └─[$] vainfo Trying display: wayland libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.22 (libva 2.22.0) vainfo: Driver version: Mesa Gallium driver 24.3.1 for AMD Radeon Vega 8 Graphics (radeonsi, raven, LLVM 19.1.5, DRM 3.59, 6.11.8-1-default) vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileJPEGBaseline : VAEntrypointVLD VAProfileVP9Profile0 : VAEntrypointVLD VAProfileVP9Profile2 : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc Kernel Logs Reveal Multiple AMD Driver Issues: 1. PSP (Platform Security Processor) Failures: - Failed PSP commands: `LOAD_TA` and `INVOKE_CMD` - Secure display generic failure - PSP-related command responses returning error status 2. Missing Critical GPU Functionalities: - RAS (Reliability, Availability, and Serviceability) Trusted Application unavailable - RAP Trusted Application not available 3. Power Management Limitations: - Runtime Power Management (PM) not available └─[$] sudo journalctl -b -1 -g amdgpu Dec 18 17:59:39 tumbleweed-msi kernel: [drm] amdgpu kernel modesetting enabled. Dec 18 17:59:39 tumbleweed-msi kernel: amdgpu: Virtual CRAT table created for CPU Dec 18 17:59:39 tumbleweed-msi kernel: amdgpu: Topology: Add CPU node Dec 18 17:59:39 tumbleweed-msi kernel: amdgpu 0000:30:00.0: enabling device (0006 -> 0007) Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: amdgpu: Fetched VBIOS from VFCT Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu: ATOM BIOS: 113-PICASSO-118 Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: vgaarb: deactivate vga console Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: amdgpu: Trusted Memory Zone (TMZ) feature enabled Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: amdgpu: VRAM: 2048M 0x000000F400000000 - 0x000000F47FFFFFFF (2048M used) Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: amdgpu: GART: 1024M 0x0000000000000000 - 0x000000003FFFFFFF Dec 18 17:59:40 tumbleweed-msi kernel: [drm] amdgpu: 2048M of VRAM memory ready Dec 18 17:59:40 tumbleweed-msi kernel: [drm] amdgpu: 6950M of GTT memory ready. Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu: hwmgr_sw_init smu backed is smu10_smu Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: amdgpu: reserve 0x400000 from 0xf47fc00000 for PSP TMR Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: amdgpu: RAS: optional ras ta ucode is not available Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: amdgpu: RAP: optional rap ta ucode is not available Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: amdgpu: psp gfx command LOAD_TA(0x1) failed and response status is (0x7) Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: amdgpu: psp gfx command INVOKE_CMD(0x3) failed and response status is (0x4) Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: amdgpu: Secure display: Generic Failure. Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: amdgpu: SECUREDISPLAY: query securedisplay TA failed. ret 0x0 Dec 18 17:59:40 tumbleweed-msi kernel: kfd kfd: amdgpu: Allocated 3969056 bytes on gart Dec 18 17:59:40 tumbleweed-msi kernel: kfd kfd: amdgpu: Total number of KFD nodes to be created: 1 Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu: Virtual CRAT table created for GPU Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu: Topology: Add dGPU node [0x15d8:0x1002] Dec 18 17:59:40 tumbleweed-msi kernel: kfd kfd: amdgpu: added device 1002:15d8 Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: amdgpu: SE 1, SH per SE 1, CU per SH 11, active_cu_number 8 Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: amdgpu: ring gfx uses VM inv eng 0 on hub 0 Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0 Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0 Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 5 on hub 0 Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 6 on hub 0 Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 7 on hub 0 Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 8 on hub 0 Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 on hub 0 Dec 18 17:59:40 tumbleweed-msi kernel: amdgpu 0000:30:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 on hub 0 Dec 18 17:59:40 tumbleweed-ms -- You are receiving this mail because: You are the assignee for the bug.

1 8

[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 1234330] New: AMDGPU makes CPU stuck
by bugzilla_noreply＠suse.com 07 Jan '25

07 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1234330 Bug ID: 1234330 Summary: AMDGPU makes CPU stuck 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: axel(a)hiq2.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Recently, my system regularly freezes completely. Sometimes, mouse movement becomes slow before, sometimes it freezes suddenly. After a reboot, I find the attached messages in the journal. Kernel version is 6.11.8-1-default. Hint: these logs have been collected during some days, updates regarding affected modules were installed in between. Carsh3.log is recent. -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 1234619] New: CPU reporting and using incorrect max freq
by bugzilla_noreply＠suse.com 05 Jan '25

05 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1234619 Bug ID: 1234619 Summary: CPU reporting and using incorrect max freq Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: ez2blost(a)yahoo.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- On an Intel i9-13900HX, /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq reports the same frequency as base_frequency. E.g., cat /sys/devices/system/cpu/cpu0/cpufreq/{base_frequency,cpuinfo_max_freq} 2200000 2200000 By default the maximum scaling frequency for performance is set to the cpuinfo_max_freq cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq 2200000 However the maximum frequency for cpu1 is 5400000 as can be seen if a higher valuer is written to scaling_max_freq: echo 10000000 >| /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq ; cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 5400000 By default the cpu frequency never exceeds 2.2Ghz resulting in poor performance. A workaround is to set the maximum scaling frequency in the TLP configuration file (if tlp is used), e.g. Echo "CPU_SCALING_MAX_FREQ_ON_AC=5400000" >> /etc/tlp.d/50.local.conf This is partial fix because other software, such as NVIDIA power management features, can reset the scaling_max_frequency to cpuinfo_max_frequency, and cannot be enabled easily without a performance hit. -- You are receiving this mail because: You are the assignee for the bug.

1 4