This fixed it for me: sudo apt install linux-oem-26.04 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2149877 Title: Intermittent micro‑stutters affecting mouse and audio after updating to Linux 7.0.0‑14‑generic on AMD system Status in linux package in Ubuntu: Triaged Status in linux source package in Resolute: Triaged Bug description: For the past few days I have been experiencing intermittent micro‑stutters in Ubuntu 26.04. The mouse cursor freezes for about half a second, and occasionally the system audio also cuts out briefly. This happens irregularly but repeatedly. The issue started after updating to Linux 7.0.0‑14‑generic. Around the same time, linux‑firmware was also updated, so I cannot determine which change might be responsible. On my laptop (Intel + Nvidia) I cannot reproduce the issue, but another user with AMD hardware reported similar symptoms on Discourse. Affected hardware: · CPU: AMD Ryzen 5 9600X (12) @ 5.49 GHz · GPU: AMD Radeon RX 9060 XT · OS: Ubuntu 26.04 Observed behaviour: · Mouse cursor freezes for ~0.5 seconds (“micro‑stutter”). · Occasional short audio dropouts. · I have not noticed the issue while gaming, although another user claims it also happens there. I would appreciate guidance on additional tools or diagnostics that could help identify the root cause. At the moment, the only evidence I can provide is the observed behaviour described above. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2149877/+subscriptions
пятница
[Bug 2157590] [NEW] Mic Mute LED not working on HP Laptop 15-fc0xxx (Board 8B2F) / Realtek ALC236
Public bug reported: Hello, I am running Ubuntu 26.04 on an HP Laptop 15-fc0xxx (Ryzen 3 7320U platform) and the physical microphone mute LED (on the F8 key) does not toggle or illuminate when the mic mute hotkey is pressed, even though the software mutes correctly. The standard 'hda::micmute' node is entirely missing from /sys/class/leds/. Here are the system details gathered from troubleshooting: - OS: Ubuntu 26.04 LTS - Kernel: 7.0.0-22-generic - Audio Codec: Realtek ALC236 (Subsystem Id: 0x103c8b2f) - Board ID: HP 8B2F (SKU: 946T5EA#UUG) Testing with evtest shows that 'HP WMI hotkeys' successfully registers EV_KEY / KEY_MICMUTE (code 248) on keypress, but the corresponding LED is not hooked up via the hp-wmi driver for this specific motherboard revision. Please consider adding a quirk mapping for Subsystem 0x103c8b2f / Board 8B2F to enable the mic mute LED trigger. Thank you! ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: 26.04 alc236 alsa-driver amd-acp hp-wmi micmute-led ** Tags added: 26.04 alc236 alsa-driver hp-wmi micmute-led -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2157590 Title: Mic Mute LED not working on HP Laptop 15-fc0xxx (Board 8B2F) / Realtek ALC236 Status in linux package in Ubuntu: New Bug description: Hello, I am running Ubuntu 26.04 on an HP Laptop 15-fc0xxx (Ryzen 3 7320U platform) and the physical microphone mute LED (on the F8 key) does not toggle or illuminate when the mic mute hotkey is pressed, even though the software mutes correctly. The standard 'hda::micmute' node is entirely missing from /sys/class/leds/. Here are the system details gathered from troubleshooting: - OS: Ubuntu 26.04 LTS - Kernel: 7.0.0-22-generic - Audio Codec: Realtek ALC236 (Subsystem Id: 0x103c8b2f) - Board ID: HP 8B2F (SKU: 946T5EA#UUG) Testing with evtest shows that 'HP WMI hotkeys' successfully registers EV_KEY / KEY_MICMUTE (code 248) on keypress, but the corresponding LED is not hooked up via the hp-wmi driver for this specific motherboard revision. Please consider adding a quirk mapping for Subsystem 0x103c8b2f / Board 8B2F to enable the mic mute LED trigger. Thank you! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2157590/+subscriptions
[Bug 2157584] Re: Kernel NULL pointer dereference in __queue_work via delayed_work_timer_fn on 7.0.0-22-generic (Ubuntu 26.04)
The crash matches a known workqueue state-machine bug fixed upstream by commit a7488f089bdfa87c4fef1744d4dca9f4f8b46f8b ("workqueue: Release PENDING in __queue_work() drain/destroy reject path"), authored by Breno Leitao, applied by Tejun Heo to wq/for-7.1-fixes on 2026-05-08, merged mainline via wq-for-7.1-rc3-fixes pull (2026-05-13). The bug: when delayed_work_timer_fn() -> __queue_work() hits the __WQ_DESTROYING | __WQ_DRAINING reject path, it WARNs and returns without clearing WORK_STRUCT_PENDING, leaving the work in an inconsistent state (PENDING=1, PWQ=0, entry empty). This matches our observed sequence: the WARNING at 17:44:49 was the reject path firing, and the NULL pointer dereference at 19:06:42 was the downstream consequence. An AUTOSEL backport to 7.0 stable was posted 2026-05-20 but has not landed in any released 7.0.x point release through 7.0.12 (2026-06-09) -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2157584 Title: Kernel NULL pointer dereference in __queue_work via delayed_work_timer_fn on 7.0.0-22-generic (Ubuntu 26.04) Status in linux package in Ubuntu: New Bug description: Package: linux Affects: Ubuntu 26.04 (resolute) Description A QEMU/KVM virtio guest running Ubuntu 26.04 with kernel 7.0.0-22-generic froze completely. The guest agent stopped responding, SSH timed out, and the VM required a virsh reset to recover. Investigation of the previous boot's journal revealed a kernel NULL pointer dereference in __queue_work, preceded by a WARNING at the same location on a separate occasion earlier in the same boot. This matches a known upstream workqueue use-after-free / NULL- deref pattern where delayed work is queued to a workqueue that has been destroyed (wq->cpu_pwq nullified), causing a NULL pointer dereference when the delayed timer fires and calls delayed_work_timer_fn -> __queue_work. Steps to reproduce Not reliably reproducible. The crash occurs when a delayed_work timer fires after the owning workqueue has been destroyed. The VM had been running for ~2 days under mixed workload (GNOME desktop, Docker containers with nftables/wireguard networking, JetBrains IDEs). Kernel version Linux ubuntu-dev-2024 7.0.0-22-generic #22-Ubuntu SMP PREEMPT_DYNAMIC Mon May 25 15:54:34 UTC 2026 x86_64 GNU/Linux Package: linux-image-7.0.0-22-generic 7.0.0-22.22 Hardware QEMU Standard PC (Q35 + ICH9, 2009), BIOS 2025.11-3ubuntu8 04/09/2026 16 vCPUs, 20GB RAM, virtio-blk + virtio-net + virtiofs + virtio-gpu Kernel command line BOOT_IMAGE=/boot/vmlinuz-7.0.0-22-generic root=UUID=25a32e36-0866-4e02-b7ef-0703c8b6d784 ro zswap.enabled=1 zswap.compressor=zstd zswap.zpool=zsmalloc zswap.max_pool_percent=30 splash plymouth crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M Timeline 1. 17:44:49 — WARNING at kernel/workqueue.c:2350 on CPUs 4, 11, 8 (swapper/idle). VM continued running. 2. 19:06:42 — BUG: kernel NULL pointer dereference on CPUs 9 and 1 (swapper/idle). VM froze. Oops trace (19:06:42 event) BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page CPU: 9 UID: 0 PID: 0 Comm: swapper/9 Tainted: G W 7.0.0-22-generic #22-Ubuntu PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 2025.11-3ubuntu8 04/09/2026 RIP: 0010:__queue_work.part.0+0x190/0x390 Code: ... <0f> 0b e9 65 ff ff ff ... RSP: 0018:ffffcce10016cdd8 EFLAGS: 00010003 RAX: ffff8c35a542f2c0 RBX: ffff8c35a542f2b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffcce10016ce10 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8c392bab2680 R13: 0000000000002000 R14: ffff8c34c0386c00 R15: ffff8c34c0389200 FS: 0000000000000000(0000) GS:ffff8c3980880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000072ea901a3fb8 CR3: 0000000199a02000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <IRQ> __queue_work+0x39/0xc0 ? __pfx_delayed_work_timer_fn+0x10/0x10 delayed_work_timer_fn+0x19/0x30 call_timer_fn+0x30/0x170 ? __pfx_delayed_work_timer_fn+0x10/0x10 __run_timers+0x1af/0x2c0 run_timer_softirq+0x8a/0x100 handle_softirqs+0xe1/0x360 __irq_exit_rcu+0x100/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x9f/0xd0 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1b/0x20 RIP: 0010:pv_native_safe_halt+0xb/0x10 ... arch_cpu_idle+0x9/0x10 default_idle_call+0x2f/0x130 cpuidle_idle_call+0x114/0x1f0 do_idle+0x94/0xf0 cpu_startup_entry+0x29/0x30 start_secondary+0x125/0x180 ? soft_restart_cpu+0x14/0x14 common_startup_64+0x13e/0x141 </TASK> ---[ end trace 0000000000000000 ]--- A second identical oops was logged simultaneously on CPU 1. WARNING trace (17:44:49 event, same boot, earlier) WARNING: kernel/workqueue.c:2350 at __queue_work.part.0+0x190/0x390, CPU#4: swapper/4/0 WARNING: kernel/workqueue.c:2350 at __queue_work.part.0+0x190/0x390, CPU#11: swapper/11/0 WARNING: kernel/workqueue.c:2350 at __queue_work.part.0+0x190/0x390, CPU#8: swapper/8/0 Modules linked in: nft_ct, wireguard, libcurve25519, ip6_udp_tunnel, udp_tunnel, nf_conntrack_netlink, xt_nat, xt_tcpudp, veth, xt_multiport, xt_conntrack, xt_MASQUERADE, xfrm_user, xfrm_algo, xt_set, ip_set, nft_chain_nat, nf_nat, nf_conntrack, nf_defrag_ipv6, nf_defrag_ipv4, nft_compat, nf_tables, virtiofs, serio_raw, vmw_vsock_virtio_transport, virtio_dma_buf, vsock, virtio_rng, autofs4, libahci, netconsole, virtio_gpu, psmouse, hid_generic, ahci, usbhid, hid Analysis The crash occurs in the timer interrupt path during CPU idle: 1. CPU is idle (pv_native_safe_halt / do_idle) 2. APIC timer interrupt fires 3. __run_timers expires a delayed_work timer 4. delayed_work_timer_fn calls __queue_work 5. __queue_work dereferences a NULL pointer (pwq/pool is NULL) The Tainted [W] flag confirms a prior WARN at the same code path. The simultaneous occurrence on two CPUs suggests a race condition during workqueue teardown — a delayed_work timer fires after the workqueue's cpu_pwq has been nullified by destroy_workqueue(). This matches the upstream pattern described in: - Tim Van Patten's patch "workqueue: Prevent delayed work UAF kernel panic" (June 2024): LKML — adds NULL check for pwq/pool in __queue_work - Tejun Heo's response and removal of WARN_ON_ONCE(!wq) (March 2026): GitHub mirror Related bugs - Launchpad #2068103 — same pattern on kernel 6.8.0-35 (workqueue.c:1790) - bugzilla.kernel.org #218288 — same pattern on kernel 6.6 (workqueue.c:1638) Availability of fix Kernel 7.0.0-26.26 is in resolute-proposed and includes upstream stable releases v7.0.1 through v7.0.6. It is unclear whether the workqueue UAF fix is included in those stable releases. The guest currently has 7.0.0-22.22 installed with no upgradable kernel in updates/security. Workaround None known. Rebooting after a virsh reset recovers the guest. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2157584/+subscriptions
[Bug 2157584] [NEW] Kernel NULL pointer dereference in __queue_work via delayed_work_timer_fn on 7.0.0-22-generic (Ubuntu 26.04)
Public bug reported: Package: linux Affects: Ubuntu 26.04 (resolute) Description A QEMU/KVM virtio guest running Ubuntu 26.04 with kernel 7.0.0-22-generic froze completely. The guest agent stopped responding, SSH timed out, and the VM required a virsh reset to recover. Investigation of the previous boot's journal revealed a kernel NULL pointer dereference in __queue_work, preceded by a WARNING at the same location on a separate occasion earlier in the same boot. This matches a known upstream workqueue use-after-free / NULL-deref pattern where delayed work is queued to a workqueue that has been destroyed (wq->cpu_pwq nullified), causing a NULL pointer dereference when the delayed timer fires and calls delayed_work_timer_fn -> __queue_work. Steps to reproduce Not reliably reproducible. The crash occurs when a delayed_work timer fires after the owning workqueue has been destroyed. The VM had been running for ~2 days under mixed workload (GNOME desktop, Docker containers with nftables/wireguard networking, JetBrains IDEs). Kernel version Linux ubuntu-dev-2024 7.0.0-22-generic #22-Ubuntu SMP PREEMPT_DYNAMIC Mon May 25 15:54:34 UTC 2026 x86_64 GNU/Linux Package: linux-image-7.0.0-22-generic 7.0.0-22.22 Hardware QEMU Standard PC (Q35 + ICH9, 2009), BIOS 2025.11-3ubuntu8 04/09/2026 16 vCPUs, 20GB RAM, virtio-blk + virtio-net + virtiofs + virtio-gpu Kernel command line BOOT_IMAGE=/boot/vmlinuz-7.0.0-22-generic root=UUID=25a32e36-0866-4e02-b7ef-0703c8b6d784 ro zswap.enabled=1 zswap.compressor=zstd zswap.zpool=zsmalloc zswap.max_pool_percent=30 splash plymouth crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M Timeline 1. 17:44:49 — WARNING at kernel/workqueue.c:2350 on CPUs 4, 11, 8 (swapper/idle). VM continued running. 2. 19:06:42 — BUG: kernel NULL pointer dereference on CPUs 9 and 1 (swapper/idle). VM froze. Oops trace (19:06:42 event) BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page CPU: 9 UID: 0 PID: 0 Comm: swapper/9 Tainted: G W 7.0.0-22-generic #22-Ubuntu PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 2025.11-3ubuntu8 04/09/2026 RIP: 0010:__queue_work.part.0+0x190/0x390 Code: ... <0f> 0b e9 65 ff ff ff ... RSP: 0018:ffffcce10016cdd8 EFLAGS: 00010003 RAX: ffff8c35a542f2c0 RBX: ffff8c35a542f2b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffcce10016ce10 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8c392bab2680 R13: 0000000000002000 R14: ffff8c34c0386c00 R15: ffff8c34c0389200 FS: 0000000000000000(0000) GS:ffff8c3980880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000072ea901a3fb8 CR3: 0000000199a02000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <IRQ> __queue_work+0x39/0xc0 ? __pfx_delayed_work_timer_fn+0x10/0x10 delayed_work_timer_fn+0x19/0x30 call_timer_fn+0x30/0x170 ? __pfx_delayed_work_timer_fn+0x10/0x10 __run_timers+0x1af/0x2c0 run_timer_softirq+0x8a/0x100 handle_softirqs+0xe1/0x360 __irq_exit_rcu+0x100/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x9f/0xd0 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1b/0x20 RIP: 0010:pv_native_safe_halt+0xb/0x10 ... arch_cpu_idle+0x9/0x10 default_idle_call+0x2f/0x130 cpuidle_idle_call+0x114/0x1f0 do_idle+0x94/0xf0 cpu_startup_entry+0x29/0x30 start_secondary+0x125/0x180 ? soft_restart_cpu+0x14/0x14 common_startup_64+0x13e/0x141 </TASK> ---[ end trace 0000000000000000 ]--- A second identical oops was logged simultaneously on CPU 1. WARNING trace (17:44:49 event, same boot, earlier) WARNING: kernel/workqueue.c:2350 at __queue_work.part.0+0x190/0x390, CPU#4: swapper/4/0 WARNING: kernel/workqueue.c:2350 at __queue_work.part.0+0x190/0x390, CPU#11: swapper/11/0 WARNING: kernel/workqueue.c:2350 at __queue_work.part.0+0x190/0x390, CPU#8: swapper/8/0 Modules linked in: nft_ct, wireguard, libcurve25519, ip6_udp_tunnel, udp_tunnel, nf_conntrack_netlink, xt_nat, xt_tcpudp, veth, xt_multiport, xt_conntrack, xt_MASQUERADE, xfrm_user, xfrm_algo, xt_set, ip_set, nft_chain_nat, nf_nat, nf_conntrack, nf_defrag_ipv6, nf_defrag_ipv4, nft_compat, nf_tables, virtiofs, serio_raw, vmw_vsock_virtio_transport, virtio_dma_buf, vsock, virtio_rng, autofs4, libahci, netconsole, virtio_gpu, psmouse, hid_generic, ahci, usbhid, hid Analysis The crash occurs in the timer interrupt path during CPU idle: 1. CPU is idle (pv_native_safe_halt / do_idle) 2. APIC timer interrupt fires 3. __run_timers expires a delayed_work timer 4. delayed_work_timer_fn calls __queue_work 5. __queue_work dereferences a NULL pointer (pwq/pool is NULL) The Tainted [W] flag confirms a prior WARN at the same code path. The simultaneous occurrence on two CPUs suggests a race condition during workqueue teardown — a delayed_work timer fires after the workqueue's cpu_pwq has been nullified by destroy_workqueue(). This matches the upstream pattern described in: - Tim Van Patten's patch "workqueue: Prevent delayed work UAF kernel panic" (June 2024): LKML — adds NULL check for pwq/pool in __queue_work - Tejun Heo's response and removal of WARN_ON_ONCE(!wq) (March 2026): GitHub mirror Related bugs - Launchpad #2068103 — same pattern on kernel 6.8.0-35 (workqueue.c:1790) - bugzilla.kernel.org #218288 — same pattern on kernel 6.6 (workqueue.c:1638) Availability of fix Kernel 7.0.0-26.26 is in resolute-proposed and includes upstream stable releases v7.0.1 through v7.0.6. It is unclear whether the workqueue UAF fix is included in those stable releases. The guest currently has 7.0.0-22.22 installed with no upgradable kernel in updates/security. Workaround None known. Rebooting after a virsh reset recovers the guest. ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2157584 Title: Kernel NULL pointer dereference in __queue_work via delayed_work_timer_fn on 7.0.0-22-generic (Ubuntu 26.04) Status in linux package in Ubuntu: New Bug description: Package: linux Affects: Ubuntu 26.04 (resolute) Description A QEMU/KVM virtio guest running Ubuntu 26.04 with kernel 7.0.0-22-generic froze completely. The guest agent stopped responding, SSH timed out, and the VM required a virsh reset to recover. Investigation of the previous boot's journal revealed a kernel NULL pointer dereference in __queue_work, preceded by a WARNING at the same location on a separate occasion earlier in the same boot. This matches a known upstream workqueue use-after-free / NULL- deref pattern where delayed work is queued to a workqueue that has been destroyed (wq->cpu_pwq nullified), causing a NULL pointer dereference when the delayed timer fires and calls delayed_work_timer_fn -> __queue_work. Steps to reproduce Not reliably reproducible. The crash occurs when a delayed_work timer fires after the owning workqueue has been destroyed. The VM had been running for ~2 days under mixed workload (GNOME desktop, Docker containers with nftables/wireguard networking, JetBrains IDEs). Kernel version Linux ubuntu-dev-2024 7.0.0-22-generic #22-Ubuntu SMP PREEMPT_DYNAMIC Mon May 25 15:54:34 UTC 2026 x86_64 GNU/Linux Package: linux-image-7.0.0-22-generic 7.0.0-22.22 Hardware QEMU Standard PC (Q35 + ICH9, 2009), BIOS 2025.11-3ubuntu8 04/09/2026 16 vCPUs, 20GB RAM, virtio-blk + virtio-net + virtiofs + virtio-gpu Kernel command line BOOT_IMAGE=/boot/vmlinuz-7.0.0-22-generic root=UUID=25a32e36-0866-4e02-b7ef-0703c8b6d784 ro zswap.enabled=1 zswap.compressor=zstd zswap.zpool=zsmalloc zswap.max_pool_percent=30 splash plymouth crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M Timeline 1. 17:44:49 — WARNING at kernel/workqueue.c:2350 on CPUs 4, 11, 8 (swapper/idle). VM continued running. 2. 19:06:42 — BUG: kernel NULL pointer dereference on CPUs 9 and 1 (swapper/idle). VM froze. Oops trace (19:06:42 event) BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page CPU: 9 UID: 0 PID: 0 Comm: swapper/9 Tainted: G W 7.0.0-22-generic #22-Ubuntu PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 2025.11-3ubuntu8 04/09/2026 RIP: 0010:__queue_work.part.0+0x190/0x390 Code: ... <0f> 0b e9 65 ff ff ff ... RSP: 0018:ffffcce10016cdd8 EFLAGS: 00010003 RAX: ffff8c35a542f2c0 RBX: ffff8c35a542f2b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffcce10016ce10 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8c392bab2680 R13: 0000000000002000 R14: ffff8c34c0386c00 R15: ffff8c34c0389200 FS: 0000000000000000(0000) GS:ffff8c3980880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000072ea901a3fb8 CR3: 0000000199a02000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <IRQ> __queue_work+0x39/0xc0 ? __pfx_delayed_work_timer_fn+0x10/0x10 delayed_work_timer_fn+0x19/0x30 call_timer_fn+0x30/0x170 ? __pfx_delayed_work_timer_fn+0x10/0x10 __run_timers+0x1af/0x2c0 run_timer_softirq+0x8a/0x100 handle_softirqs+0xe1/0x360 __irq_exit_rcu+0x100/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x9f/0xd0 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1b/0x20 RIP: 0010:pv_native_safe_halt+0xb/0x10 ... arch_cpu_idle+0x9/0x10 default_idle_call+0x2f/0x130 cpuidle_idle_call+0x114/0x1f0 do_idle+0x94/0xf0 cpu_startup_entry+0x29/0x30 start_secondary+0x125/0x180 ? soft_restart_cpu+0x14/0x14 common_startup_64+0x13e/0x141 </TASK> ---[ end trace 0000000000000000 ]--- A second identical oops was logged simultaneously on CPU 1. WARNING trace (17:44:49 event, same boot, earlier) WARNING: kernel/workqueue.c:2350 at __queue_work.part.0+0x190/0x390, CPU#4: swapper/4/0 WARNING: kernel/workqueue.c:2350 at __queue_work.part.0+0x190/0x390, CPU#11: swapper/11/0 WARNING: kernel/workqueue.c:2350 at __queue_work.part.0+0x190/0x390, CPU#8: swapper/8/0 Modules linked in: nft_ct, wireguard, libcurve25519, ip6_udp_tunnel, udp_tunnel, nf_conntrack_netlink, xt_nat, xt_tcpudp, veth, xt_multiport, xt_conntrack, xt_MASQUERADE, xfrm_user, xfrm_algo, xt_set, ip_set, nft_chain_nat, nf_nat, nf_conntrack, nf_defrag_ipv6, nf_defrag_ipv4, nft_compat, nf_tables, virtiofs, serio_raw, vmw_vsock_virtio_transport, virtio_dma_buf, vsock, virtio_rng, autofs4, libahci, netconsole, virtio_gpu, psmouse, hid_generic, ahci, usbhid, hid Analysis The crash occurs in the timer interrupt path during CPU idle: 1. CPU is idle (pv_native_safe_halt / do_idle) 2. APIC timer interrupt fires 3. __run_timers expires a delayed_work timer 4. delayed_work_timer_fn calls __queue_work 5. __queue_work dereferences a NULL pointer (pwq/pool is NULL) The Tainted [W] flag confirms a prior WARN at the same code path. The simultaneous occurrence on two CPUs suggests a race condition during workqueue teardown — a delayed_work timer fires after the workqueue's cpu_pwq has been nullified by destroy_workqueue(). This matches the upstream pattern described in: - Tim Van Patten's patch "workqueue: Prevent delayed work UAF kernel panic" (June 2024): LKML — adds NULL check for pwq/pool in __queue_work - Tejun Heo's response and removal of WARN_ON_ONCE(!wq) (March 2026): GitHub mirror Related bugs - Launchpad #2068103 — same pattern on kernel 6.8.0-35 (workqueue.c:1790) - bugzilla.kernel.org #218288 — same pattern on kernel 6.6 (workqueue.c:1638) Availability of fix Kernel 7.0.0-26.26 is in resolute-proposed and includes upstream stable releases v7.0.1 through v7.0.6. It is unclear whether the workqueue UAF fix is included in those stable releases. The guest currently has 7.0.0-22.22 installed with no upgradable kernel in updates/security. Workaround None known. Rebooting after a virsh reset recovers the guest. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2157584/+subscriptions
[Bug 2155617] Re: Backlight device disappears and brightness breaks on kernel 6.17.0-23+ (Lenovo Legion 5 Pro, NVIDIA hybrid graphics)
Hi An, Sorry for the delay. I ran the requested commands. Here is copy-paste of the terminal in the different kernels: 6.17.0-35 kernel (broken): ``` vesa@vesa-Legion-5-Pro-16ACH6H:~$ lsmod | grep nvidia vesa@vesa-Legion-5-Pro-16ACH6H:~$ sudo dkms status [sudo] password for vesa: sudo: dkms: command not found vesa@vesa-Legion-5-Pro-16ACH6H:~$ ``` 6.17.0-22 kernel (working): ``` vesa@vesa-Legion-5-Pro-16ACH6H:~$ lsmod | grep nvidia nvidia_uvm 2039808 0 nvidia_drm 131072 12 nvidia_modeset 1548288 12 nvidia_drm nvidia 90587136 197 nvidia_uvm,nvidia_drm,nvidia_modeset drm_ttm_helper 16384 1 nvidia_drm video 77824 2 ideapad_laptop,nvidia_modeset vesa@vesa-Legion-5-Pro-16ACH6H:~$ sudo dkms status [sudo] password for vesa: sudo: dkms: command not found vesa@vesa-Legion-5-Pro-16ACH6H:~$ ``` -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2155617 Title: Backlight device disappears and brightness breaks on kernel 6.17.0-23+ (Lenovo Legion 5 Pro, NVIDIA hybrid graphics) Status in linux package in Ubuntu: New Bug description: On Ubuntu 24.04.2 LTS running on a Lenovo Legion 5 Pro 16ACH6H (AMD + NVIDIA RTX 3070 hybrid system), brightness control breaks starting from kernel 6.17.0-23-generic and remains broken on all newer kernels up to 6.17.0-35. The issue is fully reproducible. WORKING KERNEL: - 6.17.0-22-generic - Display session: X11 - NVIDIA proprietary driver in use - Backlight device present: /sys/class/backlight/nvidia_0 - Brightness control works normally BROKEN KERNELS: - 6.17.0-23-generic and newer (tested up to 6.17.0-35) - Wayland or X11 both affected - Backlight directory is empty: /sys/class/backlight/ SYMPTOMS: - Brightness stuck at 100% - No backlight device exposed in sysfs - Mouse cursor shows trailing/ghosting artifacts on Wayland - Display rendering instability EXPECTED BEHAVIOR: - /sys/class/backlight/nvidia_0 should be present - Brightness control should function via NVIDIA DRM backlight interface ACTUAL BEHAVIOR: - No backlight device is registered at all in /sys/class/backlight/ - GNOME brightness controls have no effect HARDWARE: - Lenovo Legion 5 Pro 16ACH6H - AMD Ryzen CPU (iGPU present but not used for display in working kernel) - NVIDIA RTX 3070 Mobile (primary display output via nvidia-drm) - NVIDIA proprietary driver active REGRESSION: - Kernel 6.17.0-22 works correctly - 6.17.0-23 introduces regression and all newer kernels inherit it This appears to be a regression in NVIDIA DRM backlight device registration (fbdev / sysfs exposure). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2155617/+subscriptions
четверг
[Bug 2154194] Re: [Jammy] Priority inversion problem in epoll for rt kernel
** Changed in: linux (Ubuntu) Status: New => Fix Released ** Changed in: linux (Ubuntu Jammy) Status: New => In Progress -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2154194 Title: [Jammy] Priority inversion problem in epoll for rt kernel Status in linux package in Ubuntu: Fix Released Status in linux source package in Jammy: In Progress Status in linux source package in Noble: Fix Released Status in linux source package in Resolute: Fix Released Bug description: [SRU Justification] [Impact] The current epoll implementation in the 5.15 kernel utilizes a read-write semaphore (rwlock_t) to protect the ready event list. While this allows multiple producers to concurrently add items, it introduces a scheduling priority inversion vulnerability. If a high-priority consumer, such as a real-time thread calling epoll_wait, is blocked waiting for the exclusive write lock, it can be indefinitely stalled by a low-priority producer holding the read lock. This results in un-deterministic system stalls and latency spikes. This was observed on the 5.15.0-1087-realtime kernel, where a high-priority hardware IRQ thread was blocked by a low-priority worker thread holding the epoll read lock while throttled by CFS CPU quota limits. Because PREEMPT_RT does not extend priority inheritance to rwlock readers, the IRQ thread had no mechanism to boost the throttled worker, resulting in a deadlock. [Fix] Cherry-pick upstream commit: 0c43094f8cc9 ("eventpoll: Replace rwlock with spinlock") The fix involves replacing rwlock_t with spinlock_t, and removing the now-redundant lockless helper functions (list_add_tail_lockless and chain_epi_lockless). This ensures that under real-time configurations, priority inheritance works correctly across the epoll subsystem. [Test Plan] This is a priority inversion race condition, so it is highly non-deterministic and impractical to trigger on command. This is why it is not feasable to provide a reliable reproduction script. Therefore, validation relies on verifying that the replacement locking mechanism functions correctly, introduces no regressions, and scales safely under synthetic load. Validation was performed on a 2-core/4GB RAM x86 VM running the test kernel in the following PPA: https://launchpad.net/~munirsid/+archive/ubuntu/lp2154194. As mentioned in the upstream commit, we ran `perf bench epoll wait` with 4 threads (-t 4) and 10 iterations (-r 10). By configuring 4 threads on a 2-core VM, we intentionally overcommit the CPUs to force heavy context-switching and lock preemption in order to stress-test the new spinlock boundaries under contention. Observed Results: Before patch (5.15.0-179-generic #189-Ubuntu): $ perf bench epoll wait -t 4 -r 10 [thread 0] fdmap: 0x556599b44e80 ... 0x556599b44f7c [ 281994 ops/sec ] [thread 1] fdmap: 0x556599b451a0 ... 0x556599b4529c [ 279775 ops/sec ] [thread 2] fdmap: 0x556599b45420 ... 0x556599b4551c [ 267177 ops/sec ] [thread 3] fdmap: 0x556599b456a0 ... 0x556599b4579c [ 270819 ops/sec ] Averaged 274941 operations/sec (+- 1.29%), total secs = 10 After patch (5.15.0-183-generic #193+TEST427638v20260525b1-Ubuntu): $ perf bench epoll wait -t 4 -r 10 [thread 0] fdmap: 0x55a665734e80 ... 0x55a665734f7c [ 291941 ops/sec ] [thread 1] fdmap: 0x55a6657351a0 ... 0x55a66573529c [ 306480 ops/sec ] [thread 2] fdmap: 0x55a665735420 ... 0x55a66573551c [ 286868 ops/sec ] [thread 3] fdmap: 0x55a6657356a0 ... 0x55a66573579c [ 312054 ops/sec ] Averaged 299335 operations/sec (+- 1.98%), total secs = 10 Consistent with the upstream commit description for x86, we observed per-thread throughput improve across all 4 threads, with ~8.9% improvement in average throughput. No regression was observed and the logs showed no lockups, RCU stalls, or kernel warnings across multiple iterations. [Where Problems Could Occur] There could be a performance degradation with some synthetic workloads on the GA kernel as seen in the upstream commit description [0]. In artificial benchmarks where hundreds of threads continuously spam epoll events, throughput can drop due to serialization around the new spinlock. However, testing with realistic workloads (via perf bench epoll wait) actually demonstrates a performance improvement on x86 architectures, as mentioned in the upstream commit, and demonstrated in the Test Plan section above. The regression potential for real-world production environments is low, as typical workloads do not exhibit continuous, uninterrupted event-spamming behavior. Moreover, the fix is strictly isolated to fs/eventpoll.c and is already available on Noble and Resolute, where it has been thoroughly tested. [Other Info] Similar issues have been reported in [1] and [2]. This bug was addressed upstream [0] and the fix has already been integrated into Noble and subsequent releases. Backporting this fix ensures stability for users of the 5.15 real- time kernel. [0] - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c43094f8cc9d3d99d835c0ac9c4fe1ccc62babd [1] - https://lore.kernel.org/linux-rt-users/xhsmhttqvnall.mognet@vschneid.remote.csb/ [2] - https://lore.kernel.org/linux-rt-users/20210825132754.GA895675@lothringen/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2154194/+subscriptions
[Bug 2157524] Re: HP ZBook Firefly G8 hard lock in Intel i915 DRM atomic cursor plane path
** Description changed: System: HP ZBook Firefly G8 laptop, Intel Iris Xe / Tiger Lake graphics, Xubuntu/Ubuntu 26.04. Problem: The system intermittently hard-locks and requires forced power-off. The power LED remains on, the system becomes completely unresponsive, and previous crashes showed Caps Lock LED flickering/blinking. This is not a normal application crash or clean shutdown. Latest crash: On 2026-06-18 the boot ended abruptly at 10:59:06 MDT. The next boot started at 11:00:45 MDT. kdump was enabled and reported ready, with crashkernel memory reserved, but no vmcore was captured. /var/crash contained only kdump_lock and kexec_cmd for the hard lock. This suggests a hard hang/deadlock rather than a clean kernel panic. Kernel/debug configuration at time of crash: The system was booted with: zswap.enabled=1 i915.enable_psr=0 i915.enable_dc=0 i915.enable_fbc=0 drm.debug=0x1e log_buf_len=4M XFCE compositor was already disabled. Intel OpenCL packages had been removed. The crash therefore appears unrelated to compositor effects or OpenCL workloads. Observed kernel evidence: The final kernel messages before logging stopped repeatedly show i915 / DRM atomic cursor-plane updates on the same pipe/plane: [CRTC:584:pipe D] with [PLANE:578:cursor D] drm_atomic_set_fb_for_plane intel_plane_atomic_calc_changes visible 1 -> 1, off 0, on 0, ms 0 The same cursor D / pipe D messages repeat continuously at the final timestamp, 2026-06-18 10:59:06, until logging stops. No clean shutdown, panic, oops, or vmcore was captured. Earlier related crash evidence: Previous crashes also pointed at Intel i915 / DRM display handling, including stack traces involving: - i915_hotplug_work_func [i915] - drm_kms_helper_connector_hotplug_event - drm_atomic_commit - intel_atomic_commit - intel_audio_codec_disable Expected result: The system should remain responsive during normal desktop use. Actual result: The system hard-locks and requires forced power-off, risking data loss. Impact: High/severe. Full system lockup. Suspected area: Intel i915 / DRM atomic modesetting, specifically hardware cursor plane handling on pipe D. External display/dock involvement is possible but not fully proven. Next test: I will force Xorg software cursor using the modesetting driver option SWCursor=true. If this stops the crashes, I will update the bug because the final logs currently point strongly at the hardware cursor plane path. + + imwheel was running because without it the mouse wheel does not work + correctly in QGIS on this system. It may increase scroll/input event + handling, but it is a user-space X11 tool and should not be able to + hard-lock the kernel. The final kernel logs point to i915 DRM cursor- + plane updates. Attachments provided: - previous-boot-kernel-full.txt - previous-boot-kernel-filtered.txt - previous-boot-end.txt - boots.txt - cmdline.txt - uname.txt - version_signature.txt - lspci-vvnn.txt - xrandr.txt - kdump-status.txt - var-crash-files.txt - system-product.txt - bios-version.txt - bios-release-date.txt ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-22-generic 7.0.0-22.22 ProcVersionSignature: Ubuntu 7.0.0-22.22-generic 7.0.0 Uname: Linux 7.0.0-22-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: notabrick 2889 F.... pipewire notabrick 2898 F.... wireplumber /dev/snd/controlC1: notabrick 2898 F.... wireplumber /dev/snd/seq: notabrick 2889 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: XFCE Date: Thu Jun 18 11:11:29 2026 InstallationDate: Installed on 2026-05-10 (39 days ago) InstallationMedia: Xubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: HP HP ZBook Firefly 14 inch G8 Mobile Workstation PC ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-22-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash zswap.enabled=1 i915.enable_psr=0 i915.enable_dc=0 i915.enable_fbc=0 drm.debug=0x1e log_buf_len=4M crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/06/2026 dmi.bios.release: 24.1 dmi.bios.vendor: HP dmi.bios.version: T76 Ver. 01.24.01 dmi.board.name: 880D dmi.board.vendor: HP dmi.board.version: KBC Version 30.57.00 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.ec.firmware.release: 48.87 dmi.modalias: dmi:bvnHP:bvrT76Ver.01.24.01:bd03/06/2026:br24.1:efr48.87:svnHP:pnHPZBookFirefly14inchG8MobileWorkstationPC:pvrSBKPFV3:rvnHP:rn880D:rvrKBCVersion30.57.00:cvnHP:ct10:cvr:sku3V328UT#ABA:pfa103C_5336ANHPZBook: dmi.product.family: 103C_5336AN HP ZBook dmi.product.name: HP ZBook Firefly 14 inch G8 Mobile Workstation PC dmi.product.sku: 3V328UT#ABA dmi.product.version: SBKPFV3 dmi.sys.vendor: HP -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2157524 Title: HP ZBook Firefly G8 hard lock in Intel i915 DRM atomic cursor plane path Status in linux package in Ubuntu: New Bug description: System: HP ZBook Firefly G8 laptop, Intel Iris Xe / Tiger Lake graphics, Xubuntu/Ubuntu 26.04. Problem: The system intermittently hard-locks and requires forced power-off. The power LED remains on, the system becomes completely unresponsive, and previous crashes showed Caps Lock LED flickering/blinking. This is not a normal application crash or clean shutdown. Latest crash: On 2026-06-18 the boot ended abruptly at 10:59:06 MDT. The next boot started at 11:00:45 MDT. kdump was enabled and reported ready, with crashkernel memory reserved, but no vmcore was captured. /var/crash contained only kdump_lock and kexec_cmd for the hard lock. This suggests a hard hang/deadlock rather than a clean kernel panic. Kernel/debug configuration at time of crash: The system was booted with: zswap.enabled=1 i915.enable_psr=0 i915.enable_dc=0 i915.enable_fbc=0 drm.debug=0x1e log_buf_len=4M XFCE compositor was already disabled. Intel OpenCL packages had been removed. The crash therefore appears unrelated to compositor effects or OpenCL workloads. Observed kernel evidence: The final kernel messages before logging stopped repeatedly show i915 / DRM atomic cursor-plane updates on the same pipe/plane: [CRTC:584:pipe D] with [PLANE:578:cursor D] drm_atomic_set_fb_for_plane intel_plane_atomic_calc_changes visible 1 -> 1, off 0, on 0, ms 0 The same cursor D / pipe D messages repeat continuously at the final timestamp, 2026-06-18 10:59:06, until logging stops. No clean shutdown, panic, oops, or vmcore was captured. Earlier related crash evidence: Previous crashes also pointed at Intel i915 / DRM display handling, including stack traces involving: - i915_hotplug_work_func [i915] - drm_kms_helper_connector_hotplug_event - drm_atomic_commit - intel_atomic_commit - intel_audio_codec_disable Expected result: The system should remain responsive during normal desktop use. Actual result: The system hard-locks and requires forced power-off, risking data loss. Impact: High/severe. Full system lockup. Suspected area: Intel i915 / DRM atomic modesetting, specifically hardware cursor plane handling on pipe D. External display/dock involvement is possible but not fully proven. Next test: I will force Xorg software cursor using the modesetting driver option SWCursor=true. If this stops the crashes, I will update the bug because the final logs currently point strongly at the hardware cursor plane path. imwheel was running because without it the mouse wheel does not work correctly in QGIS on this system. It may increase scroll/input event handling, but it is a user-space X11 tool and should not be able to hard-lock the kernel. The final kernel logs point to i915 DRM cursor- plane updates. Attachments provided: - previous-boot-kernel-full.txt - previous-boot-kernel-filtered.txt - previous-boot-end.txt - boots.txt - cmdline.txt - uname.txt - version_signature.txt - lspci-vvnn.txt - xrandr.txt - kdump-status.txt - var-crash-files.txt - system-product.txt - bios-version.txt - bios-release-date.txt ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-22-generic 7.0.0-22.22 ProcVersionSignature: Ubuntu 7.0.0-22.22-generic 7.0.0 Uname: Linux 7.0.0-22-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: notabrick 2889 F.... pipewire notabrick 2898 F.... wireplumber /dev/snd/controlC1: notabrick 2898 F.... wireplumber /dev/snd/seq: notabrick 2889 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: XFCE Date: Thu Jun 18 11:11:29 2026 InstallationDate: Installed on 2026-05-10 (39 days ago) InstallationMedia: Xubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: HP HP ZBook Firefly 14 inch G8 Mobile Workstation PC ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-22-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash zswap.enabled=1 i915.enable_psr=0 i915.enable_dc=0 i915.enable_fbc=0 drm.debug=0x1e log_buf_len=4M crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/06/2026 dmi.bios.release: 24.1 dmi.bios.vendor: HP dmi.bios.version: T76 Ver. 01.24.01 dmi.board.name: 880D dmi.board.vendor: HP dmi.board.version: KBC Version 30.57.00 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.ec.firmware.release: 48.87 dmi.modalias: dmi:bvnHP:bvrT76Ver.01.24.01:bd03/06/2026:br24.1:efr48.87:svnHP:pnHPZBookFirefly14inchG8MobileWorkstationPC:pvrSBKPFV3:rvnHP:rn880D:rvrKBCVersion30.57.00:cvnHP:ct10:cvr:sku3V328UT#ABA:pfa103C_5336ANHPZBook: dmi.product.family: 103C_5336AN HP ZBook dmi.product.name: HP ZBook Firefly 14 inch G8 Mobile Workstation PC dmi.product.sku: 3V328UT#ABA dmi.product.version: SBKPFV3 dmi.sys.vendor: HP To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2157524/+subscriptions
[Bug 2150819] Re: Internal webcam does not work on Lenovo 21Q7000LBR after fresh Ubuntu 26.04 install.
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: linux (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2150819 Title: Internal webcam does not work on Lenovo 21Q7000LBR after fresh Ubuntu 26.04 install. Status in linux package in Ubuntu: Confirmed Bug description: Internal webcam does not work on Lenovo 21Q7000LBR after fresh Ubuntu 26.04 install. This appears related to Ubuntu bug #2107320: https://bugs.launchpad.net/bugs/2107320 That bug added support for the Sony IMX471 / SONY471A camera sensor on Intel IPU7 platforms. My system detects the same SONY471A sensor, but the IPU7 bridge fails with a duplicate software node error before camera/media devices are created. System: - Lenovo 21Q7000LBR - Ubuntu 26.04 LTS - Kernel: 7.0.0-15-generic - intel-ipu7-dkms: 0~git202602091007.a88b1909-0ubuntu1 - Sensor appears to be Sony IMX471 / SONY471A - BIOS IntegratedCameraAccess: Enable Problem: - No /dev/video* devices are created - No /dev/media* devices are created - Camera apps cannot see the internal webcam Relevant kernel log: Found supported sensor SONY471A:00 sysfs: cannot create duplicate filename '/kernel/software_nodes/SONY471A-0' kobject: kobject_add_internal failed for SONY471A-0 with -EEXIST intel-ipu7 0000:00:05.0: error -EEXIST: IPU bridge init failed intel-ipu7 0000:00:05.0: probe with driver intel-ipu7 failed with error -17 Expected behavior: The IPU7 driver should bind the IMX471 sensor and create camera/media devices, similar to the expected working path from Ubuntu bug #2107320: Found supported sensor SONY471A:00 Connected 1 cameras bind imx471 ... All sensor registration completed ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-15-generic 7.0.0-15.15 ProcVersionSignature: Ubuntu 7.0.0-15.15-generic 7.0.0 Uname: Linux 7.0.0-15-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: portugal 3618 F.... pipewire portugal 3640 F.... wireplumber /dev/snd/seq: portugal 3618 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sat May 2 11:18:01 2026 InstallationDate: Installed on 2026-05-02 (1 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: LENOVO 21Q7000LBR ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color ProcFB: 0 xedrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-15-generic root=UUID=57b10f72-ea94-4402-b27e-a35bf6019678 ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux StagingDrivers: intel_ipu7 UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/06/2025 dmi.bios.release: 1.12 dmi.bios.vendor: LENOVO dmi.bios.version: N4CET36W (1.12 ) dmi.board.asset.tag: Not Available dmi.board.name: 21Q7000LBR dmi.board.vendor: LENOVO dmi.board.version: SDK0T76576 WIN dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.ec.firmware.release: 1.8 dmi.modalias: dmi:bvnLENOVO:bvrN4CET36W(1.12):bd03/06/2025:br1.12:efr1.8:svnLENOVO:pn21Q7000LBR:pvrThinkPadX9-15Gen1:rvnLENOVO:rn21Q7000LBR:rvrSDK0T76576WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_21Q7_BU_Think_FM_ThinkPadX9-15Gen1:pfaThinkPadX9-15Gen1: dmi.product.family: ThinkPad X9-15 Gen 1 dmi.product.name: 21Q7000LBR dmi.product.sku: LENOVO_MT_21Q7_BU_Think_FM_ThinkPad X9-15 Gen 1 dmi.product.version: ThinkPad X9-15 Gen 1 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2150819/+subscriptions
[Bug 2153556] Re: Kernel regression (6.8.0-117.generic)
** Tags removed: verification-done-jammy-linux verification-done-noble-linux verification-done-questing-linux ** Tags added: verification-done-jammy verification-done-noble verification-done-questing -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2153556 Title: Kernel regression (6.8.0-117.generic) Status in linux package in Ubuntu: Fix Committed Status in linux source package in Jammy: Fix Committed Status in linux source package in Noble: Fix Committed Status in linux source package in Questing: Fix Committed Bug description: There is a regression for the CVE-2026-31419 patch in kernel 117.generic that was supposed to fix a vulnerability in bonding mode 3. This patch caused mode 3 bonding to completely break on a production cluster. We were able to recover services by booting on a .111 fallback. Hardware is ConnectX-6 at 100G, all interfaces, links and bonding status appear to be up but no packets are passed. Unfortunately, this is a production system so it's now on an older kernel so testing isn't possible. If necessary, I can bring up a pair of VMs to run some tests for this. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2153556/+subscriptions
[Bug 2154748] Comment bridged from LTC Bugzilla
------- Comment From Boris.mail@de.ibm.com 2026-06-18 06:13 EDT------- That's awesome Massimiliano, thanks a lot for your work! -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2154748 Title: [Ubuntu 26.04] Severe Performance Degradation on kernel 7.0.0-15 Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: In Progress Bug description: [ Impact ] s390 selects GENERIC_LOCKBREAK if PREEMPT is enabled. Reason is a historic 18 years old commit [1] which fixed a compile error for PREEMPT enabled kernels. Back than only PREEMPT_NONE and PREEMPT_VOLUNTARY kernels were considered to be important for s390. PREEMPT should "just work". However, since recently PREEMPT is always enabled [2], which also causes GENERIC_LOCKBREAK to be always enabled. For some workloads this leads to massive performance degradation; e.g. a simple kernel compile on machines with many CPUs may take up to four times longer. To fix this just remove the GENERIC_LOCKBREAK from s390's Kconfig, since the compile error from 18 years ago does not exist anymore. [1] commit b6b40c532a36 ("[S390] Define GENERIC_LOCKBREAK.") [2] commit 7dadeaa6e851 ("sched: Further restrict the preemption modes") [ Fix ] Backport commit: 1f57f68c4dd1 ("s390: Remove GENERIC_LOCKBREAK Kconfig option") [ Test Plan ] Compile and boot tested. Tested performance by compiling a kernel and monitoring execution with perf. [ Regression Potential ] The regression potential of the patch is low. It affects only s390x spinlock implementation. --- == Comment: #2 - Mete Durlu <Mete.Durlu@ibm.com> - 2026-06-01 08:59:07 == ---Problem Description--- Ubuntu 26.04 shows massive performance degradation. On large machines with more than 20 COREs (40 CPUs with SMT) CPU bound workloads suffer greatly. Ex: linux kernel compilation takes >10x more time Resource utilization shows up to 100% system time during the workload. perf top output indicates excessive lock contention in the kernel. $ make -j$(nproc) $ perf top 52.41% [kernel] [k] arch_spin_trylock_retry 8.76% [kernel] [k] _raw_spin_lock_irqsave 2.03% [kernel] [k] arch_spin_relax 1.09% cc1 [.] ht_lookup_with_hash(ht*, unsigned char 0.97% [kernel] [k] diag49c 0.95% [kernel] [k] lru_gen_add_folio 0.80% [kernel] [k] post_alloc_hook.localalias 0.77% [kernel] [k] lru_gen_del_folio.constprop.0 0.63% cc1 [.] htab_find_slot_with_hash 0.60% [kernel] [k] folios_put_refs 0.49% [kernel] [k] arch_vcpu_is_preempted 0.48% cc1 [.] ggc_internal_alloc_no_dtor(unsigned lo 0.44% cc1 [.] _cpp_lex_direct ... The lock contention seems to be linked directly to the thread count on the workload; # on a system with 34 COREs (68 CPUs w SMT) $ make -j20 perf top shows no arch_spin_trylock_retry $ make -j25 perf top shows ~2% arch_spin_trylock_retry $ make -j30 perf top shows ~5% arch_spin_trylock_retry $ make -j34 # thread count = core count perf top shows ~15% arch_spin_trylock_retry $ make -j40 # thread count > core count perf top shows >30% arch_spin_trylock_retry There has also been hints of delays on workqueue execution in dmesg output: ... [10600.136975] workqueue: vmstat_update hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND [10806.428576] workqueue: delayed_vfree_work hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND [10819.822422] workqueue: delayed_vfree_work hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND [10885.381900] workqueue: delayed_vfree_work hogged CPU for >10000us 7 times, consider switching to WQ_UNBOUND [10915.209117] workqueue: pcpu_balance_workfn hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND [11059.719121] workqueue: pcpu_balance_workfn hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND [20223.529295] workqueue: inode_switch_wbs_work_fn hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND [22584.374168] workqueue: mmput_async_fn hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND [22602.115559] workqueue: delayed_vfree_work hogged CPU for >10000us 11 times, consider switching to WQ_UNBOUND [22817.328172] workqueue: vmstat_update hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND [22840.202092] workqueue: delayed_vfree_work hogged CPU for >10000us 19 times, consider switching to WQ_UNBOUND [26834.512017] workqueue: delayed_vfree_work hogged CPU for >10000us 35 times, consider switching to WQ_UNBOUND [26883.480296] workqueue: vmstat_update hogged CPU for >10000us 7 times, consider switching to WQ_UNBOUND ... Systems with less COREs don't seem to be effected. The limit seems to be around 15 COREs (30 CPUs) ---uname output--- Linux localhost 7.0.0-15-generic #15-Ubuntu SMP PREEMPT Wed Apr 22 15:04:00 UTC 2026 s390x GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2154748/+subscriptions
[Bug 2147427] Re: Failed to add generic LLDP Rx filter on VSI 13 error
Hi Jeff, This bug can be closed -- we confirmed that the latest image already fixed it. Thanks. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2147427 Title: Failed to add generic LLDP Rx filter on VSI 13 error Status in linux package in Ubuntu: New Bug description: 1.Install Ubuntu 26.04/20260302/ (resolute-live-server-amd64) 2.Check dmesg and observe "Failed to add generic LLDP Rx filter on VSI 13 error: -5, falling back to specialized AQ control" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2147427/+subscriptions
[Bug 2155161] Re: Jabra Evolve 2 85 headset keeps reconnecting via usb
Hi Alexander Thank you for your patience, I would like to ask you to do a test. please run the command: ``` echo "blacklist snd_usb_audio" | sudo tee /etc/modprobe.d/no-usb-audio.conf sudo reboot ``` After reboot, please help me to check if connection stable (no sound is expected). If yes, please remove the no-usb-audio.conf file and run command ``` echo "options snd-usb-audio quirk_flags=0b0e:24ca:SKIP_IFACE_SETUP" | \ sudo tee /etc/modprobe.d/jabra-audio-test.conf sudo reboot ``` See if issue happen again. BR An -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2155161 Title: Jabra Evolve 2 85 headset keeps reconnecting via usb Status in linux package in Ubuntu: New Bug description: As soon as i want to use any kind of usb connection with the headset the usb connects and reconnects over and over again. I made sure its not an issue of cable used or the usb hub in the docking station. by connecting it directly to the laptop. Although i could use usb with this headset on ubuntu lts 24 without any issues since i reinstalled with kubuntu 26 this occurs (guess it would happen in ubuntu 26 too) I gladly provide more info if needed. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-22-generic 7.0.0-22.22 ProcVersionSignature: Ubuntu 7.0.0-22.22-generic 7.0.0 Uname: Linux 7.0.0-22-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Wed Jun 3 16:10:16 2026 InstallationDate: Installed on 2026-05-12 (22 days ago) InstallationMedia: Kubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423) IwDevWlp0s20f3Link: Not connected. MachineType: Dell Inc. Precision 3581 ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-22-generic root=UUID=e1d7f812-2942-4efe-80f9-510636bb0378 ro quiet cryptdevice=UUID=24e90ca6-128d-41d3-be29-328e50acf97d:luks-24e90ca6-128d-41d3-be29-328e50acf97d root=/dev/mapper/luks-24e90ca6-128d-41d3-be29-328e50acf97d splash nvidia-drm.modeset=1 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/12/2025 dmi.bios.release: 1.27 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.27.1 dmi.board.name: 0V8YXF dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.ec.firmware.release: 1.25 dmi.modalias: dmi:bvnDellInc.:bvr1.27.1:bd12/12/2025:br1.27:efr1.25:svnDellInc.:pnPrecision3581:pvr:rvnDellInc.:rn0V8YXF:rvrA00:cvnDellInc.:ct10:cvr:sku0C07:pfaPrecision: dmi.product.family: Precision dmi.product.name: Precision 3581 dmi.product.sku: 0C07 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2155161/+subscriptions
среда
[Bug 2157079] [NEW] ubuntu 26.04 freeze on ThinkPad P1 Gen 8
Public bug reported: I just left my laptop with lock screen, the 26.04 is freeze when I return. Kernel: 7.0.0-22-generic BIOS: N4EET22W (1.08 ) Jun 18 11:19:49 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* Timeout waiting for DDI BUF A to get active Jun 18 11:19:50 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* Timed out waiting for DP idle patterns Jun 18 11:20:00 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] flip_done timed out Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] mismatch in pixel_rate (expected 604999, found 45891) Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] mismatch in dpll_hw_state·· Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* expected: Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* cx0pll_hw_state: lane_count: 4, ssc_enabled: no, use_c10: yes, tbt_mode: no Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* c10pll_hw_state: clock: 810000, fracen: yes,· Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* quot: 61440, rem: 0, den: 1, Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* multiplier: 210, tx_clk_div: 0. Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* c10pll_rawhw_state: Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* tx: 0x10, cmn: 0x21 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[0] = 0x34, pll[1] = 0x0, pll[2] = 0x84, pll[3] = 0x1 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[4] = 0x0, pll[5] = 0x0, pll[6] = 0x0, pll[7] = 0x0 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[8] = 0x0, pll[9] = 0x1, pll[10] = 0x0, pll[11] = 0x0 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[12] = 0xf0, pll[13] = 0x0, pll[14] = 0x0, pll[15] = 0x0 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[16] = 0x84, pll[17] = 0xf, pll[18] = 0xe5, pll[19] = 0x23 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* found: Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* cx0pll_hw_state: lane_count: 4, ssc_enabled: no, use_c10: yes, tbt_mode: no Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* c10pll_hw_state: clock: 61440, fracen: no,· Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* multiplier: 16, tx_clk_div: 0. Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* c10pll_rawhw_state: Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* tx: 0x0, cmn: 0x0 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[0] = 0x0, pll[1] = 0x0, pll[2] = 0x0, pll[3] = 0x0 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[4] = 0x0, pll[5] = 0x0, pll[6] = 0x0, pll[7] = 0x0 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[8] = 0x0, pll[9] = 0x0, pll[10] = 0x0, pll[11] = 0x0 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[12] = 0x0, pll[13] = 0x0, pll[14] = 0x0, pll[15] = 0x0 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[16] = 0x0, pll[17] = 0x0, pll[18] = 0x0, pll[19] = 0x0 Jun 18 11:20:01 Curie2 kernel: ------------[ cut here ]------------ Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] pipe state doesn't match! Jun 18 11:20:01 Curie2 kernel: WARNING: drivers/gpu/drm/i915/display/intel_modeset_verify.c:225 at verify_crtc_state+0x349/0x5c0 [i915], CPU#1: KMS thread/4149 Jun 18 11:20:01 Curie2 kernel: Call Trace: Jun 18 11:20:01 Curie2 kernel: <TASK> Jun 18 11:20:01 Curie2 kernel: intel_modeset_verify_crtc+0x4f/0xb0 [i915] Jun 18 11:20:01 Curie2 kernel: intel_atomic_commit_tail+0x8a3/0xc50 [i915] Jun 18 11:20:01 Curie2 kernel: intel_atomic_commit+0x28e/0x2e0 [i915] Jun 18 11:20:01 Curie2 kernel: drm_atomic_commit+0xad/0xf0 Jun 18 11:20:01 Curie2 kernel: ? __pfx___drm_printfn_info+0x10/0x10 Jun 18 11:20:01 Curie2 kernel: drm_mode_atomic_ioctl+0x7d1/0x910 Jun 18 11:20:01 Curie2 kernel: ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 Jun 18 11:20:01 Curie2 kernel: drm_ioctl_kernel+0xb5/0x110 Jun 18 11:20:01 Curie2 kernel: drm_ioctl+0x309/0x5f0 Jun 18 11:20:01 Curie2 kernel: ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 Jun 18 11:20:01 Curie2 kernel: __x64_sys_ioctl+0xa3/0x100 Jun 18 11:20:01 Curie2 kernel: x64_sys_call+0x103b/0x2390 Jun 18 11:20:01 Curie2 kernel: do_syscall_64+0x115/0x5a0 Jun 18 11:20:01 Curie2 kernel: ? check_heap_object+0x146/0x1c0 Jun 18 11:20:01 Curie2 kernel: ? __check_object_size+0x86/0xf0 Jun 18 11:20:01 Curie2 kernel: ? ptep_set_access_flags+0x4a/0x70 Jun 18 11:20:01 Curie2 kernel: ? wp_page_reuse+0x97/0xc0 Jun 18 11:20:01 Curie2 kernel: ? do_wp_page+0x4ee/0x6f0 Jun 18 11:20:01 Curie2 kernel: ? handle_pte_fault+0x1d8/0x1f0 Jun 18 11:20:01 Curie2 kernel: ? __handle_mm_fault+0x493/0x720 Jun 18 11:20:01 Curie2 kernel: ? count_memcg_events+0x103/0x250 Jun 18 11:20:01 Curie2 kernel: ? handle_mm_fault+0x1c0/0x2e0 Jun 18 11:20:01 Curie2 kernel: ? arch_exit_to_user_mode_prepare.isra.0+0xd/0x100 Jun 18 11:20:01 Curie2 kernel: ? irqentry_exit+0x97/0x5a0 Jun 18 11:20:01 Curie2 kernel: ? exc_page_fault+0x94/0x1e0 Jun 18 11:20:01 Curie2 kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e Jun 18 11:20:01 Curie2 kernel: RIP: 0033:0x76eaf7f32cbd ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Attachment added: "crash.log" https://bugs.launchpad.net/bugs/2157079/+attachment/5977950/+files/crash.log -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2157079 Title: ubuntu 26.04 freeze on ThinkPad P1 Gen 8 Status in linux package in Ubuntu: New Bug description: I just left my laptop with lock screen, the 26.04 is freeze when I return. Kernel: 7.0.0-22-generic BIOS: N4EET22W (1.08 ) Jun 18 11:19:49 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* Timeout waiting for DDI BUF A to get active Jun 18 11:19:50 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* Timed out waiting for DP idle patterns Jun 18 11:20:00 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] flip_done timed out Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] mismatch in pixel_rate (expected 604999, found 45891) Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] mismatch in dpll_hw_state·· Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* expected: Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* cx0pll_hw_state: lane_count: 4, ssc_enabled: no, use_c10: yes, tbt_mode: no Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* c10pll_hw_state: clock: 810000, fracen: yes,· Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* quot: 61440, rem: 0, den: 1, Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* multiplier: 210, tx_clk_div: 0. Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* c10pll_rawhw_state: Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* tx: 0x10, cmn: 0x21 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[0] = 0x34, pll[1] = 0x0, pll[2] = 0x84, pll[3] = 0x1 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[4] = 0x0, pll[5] = 0x0, pll[6] = 0x0, pll[7] = 0x0 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[8] = 0x0, pll[9] = 0x1, pll[10] = 0x0, pll[11] = 0x0 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[12] = 0xf0, pll[13] = 0x0, pll[14] = 0x0, pll[15] = 0x0 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[16] = 0x84, pll[17] = 0xf, pll[18] = 0xe5, pll[19] = 0x23 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* found: Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* cx0pll_hw_state: lane_count: 4, ssc_enabled: no, use_c10: yes, tbt_mode: no Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* c10pll_hw_state: clock: 61440, fracen: no,· Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* multiplier: 16, tx_clk_div: 0. Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* c10pll_rawhw_state: Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* tx: 0x0, cmn: 0x0 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[0] = 0x0, pll[1] = 0x0, pll[2] = 0x0, pll[3] = 0x0 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[4] = 0x0, pll[5] = 0x0, pll[6] = 0x0, pll[7] = 0x0 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[8] = 0x0, pll[9] = 0x0, pll[10] = 0x0, pll[11] = 0x0 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[12] = 0x0, pll[13] = 0x0, pll[14] = 0x0, pll[15] = 0x0 Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[16] = 0x0, pll[17] = 0x0, pll[18] = 0x0, pll[19] = 0x0 Jun 18 11:20:01 Curie2 kernel: ------------[ cut here ]------------ Jun 18 11:20:01 Curie2 kernel: i915 0000:00:02.0: [drm] pipe state doesn't match! Jun 18 11:20:01 Curie2 kernel: WARNING: drivers/gpu/drm/i915/display/intel_modeset_verify.c:225 at verify_crtc_state+0x349/0x5c0 [i915], CPU#1: KMS thread/4149 Jun 18 11:20:01 Curie2 kernel: Call Trace: Jun 18 11:20:01 Curie2 kernel: <TASK> Jun 18 11:20:01 Curie2 kernel: intel_modeset_verify_crtc+0x4f/0xb0 [i915] Jun 18 11:20:01 Curie2 kernel: intel_atomic_commit_tail+0x8a3/0xc50 [i915] Jun 18 11:20:01 Curie2 kernel: intel_atomic_commit+0x28e/0x2e0 [i915] Jun 18 11:20:01 Curie2 kernel: drm_atomic_commit+0xad/0xf0 Jun 18 11:20:01 Curie2 kernel: ? __pfx___drm_printfn_info+0x10/0x10 Jun 18 11:20:01 Curie2 kernel: drm_mode_atomic_ioctl+0x7d1/0x910 Jun 18 11:20:01 Curie2 kernel: ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 Jun 18 11:20:01 Curie2 kernel: drm_ioctl_kernel+0xb5/0x110 Jun 18 11:20:01 Curie2 kernel: drm_ioctl+0x309/0x5f0 Jun 18 11:20:01 Curie2 kernel: ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 Jun 18 11:20:01 Curie2 kernel: __x64_sys_ioctl+0xa3/0x100 Jun 18 11:20:01 Curie2 kernel: x64_sys_call+0x103b/0x2390 Jun 18 11:20:01 Curie2 kernel: do_syscall_64+0x115/0x5a0 Jun 18 11:20:01 Curie2 kernel: ? check_heap_object+0x146/0x1c0 Jun 18 11:20:01 Curie2 kernel: ? __check_object_size+0x86/0xf0 Jun 18 11:20:01 Curie2 kernel: ? ptep_set_access_flags+0x4a/0x70 Jun 18 11:20:01 Curie2 kernel: ? wp_page_reuse+0x97/0xc0 Jun 18 11:20:01 Curie2 kernel: ? do_wp_page+0x4ee/0x6f0 Jun 18 11:20:01 Curie2 kernel: ? handle_pte_fault+0x1d8/0x1f0 Jun 18 11:20:01 Curie2 kernel: ? __handle_mm_fault+0x493/0x720 Jun 18 11:20:01 Curie2 kernel: ? count_memcg_events+0x103/0x250 Jun 18 11:20:01 Curie2 kernel: ? handle_mm_fault+0x1c0/0x2e0 Jun 18 11:20:01 Curie2 kernel: ? arch_exit_to_user_mode_prepare.isra.0+0xd/0x100 Jun 18 11:20:01 Curie2 kernel: ? irqentry_exit+0x97/0x5a0 Jun 18 11:20:01 Curie2 kernel: ? exc_page_fault+0x94/0x1e0 Jun 18 11:20:01 Curie2 kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e Jun 18 11:20:01 Curie2 kernel: RIP: 0033:0x76eaf7f32cbd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2157079/+subscriptions