[Bug 2154558] Re: wrong signature in the kernel 7.0.0-22

The signature is correct. -22 is an emergency respin based on -20 which is based on -15 which is 7.0.0. ** Changed in: linux (Ubuntu) Status: New => Invalid -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2154558 Title: wrong signature in the kernel 7.0.0-22 Status in linux package in Ubuntu: Invalid Bug description: I noticed something interesting in the latest kernel version, 7.0.0-22: The signature for the kernel, got from /boot/config-7.0.0-22-generic, is: CONFIG_VERSION_SIGNATURE="Ubuntu 7.0.0-22.22-generic 7.0.0" Notice that it says the version is 7.0.0. Thought the signature for the older version 7.0.0-17 is: CONFIG_VERSION_SIGNATURE="Ubuntu 7.0.0-17.17-generic 7.0.2" It says it's using version 7.0.2 as base. I understand that Ubuntu doesn't follow the official kernel versioning, but I usually use this information to know how much the Ubuntu kernel is updated. For instance, in this release, 7.0.0-22, I tested against Dirty Frag and Fragnesia, and both were fixed, so I think it should be 7.0.10 and not 7.0.0. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-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: pass CurrentDesktop: ubuntu:GNOME Date: Fri May 29 06:39:41 2026 InstallationDate: Installed on 2021-11-26 (1645 days ago) InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012) IwDevWlp47s0f0Link: Not connected. MachineType: Dell Inc. Dell G15 5511 ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-22-generic root=UUID=a15c1e1a-d162-4e98-98e6-bbc6e85a39c3 ro intel_iommu=on iommu=pt quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux UpgradeStatus: Upgraded to resolute on 2026-02-28 (90 days ago) dmi.bios.date: 03/31/2026 dmi.bios.release: 1.42 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.42.0 dmi.board.name: 0836K6 dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.42.0:bd03/31/2026:br1.42:svnDellInc.:pnDellG155511:pvr:rvnDellInc.:rn0836K6:rvrA00:cvnDellInc.:ct10:cvr:sku0A70:pfaGSeries: dmi.product.family: GSeries dmi.product.name: Dell G15 5511 dmi.product.sku: 0A70 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2154558/+subscriptions

[Bug 2142275] Re: Mediatek MT7902 support

That's what HWE kernels are for. You'll get it with 7.2 then. We're not backporting support of new HW to older kernels. ** Changed in: linux-signed-hwe-6.17 (Ubuntu) Status: Confirmed => Invalid ** Changed in: linux (Ubuntu) Status: Confirmed => Invalid -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2142275 Title: Mediatek MT7902 support Status in linux package in Ubuntu: Invalid Status in linux-signed-hwe-6.17 package in Ubuntu: Invalid Bug description: Mediatek MT7902 is supported in upstream kernel 7.1. Please backport to 7.0 kernel for Ubuntu 24.04 and 26.04 ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.17.0-14-generic 6.17.0-14.14~24.04.1 ProcVersionSignature: Ubuntu 6.17.0-14.14~24.04.1-generic 6.17.9 Uname: Linux 6.17.0-14-generic x86_64 ApportVersion: 2.28.1-0ubuntu3.8 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Feb 20 14:46:06 2026 InstallationDate: Installed on 2026-02-20 (0 days ago) InstallationMedia: Ubuntu 24.04.4 LTS "Noble Numbat" - Release amd64 (20260210) ProcEnviron:  LANG=en_US.UTF-8  PATH=(custom, no user)  SHELL=/bin/bash  TERM=xterm-256color  XDG_RUNTIME_DIR=<set> SourcePackage: linux-signed-hwe-6.17 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2142275/+subscriptions

[Bug 2154194] Re: [Jammy] Priority inversion problem in epoll for rt kernel

** Description changed: [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. [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, eliminating the - priority inversion problem. + inheritance works correctly across the epoll subsystem. [Test Plan] This is a priority inversion race condition, so it is highly non-deterministic - and cannot be triggered on command. This is why it is not feasable to provide a - reliable reproduction script. + 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. - There is a test kernel available in the following PPA: - https://launchpad.net/~munirsid/+archive/ubuntu/lp2154194 + 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% average improvement in + 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. + 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 alters - no external kernel APIs. + 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 has already been integrated into Noble and subsequent + 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/ -- 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: New Status in linux source package in Jammy: New 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. [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% average improvement in 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 2149877] Re: Intermittent micro‑stutters affecting mouse and audio after updating to Linux 7.0.0‑14‑generic on AMD system

Following up on this bug. I had been using 7.0.0-17-generic since my original comment, and I experienced no micro-stuttering with that kernel. I just updated the kernel to 7.0.0-22-generic, and the micro-stuttering issue is occurring again. -- 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 2154671] Re: Regression: Wacom tablet no longer detected on Latitude 5290 2-in-1

** Tags added: kernel-daily-bug -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2154671 Title: Regression: Wacom tablet no longer detected on Latitude 5290 2-in-1 Status in linux package in Ubuntu: New Bug description: After upgrading to linux (7.0.0-22.22) the touchscreen/wacom tablet is no longer detected and does not work. Neither pen, nor touch input work. Workaround is to boot into 7.0.0-15.15 where everything functions as expected. 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: kstoilov 5134 F.... wireplumber /dev/snd/seq: kstoilov 5114 F.... pipewire CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Sun May 31 20:15:31 2026 InstallationDate: Installed on 2025-01-03 (513 days ago) InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Release amd64 (20240424) Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 8087:0a2b Intel Corp. Bluetooth wireless interface Bus 001 Device 004: ID 044e:1218 Alps Electric Co., Ltd Electric Touchpad Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 002: ID 413c:81b6 Dell Computer Corp. DW5811e Snapdragon™ X7 LTE MachineType: Dell Inc. Latitude 5290 2-in-1 ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-22-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. SourcePackage: linux StagingDrivers: ipu3_imgu UpgradeStatus: Upgraded to resolute on 2026-05-09 (22 days ago) dmi.bios.date: 04/02/2025 dmi.bios.release: 1.40 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.40.0 dmi.board.name: 062MFC dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 32 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.40.0:bd04/02/2025:br1.40:svnDellInc.:pnLatitude52902-in-1:pvr:rvnDellInc.:rn062MFC:rvrA00:cvnDellInc.:ct32:cvr:sku081D:pfaLatitude: dmi.product.family: Latitude dmi.product.name: Latitude 5290 2-in-1 dmi.product.sku: 081D dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2154671/+subscriptions

[Bug 2154681] Re: cs35l41-hda: SSID 10431A63 (ASUS Zenbook 14 UX3405MA) speakers silent — PUP_DONE_MASK -110 on runtime power cycle due to missing VSPK GPIO regulator

** Tags added: kernel-daily-bug -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2154681 Title: cs35l41-hda: SSID 10431A63 (ASUS Zenbook 14 UX3405MA) speakers silent — PUP_DONE_MASK -110 on runtime power cycle due to missing VSPK GPIO regulator Status in linux package in Ubuntu: New Bug description: Description: Hardware: ASUS Zenbook 14 UX3405MA Affected device: Cirrus Logic CS35L41 (SSID 10431A63), L+R sidecar amps via SPI Symptom: Built-in speakers produce no sound. Kernel log shows repeated Failed waiting for CS35L41_PUP_DONE_MASK: -110 errors 5–6 seconds after boot, triggered on first audio playback. Root cause: SSDT16 (_ASUS_/SPKRAMPS) defines cirrus,boost-type = 1 (external boost) for SSID 10431A63. The CS35L41 VSPK supply is controlled by an external GPIO (GPI0 pin 0x48 / Linux GPIO 584 on INTC1083:00, CRS resource index 0 in the SPK1 device). The driver has no regulator mapped to this GPIO and falls back to a dummy regulator. regulator_enable() becomes a no-op — VSPK is never re-enabled after a runtime power cycle. At cold boot the BIOS leaves VSPK HIGH, so the initial driver probe succeeds. On first playback, the driver's playback hook power-cycles the amps; VSPK is not re-enabled; PUP_DONE_MASK times out. ACPI path: \_SB.PC00.SPI1.SPK1 Relevant GPIO (VSPK enable): GPI0 pin 0x48, output, PullUp — present in _CRS but not referenced in _DSD Reset GPIO: GPI0 pin 0xD0, output, PullDown Kernel log (failure): cs35l41-hda spi0-CSC3551:00-cs35l41-hda.0: Using extra _DSD properties, bypassing _DSD in ACPI cs35l41-hda spi0-CSC3551:00-cs35l41-hda.0: Cirrus Logic CS35L41 (35a40), Revision: B2 cs35l41-hda spi0-CSC3551:00-cs35l41-hda.0: CS35L41 Bound - SSID: 10431A63, BST: 1, VSPK: 1, CH: L, FW EN: 1, SPKID: 1 cs35l41-hda spi0-CSC3551:00-cs35l41-hda.0: Failed waiting for CS35L41_PUP_DONE_MASK: -110 Workaround (audio works but speaker protection firmware disabled): echo "options snd_hda_scodec_cs35l41 firmware_autostart=0" > /etc/modprobe.d/cs35l41-nofw.conf With firmware_autostart=0: FW EN: 0, no PUP_DONE_MASK errors, audio works. Required fix: Add a proper GPIO regulator mapping for the VSPK supply (GPI0 pin 0x48) for SSID 10431A63 in cs35l41-hda-property.c, so the driver can properly re-enable VSPK during runtime power cycles. 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: jens 5827 F.... pipewire jens 5847 F.... wireplumber /dev/snd/seq: jens 5827 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun May 31 22:06:02 2026 InstallationDate: Installed on 2026-02-04 (116 days ago) InstallationMedia: Ubuntu 25.10 "Questing Quokka" - Release amd64 (20251007) MachineType: ASUSTeK COMPUTER INC. ASUS Zenbook 14 UX3405MA ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-15-generic root=UUID=5adc1058-8261-4c9f-877c-899756f0d609 ro quiet splash acpi_enforce_resources=lax crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. SourcePackage: linux UpgradeStatus: Upgraded to resolute on 2026-05-16 (15 days ago) dmi.bios.date: 06/06/2025 dmi.bios.release: 5.32 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: UX3405MA.311 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: UX3405MA dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrUX3405MA.311:bd06/06/2025:br5.32:svnASUSTeKCOMPUTERINC.:pnASUSZenbook14UX3405MA:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX3405MA:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:sku:pfaASUSZenbook14: dmi.product.family: ASUS Zenbook 14 dmi.product.name: ASUS Zenbook 14 UX3405MA dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2154681/+subscriptions

[Bug 1766857] Re: [Hyper-V] KVP daemon still fails to run scripts in LTS release

The lack of response to this bug is extremely disappointing. It's 100% reproduceable, the specific makefiles and sources involved are identified, the extremely simple fix is identified. Despite all that, it's just been essentially ignored for years. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/1766857 Title: [Hyper-V] KVP daemon still fails to run scripts in LTS release Status in linux package in Ubuntu: Confirmed Status in linux-azure package in Ubuntu: Confirmed Status in linux source package in Bionic: Confirmed Status in linux-azure source package in Bionic: Confirmed Status in linux source package in Cosmic: Won't Fix Status in linux-azure source package in Cosmic: Won't Fix Bug description: While testing Bionic daily build with kernel 4.15.0-20-generic we saw that there are 2 issues with the KVP daemon: 1. KVP daemon crash after boot. Opened a different bug for this: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779640 2. After the KVP daemon is being started the following messages appear: Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: /usr/libexec/hypervkvpd/hv_get_dns_info: not found Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: /usr/libexec/hypervkvpd/hv_get_dhcp_info: not found The above binaries are present on the system, but the their actual path is /usr/sbin/hv_get_dns_info and /usr/sbin/hv_get_dhcp_info. Either the hv_get_dhcp_info and hv_get_dns_info binaries should be placed in the location where the daemon is looking for (/usr/libexec/hypervkvpd/), or the daemon should be set to search for the binaries in the /usr/sbin directory. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1766857/+subscriptions

[Bug 1766857] Re: [Hyper-V] KVP daemon still fails to run scripts in LTS release

** Tags added: noble resolute -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/1766857 Title: [Hyper-V] KVP daemon still fails to run scripts in LTS release Status in linux package in Ubuntu: Confirmed Status in linux-azure package in Ubuntu: Confirmed Status in linux source package in Bionic: Confirmed Status in linux-azure source package in Bionic: Confirmed Status in linux source package in Cosmic: Won't Fix Status in linux-azure source package in Cosmic: Won't Fix Bug description: While testing Bionic daily build with kernel 4.15.0-20-generic we saw that there are 2 issues with the KVP daemon: 1. KVP daemon crash after boot. Opened a different bug for this: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779640 2. After the KVP daemon is being started the following messages appear: Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: /usr/libexec/hypervkvpd/hv_get_dns_info: not found Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: /usr/libexec/hypervkvpd/hv_get_dhcp_info: not found The above binaries are present on the system, but the their actual path is /usr/sbin/hv_get_dns_info and /usr/sbin/hv_get_dhcp_info. Either the hv_get_dhcp_info and hv_get_dns_info binaries should be placed in the location where the daemon is looking for (/usr/libexec/hypervkvpd/), or the daemon should be set to search for the binaries in the /usr/sbin directory. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1766857/+subscriptions

[Bug 2154650] Re: Severe Boot Latency and General Performance Degradation After Recent Kernel Update

The boot latency and performance degradation issue seems to have resolved itself for now and boot time is back to normal (~20s) on the same kernel. However, I am leaving this report open as the ACPI errors might still be present in the logs, and the issue might be intermittent. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2154650 Title: Severe Boot Latency and General Performance Degradation After Recent Kernel Update Status in linux package in Ubuntu: New Bug description: Since the latest system/kernel update, I am experiencing significant issues with my system’s boot time and overall performance. Hardware Specifications: device model: redmi book 16 2024 CPU: intel core i5-13500H BIOS version: RMARP6B0P0606 Observed Issues: 1. Boot Latency: The boot time has drastically increased after the update, taking approximately 1 minute and 12 seconds to reach the login screen. 2. Performance Degradation: Following the delayed boot, the system suffers from noticeable slowness, lag, and generally degraded performance during normal usage. Actions Taken: Attempted to check for firmware updates via fwupdmgr, but no updates were found for Linux. Updating the BIOS currently requires a Windows environment. Logs have already been collected and submitted to Canonical via the ubuntu-bug linux tool. Workaround: Temporarily, booting into an older kernel version from the GRUB menu resolves both the boot delay and the performance lag, confirming that the issue is specific to the latest update. Any assistance or guidance on a permanent patch for this kernel-ACPI conflict would be highly appreciated. 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: mohammad-reza 4539 F.... pipewire mohammad-reza 4561 F.... wireplumber /dev/snd/seq: mohammad-reza 4539 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sat May 30 23:37:54 2026 HibernationDevice: RESUME=auto InstallationDate: Installed on 2026-02-12 (107 days ago) InstallationMedia: Ubuntu 25.10 "Questing Quokka" - Release amd64 (20251007) MachineType: XIAOMI Redmi Book 16 2024 (Gen13 CPU) ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-22-generic root=UUID=75dacbbe-81a5-462a-8226-de7df7f234ce ro quiet splash resume=UUID=52871a6d-83ee-4a6f-ba5b-e0ad819b7db4 intel_iommu=off crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. SourcePackage: linux UpgradeStatus: Upgraded to resolute on 2026-05-30 (0 days ago) dmi.bios.date: 08/23/2024 dmi.bios.release: 1.6 dmi.bios.vendor: XIAOMI dmi.bios.version: RMARP6B0P0606 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: TM2305 dmi.board.vendor: XIAOMI dmi.board.version: V24D2 dmi.chassis.asset.tag: Chassis Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: XIAOMI dmi.ec.firmware.release: 1.6 dmi.modalias: dmi:bvnXIAOMI:bvrRMARP6B0P0606:bd08/23/2024:br1.6:efr1.6:svnXIAOMI:pnRedmiBook162024(Gen13CPU):pvr:rvnXIAOMI:rnTM2305:rvrV24D2:cvnXIAOMI:ct10:cvr:skuTM2305-53219:pfaMiLaptop: dmi.product.family: Mi Laptop dmi.product.name: Redmi Book 16 2024 (Gen13 CPU) dmi.product.sku: TM2305-53219 dmi.sys.vendor: XIAOMI To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2154650/+subscriptions

[Bug 2137291] Re: mt7925e: Kernel panic NULL pointer dereference in mt76_connac_mcu_uni_add_dev during WiFi reset - Framework Desktop

The deadlock half of this report — the AB-BA deadlock between cfg80211_wiphy_work and mt7925_roc_work that hard-freezes the machine — is now in mainline, authored by Sean Wang (no attribution to Zac's stellar work, but internet knows :-) ) and merged via the mt76 tree: - dd08ca3f092f4185ece69ce2a835c23198b1628a — "wifi: mt76: mt7925: fix potential deadlock in mt7925_roc_abort_sync" https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dd08ca3f092f4185ece69ce2a835c23198b1628a - 9e4d518a4707175e1154876b760d4f2b39967e9d — "wifi: mt76: mt7925: pass mlink to mac_link_sta_remove()" https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9e4d518a4707175e1154876b760d4f2b39967e9d I can confirm on a Framework Laptop 16 (Ryzen AI 7 350, MT7925) running 24.04 LTS with the linux-hwe-6.17 kernel (6.17.0-35-generic) that this deadlock reproduces reliably on the stock kernel — captured kernel stack traces match this report exactly (cfg80211_wiphy_work → mt7925_mac_link_sta_remove → cancel_work_sync holding the mt76 mutex, while mt7925_roc_work blocks on the same mutex; NetworkManager/wpa_supplicant then wedge in D state and reboot hangs). It is resolved by the patched DKMS build. The stock 6.17.0-35 changelog does not yet include these commits. Now that the upstream-acceptance gate is met for the deadlock fix: is there a plan/timeline to SRU these two commits into the linux-hwe-6.17 (24.04 LTS) and linux 6.17 (25.10) kernels? Separately, it's not clear what is happening with the NULL-pointer- dereference fix (mt76_connac_mcu_uni_add_dev) and when it might land upstream. Zac, any chance for reviving https://lkml.org/lkml/2026/1/29/484 thread now that at least some changes landed in mainline? -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2137291 Title: mt7925e: Kernel panic NULL pointer dereference in mt76_connac_mcu_uni_add_dev during WiFi reset - Framework Desktop Status in linux package in Ubuntu: Confirmed Bug description: (Refiling this bug with more data from `ubuntu-bug linux` and a correct title) System experiences kernel panics causing complete lockups when the mt7925e WiFi driver attempts to reset after association failures. Hardware: Framework Desktop (AMD Ryzen AI Max 300 Series) BIOS: 03.04 (11/19/2025) WiFi Card: MediaTek MT7925 (RZ717) Wi-Fi 7 at c0:00.0 Firmware: Build Time: 20250721232943 Root Cause: NULL pointer dereference in mt76_connac_mcu_uni_add_dev() function at offset 0xba during WiFi MAC reset workflow. Crash Pattern: 1. WiFi association attempts fail/timeout with AP 2. Driver logs "Message timeout" errors (sequences 6-10) 3. mt7925_mac_reset_work initiated 4. During interface re-initialization via ieee80211_iterate_interfaces 5. mt76_connac_mcu_uni_add_dev attempts to dereference NULL pointer 6. Kernel panic - system completely locks up Frequency: Multiple crashes per day, making system unusable This appears to be a known issue affecting multiple users on Ubuntu 25.10 kernel 6.17.0-8 with this hardware. ProblemType: Bug DistroRelease: Ubuntu 25.10 Package: linux-image-6.17.0-8-generic 6.17.0-8.8 ProcVersionSignature: Ubuntu 6.17.0-8.8-generic 6.17.2 Uname: Linux 6.17.0-8-generic x86_64 ApportVersion: 2.33.1-0ubuntu3 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: gdm-greeter 6080 F.... wireplumber /dev/snd/controlC0: gdm-greeter 6080 F.... wireplumber /dev/snd/seq: gdm-greeter 6066 F.... pipewire CasperMD5CheckResult: pass Date: Tue Dec 30 17:36:29 2025 InstallationDate: Installed on 2025-11-30 (30 days ago) InstallationMedia: Ubuntu 25.10 "Questing Quokka" - Release amd64 (20251007) MachineType: Framework Desktop (AMD Ryzen AI Max 300 Series) ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-ghostty ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.17.0-8-generic root=UUID=7c001a2e-fa2b-447b-98ee-6322215addb9 ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M vt.handoff=7 RelatedPackageVersions: firmware-sof N/A linux-firmware 20250901.git993ff19b-0ubuntu1.4 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/19/2025 dmi.bios.release: 3.4 dmi.bios.vendor: INSYDE Corp. dmi.bios.version: 03.04 dmi.board.asset.tag: * dmi.board.name: FRANMFCP06 dmi.board.vendor: Framework dmi.board.version: A6 dmi.chassis.asset.tag: FRAMDACPA65382007P dmi.chassis.type: 35 dmi.chassis.vendor: Framework dmi.chassis.version: A6 dmi.modalias: dmi:bvnINSYDECorp.:bvr03.04:bd11/19/2025:br3.4:svnFramework:pnDesktop(AMDRyzenAIMax300Series):pvrA6:rvnFramework:rnFRANMFCP06:rvrA6:cvnFramework:ct35:cvrA6:skuFRAMDACP06: dmi.product.family: Desktop dmi.product.name: Desktop (AMD Ryzen AI Max 300 Series) dmi.product.sku: FRAMDACP06 dmi.product.version: A6 dmi.sys.vendor: Framework To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2137291/+subscriptions

[Bug 2154646] Re: i915 Arrow Lake: PHY A powerdown failure + DPLL hw state mismatch on s2idle resume — recovers most cycles, hard-freezes some (Dell Pro Max 16, kernel 7.0.0-22)

Likely same root cause as bug #2150605 (HP ZBook Fury G1i, Arrow Lake-S). Same i915 Failed to bring PHY A to idle / PHY A Read 0c70 / DPLL hw state mismatch signature, same code path in intel_cx0_phy.c, same Ubuntu 26.04 / Wayland / Blackwell-hybrid environment, same ineffective workarounds (i915.enable_psr=0 converts hang to slow recover but doesn't fix). Key differences in my case: (1) Arrow Lake-P variant rather than Arrow Lake-S, (2) bug triggers on every s2idle resume regardless of dwell time, not only long dwells, (3) recovery time 30–75s rather than 5–10s, and (4) occasional silent hard freezes ~minute after a seemingly-clean resume (see "Silent freeze case" in the description). Ubuntu kernel team to decide formal duplicate status. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2154646 Title: i915 Arrow Lake: PHY A powerdown failure + DPLL hw state mismatch on s2idle resume — recovers most cycles, hard-freezes some (Dell Pro Max 16, kernel 7.0.0-22) Status in linux package in Ubuntu: New Bug description: # i915 Arrow Lake: PHY A powerdown failure + DPLL hw state mismatch on s2idle resume — recovers most cycles, hard-freezes some (Dell Pro Max 16, kernel 7.0.0-22) ## Summary Every s2idle suspend/resume cycle triggers an identical i915 failure on the internal display (eDP-1). The bug reproduces 100% of the time, independent of external monitors, dock state, or session activity. Most resume cycles now recover after 30–75 seconds of degraded display state via timeout-based fallback paths in i915. However, **some resume cycles produce a complete, silent system freeze**: the desktop remains visible but is entirely unresponsive (no keyboard, mouse, or remote SSH), the kernel log stops with no further entries, no soft lockup watchdog trace fires, and only a power button hold recovers the system. The proportion of cycles that result in a silent freeze vs. a noisy recovery is non-deterministic. On earlier kernels (6.17.0-1017-oem, 7.0.0-15-generic) the same bug presented as a soft lockup in `nvidia-modeset` blocked downstream of the stuck i915 display state, with a visible watchdog trace in dmesg. As of 7.0.0-22 the soft-lockup path no longer fires — but the underlying race is unchanged, and now manifests as a silent hang of the entire graphics pipeline when it does cause a freeze. ## Hardware - **Machine**: Dell Pro Max 16 Premium (MA16250), BIOS 1.9.0 (2026-03-31) — latest available from Dell - **iGPU**: Intel Arrow Lake-P / Arc Pro 130T (rev 03) at `0000:00:02.0` - **dGPU**: NVIDIA RTX PRO 2000 Blackwell (Open kernel modules, driver 595.71.05) — verified not involved in this trace - **Internal display**: eDP-1 (CONNECTOR:507), driven via PHY A / DPLL 0 / pipe A / PLANE:34 - **RAM**: 61 GiB ## Software - **OS**: Ubuntu 26.04 LTS - **Kernel**: `7.0.0-22-generic` (`linux-image-7.0.0-22-generic`) - **Session**: Wayland (GNOME) - **Suspend mode**: `s2idle` only — BIOS does not expose `deep`/S3 (`cat /sys/power/mem_sleep` returns `[s2idle]`) - **Kernel command line**: `quiet splash i915.enable_psr=0 nvidia-drm.modeset=1` ## Steps to reproduce 1. Boot the system normally (any user activity, GNOME Wayland session) 2. `systemctl suspend` 3. Wake via keyboard/lid within ~30 seconds 4. Observe dmesg ## Expected behavior Suspend/resume completes within a few seconds, no display errors, dmesg clean. ## Actual behavior Resume takes 30–75 seconds during which the internal display is in a glitched/unresponsive state. dmesg shows the identical sequence on every cycle: ``` i915 0000:00:02.0: [drm] *ERROR* Failed to bring PHY A to idle. i915 0000:00:02.0: [drm] *ERROR* PHY A Read 0c70 failed after 3 retries. i915 0000:00:02.0: [drm] *ERROR* PHY A Write 0c70 failed after 3 retries. i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] flip_done timed out i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] mismatch in dpll_hw_state i915 0000:00:02.0: [drm] DPLL 0: pll hw state mismatch ------------[ cut here ]------------ WARNING: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:4945 at verify_single_dpll_state+0x2a6/0x6b0 [i915] RIP: 0010:verify_single_dpll_state+0x2b3/0x6b0 [i915] Call Trace: intel_dpll_state_verify+0x63/0x260 [i915] intel_modeset_verify_crtc+0x5a/0xb0 [i915] intel_atomic_commit_tail+0x8a3/0xc50 [i915] intel_atomic_commit+0x28e/0x2e0 [i915] drm_atomic_commit+0xad/0xf0 drm_atomic_helper_commit_duplicated_state+0xfe/0x120 __intel_display_driver_resume+0xb8/0x130 [i915] intel_display_driver_resume+0xc7/0x140 [i915] i915_drm_resume+0x147/0x1e0 [i915] i915_pm_resume+0x1b/0x30 [i915] pci_pm_resume+0x8c/0x140 dpm_run_callback+0x5f/0x180 device_resume+0x177/0x270 async_resume+0x21/0x40 ---[ end trace 0000000000000000 ]--- i915 0000:00:02.0: [drm] *ERROR* flip_done timed out i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] commit wait timed out i915 0000:00:02.0: [drm] *ERROR* flip_done timed out i915 0000:00:02.0: [drm] *ERROR* [CONNECTOR:507:eDP-1] commit wait timed out i915 0000:00:02.0: [drm] *ERROR* flip_done timed out i915 0000:00:02.0: [drm] *ERROR* [PLANE:34:plane 1A] commit wait timed out [further trace through intel_dp_retrain_link → intel_dp_link_check → intel_encoder_link_check_work_fn] i915 0000:00:02.0: [drm] PHY A failed to change powerdown state ``` ## Test matrix (all produced the identical trace) | # | Dock state | Outcome | |---|------------|---------| | 1 | Dell Thunderbolt dock attached throughout | recovered, 33s | | 2 | Dock attached throughout (different cycle, same boot) | recovered, 74s | | 3 | Dock attached at suspend, disconnected before wake | recovered, 74s | | 4 | No dock attached at any time | recovered, 32s | Conclusion: dock state is irrelevant to the recovery cases. Bug is internal to i915 handling of eDP-1 / PHY A during s2idle resume. ## Silent freeze case (2026-05-30, kernel 7.0.0-22-generic, docked) A separate boot exhibited four consecutive recoverable resume cycles followed by a fifth cycle that hard-froze. Timeline from `journalctl -k -b -3`: ``` 10:31:54 suspend 1: visible PHY A errors → recovered 10:43:44 suspend 2: visible PHY A errors → recovered 11:05:47 suspend 3: visible PHY A errors → recovered 11:17:08 suspend 4: visible PHY A errors → recovered 11:30:54 suspend 5: PM: suspend exit @ 11:30:55 (no PHY A errors logged) 11:30:56 evdi reconnects, displays reinitialize 11:31:02 WiFi reassociates, DisplayLink reconnects 11:31:05 usb 3-9: reset full-speed USB device number 7 using xhci_hcd 11:31:53 cgroup: Unknown subsys name 'memory' ← LAST KERNEL LOG ENTRY ??? HARD FREEZE — no further entries, no watchdog trace ``` Operational symptoms during the freeze: - Desktop on internal display remained visible — last frame held, not black - Keyboard, mouse, and trackpad completely unresponsive - Lid state at freeze: undetermined (user docked, internal display in use) - Recovery required holding the power button (no other path; SSH/SysRq not tried but kernel logging had stopped, suggesting they would not have worked) - Boot session ended at uptime ~5500s (boot at 10:00, freeze at 11:31) This freeze was preceded by a resume that *appeared* clean in dmesg — no PHY A errors logged before the hang. The previous four resume cycles in the same boot all triggered the standard PHY A / DPLL trace but recovered. This suggests the same underlying race can either (a) trigger visible recovery, or (b) lock the entire display pipeline silently — the difference is not yet understood from available logs. The kernel `watchdog: BUG: soft lockup` mechanism does **not** fire for this failure mode. Earlier kernels (6.17.0-1017-oem, 7.0.0-15-generic) produced a visible soft lockup trace in `nvidia- modeset` after ~22 seconds in cases where i915 hung — that downstream effect appears to have been mitigated in 7.0.0-22, but the upstream i915 deadlock that caused those lockups still exists and now hangs silently when it triggers. ## Workarounds attempted (no effect on the bug) - NVIDIA driver upgrade `595.58.03` → `595.71.05` - Kernel upgrade `6.17.0-1017-oem` → `7.0.0-15-generic` → `7.0.0-22-generic` - BIOS upgrade `1.8.1` → `1.9.0` - Dell dock firmware updates (MST VMM9 9.03→9.04, PD 1.34→1.37, WD25TB5 1.0.9→1.0.10, USB4v2 controller, dock package) - Kernel command line already has `i915.enable_psr=0` ## Behavior across kernel versions - **6.17.0-1017-oem / 7.0.0-15-generic**: Bug fired on most s2idle resumes and caused hard system freezes. Soft lockup watchdog visibly triggered in `nvidia-modeset` thread blocked downstream of the stuck i915 state. System unrecoverable without power button reset. Frequency: multiple per week under normal use. - **7.0.0-22-generic**: Bug still fires on every s2idle resume (visible PHY A / DPLL trace in dmesg). i915 timeout-based recovery paths handle most cycles, leaving the system in a degraded display state for 30–75 seconds before continuing. However, occasional cycles result in a complete silent system freeze (see "Silent freeze case" section above) — desktop visible but unresponsive, no kernel trace, no watchdog firing. Hard freeze frequency: at least one per week of normal use with the current workaround in place to avoid most suspends. Without the workaround (allowing GNOME idle suspend), prior measurements suggest higher frequency. The 7.0.0-22 change has eliminated the *visible* soft lockup symptom, but has not fixed the underlying race in PHY A / DPLL state validation during s2idle resume. ## Workaround currently in use Avoid s2idle suspend entirely: ``` # /etc/systemd/logind.conf.d/no-suspend.conf [Login] HandleLidSwitch=lock HandleLidSwitchDocked=ignore HandleLidSwitchExternalPower=lock ``` ``` gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing' gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type 'nothing' ``` System runs indefinitely with display blanked when idle. No bug triggered. 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 CasperMD5CheckMismatches: ./casper/initrd ./casper/minimal.standard.live.hotfix.manifest ./casper/minimal.standard.live.hotfix.size ./casper/minimal.standard.live.size ./casper/minimal.manifest ./casper/minimal.standard.manifest ./casper/minimal.standard.size ./casper/minimal.hotfix.size ./casper/minimal.standard.live.hotfix.squashfs ./casper/minimal.standard.hotfix.squashfs ./casper/minimal.standard.hotfix.size ./casper/minimal.hotfix.squashfs ./casper/minimal.standard.live.manifest ./casper/minimal.size ./boot/grub/grub.cfg CasperMD5CheckResult: fail CurrentDesktop: ubuntu:GNOME Date: Sat May 30 20:33:57 2026 DistributionChannelDescriptor: # This is the distribution channel descriptor for Ubuntu 24.04 for Dell # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-somerville-noble-oem-24.04c-20251113-97 InstallationDate: Installed on 2026-03-04 (87 days ago) InstallationMedia: Ubuntu OEM 24.04.3 LTS "Noble Numbat" - Release amd64 (20251111) MachineType: Dell Inc. Dell Pro Max 16 Premium MA16250 ProcEnviron: LANG=C.UTF-8 PATH=(custom, no user) SHELL=/usr/bin/zsh TERM=tmux-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 i915drmfb 1 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-22-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash i915.enable_psr=0 nvidia-drm.modeset=1 ipv6.disable=1 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/31/2026 dmi.bios.release: 1.9 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.9.0 dmi.board.name: 061K67 dmi.board.vendor: Dell Inc. dmi.board.version: A02 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.ec.firmware.release: 1.8 dmi.modalias: dmi:bvnDellInc.:bvr1.9.0:bd03/31/2026:br1.9:efr1.8:svnDellInc.:pnDellProMax16PremiumMA16250:pvr:rvnDellInc.:rn061K67:rvrA02:cvnDellInc.:ct10:cvr:sku0D33:pfaDellProMaxLaptops: dmi.product.family: Dell Pro Max Laptops dmi.product.name: Dell Pro Max 16 Premium MA16250 dmi.product.sku: 0D33 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2154646/+subscriptions

[Bug 2154650] Re: Severe Boot Latency and General Performance Degradation After Recent Kernel Update

** Tags added: kernel-daily-bug -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2154650 Title: Severe Boot Latency and General Performance Degradation After Recent Kernel Update Status in linux package in Ubuntu: New Bug description: Since the latest system/kernel update, I am experiencing significant issues with my system’s boot time and overall performance. Hardware Specifications: device model: redmi book 16 2024 CPU: intel core i5-13500H BIOS version: RMARP6B0P0606 Observed Issues: 1. Boot Latency: The boot time has drastically increased after the update, taking approximately 1 minute and 12 seconds to reach the login screen. 2. Performance Degradation: Following the delayed boot, the system suffers from noticeable slowness, lag, and generally degraded performance during normal usage. Actions Taken: Attempted to check for firmware updates via fwupdmgr, but no updates were found for Linux. Updating the BIOS currently requires a Windows environment. Logs have already been collected and submitted to Canonical via the ubuntu-bug linux tool. Workaround: Temporarily, booting into an older kernel version from the GRUB menu resolves both the boot delay and the performance lag, confirming that the issue is specific to the latest update. Any assistance or guidance on a permanent patch for this kernel-ACPI conflict would be highly appreciated. 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: mohammad-reza 4539 F.... pipewire mohammad-reza 4561 F.... wireplumber /dev/snd/seq: mohammad-reza 4539 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sat May 30 23:37:54 2026 HibernationDevice: RESUME=auto InstallationDate: Installed on 2026-02-12 (107 days ago) InstallationMedia: Ubuntu 25.10 "Questing Quokka" - Release amd64 (20251007) MachineType: XIAOMI Redmi Book 16 2024 (Gen13 CPU) ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-22-generic root=UUID=75dacbbe-81a5-462a-8226-de7df7f234ce ro quiet splash resume=UUID=52871a6d-83ee-4a6f-ba5b-e0ad819b7db4 intel_iommu=off crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. SourcePackage: linux UpgradeStatus: Upgraded to resolute on 2026-05-30 (0 days ago) dmi.bios.date: 08/23/2024 dmi.bios.release: 1.6 dmi.bios.vendor: XIAOMI dmi.bios.version: RMARP6B0P0606 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: TM2305 dmi.board.vendor: XIAOMI dmi.board.version: V24D2 dmi.chassis.asset.tag: Chassis Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: XIAOMI dmi.ec.firmware.release: 1.6 dmi.modalias: dmi:bvnXIAOMI:bvrRMARP6B0P0606:bd08/23/2024:br1.6:efr1.6:svnXIAOMI:pnRedmiBook162024(Gen13CPU):pvr:rvnXIAOMI:rnTM2305:rvrV24D2:cvnXIAOMI:ct10:cvr:skuTM2305-53219:pfaMiLaptop: dmi.product.family: Mi Laptop dmi.product.name: Redmi Book 16 2024 (Gen13 CPU) dmi.product.sku: TM2305-53219 dmi.sys.vendor: XIAOMI To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2154650/+subscriptions

[Bug 2149877] Re: Intermittent micro‑stutters affecting mouse and audio after updating to Linux 7.0.0‑14‑generic on AMD system

I upgraded to 7.0.0.22 kernel, and the stuttering might be worse than before -- 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: Confirmed Status in linux source package in Resolute: Confirmed 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