** 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/2164967 Title: Fix TAS2783 SoundWire amp resume timeout >5s Status in HWE Next: New Status in linux package in Ubuntu: New Status in linux-oem-6.17 package in Ubuntu: New Status in linux source package in Noble: New Status in linux-oem-6.17 source package in Noble: In Progress Status in linux source package in Resolute: In Progress Status in linux-oem-6.17 source package in Resolute: New Bug description: [Impact] TAS2783 SoundWire smart amplifiers add >5s to resume on systems with AMD ACP (e.g., ASUS ProArt PX13, HP EliteBook X G2i). Each TAS2783 device waits up to 5s (TAS2783_PROBE_TIMEOUT) for slave->initialization_complete during resume. The SoundWire slaves do not re-enumerate after s2idle on AMD ACP, so the timeout fires for each device sequentially, causing ~15s slow resume on systems with 2-3 TAS2783 amps. After resume, speakers stay silent even though firmware re-downloads successfully. The regcache holds stale pre-suspend values, so subsequent read-modify-write updates (DAPM power-up, SDCA PDE transitions) see "no change" and skip the hardware write. Audio runs without errors while the amplifier remains muted. Error log: slave-tas2783 sdw:0:1:0102:0000:01:8: resume: initialization timed out slave-tas2783 sdw:0:1:0102:0000:01:8: PM: dpm_run_callback(): acpi_subsys_resume returns -110 slave-tas2783 sdw:0:1:0102:0000:01:8: PM: failed to resume: error -110 [Fix] Three patches from upstream sound tree: 1. Commit: 0d6b2d6f93a6 ("ASoC: codecs: tas2783-sdw: Propagate regcache_sync() errors") Upstream: v7.3-rc1 2. Commit: ac6d4f298160 ("ASoC: tas2783: Use new SoundWire enumeration helper") Upstream: v7.2-rc1 3. Commit: b627da430357 ("ASoC: tas2783-sdw: drop stale regcache on uninitialized re-attach") Upstream: linux-next / sound-7.3-rc1 (not yet in released tag) Fixes: 4cc9bd8d7b32 ("ASoc: tas2783A: Add soundwire based codec driver") [Test Plan] Suspend 30 times: $ sudo rtcwake -m mem -s 20 Without patches: resume takes >5s per TAS2783 device, speakers produce no audio after resume, dmesg shows "resume: initialization timed out" and "PM: failed to resume: error -110". With patches: resume completes in <1s, speakers work after resume, no timeout errors in dmesg. [Where problems could occur] Could break TAS2783 SoundWire driver resume and device initialization. The sdw_slave_wait_for_init() helper changes how the driver waits for SoundWire enumeration. If the helper has a bug, resume could hang or return an error for all SoundWire slaves, not just TAS2783. The regcache_drop_region() call removes all cached register values. If the device does not actually lose power during suspend (e.g., S3 instead of S0i3), dropping the cache forces a full re-initialization that is unnecessary and could cause a brief audio glitch on resume. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2164967/+subscriptions
вторник
[Bug 2165013] Re: HP ProBook x360 435 G8 — Recurring Hard Freeze / Crash Investigation
** 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/2165013 Title: HP ProBook x360 435 G8 — Recurring Hard Freeze / Crash Investigation Status in linux package in Ubuntu: New Bug description: # HP ProBook x360 435 G8 — Recurring Hard Freeze / Crash Investigation ## System - **Model:** HP ProBook x360 435 G8 Notebook PC - **BIOS:** T80 Ver. 01.24.02, dated 05/07/2026 (current as of investigation; no newer version found via `fwupdmgr` or public HP records) - **CPU/APU:** AMD Ryzen (Renoir, Cezanne-class), board 8886 - **OS:** Ubuntu 26.04 - **Kernel:** 7.0.0-30-generic (also reproduced under 7.0.0-29-generic) - **WiFi/BT combo:** Realtek RTL8822CE (`rtw88_8822ce` in-tree driver; also reproduced under the `rtw88-dkms` out-of-tree package) ## Symptom Intermittent hard freeze/hang under normal desktop use, most frequently correlated with sustained WiFi + disk I/O load (e.g. torrenting). Onset is abrupt — seconds of visible glitching (frozen cursor, unresponsive UI) followed by total unresponsiveness (no keyboard/mouse, no network, no visible activity). No consistent trigger identified beyond "sustained load," and it has recurred across multiple distinct mitigation attempts (see below). Occasionally recurs in rapid, back-to-back cycles (system re-freezing within 1–2 minutes of a fresh boot under the same workload). ## Root cause candidate: BIOS ACPI thermal-zone bug Every single boot — regardless of workload, kernel version, or driver configuration — logs the same malformed AML error from the BIOS's DSDT thermal zone method, at boot time, before any user activity: ``` ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000005) is beyond end of object (length 0x5) (20251212/exoparg2-393) ACPI Error: Aborting method \_TZ.GTTP due to previous error (AE_AML_PACKAGE_LIMIT) (20251212/psparse-529) ACPI Error: Aborting method \_TZ.CHGZ._TMP due to previous error (AE_AML_PACKAGE_LIMIT) (20251212/psparse-529) ``` This indicates the BIOS's `_TZ.GTTP` (Get Trip Points) method references a package object with an index (5) that exceeds the object's actual length (5, i.e. valid indices 0–4), causing the ACPI interpreter to abort the method every time it is invoked. This is present in the current shipping BIOS (01.24.02) and appears to be an HP firmware defect, not a Linux/kernel issue — the malformed AML table ships from the factory. Alongside this, every boot also logs a fan-control failure via HP's WMI interface: ``` hp_wmi: query 0x4 returned error 0x5 hp-wmi hp-wmi: Failed to apply initial fan settings: -22 ``` This is consistent with the OS's inability to reliably interact with thermal/fan management on this platform, likely downstream of the same firmware defect. ## Investigation timeline and eliminated causes Extensive diagnostics were performed to isolate the cause, in this order: 1. **Hardware watchdog (`sp5100_tco` + `watchdog`/`wd_keepalive`)** was configured to force a reboot on true system hang. Confirmed working via `wd_keepalive` heartbeat and a live SysRq panic test — the watchdog reliably recovers the system after a hang, but does not explain or fix the underlying cause. 2. **Thermal/heat ruled out.** A continuous background logger (`sensors` output every 5s) was run for days across multiple crash events. In every case, CPU/GPU temperatures immediately preceding a crash were in the mid-40s–50s °C — well below thermal throttling thresholds (NVMe critical: 79.8°C) — and load average was unremarkable (<1.0). No correlation between temperature and crash timing was found. 3. **CPU idle/C-state transitions ruled out.** An initial kernel WARNING was observed repeatedly across multiple CPUs: ``` WARNING: kernel/workqueue.c:2351 at __queue_work.part.0+0x190/0x390, CPU#N: swapper/N/0 ``` fired from `delayed_work_timer_fn → call_timer_fn → __run_timers`, on idle-thread context across several CPUs within seconds of each other. Hypothesis: CPU C-state entry/exit racing with timer-queued work. Tested via `processor.max_cstate=1` boot parameter — crashes continued at the same frequency under identical load, disconfirming this as the primary cause. 4. **WiFi driver (rtw88) implicated by a genuine use-after-free — since fixed, but not the whole story.** Kernel crash dumps (via `kdump`/`apport`, see below) captured a real kernel Oops: ``` Oops: general protection fault, probably for non-canonical address 0xdead00000000012a: 0000 [#1] SMP NOPTI RIP: 0010:__run_timers+0x1e0/0x2c0 RAX: dead000000000122 R12: dead000000000122 ``` `0xdead000000000122` is the kernel's `LIST_POISON2` sentinel — this is a genuine use-after-free in the timer/workqueue subsystem: a list node was dereferenced after being freed. All three captured Oops dumps were tainted `(OE)` (out-of-tree, unsigned module), with `rtw_8822ce(OE)`, `rtw_core(OE)`, `rtw_pci(OE)` in the loaded module list — identifying the **out-of-tree `rtw88-dkms` package**, not the in-tree kernel driver, as the module active at time of crash. **Mitigation applied:** removed `rtw88-dkms` entirely (`dkms remove rtw88/0.6 --all`), reverted to the in-tree `rtw88_8822ce`/`rtw88_core`/`rtw88_pci` modules bundled with the kernel. Additionally applied, as defense in depth: - `disable_lps_deep=Y` module parameter (deep power-save disabled) - `iw dev wlp1s0 set power_save off` + persisted via NetworkManager - `pcie_aspm=off` kernel boot parameter **Result: the specific use-after-free signature has not recurred since.** However, hard freezes continued to occur afterward under the same load pattern, indicating this fixed a real, independent bug but was not the sole cause of the reported symptom. 5. **`hung_task_panic=1` / `softlockup_panic=1` enabled** to force any future scheduler-visible hang into a full kernel panic + `kdump` capture, for better diagnostics. On the most recent recurrences of the freeze, **neither trigger fired** — no hung-task warning, no softlockup warning, no Oops, nothing abnormal in the kernel log beyond the standing `_TZ.GTTP` ACPI error — the log simply stops mid-routine- activity with no further entries until the next boot. This indicates the freeze is occurring **below the level the kernel's own scheduler- based hang detection can observe** (consistent with an EC/firmware- level deadlock rather than a kernel-level stall). 6. **Manual `kdump` capture test also fails to complete.** A deliberate `echo c | sudo tee /proc/sysrq-trigger` panic was triggered on a working system (confirmed `kexec_crash_loaded=1`, `kdump- tools.service` active and enabled, valid `/var/crash` target with ample free space) and left for 5+ minutes with no recovery — required a manual power cycle. This suggests that even a deliberately-triggered kernel panic cannot reliably hand off to the crash kernel on this specific hardware, which is consistent with (though not conclusive proof of) a firmware/EC-level fault interfering with the kexec handoff itself. ## Current assessment The most likely root cause is a **BIOS/EC firmware defect** centered on the malformed `_TZ.GTTP` ACPI thermal method (confirmed present in BIOS 01.24.02, the latest available version). This firmware bug: - Fires on every single boot, unconditionally - Correlates with a fan-control failure via `hp-wmi` - Cannot be worked around from the OS side (C-states, WiFi driver, ASPM, power-save were all eliminated as primary causes) - Appears able to wedge the system at a level below the kernel's own panic/hang detection, given that `hung_task_panic`/`softlockup_panic`/manual `kdump` triggers have all failed to produce a normal recovery during or after the actual freeze The only reliable recovery mechanism found is the AMD chipset-level hardware watchdog (`sp5100_tco`), which operates independently of the OS/kernel scheduler and forces a hardware reboot regardless of what is wedged above it. ## Requests **To HP:** Please investigate and correct the malformed `_TZ.GTTP` AML method in the DSDT for the ProBook x360 435 G8 (board 8886), as reported in BIOS 01.24.02. The specific ACPI error is: ``` AE_AML_PACKAGE_LIMIT, Index (0x000000005) is beyond end of object (length 0x5) ``` in the `\_TZ.GTTP` method (and its caller `\_TZ.CHGZ._TMP`). This appears to be a straightforward off-by-one or incorrectly sized package object in the DSDT thermal zone table. **To Ubuntu/kernel maintainers:** Investigating why `hung_task_panic=1`/`softlockup_panic=1` and a manually-triggered SysRq panic both fail to produce a completed `kdump` capture on this hardware would help future diagnosis of firmware-adjacent freezes of this kind — ideally kdump should be robust even when the underlying fault is outside the kernel's control. ## Supporting evidence available on request - Full `journalctl -k` output from multiple affected boots - Three decompressed `VmCoreDmesg` crash dumps (Aug 24, 2026, boots at 20:19, 20:44, 20:57) showing the `LIST_POISON2` use-after-free Oops, including full register state and stack traces - Continuous thermal/load logs spanning multiple crash events, showing no thermal correlation - `dmidecode` hardware/BIOS identification output ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-30-generic 7.0.0-30.30 ProcVersionSignature: Ubuntu 7.0.0-30.30-generic 7.0.12 Uname: Linux 7.0.0-30-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: user 2439 F.... wireplumber /dev/snd/controlC0: user 2439 F.... wireplumber /dev/snd/seq: user 2408 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Aug 25 18:02:12 2026 InstallationDate: Installed on 2026-07-22 (34 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: HP HP ProBook x360 435 G8 Notebook PC ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-30-generic root=UUID=0f4e9813-352a-4b48-a23f-e0a88c3524d7 ro quiet splash pcie_aspm=off 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: 05/07/2026 dmi.bios.release: 24.2 dmi.bios.vendor: HP dmi.bios.version: T80 Ver. 01.24.02 dmi.board.name: 8886 dmi.board.vendor: HP dmi.board.version: KBC Version 45.38.00 dmi.chassis.type: 31 dmi.chassis.vendor: HP dmi.ec.firmware.release: 69.56 dmi.modalias: dmi:bvnHP:bvrT80Ver.01.24.02:bd05/07/2026:br24.2:efr69.56:svnHP:pnHPProBookx360435G8NotebookPC:pvrSBKPFV3:rvnHP:rn8886:rvrKBCVersion45.38.00:cvnHP:ct31:cvr:sku4V8H3PA#ABG:pfa103C_5336ANHPProBookx360: dmi.product.family: 103C_5336AN HP ProBook x360 dmi.product.name: HP ProBook x360 435 G8 Notebook PC dmi.product.sku: 4V8H3PA#ABG dmi.product.version: SBKPFV3 dmi.sys.vendor: HP To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2165013/+subscriptions
[Bug 2165019] Re: rtl8723bs: WiFi association succeeds but 4-way handshake and DHCP fail — "coalesce failed with error -22" (regression fixed upstream in 7.1.5)
** 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/2165019 Title: rtl8723bs: WiFi association succeeds but 4-way handshake and DHCP fail — "coalesce failed with error -22" (regression fixed upstream in 7.1.5) Status in linux package in Ubuntu: New Bug description: [Impact] WiFi is completely unusable as a client on devices with the Realtek RTL8723BS (SDIO) chipset running the 7.0 kernel shipped with Ubuntu 26.04 LTS. The device associates with the access point, but no data frames are transmitted: the WPA 4-way handshake times out, and on open networks DHCP never completes. dmesg is flooded with: rtl8723bs mmc0:0001:1 wlan0: xmit_xmitframes: coalesce failed with error -22 This affects a large class of cheap Bay Trail / Cherry Trail laptops, tablets and ARM boards that ship this chipset. [System information] Ubuntu release: 26.04 LTS (resolute) Affected kernels: 7.0.0-14-generic, 7.0.0-30-generic (both reproduce) Working kernel: 7.1.9 (mainline, from kernel.ubuntu.com/mainline) Architecture: amd64 (32-bit UEFI firmware, 64-bit CPU) Hardware: Irbis NB11, Intel Atom Z3735F (Bay Trail-T) WiFi: Realtek RTL8723BS over SDIO, driver r8723bs (staging) [Steps to reproduce] 1. Boot Ubuntu 26.04 with kernel 7.0.0-x on RTL8723BS hardware. 2. Attempt to connect to any WPA2-PSK network. 3. Connection fails. NetworkManager reports "no-secrets" / wrong password, which is misleading — the passphrase is correct. [Actual behaviour] wpa_supplicant output shows association succeeding, then the handshake failing: wlan0: Associated with xx:xx:xx:xx:xx:xx wlan0: CTRL-EVENT-DISCONNECTED reason=0 locally_generated=1 wlan0: WPA: 4-Way Handshake failed - pre-shared key may be incorrect The same happens on an open (unencrypted) network: association succeeds, the link comes up, but DHCP never obtains an address. This confirms the problem is in the TX path, not in the crypto or the credentials. Management frames are transmitted fine (association works), which is why the failure only shows up once data frames need to be sent. [Root cause] Regression introduced by commit: bc4df274dca66a8f534feff5d3e1881f3c9b9bf6 "staging: rtl8723bs: update _rtw_pktfile_read() to return error codes" The commit changes _rtw_pktfile_read() to return -EINVAL when the remaining data is shorter than the requested length. Previously the function clamped the length. However, rtw_xmitframe_coalesce() legitimately requests more than the remaining length, so every such transmission now aborts with -EINVAL instead of sending a correctly clamped frame. [Fix] Fixed upstream; the fix is present in kernel 7.1.5 and later. Verified: installing mainline kernel 7.1.9 on the same machine, with no other changes, restores full WiFi functionality. No more "coalesce failed" messages, WPA2 connects normally, DHCP works. [Request] Please backport the upstream fix to the 7.0 kernel in 26.04 LTS. Users on this hardware currently have no supported option: there is no maintained out-of-tree driver for RTL8723BS (the code lives in staging), so the only workarounds are running an unsupported mainline kernel with no security updates, or buying a USB WiFi adapter. [Reference] Upstream discussion and confirmation that 7.1.5 contains the fix: https://bbs.archlinux.org/viewtopic.php?id=313401 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2165019/+subscriptions
[Bug 2165021] Re: Backport of GPIO driver patch
** 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/2165021 Title: Backport of GPIO driver patch Status in linux package in Ubuntu: New Bug description: The Nuvoton NCT6126D Super-I/O is available in two hardware revisions with different chip IDs. The current driver supports only the version A, while the new patched version also supports the version B. The patched version is already merged in the upstream: https://github.com/torvalds/linux/commit/9a6c0b6ea12746d50cf53d59a7e05fd83f974bda It has been released in upstream 7.2. and 7.1.y. Please, backport the mainline commit into the Ubuntu 26.04; linux 7.0.0-xx. I am on Ubuntu Core pc-kernel 26/stable. Thanks, Pavel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2165021/+subscriptions
[Bug 1786013] Autopkgtest regression report (linux-meta-oem-7.0/7.0.0-1013.13)
All autopkgtests for the newly accepted linux-meta-oem-7.0 (7.0.0-1013.13) for resolute have finished running. The following regressions have been reported in tests triggered by the package: backport-iwlwifi-dkms/unknown (amd64v3) lxc/unknown (amd64v3) systemd/259.5-0ubuntu3.4 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://ubuntu-archive-team.ubuntu.com/proposed- migration/resolute/update_excuses.html#linux-meta-oem-7.0 [1] https://documentation.ubuntu.com/project/SRU/howto/autopkgtest- failure/ Thank you! -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/1786013 Title: Packaging resync Status in linux package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: Fix Released Status in linux-azure-edge package in Ubuntu: Fix Released Status in linux source package in Precise: Fix Released Status in linux-azure source package in Precise: Won't Fix Status in linux-azure-edge source package in Precise: Won't Fix Status in linux source package in Trusty: Fix Released Status in linux-azure source package in Trusty: Fix Released Status in linux-azure-edge source package in Trusty: Won't Fix Status in linux source package in Xenial: Fix Released Status in linux-azure source package in Xenial: Fix Released Status in linux-azure-edge source package in Xenial: Fix Released Status in linux source package in Bionic: Fix Released Status in linux-azure source package in Bionic: Fix Released Status in linux-azure-edge source package in Bionic: Fix Released Status in linux source package in Cosmic: Fix Released Status in linux-azure source package in Cosmic: Fix Released Status in linux-azure-edge source package in Cosmic: Won't Fix Status in linux source package in Disco: Fix Released Status in linux-azure source package in Disco: Fix Released Status in linux-azure-edge source package in Disco: Won't Fix Bug description: Ongoing packaging resyncs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1786013/+subscriptions
[Bug 2158971] Re: amdgpu: ring gfx_0.1.0 timeout + page fault on gnome-shell (Rembrandt/YELLOW_CARP, GFX10.3, RTL8852BE notebook)
*** This bug is a duplicate of bug 2158614 *** https://bugs.launchpad.net/bugs/2158614 Thanks for confirming, I will mark this as a duplicate of bug 2158614. Please feel free to continue the discussion on that bug. ** This bug has been marked a duplicate of bug 2158614 amdgpu: Granite Ridge iGPU gfx ring timeout after Chrome GPU page fault causes gnome-shell SIGABRT and session loss -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2158971 Title: amdgpu: ring gfx_0.1.0 timeout + page fault on gnome-shell (Rembrandt/YELLOW_CARP, GFX10.3, RTL8852BE notebook) Status in linux package in Ubuntu: Incomplete Bug description: Hardware: Lenovo IdeaPad Slim 3 (AMD Rembrandt/YELLOW_CARP, 0x1681) Kernel: 6.17.0-35-generic (Ubuntu HWE 24.04) Mesa: 25.2.8-0ubuntu0.24.04.2 Driver: amdgpu (radeonsi, DRM 3.64) Session: GNOME Wayland Symptom: Recurring GPU reset (4 times in 10 days, increasing frequency). Screen freezes for ~2-3 seconds, recovers automatically via MODE2 reset. Process always involved: gnome-shell (cs0 thread). Kernel log pattern on every occurrence: - ring gfx_0.1.0 timeout - [gfxhub] page fault, PERMISSION_FAULTS, client UTCL2/SQC - Ring gfx_0.1.0 reset failed - GPU reset begin / MODE2 reset / GPU reset succeeded AMDGPU coredump attached (captured via udev rule immediately after fault). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2158971/+subscriptions
[Bug 2159937] Re: ASUS X411UA hard-freezes after GDM blanks display on i915
*** This bug is a duplicate of bug 2150732 *** https://bugs.launchpad.net/bugs/2150732 Hi Alan, Thanks for taking the time to report a bug and helping to improve Ubuntu. This bug report appears to be a duplicate of bug 2150732 so I am marking it as such. Please look at the other bug report and see if there is any additional information you can provide, or report a discovered workaround. Further discussion should occur in bug 2150732. Feel free to continue to report any other bugs you find. ** This bug has been marked a duplicate of bug 2150732 Screen stays black after resuming from sleep -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2159937 Title: ASUS X411UA hard-freezes after GDM blanks display on i915 Status in linux package in Ubuntu: New Bug description: Hardware: - ASUS VivoBook S X411UA - Intel Core i7-8550U - Intel UHD Graphics 620, PCI ID 8086:5917, i915 - BIOS X411UA.310 - Internal 1920×1080 display Software: - Ubuntu 26.04 - Kernel 7.0.0-27-generic - GNOME/GDM using Wayland Steps to reproduce: 1. Boot to the GDM login screen. 2. Leave the machine idle until the display blanks. 3. The machine subsequently becomes completely unresponsive and requires a hard power-off. Moving the cursor delays both display blanking and the freeze. The issue reproduced repeatedly. The journal ends abruptly without a clean shutdown, OOM, storage, or thermal error. Before one freeze, the kernel repeatedly reported: workqueue: output_poll_execute hogged CPU workqueue: i915_hpd_poll_init_work [i915] hogged CPU Testing: - i915.enable_psr=0 alone did not fix the problem. - i915.enable_psr=0 i915.enable_dc=0 has remained stable during stress testing and display blanking so far. Expected result: The display blanks and wakes normally without affecting the system. Actual result: Display blanking leads to a complete system freeze. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-27-generic 7.0.0-27.27 ProcVersionSignature: Ubuntu 7.0.0-27.27-generic 7.0.6 Uname: Linux 7.0.0-27-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', '/dev/snd/controlC0', '/dev/snd/hwC0D2', '/dev/snd/hwC0D0', '/dev/snd/pcmC0D8p', '/dev/snd/pcmC0D7p', '/dev/snd/pcmC0D3p', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CasperMD5CheckResult: unknown Date: Tue Jul 7 16:16:10 2026 InstallationDate: Installed on 2026-07-07 (0 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 13d3:5a07 IMC Networks VGA UVC WebCam Bus 001 Device 003: ID 8087:0a2b Intel Corp. Bluetooth wireless interface Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub MachineType: ASUSTeK COMPUTER INC. X411UA ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no username) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-27-generic root=UUID=be61cce7-c4dc-42f6-99ea-8d7847981abe ro i915.enable_psr=0 i915.enable_psr=0 i915.enable_dc=0 quiet splash 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: 04/16/2019 dmi.bios.release: 5.12 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: X411UA.310 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: X411UA 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:bvnAmericanMegatrendsInc.:bvrX411UA.310:bd04/16/2019:br5.12:svnASUSTeKCOMPUTERINC.:pnX411UA:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnX411UA:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:sku:pfaVivoBookS: dmi.product.family: VivoBook S dmi.product.name: X411UA 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/2159937/+subscriptions
[Bug 2161937] Re: ThinkPad P1 Gen 7 (Intel Meteor Lake) black screen after suspend (s2idle) on Ubuntu 26.04
Tested a 104min suspend on mainline kernel 7.2 https://kernel.ubuntu.com/mainline/v7.2/ and it resumed without issue. No other changes. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161937 Title: ThinkPad P1 Gen 7 (Intel Meteor Lake) black screen after suspend (s2idle) on Ubuntu 26.04 Status in linux package in Ubuntu: Confirmed Bug description: Summary Suspend/resume consistently fails to restore the display on a Lenovo ThinkPad P1 Gen 7 with Intel 135H CPU (no dedicated GPU). The system appears to resume successfully (keyboard remains responsive, Caps Lock light toggles), but the internal display remains black. Sometimes connecting an external monitor immediately restores both displays (laptop screen and external monitor). Other times neither the internal nor external display comes back and a hard reboot is required. Some extended testing seems to suggest that the system successfully resumes as long as you bring it back before the Automatic Suspend Delay kicks in. I can manually suspend it and bring it right back up without issue. I can close the lid which suspends it and bring it right back up without issue. If I leave the computer open and allow the Automatic Suspend Delay (15 min on my machine) to be reached, then it will not come back up. This is the issue being described in this bug report. I have not tried manually suspending and then waiting 15+ min to bring back up yet, but will try soon. *UPDATE: manual suspending and then waiting a long time also has the same issue. It seems to be time related, and not directly related to what triggered the suspend. Plugged in vs unplugged does not appear to make a difference, but more in depth testing may be required. Hardware Lenovo ThinkPad P1 Gen 7 Intel Core Ultra 5 135H Intel Arc integrated graphics only (no NVIDIA GPU) BIOS N48ET34W (1.21) Software Ubuntu 26.04, installed from official Ubuntu ISO on July 25th 2026. Kernel 7.0.0-28-generic **UPDATE: still broken on 7.0.0-29-generic & 7.0.0-30-generic GNOME on Wayland Suspend mode: s2idle Graphics driver: i915 (xe driver available, but i915 seems to be the default) Steps to reproduce Boot normally. Suspend the system. Resume the system. Note, does NOT occur on every suspend/resume cycle, only sometimes. It seems to happen more consistently when the computer has been suspended for a long time. Quick suspend/resume cycles in rapid succession are usually successful (but not always). This is covered in the summary section above. Expected result The display should restore normally. Actual result The system resumes but the display remains black. Caps Lock continues to function, and well as other keyboard lights, indicating the system is still running. Sometimes attaching an external monitor restores the display. Other times it does not. One time it brought itself back on after a few minutes, but I have not been able to reproduce that in a while. Relevant kernel messages After resume the kernel reports Intel i915 display failures including: Failed to bring PHY A to idle Timeout waiting for DDI BUF A flip_done timed out DPLL hardware state mismatch These occur immediately after resume. Other bugs that seems similar or related: Red Hat Bugzilla #2463170 (Fedora 44, kernel 7.0.x) https://bugzilla.redhat.com/show_bug.cgi?id=2463170&utm_source=chatgpt.com ThinkPad P1 Gen 7 Intel integrated graphics Suspend/resume failures Exact same errors: Failed to bring PHY A to idle Timeout waiting for DDI BUF A to get active Timed out waiting for DP idle patterns flip_done timed out Arch Linux forum thread (May 2026) https://bbs.archlinux.org/viewtopic.php?id=313680&utm_source=chatgpt.com Users on 7.0 kernels report: Failed to bring PHY A to idle Pageflip timed out! This is a bug in the i915 kernel driver flip_done timed out Ubuntu Community (Discourse) https://discourse.ubuntu.com/t/laptop-screen-having-trouble-turning-on-after-sleep-being-off/81112?utm_source=chatgpt.com Another ThinkPad P1 Gen 7 owner (replying in the comments) reports black-screen-after-sleep behavior on Ubuntu 26.04. Their hardware includes a discrete NVIDIA GPU, but they're using Wayland with Mesa, and the symptom (internal display failing after suspend) is similar. Gitlab https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16098 . . . ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-28-generic 7.0.0-28.28 ProcVersionSignature: Ubuntu 7.0.0-28.28-generic 7.0.12 Uname: Linux 7.0.0-28-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: jeff 4502 F.... pipewire jeff 4522 F.... wireplumber /dev/snd/seq: jeff 4502 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon Jul 27 21:21:31 2026 InstallationDate: Installed on 2026-07-23 (4 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: LENOVO 21KVCTO1WW 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-28-generic root=UUID=c5c9f1a7-f9a8-4681-8d58-4dbe3736da6e ro quiet splash 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: 05/11/2026 dmi.bios.release: 1.21 dmi.bios.vendor: LENOVO dmi.bios.version: N48ET34W (1.21 ) dmi.board.asset.tag: Not Available dmi.board.name: 21KVCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0T76530 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.ec.firmware.release: 1.15 dmi.modalias: dmi:bvnLENOVO:bvrN48ET34W(1.21):bd05/11/2026:br1.21:efr1.15:svnLENOVO:pn21KVCTO1WW:pvrThinkPadP1Gen7:rvnLENOVO:rn21KVCTO1WW:rvrSDK0T76530WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_21KV_BU_Think_FM_ThinkPadP1Gen7:pfaThinkPadP1Gen7: dmi.product.family: ThinkPad P1 Gen 7 dmi.product.name: 21KVCTO1WW dmi.product.sku: LENOVO_MT_21KV_BU_Think_FM_ThinkPad P1 Gen 7 dmi.product.version: ThinkPad P1 Gen 7 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161937/+subscriptions
Re: [Bug 2160752] Re: uvcvideo: unkillable deadlock in status-event/PM path wedges USB stack (RealSense D405)
Thanks for this, Alice! In the meantime, we have a local patch and block any upstream updates from overwriting it. Once we know the release is out, we can lift the update block for our machines. On Tue, Aug 25, 2026 at 8:40 AM Alice C. Munduruca < 2160752@bugs.launchpad.net> wrote: > Hello Jay, > > Your fix commit has been pulled in from upstream stable and will thus be > included in the kernel version succeeding 7.0.0-31.31. I'll get back to > you once the fixed kernel is released :) > > ** Changed in: linux (Ubuntu Resolute) > Status: In Progress => Fix Committed > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/2160752 > > Title: > uvcvideo: unkillable deadlock in status-event/PM path wedges USB stack > (RealSense D405) > > Status in linux package in Ubuntu: > New > Status in linux source package in Resolute: > Fix Committed > > Bug description: > # uvcvideo: unkillable deadlock in status-event / PM path (kernel 7.0) > > Draft for: Launchpad (`ubuntu-bug linux`, tag `regression-update`) and > linux-media@vger.kernel.org (CC uvcvideo maintainer + granular-PM > series author). > Status: draft, 2026-07-15. Traces: `uvcvideo-deadlock-traces.txt` (same > directory). > > ## Summary > > Control access to an Intel RealSense D405 (USB 8086:0b5b) reliably > wedges the > whole USB host stack on Ubuntu kernel 7.0.0-27-generic (also present, by > code > inspection, in upstream v7.0.6 and current mainline). The triggering > process > enters uninterruptible sleep (unkillable, survives SIGKILL), and the > device's > USB disconnect path then deadlocks the hub workqueue (`usb_hub_wq` in D > state), > after which no device on that hub can enumerate. Only a reboot recovers. > > ## Root cause (source analysis, drivers/media/usb/uvc) > > `uvc_ctrl_set_handle()` takes a PM reference (`uvc_pm_get`) for a pending > async control, released by `uvc_ctrl_clear_handle()` -> `uvc_pm_put()` > when the > control-change status event arrives. That release runs inside > `uvc_ctrl_status_event()`, which is invoked from two contexts where > dropping > the LAST status user deadlocks: > > 1. From the async worker `uvc_ctrl_status_event_work()`: > `uvc_pm_put` -> `uvc_status_put` (takes `status_lock`) -> > `uvc_status_stop` > -> `cancel_work_sync(&dev->async_ctrl.work)` — cancelling the work > item it > is currently executing in. Waits for itself forever, holding > `status_lock`. > > 2. From `uvc_status_stop()` itself (the synchronous flush, > `if (cancel_work_sync(&w->work)) uvc_ctrl_status_event(...)`): > the same put chain then re-acquires `status_lock`, which the caller > (`uvc_status_put`/`uvc_status_suspend`) already holds. Self-deadlock > on a > non-recursive mutex. > > Every subsequent open/ioctl blocks in `uvc_status_get()` on `status_lock` > (observed hung tasks), and `uvc_status_unregister()` -> > `uvc_status_suspend()` > blocks the USB disconnect path, freezing the hub workqueue. > > ## Observed impact (hardware reproduction) > > - Machine: omen rig, Ubuntu resolute, kernel 7.0.0-27-generic, 2x Intel > RealSense D405 + 1x D435 on the same bus. > - One D405 unit hits the race nearly every time on XU control access (its > firmware emits the status event at the fatal moment); the other unit > survives identical commands. Reproduced via librealsense enumeration > AND via > minimal raw UVCIOC_CTRL_QUERY ioctls; also right after a clean boot. > - Hung-task stacks captured in `uvcvideo-deadlock-traces.txt` show both > sides: > `uvc_v4l2_unlocked_ioctl -> uvc_status_get` blocked, and > `Workqueue: events uvc_ctrl_status_event_work -> uvc_ctrl_status_event > -> > uvc_pm_put -> uvc_status_put -> uvc_status_stop` blocked. > - No uvcvideo changes between Ubuntu 7.0.0-14 and -27 (changelog); not an > Ubuntu-local regression. `uvc_status.c` identical in mainline as of > 2026-07-15; no fix or report found on linux-media/patchwork. > > ## Suggested direction for a fix > > Dropping the pending-async-control PM reference must not synchronously > stop > the status URB from the event-delivery contexts. Options: defer the final > `uvc_status_stop()` to a separate work item when called from the async > worker > (`current_work() == &dev->async_ctrl.work`), or drop the reference > outside > `status_lock` / outside the worker. The synchronous-flush path (2) > additionally > must not re-enter `uvc_status_put` under `status_lock`. > > ## Verification (2026-07-15, same machine) > > - Firmware dependence of the trigger: on camera FW 5.15.1.55 one D405 > unit > wedged nearly every XU control access and the other rarely; after > updating > both cameras to FW 5.17.3.10 the deadlock became DETERMINISTIC on both > units (first control-change sequence wedges both cameras, reproduced > immediately after a clean boot). Newer firmware appears to deliver the > async control-change status event more reliably, hitting the race > window > every time. > - Workaround validation: with the patched module (status endpoint never > armed, see below), the identical control sequences complete with zero > hangs across repeated apply/hammer cycles on both FW versions' event > behavior. Side effect observed: async controls (AE/exposure) remain > "pending" forever (GET returns EBUSY) since the confirmation event > never > arrives — consistent with uvc_ctrl_set_handle never being cleared, and > benign for operation (SETs land; streaming unaffected). > > ## Local mitigation deployed on this machine > > Out-of-tree build of uvcvideo 7.0.0-27 with a `disable_status` module > parameter that skips `uvc_status_init()` URB arming entirely (no status > events -> no worker -> no deadlock; costs async control-change > notifications > and camera-button events). Installed under > `/lib/modules/7.0.0-27-generic/updates/`, enabled via > `/etc/modprobe.d/uvcvideo-rig.conf`. > > ProblemType: Bug > DistroRelease: Ubuntu 26.04 > Package: linux-image-7.0.0-27-generic 7.0.0-27.27 > ProcVersionSignature: Ubuntu 7.0.0-27.27-generic 7.0.6 > Uname: Linux 7.0.0-27-generic x86_64 > ApportVersion: 2.34.0-0ubuntu2 > Architecture: amd64 > AudioDevicesInUse: > USER PID ACCESS COMMAND > /dev/snd/controlC2: robocurve 5721 F.... wireplumber > /dev/snd/controlC0: robocurve 5721 F.... wireplumber > /dev/snd/controlC1: robocurve 5721 F.... wireplumber > /dev/snd/seq: robocurve 5703 F.... pipewire > CasperMD5CheckResult: unknown > CurrentDesktop: ubuntu:GNOME > Date: Thu Jul 16 00:03:18 2026 > InstallationDate: Installed on 2026-06-29 (16 days ago) > InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 > (20260423.1) > MachineType: HP OMEN by HP 45L Gaming Desktop GT22-3xxx > ProcEnviron: > LANG=en_US.UTF-8 > PATH=(custom, no user) > SHELL=/bin/bash > TERM=tmux-256color > XDG_RUNTIME_DIR=<set> > ProcFB: 0 nvidia-drmdrmfb > ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-27-generic > root=UUID=1639853a-6154-4c17-954d-08761337d8ae ro quiet splash > 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: 11/13/2025 > dmi.bios.release: 15.32 > dmi.bios.vendor: AMI > dmi.bios.version: F.20 > dmi.board.name: 8D2C > dmi.board.vendor: HP > dmi.board.version: 00 > dmi.chassis.type: 3 > dmi.chassis.vendor: HP > dmi.ec.firmware.release: 36.15 > dmi.modalias: > dmi:bvnAMI:bvrF.20:bd11/13/2025:br15.32:efr36.15:svnHP:pnOMENbyHP45LGamingDesktopGT22-3xxx:pvr:rvnHP:rn8D2C:rvr00:cvnHP:ct3:cvr:skuB91WJAA#ABA:pfa103C_5331M5HPOMEN: > dmi.product.family: 103C_5331M5 HP OMEN > dmi.product.name: OMEN by HP 45L Gaming Desktop GT22-3xxx > dmi.product.sku: B91WJAA#ABA > dmi.sys.vendor: HP > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2160752/+subscriptions > > -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2160752 Title: uvcvideo: unkillable deadlock in status-event/PM path wedges USB stack (RealSense D405) Status in linux package in Ubuntu: New Status in linux source package in Resolute: Fix Committed Bug description: # uvcvideo: unkillable deadlock in status-event / PM path (kernel 7.0) Draft for: Launchpad (`ubuntu-bug linux`, tag `regression-update`) and linux-media@vger.kernel.org (CC uvcvideo maintainer + granular-PM series author). Status: draft, 2026-07-15. Traces: `uvcvideo-deadlock-traces.txt` (same directory). ## Summary Control access to an Intel RealSense D405 (USB 8086:0b5b) reliably wedges the whole USB host stack on Ubuntu kernel 7.0.0-27-generic (also present, by code inspection, in upstream v7.0.6 and current mainline). The triggering process enters uninterruptible sleep (unkillable, survives SIGKILL), and the device's USB disconnect path then deadlocks the hub workqueue (`usb_hub_wq` in D state), after which no device on that hub can enumerate. Only a reboot recovers. ## Root cause (source analysis, drivers/media/usb/uvc) `uvc_ctrl_set_handle()` takes a PM reference (`uvc_pm_get`) for a pending async control, released by `uvc_ctrl_clear_handle()` -> `uvc_pm_put()` when the control-change status event arrives. That release runs inside `uvc_ctrl_status_event()`, which is invoked from two contexts where dropping the LAST status user deadlocks: 1. From the async worker `uvc_ctrl_status_event_work()`: `uvc_pm_put` -> `uvc_status_put` (takes `status_lock`) -> `uvc_status_stop` -> `cancel_work_sync(&dev->async_ctrl.work)` — cancelling the work item it is currently executing in. Waits for itself forever, holding `status_lock`. 2. From `uvc_status_stop()` itself (the synchronous flush, `if (cancel_work_sync(&w->work)) uvc_ctrl_status_event(...)`): the same put chain then re-acquires `status_lock`, which the caller (`uvc_status_put`/`uvc_status_suspend`) already holds. Self-deadlock on a non-recursive mutex. Every subsequent open/ioctl blocks in `uvc_status_get()` on `status_lock` (observed hung tasks), and `uvc_status_unregister()` -> `uvc_status_suspend()` blocks the USB disconnect path, freezing the hub workqueue. ## Observed impact (hardware reproduction) - Machine: omen rig, Ubuntu resolute, kernel 7.0.0-27-generic, 2x Intel RealSense D405 + 1x D435 on the same bus. - One D405 unit hits the race nearly every time on XU control access (its firmware emits the status event at the fatal moment); the other unit survives identical commands. Reproduced via librealsense enumeration AND via minimal raw UVCIOC_CTRL_QUERY ioctls; also right after a clean boot. - Hung-task stacks captured in `uvcvideo-deadlock-traces.txt` show both sides: `uvc_v4l2_unlocked_ioctl -> uvc_status_get` blocked, and `Workqueue: events uvc_ctrl_status_event_work -> uvc_ctrl_status_event -> uvc_pm_put -> uvc_status_put -> uvc_status_stop` blocked. - No uvcvideo changes between Ubuntu 7.0.0-14 and -27 (changelog); not an Ubuntu-local regression. `uvc_status.c` identical in mainline as of 2026-07-15; no fix or report found on linux-media/patchwork. ## Suggested direction for a fix Dropping the pending-async-control PM reference must not synchronously stop the status URB from the event-delivery contexts. Options: defer the final `uvc_status_stop()` to a separate work item when called from the async worker (`current_work() == &dev->async_ctrl.work`), or drop the reference outside `status_lock` / outside the worker. The synchronous-flush path (2) additionally must not re-enter `uvc_status_put` under `status_lock`. ## Verification (2026-07-15, same machine) - Firmware dependence of the trigger: on camera FW 5.15.1.55 one D405 unit wedged nearly every XU control access and the other rarely; after updating both cameras to FW 5.17.3.10 the deadlock became DETERMINISTIC on both units (first control-change sequence wedges both cameras, reproduced immediately after a clean boot). Newer firmware appears to deliver the async control-change status event more reliably, hitting the race window every time. - Workaround validation: with the patched module (status endpoint never armed, see below), the identical control sequences complete with zero hangs across repeated apply/hammer cycles on both FW versions' event behavior. Side effect observed: async controls (AE/exposure) remain "pending" forever (GET returns EBUSY) since the confirmation event never arrives — consistent with uvc_ctrl_set_handle never being cleared, and benign for operation (SETs land; streaming unaffected). ## Local mitigation deployed on this machine Out-of-tree build of uvcvideo 7.0.0-27 with a `disable_status` module parameter that skips `uvc_status_init()` URB arming entirely (no status events -> no worker -> no deadlock; costs async control-change notifications and camera-button events). Installed under `/lib/modules/7.0.0-27-generic/updates/`, enabled via `/etc/modprobe.d/uvcvideo-rig.conf`. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-27-generic 7.0.0-27.27 ProcVersionSignature: Ubuntu 7.0.0-27.27-generic 7.0.6 Uname: Linux 7.0.0-27-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC2: robocurve 5721 F.... wireplumber /dev/snd/controlC0: robocurve 5721 F.... wireplumber /dev/snd/controlC1: robocurve 5721 F.... wireplumber /dev/snd/seq: robocurve 5703 F.... pipewire CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Thu Jul 16 00:03:18 2026 InstallationDate: Installed on 2026-06-29 (16 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: HP OMEN by HP 45L Gaming Desktop GT22-3xxx ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=tmux-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 nvidia-drmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-27-generic root=UUID=1639853a-6154-4c17-954d-08761337d8ae ro quiet splash 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: 11/13/2025 dmi.bios.release: 15.32 dmi.bios.vendor: AMI dmi.bios.version: F.20 dmi.board.name: 8D2C dmi.board.vendor: HP dmi.board.version: 00 dmi.chassis.type: 3 dmi.chassis.vendor: HP dmi.ec.firmware.release: 36.15 dmi.modalias: dmi:bvnAMI:bvrF.20:bd11/13/2025:br15.32:efr36.15:svnHP:pnOMENbyHP45LGamingDesktopGT22-3xxx:pvr:rvnHP:rn8D2C:rvr00:cvnHP:ct3:cvr:skuB91WJAA#ABA:pfa103C_5331M5HPOMEN: dmi.product.family: 103C_5331M5 HP OMEN dmi.product.name: OMEN by HP 45L Gaming Desktop GT22-3xxx dmi.product.sku: B91WJAA#ABA dmi.sys.vendor: HP To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2160752/+subscriptions
[Bug 2160733] Re: Resolute update: upstream stable patchset 2026-07-15
-- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2160733 Title: Resolute update: upstream stable patchset 2026-07-15 Status in linux package in Ubuntu: Invalid Status in linux source package in Resolute: Fix Committed Bug description: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: upstream stable patchset 2026-07-15 Ported from the following upstream stable releases: v6.18.38, v7.1.3 from git://git.kernel.org/ KVM: x86: Fix shadow paging use-after-free due to unexpected role Revert "PCI: qcom: Advertise Hotplug Slot Capability with no Command Completion support" batman-adv: tp_meter: keep unacked list in ascending ordered batman-adv: tp_meter: initialize dup_acks explicitly batman-adv: tp_meter: initialize dec_cwnd explicitly batman-adv: tp_meter: avoid window underflow batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd batman-adv: tp_meter: fix fast recovery precondition batman-adv: tp_meter: handle seqno wrap-around for fast recovery detection batman-adv: tp_meter: add only finished tp_vars to lists batman-adv: bla: annotate lasttime access with READ/WRITE_ONCE batman-adv: prevent ELP transmission interval underflow batman-adv: tp_meter: initialize last_recv_time during init batman-adv: gw: don't deselect gateway with active hardif batman-adv: ensure bcast is writable before modifying TTL batman-adv: fix (m|b)cast csum after decrementing TTL batman-adv: frag: ensure fragment is writable before modifying TTL batman-adv: frag: avoid underflow of TTL batman-adv: v: prevent OGM aggregation on disabled hardif batman-adv: tp_meter: restrict number of unacked list entries batman-adv: tp_meter: annotate last_recv_time access with READ/WRITE_ONCE batman-adv: tp_meter: prevent parallel modifications of last_recv batman-adv: tp_meter: handle overlapping packets batman-adv: tt: don't merge change entries with different VIDs batman-adv: tt: track roam count per VID batman-adv: dat: prevent false sharing between VLANs batman-adv: tvlv: enforce 2-byte alignment batman-adv: tvlv: avoid race of cifsnotfound handler state ipv6: account for fraggap on the paged allocation path ipv4: account for fraggap on the paged allocation path ntfs3: reject direct userspace writes to reserved $LX* xattrs wifi: mt76: add wcid publish check in mt76_sta_add af_unix: Set gc_in_progress to true in unix_gc(). mac802154: llsec: add skb_cow_data() before in-place crypto net: skmsg: preserve sg.copy across SG transforms net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink apparmor: mediate the implicit connect of TCP fast open sendmsg apparmor: fix use-after-free in rawdata dedup loop NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR fbdev: fix use-after-free in store_modes() kernel/fork: clear PF_BLOCK_TS in copy_process() block: invalidate cached plug timestamp after task switch KVM: arm64: Omit tag sync on stage-2 mappings of the zero page err.h: use __always_inline on all error pointer helpers gcov: use atomic counter updates to fix concurrent access crashes KEYS: fix overflow in keyctl_pkey_params_get_2() keys: Pin request_key_auth payload in instantiate paths userfaultfd: ensure mremap_userfaultfd_fail() releases mmap_changing wifi: mt76: mt76x2u: Add support for ELECOM WDC-867SU3S wifi: mt76: mt7925: don't disable AP BSS when removing TDLS peer wifi: ath11k: fix warning when unbinding wifi: rtlwifi: rtl8821ae: Fix C2H bit location in RX descriptor wifi: rtw88: increase TX report timeout to fix race condition wifi: rtw88: usb: fix memory leaks on USB write failures wifi: iwlwifi: mvm: fix race condition in PTP removal wifi: iwlwifi: mld: fix race condition in PTP removal wifi: iwlwifi: mld: validate sta_mask before ffs() in BA session handlers f2fs: pass correct iostat type for single node writes f2fs: validate orphan inode entry count f2fs: validate compress cache inode only when enabled f2fs: fix to round down start offset of fallocate for pin file f2fs: validate ACL entry sizes in f2fs_acl_from_disk() f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node() f2fs: keep atomic write retry from zeroing original data block: Avoid mounting the bdev pseudo-filesystem in userspace bpf: use kvfree() for replaced sysctl write buffer MIPS: DEC: Prevent initial console buffer from landing in XKPHYS exfat: fix potential use-after-free in exfat_find_dir_entry() KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() crypto: nx - fix nx_crypto_ctx_exit argument gfs2: fix use-after-free in gfs2_qd_dealloc pwrseq: core: fix use-after-free in pwrseq_debugfs_seq_next() hdlc_ppp: sync per-proto timers before freeing hdlc state blk-cgroup: fix UAF in __blkcg_rstat_flush() tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done LoongArch: Report dying CPU to RCU in stop_this_cpu() pNFS: Fix use-after-free in pnfs_update_layout() irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove fpga: region: fix use-after-free in child_regions_with_firmware() rpmsg: char: Fix use-after-free on probe error path ocfs2: reject oversized group bitmap descriptors 9p: avoid putting oldfid in p9_client_walk() error path MIPS: smp: report dying CPU to RCU in stop_this_cpu() KVM: x86: hyper-v: Bound the bank index when querying sparse banks KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path power: reset: linkstation-poweroff: fix use-after-free in the linkstation_poweroff_init() riscv: mm: Extract helper mark_new_valid_map() riscv: kfence: Call mark_new_valid_map() for kfence_unprotect() fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var fbdev: modedb: fix a possible UAF in fb_find_mode() fbdev: modedb: Fix misaligned fields in the 1920x1080-60 mode i2c: core: fix adapter registration race NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd: fix posix_acl leak on SETACL decode failure nfsd: fix inverted cp_ttl check in async copy reaper nfsd: check get_user() return when reading princhashlen nfsd: avoid leaking pre-allocated openowner on unconfirmed retry race nfsd: reset write verifier on deferred writeback errors NFSv4/flexfiles: reject zero filehandle version count NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr NFSv4: clear exception state on successful mkdir retry NFS: Prevent resource leak in nfs_alloc_server() ksmbd: fix out-of-bounds read in smb_check_perm_dacl() net/tcp-ao: fix use-after-free of key in del_async path apparmor: advertise the tcp fast open fix is applied PCI/P2PDMA: Add Intel QAT, DSA, IAA devices to whitelist fscrypt: Fix key setup in edge case with multiple data unit sizes wifi: rtl8xxxu: Detect the maximum supported channel width f2fs: fix missing read bio submission on large folio error f2fs: reject setattr size changes on large folio files f2fs: fix to do sanity check on f2fs_get_node_folio_ra() f2fs: atomic: fix UAF issue on f2fs_inode_info.atomic_inode f2fs: bound i_inline_xattr_size for non-inline-xattr inodes Revert "f2fs: remove non-uptodate folio from the page cache in move_data_block" f2fs: read COW data with the original inode during atomic write sched/mmcid: Fix OOB clear_bit when CID is MM_CID_UNSET in fixup path fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font() fbdev: omap2: fix inconsistent lock returns in omapfb_mmap fbdev: omap2: fix use-after-free in omapfb_mmap nfsd: release layout stid on setlease failure nfsd: fix posix_acl leak and ignored error in nfsd4_create_file nfsd: fix dead ACL conflict guard in nfsd4_create UBUNTU: Upstream stable to v6.18.38, v7.1.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2160733/+subscriptions
понедельник
[Bug 2161309] Re: Backlight regression
I could not update to kernel version 7.0.0-31-generic, nor any other kernel, due to errors, but adding the boot parameter i915.enable_dpcd_backlight=0 did help without having to change the kernel. I can confirm this helped resolve the issue of my laptop's brightness not working and being dark after waking up from suspend. Static hostname: ThinkPad Icon name: computer-laptop Chassis: laptop 💻 Machine ID: a6ba9d17a1db40b399de25da9ef40fc7 Boot ID: b27dd49b5808496a97720ad90b45f631 Operating System: Ubuntu 24.04.4 LTS Kernel: Linux 7.0.0-30-generic Architecture: x86-64 Hardware Vendor: Lenovo Hardware Model: ThinkPad X280 Firmware Version: N20ET74W (1.59 ) Firmware Date: Tue 2025-08-26 Firmware Age: 11month 4w 1d -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161309 Title: Backlight regression Status in linux package in Ubuntu: Fix Committed Status in linux-hwe-7.0 package in Ubuntu: Fix Committed Status in linux source package in Noble: Invalid Status in linux-hwe-7.0 source package in Noble: Fix Committed Status in linux source package in Resolute: Fix Committed Status in linux-hwe-7.0 source package in Resolute: Invalid Bug description: ----------------------------- Possible workaround until 7.0.0-31 kernel is released Boot with i915.enable_dpcd_backlight=0 parameter ----------------------------- ThinkPad T480 Intel UHD 620 brightness works on 7.0.0-27 brightness fails on 7.0.0-28 /sys/class/backlight/intel_backlight changes but panel does not ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-27-generic 7.0.0-27.27 ProcVersionSignature: Ubuntu 7.0.0-27.27-generic 7.0.6 Uname: Linux 7.0.0-27-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: neal 3608 F.... wireplumber /dev/snd/seq: neal 3589 F.... pipewire CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Mon Jul 20 12:47:12 2026 InstallationDate: Installed on 2026-07-12 (8 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: LENOVO 20L6S6L601 ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-27-generic root=UUID=1cea3fcd-0665-4cb4-a85a-4ebc58d5aed0 ro quiet splash acpi_backlight=native 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: 09/06/2025 dmi.bios.release: 1.56 dmi.bios.vendor: LENOVO dmi.bios.version: N24ET81W (1.56 ) dmi.board.asset.tag: Not Available dmi.board.name: 20L6S6L601 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.ec.firmware.release: 1.22 dmi.modalias: dmi:bvnLENOVO:bvrN24ET81W(1.56):bd09/06/2025:br1.56:efr1.22:svnLENOVO:pn20L6S6L601:pvrThinkPadT480:rvnLENOVO:rn20L6S6L601:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_20L6_BU_Think_FM_ThinkPadT480:pfaThinkPadT480: dmi.product.family: ThinkPad T480 dmi.product.name: 20L6S6L601 dmi.product.sku: LENOVO_MT_20L6_BU_Think_FM_ThinkPad T480 dmi.product.version: ThinkPad T480 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161309/+subscriptions
[Bug 2164961] Re: Lenovo Thinkpad x280 not waking from Suspend
Ok!! I figured it out. Thank you for your help! I will report back on #2161309 to let them know what device I'm running and what helped fix it. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2164961 Title: Lenovo Thinkpad x280 not waking from Suspend Status in linux package in Ubuntu: New Bug description: Hello! I am having issues with my Lenovo Thinkpad x280 being unable to turn my laptop on if I set it to suspend. I’m new to Linux and I am not sure what to try. I have, however, tried other versions and DE’s of Ubuntu. So far, I have used Ubuntu Desktop 26.04 LTS, Ubtuntu Cinnamon 26.04 LTS (Resolute Racoon), and Ubuntu Cinnamon 24.04.4 LTS (Noble Numbat). The problem persists across all three of these versions. Currently, I am using Ubuntu Cinnamon, 24.04 LTS. Posting here was a suggestion by the Ubuntu Discourse after I had some errors trying to follow their steps. See: https://discourse.ubuntu.com/t/lenovo-thinkpad-x280-not-waking-up-from-suspend/86614/5 --- ProblemType: Bug ApportVersion: 2.28.3-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: violet 1144 F.... wireplumber /dev/snd/seq: violet 1142 F.... pipewire CRDA: N/A CasperMD5CheckResult: pass CurrentDesktop: X-Cinnamon DistroRelease: Ubuntu 24.04 InstallationDate: Installed on 2026-08-17 (7 days ago) InstallationMedia: Ubuntu-Cinnamon 24.04.4 LTS "Noble Numbat" - Release amd64 (20260210) MachineType: LENOVO 20KES08P00 Package: linux (not installed) ProcEnviron: LANG=en_US.UTF-8 LANGUAGE=en_US PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-30-generic root=UUID=3d7c222c-ee65-4195-8959-7da19de05418 ro quiet splash loglevel=8 vt.handoff=7 ProcVersionSignature: Ubuntu 7.0.0-30.30~24.04.1-generic 7.0.12 RelatedPackageVersions: linux-restricted-modules-7.0.0-30-generic N/A linux-backports-modules-7.0.0-30-generic N/A linux-firmware 20240318.git3b128b60-0ubuntu2.29 Tags: noble Uname: Linux 7.0.0-30-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: N/A _MarkForUpload: True dmi.bios.date: 08/26/2025 dmi.bios.release: 1.59 dmi.bios.vendor: LENOVO dmi.bios.version: N20ET74W (1.59 ) dmi.board.asset.tag: Not Available dmi.board.name: 20KES08P00 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.ec.firmware.release: 1.9 dmi.modalias: dmi:bvnLENOVO:bvrN20ET74W(1.59):bd08/26/2025:br1.59:efr1.9:svnLENOVO:pn20KES08P00:pvrThinkPadX280:rvnLENOVO:rn20KES08P00:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_20KE_BU_Think_FM_ThinkPadX280:pfaThinkPadX280: dmi.product.family: ThinkPad X280 dmi.product.name: 20KES08P00 dmi.product.sku: LENOVO_MT_20KE_BU_Think_FM_ThinkPad X280 dmi.product.version: ThinkPad X280 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2164961/+subscriptions
[Bug 2164890] Re: MediaTek MT7902 Wi-Fi [14c3:7902] not supported by Ubuntu 26.04 kernel 7.0
** 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/2164890 Title: MediaTek MT7902 Wi-Fi [14c3:7902] not supported by Ubuntu 26.04 kernel 7.0 Status in linux package in Ubuntu: New Bug description: I am using Ubuntu 26.04 with the official Ubuntu kernel 7.0.0-30-generic. My laptop has a MediaTek MT7902 802.11ax PCIe Wireless Network Adapter. Hardware: MediaTek MT7902 [Filogic 310] PCI ID: 14c3:7902 Subsystem: AzureWave 1a3b:5520 The PCI device is detected by Ubuntu, but no kernel driver is bound to the device. Output of: lspci -nnk -s 02:00.0 02:00.0 Network controller [0280]: MEDIATEK Corp. MT7902 802.11ax PCIe Wireless Network Adapter [Filogic 310] [14c3:7902] Subsystem: AzureWave Device [1a3b:5520] There is no "Kernel driver in use" line. The installed linux-firmware package is: 20260319.git217ca6e4.1ubuntu Secure Boot is enabled. I have not installed a third-party MT7902 driver. Expected result: Ubuntu should provide kernel support for the MT7902 Wi-Fi adapter so that the wireless adapter works normally. Actual result: Ubuntu detects the PCI device but does not load/bind a driver, so the Wi-Fi adapter is unavailable. I would like this hardware to be supported through the official Ubuntu kernel rather than an unofficial third-party driver. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-30-generic 7.0.0-30.30 ProcVersionSignature: Ubuntu 7.0.0-30.30-generic 7.0.12 Uname: Linux 7.0.0-30-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon Aug 24 16:56:35 2026 InstallationDate: Installed on 2026-08-22 (2 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: ASUSTeK COMPUTER INC. Vivobook Go E1504FA_E1504FA ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-30-generic root=UUID=d8cbc480-789a-4fa3-8e87-09ac426a9b5a ro quiet splash 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: 01/16/2026 dmi.bios.release: 5.27 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: E1504FA.318 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: E1504FA 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.:bvrE1504FA.318:bd01/16/2026:br5.27:svnASUSTeKCOMPUTERINC.:pnVivobookGoE1504FA_E1504FA:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnE1504FA:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:sku:pfaVivobook: dmi.product.family: Vivobook dmi.product.name: Vivobook Go E1504FA_E1504FA 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/2164890/+subscriptions