February 2025 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1237526] New: SLES-16.0-Beta1 test found many cases report "Kernel Marking TSC unstable due to clocksource watchdog" on AMD Zen1 machine
by bugzilla_noreply＠suse.com 05 Mar '25

05 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1237526 Bug ID: 1237526 Summary: SLES-16.0-Beta1 test found many cases report "Kernel Marking TSC unstable due to clocksource watchdog" on AMD Zen1 machine Classification: openSUSE Product: openSUSE Tumbleweed Version: Slowroll Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: xingtao.ren(a)suse.com QA Contact: qa-bugs(a)suse.de CC: cachen(a)suse.com, jan.stehlik(a)suse.com, jcheung(a)suse.com, joyce.na(a)suse.com, jtang(a)suse.com, kernel-performance-bugs(a)suse.de, kostas.peletidis(a)suse.com, libor.miksik(a)suse.com, qi.wang(a)suse.com, sweiberg(a)suse.com, xgwang(a)suse.com, xingtao.ren(a)suse.com, yousaf.kaukab(a)suse.com, zhao.yuhu(a)suse.com Target Milestone: --- Found By: --- Blocker: --- [Issue] When we doing SLES16.0 Beta1 performance test, many test cases(syscall test, network test, IO test etc.) report "Kernel show Marking TSC unstable due to clocksource watchdog". But the issue only exist on AMD Zen1 machine. Since AMD Zen1 machine is in our low priority, it's suggested to report this issue for Tumbleweed after discussion with kernel performance team. [Environment] ph042, vh011 - Dell R740(Silver 4110 skylake, NUMA) ph043 - HP Gen10(AMD EPYC 7301, NUMA) ph046 - Dell R640(Silver 4214 CascadeLake, NUMA) ph051 - Dell R7525(AMD EPYC 7302, NUMA) ph054 - DELL PowerEdge R7525 (AMD EPYC 7413) ph055 - DELL PowerEdge R750 (Intel Gold 6330, Ice Lake-SP, NUMA) 1u-perf01 - SuperMicro 1U i-1410F-X13W (Intel Xeon Silver 4510, UMA) - host: 1u-perf01.qe.prg2.suse.org (10.146.4.156) - IPMI: 10.146.4.157 2u-perf01 - SuperMicro 2U X13DEI-T eATX13 2S-E(350W) (Intel Xeon Gold 5515+, NUMA) - host: 2u-perf01.qe.prg2.suse.org (10.146.4.160) - IPMI: 10.146.4.161 [logs] More details tests results, please refer QA dashboard: http://10.200.134.100/sleperf_dashboard/ -> performance -> SLES-16.0-Beta1 -> x86_64 -> kernel: 6.12.0-slfo.1.2-default libmicro-regular http://10.200.134.100/Results/ProductTests/performance/SLES-16.0/Beta1/x86_… libmicro-socket http://10.200.134.100/Results/ProductTests/performance/SLES-16.0/Beta1/x86_… libmicro-file http://10.200.134.100/Results/ProductTests/performance/SLES-16.0/Beta1/x86_… libmicro-memory http://10.200.134.100/Results/ProductTests/performance/SLES-16.0/Beta1/x86_… network_socket_loop_netperf_tcp4_bind_node http://10.200.134.100/Results/ProductTests/performance/SLES-16.0/Beta1/x86_… network_socket_loop_netperf_udp4_bind_node http://10.200.134.100/Results/ProductTests/performance/SLES-16.0/Beta1/x86_… io_block_generic_dbench_async_xfs http://10.200.134.100/Results/ProductTests/performance/SLES-16.0/Beta1/x86_… io_block_generic_dbench_fsync_btrfs http://10.200.134.100/Results/ProductTests/performance/SLES-16.0/Beta1/x86_… io_block_generic_dbench_fsync_ext4 http://10.200.134.100/Results/ProductTests/performance/SLES-16.0/Beta1/x86_… io_block_generic_dbench_async_ext4 http://10.200.134.100/Results/ProductTests/performance/SLES-16.0/Beta1/x86_… io_block_generic_fio_random_async_btrfs http://10.200.134.100/Results/ProductTests/performance/SLES-16.0/Beta1/x86_… io_block_generic_fio_random_fsync_ext4 http://10.200.134.100/Results/ProductTests/performance/SLES-16.0/Beta1/x86_… io_block_generic_fio_random_async_ext4 http://10.200.134.100/Results/ProductTests/performance/SLES-16.0/Beta1/x86_… io_sched_nvme_fio_random_fsync_xfs http://10.200.134.100/Results/ProductTests/performance/SLES-16.0/Beta1/x86_… io_sched_nvme_fio_random_async_xfs http://10.200.134.100/Results/ProductTests/performance/SLES-16.0/Beta1/x86_… -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 1236992] Bluetooth stops working with xHCI host not responding to stop endpoint command
by bugzilla_noreply＠suse.com 28 Feb '25

28 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1236992 https://bugzilla.suse.com/show_bug.cgi?id=1236992#c12 Heiko Schultz <schultz.heiko(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schultz.heiko(a)web.de --- Comment #12 from Heiko Schultz <schultz.heiko(a)web.de> --- Hi, I also observed this behavior, starting from kernel 6.13.x. That was combined with odd behavior during suspend, such as: - not going to sleep when pushing the power button (set in KDE) - after wake up going directly back to suspend mode. I updated to 6.13.4.1-default, now, the odd suspend behaviour seems to be gone, but still experienced the xHCI disconnect. dmesg shows tons of messages: ---- [84702.208910] [ C1] xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state. [84702.212639] [ C1] xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state. [84703.474864] [ T30794] usb 2-4: new SuperSpeed USB device number 66 using xhci_hcd [84708.864924] [ C1] xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state. [84712.177103] [ T30794] usb 2-4: new SuperSpeed USB device number 67 using xhci_hcd [84730.449909] [ T30794] usb 2-4: new SuperSpeed USB device number 68 using xhci_hcd [84735.489203] [ C1] xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state. [84739.145085] [ T30794] usb 2-4: new SuperSpeed USB device number 69 using xhci_hcd ---- I could get it back to work with "echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/unbind echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/bind " Any idea? Thanks? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1236415] New: Hitachi pi-500 EDID data causes GPU crash
by bugzilla_noreply＠suse.com 28 Feb '25

28 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1236415 Bug ID: 1236415 Summary: Hitachi pi-500 EDID data causes GPU crash 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: declanseeley(a)icloud.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Just got a Hitachi pi-500 and was able to confirm that it is sending some irregular EDID data which is crashing my GPU info: ``` usr_40476@2xeon:~> kinfo Operating System: openSUSE Tumbleweed 20250121 KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.1 Kernel Version: 6.12.10-1-default (64-bit) Graphics Platform: Wayland Processors: 88 × Intel® Xeon® CPU E5-2699 v4 @ 2.20GHz Memory: 62.6 GiB of RAM Graphics Processor: AMD Radeon R9 390 Series usr_40476@2xeon:~> ``` kernel params: ``` resume=/dev/disk/by-uuid/fa9f1657-6f6a-4695-b9da-dcd01328cb84 security=apparmor splash=0 radeon.si_support=0 amdgpu.si_support=1 radeon.cik_support=0 amdgpu.cik_support=1 ``` from laptop (no issues): ``` Jan 24 20:03:20 indestructable kernel: EDID block 1 (tag 0x1e) checksum is invalid, remainder is 132 ``` from desktop (GPU crash) ``` Jan 24 16:04:04 2xeon kernel: ------------[ cut here ]------------ Jan 24 16:04:04 2xeon kernel: memmove: detected field-spanning write (size 4224) of single field "sink->dc_edid.raw_edid" at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:932 (size 2048) Jan 24 16:04:04 2xeon kernel: WARNING: CPU: 74 PID: 1040 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:932 dm_helpers_read_local_edid+0x239/0x280 [amdgpu] Jan 24 16:04:04 2xeon kernel: Modules linked in: mptcp_diag tcp_diag udp_diag raw_diag inet_diag unix_diag rfcomm snd_seq_dummy snd_hrtimer snd_seq ccm tun af_packet nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_rej> Jan 24 16:04:04 2xeon kernel: uvc intel_pmc_bxt videobuf2_memops snd_hda_core snd_rawmidi iTCO_vendor_support videobuf2_v4l2 cfg80211 snd_hwdep snd_seq_device videobuf2_common bluetooth kvm r8169 snd_pcm videodev aiptek snd_timer real> Jan 24 16:04:04 2xeon kernel: CPU: 74 UID: 0 PID: 1040 Comm: kworker/74:1H Not tainted 6.12.10-1-default #1 openSUSE Tumbleweed 92f8b4bfae9b116207d57ef1371c30c09d434808 Jan 24 16:04:04 2xeon kernel: Hardware name: INTEL X99/X99, BIOS 5.11 03/06/2024 Jan 24 16:04:04 2xeon kernel: Workqueue: events_highpri dm_irq_work_func [amdgpu] Jan 24 16:04:04 2xeon kernel: RIP: 0010:dm_helpers_read_local_edid+0x239/0x280 [amdgpu] Jan 24 16:04:04 2xeon kernel: Code: 0f 85 8c fe ff ff b9 00 08 00 00 48 c7 c2 88 72 80 c1 48 c7 c7 f8 72 80 c1 48 89 74 24 08 c6 05 28 3f 3f 00 01 e8 57 c8 bc d5 <0f> 0b 48 8b 74 24 08 e9 5c fe ff ff 41 80 bd 70 07 00 00 00 41 b8 Jan 24 16:04:04 2xeon kernel: RSP: 0000:ffffb63bc241fc08 EFLAGS: 00210286 Jan 24 16:04:04 2xeon kernel: RAX: 0000000000000000 RBX: ffff91ba6edb2000 RCX: 0000000000000027 Jan 24 16:04:04 2xeon kernel: RDX: ffff91c97f727848 RSI: 0000000000000001 RDI: ffff91c97f727840 Jan 24 16:04:04 2xeon kernel: RBP: ffff91ba4d628800 R08: 0000000000000000 R09: ffffb63bc241fa98 Jan 24 16:04:04 2xeon kernel: R10: ffff91c97cafffa8 R11: 0000000000000003 R12: 0000000000000003 Jan 24 16:04:04 2xeon kernel: R13: ffff91ba4277a000 R14: ffff91ba4277ad58 R15: ffff91bb8768e000 Jan 24 16:04:04 2xeon kernel: FS: 0000000000000000(0000) GS:ffff91c97f700000(0000) knlGS:0000000000000000 Jan 24 16:04:04 2xeon kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jan 24 16:04:04 2xeon kernel: CR2: 00000000c9dfcc28 CR3: 0000000f1c838004 CR4: 00000000003726f0 Jan 24 16:04:04 2xeon kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Jan 24 16:04:04 2xeon kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Jan 24 16:04:04 2xeon kernel: Call Trace: Jan 24 16:04:04 2xeon kernel: <TASK> Jan 24 16:04:04 2xeon kernel: ? dm_helpers_read_local_edid+0x239/0x280 [amdgpu 145e705fb20fed36f5fe6263fd32206135db95c0] Jan 24 16:04:04 2xeon kernel: ? __warn.cold+0x93/0xf7 Jan 24 16:04:04 2xeon kernel: ? dm_helpers_read_local_edid+0x239/0x280 [amdgpu 145e705fb20fed36f5fe6263fd32206135db95c0] Jan 24 16:04:04 2xeon kernel: ? report_bug+0xff/0x140 Jan 24 16:04:04 2xeon kernel: ? prb_read_valid+0x1b/0x30 Jan 24 16:04:04 2xeon kernel: ? handle_bug+0x58/0x90 Jan 24 16:04:04 2xeon kernel: ? exc_invalid_op+0x17/0x70 Jan 24 16:04:04 2xeon kernel: ? asm_exc_invalid_op+0x1a/0x20 Jan 24 16:04:04 2xeon kernel: ? dm_helpers_read_local_edid+0x239/0x280 [amdgpu 145e705fb20fed36f5fe6263fd32206135db95c0] Jan 24 16:04:04 2xeon kernel: ? dm_helpers_read_local_edid+0x239/0x280 [amdgpu 145e705fb20fed36f5fe6263fd32206135db95c0] Jan 24 16:04:04 2xeon kernel: detect_link_and_local_sink+0x4e7/0x1050 [amdgpu 145e705fb20fed36f5fe6263fd32206135db95c0] Jan 24 16:04:04 2xeon kernel: ? dm_write_reg_func+0x47/0xb0 [amdgpu 145e705fb20fed36f5fe6263fd32206135db95c0] Jan 24 16:04:04 2xeon kernel: ? dm_write_reg_func+0x47/0xb0 [amdgpu 145e705fb20fed36f5fe6263fd32206135db95c0] Jan 24 16:04:04 2xeon kernel: ? generic_reg_update_ex+0x144/0x280 [amdgpu 145e705fb20fed36f5fe6263fd32206135db95c0] Jan 24 16:04:04 2xeon kernel: link_detect+0x38/0x4e0 [amdgpu 145e705fb20fed36f5fe6263fd32206135db95c0] Jan 24 16:04:04 2xeon kernel: ? dal_gpio_destroy_irq+0x25/0x40 [amdgpu 145e705fb20fed36f5fe6263fd32206135db95c0] Jan 24 16:04:04 2xeon kernel: ? query_hpd_status+0x6e/0xa0 [amdgpu 145e705fb20fed36f5fe6263fd32206135db95c0] Jan 24 16:04:04 2xeon kernel: handle_hpd_irq_helper+0x116/0x190 [amdgpu 145e705fb20fed36f5fe6263fd32206135db95c0] Jan 24 16:04:04 2xeon kernel: process_one_work+0x16b/0x320 Jan 24 16:04:04 2xeon kernel: worker_thread+0x2da/0x410 Jan 24 16:04:04 2xeon kernel: ? __pfx_worker_thread+0x10/0x10 Jan 24 16:04:04 2xeon kernel: kthread+0xd2/0x100 Jan 24 16:04:04 2xeon kernel: ? __pfx_kthread+0x10/0x10 Jan 24 16:04:04 2xeon kernel: ret_from_fork+0x34/0x50 Jan 24 16:04:04 2xeon kernel: ? __pfx_kthread+0x10/0x10 Jan 24 16:04:04 2xeon kernel: ret_from_fork_asm+0x1a/0x30 Jan 24 16:04:04 2xeon kernel: </TASK> Jan 24 16:04:04 2xeon kernel: ---[ end trace 0000000000000000 ]--- ``` -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 1218184] New: Eliminate the need for 'OBS source links': convert to _multibuild
by bugzilla_noreply＠suse.com 28 Feb '25

28 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1218184 Bug ID: 1218184 Summary: Eliminate the need for 'OBS source links': convert to _multibuild Classification: SUSE ALP - SUSE Adaptable Linux Platform Product: Dolomite Version: Milestone 5 Hardware: Other OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)suse.de Reporter: fcrozat(a)suse.com CC: dimstar(a)opensuse.org, dleuenberger(a)suse.com, fcrozat(a)suse.com, jslaby(a)suse.com, kernel-bugs(a)opensuse.org, mls(a)suse.com, msuchanek(a)suse.com, qa-bugs(a)suse.de, tiwai(a)suse.com Depends on: 1211226 Target Milestone: --- Group: SUSE Enterprise Partner Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1211226 +++ In order to prepare for 'git based source management', we need to fix up a few technical issues. One such issue is 'source links' not being supported in git (i.e in OBS we have openSUSE:Factory/kernel-source as the main package plus a bunch of 'linked packages', each with the name of the additional spec files) The solution is, technically seem, rather simple: using _multibuild multibuild support on OBS is known in two variants, one using a single spec file and conditionals inside the spec file based on @BUILD_FLAVOR@ (probably the more known way) but OBS also supports 'just' listing the additional spec files as 'flavors' the _multibuild to be added to the kernel-source (main package) can be generated like this:  #!/bin/sh echo "<multibuild>" > _multibuild for pkg in *.spec; do test "{$pkg}" == "kernel-source.spec" && continue echo " <package>${pkg/.spec/}</package>" >> _multibuild; done echo "</multibuild>" >> _multibuild  the spec files do not need to be changed in anyway with this method -- You are receiving this mail because: You are on the CC list for the bug.

1 62

[Bug 1236380] BUG: Unable to handle kernel data access on read at 0x17f9eb0000
by bugzilla_noreply＠suse.com 28 Feb '25

28 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1236380 https://bugzilla.suse.com/show_bug.cgi?id=1236380#c26 --- Comment #26 from Gaurav Pathak <gaurav.pathak(a)suse.com> --- (In reply to Michal Suchanek from comment #14) > There is no crash visible in the last log. > > There is no full log showing messages since boot including the initial > error, neither here nor in bug 1236379. > > Initially there is crash, then there are lockups, and different lockups in > the other bug. > > Unless the problem is that the hardware is generally flaky these all look > like different problems. Seems like the hard disk isn't working properly. In couple of crash logs, I noticed the stack trace have API calls related to inode and btrfs, and in the boot logs there is a message "ipr 0001:08:00.0: 8150: Permanent IOA failure". This IBM website lists the error code and their meaning https://www.ibm.com/docs/en/power8/9080-MHE?topic=recovery-unit-reference-c… the error code "8150: Permanent IOA failure" can be related to some failing I/O adapter maybe in this case it can be the Hard disk I/O. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1235775] Graphical installation from ISO impossible on Raspberry Pi 4
by bugzilla_noreply＠suse.com 27 Feb '25

27 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1235775 Matthias Brugger <mbrugger(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(tzimmermann@suse. | |com) CC| |mbrugger(a)suse.com -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1236868] [Build 20250205] openQA test fails in epoll_pwait03
by bugzilla_noreply＠suse.com 27 Feb '25

27 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1236868 Matthias Brugger <mbrugger(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mbrugger(a)suse.com Assignee|kernel-bugs(a)opensuse.org |arm-bugs(a)suse.de -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1235938] New: ZSWAP config cleanup
by bugzilla_noreply＠suse.com 26 Feb '25

26 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1235938 Bug ID: 1235938 Summary: ZSWAP config cleanup Classification: SUSE Linux Framework One Product: SUSE Linux Enterprise Server 16.0 Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)suse.de Reporter: jslaby(a)suse.com CC: kernel-bugs(a)opensuse.org, mgorman(a)suse.com, mhocko(a)suse.cz, mkubecek(a)suse.com, qa-bugs(a)suse.de, vbabka(a)suse.com Depends on: 1231416 Target Milestone: --- Group: novellonly Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1231416 +++ 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 We should likely do the same in SUSE-2025. This was switched in master: commit 7cce8ae7a3a847390718c88c87f264351e4f473e Author: Jiri Slaby <jslaby(a)suse.cz> Date: Wed Oct 9 12:52:47 2024 +0200 Update ZSWAP config files (bsc#1231416) * Z3FOLD is deprecated. * ZSMALLOC should be the default. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1237776] New: Machine went unresponsive. Messages about usb "not responding to setup address" and "watchdog: BUG: soft lockup"
by bugzilla_noreply＠suse.com 26 Feb '25

26 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1237776 Bug ID: 1237776 Summary: Machine went unresponsive. Messages about usb "not responding to setup address" and "watchdog: BUG: soft lockup" Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: carlos.e.r(a)opensuse.org QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 880638 --> https://bugzilla.suse.com/attachment.cgi?id=880638&action=edit Journal It has happened twice. The first symptom is this: Feb 24 00:08:45 Telcontar kernel: usb 2-1: Device not responding to setup address. Feb 24 00:08:45 Telcontar kernel: usb 2-1: Device not responding to setup address. Feb 24 00:08:45 Telcontar kernel: usb 2-1: device not accepting address 4, error -71 Feb 24 00:08:52 Telcontar kernel: usb 2-1: new SuperSpeed USB device number 6 using xhci_hcd Feb 24 00:08:52 Telcontar kernel: usb 2-1: New USB device found, idVendor=8564, idProduct=4000, bcdDevice= 0.26 Feb 24 00:08:52 Telcontar kernel: usb 2-1: New USB device strings: Mfr=3, Product=4, SerialNumber=5 Feb 24 00:08:52 Telcontar kernel: usb 2-1: Product: Transcend Feb 24 00:08:52 Telcontar kernel: usb 2-1: Manufacturer: TS-RDF8 Feb 24 00:08:52 Telcontar kernel: usb 2-1: SerialNumber: 000000082 Feb 24 00:08:52 Telcontar kernel: usb-storage 2-1:1.0: USB Mass Storage device detected That device is a camera card, which is still connected and working, after reboot and hibernation/restore cycles: cer@Telcontar:~> lsusb Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 005 Device 003: ID 05e3:0608 Genesys Logic, Inc. Hub Bus 005 Device 002: ID 046d:c404 Logitech, Inc. TrackMan Wheel Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 002: ID 0463:ffff MGE UPS Systems UPS Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 002: ID 8564:4000 Transcend Information, Inc. microSD/SD/CF UHS-II Card Reader [RDF8, RDF9] <==== Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 04d9:2020 Holtek Semiconductor, Inc. USB Keyboard Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub cer@Telcontar:~> These messages continued: Feb 24 00:32:03 Telcontar kernel: usb 2-1: Device not responding to setup address. Feb 24 00:32:08 Telcontar kernel: usb 2-1: Device not responding to setup address. Feb 24 00:32:08 Telcontar kernel: usb 2-1: device not accepting address 12, error -71 Feb 24 00:32:08 Telcontar kernel: usb 2-1: reset SuperSpeed USB device number 12 using xhci_hcd Machine became almost unresponsive, and the kernel complained: Feb 24 00:40:57 Telcontar kernel: usb 2-1: device not accepting address 12, error -71 Feb 24 00:40:57 Telcontar kernel: watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [kworker/u64:0:30616] I could see in "top" several kworker processes at 100% CPU. All CPU cores were at 100. I disconnected and reconnected all USB cables (except the memory stick which I did not see, different computer side). Keyboard was stuck all leds on. I disconnected keyboard and connected another, which took a very long time to light leds, and did not respond. At 01:34 I managed to ssh from another computer. I tried "init 3" which did not work. I issued "poweroff" which succeeded after an hour or two. I did not want to hit reset button and loose working files. The clock display showed a delay. Mouse was gone. There are many messages like this in the journal: kernel: watchdog: BUG: soft lockup - CPU#6 stuck for 23s! [kworker/u64:0:30616] I will attach journal, with mail and news messages purged, via this command: journalctl --boot=-2 --facility=kern,user,daemon,auth,syslog,lpr,uucp,cron,authpriv,ftp,12,13,14,15,local0,local1,local2,local3,local4,local5,local6,local7 > journal_purged However, notice that several megabytes of messages like this: Feb 18 12:17:58 Telcontar sddm[2599]: Initializing... are also missing. They are facility 1, should not be removed. I know they are fac 1 by comparison with syslog: <1.4> 2025-02-24T01:03:30.963177+01:00 Telcontar sddm 2599 - - Signal received: SIGTERM *..... I print the <fac.prio> numbers. If you need those messages in the log, please advise how to remove mail and news messages from the journal. Grep doesn't work because news messages are multiline. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1237462] Failed to start jobs: Failed to enqueue some jobs, see logs for details: No such file or directory
by bugzilla_noreply＠suse.com 25 Feb '25

25 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1237462 https://bugzilla.suse.com/show_bug.cgi?id=1237462#c1 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Kernel |Basesystem Assignee|kernel-bugs(a)opensuse.org |screening-team-bugs(a)suse.de CC| |tiwai(a)suse.com --- Comment #1 from Takashi Iwai <tiwai(a)suse.com> --- This doesn't look like a kernel packaging issue. Reassigned. -- You are receiving this mail because: You are the assignee for the bug.

1 0