This bug is awaiting verification that the linux- gcp-7.0/7.0.0-1011.11~24.04.1 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-noble-linux- gcp-7.0' to 'verification-done-noble-linux-gcp-7.0'. If the problem still exists, change the tag 'verification-needed-noble-linux-gcp-7.0' to 'verification-failed-noble-linux-gcp-7.0'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-noble-linux-gcp-7.0-v2 verification-needed-noble-linux-gcp-7.0 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2154748 Title: [Ubuntu 26.04] Severe Performance Degradation on kernel 7.0.0-15 Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Resolute: Fix Released Bug description: [ Impact ] s390 selects GENERIC_LOCKBREAK if PREEMPT is enabled. Reason is a historic 18 years old commit [1] which fixed a compile error for PREEMPT enabled kernels. Back than only PREEMPT_NONE and PREEMPT_VOLUNTARY kernels were considered to be important for s390. PREEMPT should "just work". However, since recently PREEMPT is always enabled [2], which also causes GENERIC_LOCKBREAK to be always enabled. For some workloads this leads to massive performance degradation; e.g. a simple kernel compile on machines with many CPUs may take up to four times longer. To fix this just remove the GENERIC_LOCKBREAK from s390's Kconfig, since the compile error from 18 years ago does not exist anymore. [1] commit b6b40c532a36 ("[S390] Define GENERIC_LOCKBREAK.") [2] commit 7dadeaa6e851 ("sched: Further restrict the preemption modes") [ Fix ] Backport commit: 1f57f68c4dd1 ("s390: Remove GENERIC_LOCKBREAK Kconfig option") [ Test Plan ] Compile and boot tested. Tested performance by compiling a kernel and monitoring execution with perf. [ Regression Potential ] The regression potential of the patch is low. It affects only s390x spinlock implementation. --- == Comment: #2 - Mete Durlu <Mete.Durlu@ibm.com> - 2026-06-01 08:59:07 == ---Problem Description--- Ubuntu 26.04 shows massive performance degradation. On large machines with more than 20 COREs (40 CPUs with SMT) CPU bound workloads suffer greatly. Ex: linux kernel compilation takes >10x more time Resource utilization shows up to 100% system time during the workload. perf top output indicates excessive lock contention in the kernel. $ make -j$(nproc) $ perf top 52.41% [kernel] [k] arch_spin_trylock_retry 8.76% [kernel] [k] _raw_spin_lock_irqsave 2.03% [kernel] [k] arch_spin_relax 1.09% cc1 [.] ht_lookup_with_hash(ht*, unsigned char 0.97% [kernel] [k] diag49c 0.95% [kernel] [k] lru_gen_add_folio 0.80% [kernel] [k] post_alloc_hook.localalias 0.77% [kernel] [k] lru_gen_del_folio.constprop.0 0.63% cc1 [.] htab_find_slot_with_hash 0.60% [kernel] [k] folios_put_refs 0.49% [kernel] [k] arch_vcpu_is_preempted 0.48% cc1 [.] ggc_internal_alloc_no_dtor(unsigned lo 0.44% cc1 [.] _cpp_lex_direct ... The lock contention seems to be linked directly to the thread count on the workload; # on a system with 34 COREs (68 CPUs w SMT) $ make -j20 perf top shows no arch_spin_trylock_retry $ make -j25 perf top shows ~2% arch_spin_trylock_retry $ make -j30 perf top shows ~5% arch_spin_trylock_retry $ make -j34 # thread count = core count perf top shows ~15% arch_spin_trylock_retry $ make -j40 # thread count > core count perf top shows >30% arch_spin_trylock_retry There has also been hints of delays on workqueue execution in dmesg output: ... [10600.136975] workqueue: vmstat_update hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND [10806.428576] workqueue: delayed_vfree_work hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND [10819.822422] workqueue: delayed_vfree_work hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND [10885.381900] workqueue: delayed_vfree_work hogged CPU for >10000us 7 times, consider switching to WQ_UNBOUND [10915.209117] workqueue: pcpu_balance_workfn hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND [11059.719121] workqueue: pcpu_balance_workfn hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND [20223.529295] workqueue: inode_switch_wbs_work_fn hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND [22584.374168] workqueue: mmput_async_fn hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND [22602.115559] workqueue: delayed_vfree_work hogged CPU for >10000us 11 times, consider switching to WQ_UNBOUND [22817.328172] workqueue: vmstat_update hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND [22840.202092] workqueue: delayed_vfree_work hogged CPU for >10000us 19 times, consider switching to WQ_UNBOUND [26834.512017] workqueue: delayed_vfree_work hogged CPU for >10000us 35 times, consider switching to WQ_UNBOUND [26883.480296] workqueue: vmstat_update hogged CPU for >10000us 7 times, consider switching to WQ_UNBOUND ... Systems with less COREs don't seem to be effected. The limit seems to be around 15 COREs (30 CPUs) ---uname output--- Linux localhost 7.0.0-15-generic #15-Ubuntu SMP PREEMPT Wed Apr 22 15:04:00 UTC 2026 s390x GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2154748/+subscriptions
пятница
[Bug 2156556] Re: Fix no audio from right built-in speaker on HP ZBook with TAS2781 amplifier
This bug is awaiting verification that the linux- gcp-7.0/7.0.0-1011.11~24.04.1 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-noble-linux- gcp-7.0' to 'verification-done-noble-linux-gcp-7.0'. If the problem still exists, change the tag 'verification-needed-noble-linux-gcp-7.0' to 'verification-failed-noble-linux-gcp-7.0'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-noble-linux-gcp-7.0-v2 verification-needed-noble-linux-gcp-7.0 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2156556 Title: Fix no audio from right built-in speaker on HP ZBook with TAS2781 amplifier 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: Fix Released Status in linux source package in Resolute: Fix Released Status in linux-oem-6.17 source package in Resolute: New Bug description: [Impact] The TI TAS2781 smart amp fails to initialize when connected over SPI on the new HP HP ZBook. The right built-in speaker will fail to output after reboot [Fix] Two changes in one commit: 1. Always run the software reset sequence for the amp, not just in the no-gpio path. This resets device-0 even when its hardware reset pin has no effect. 2. Ignore -EXDEV during block processing when the device is on SPI. The driver keeps iterating through the blocks and adds up the total block size correctly. Upstream commit (in tiwai/sound for-next, not yet in a released tag): 513480da5e9c ALSA: hda/tas2781: Fix device-0 reset issue and handle -EXDEV in block data processing https://patch.msgid.link/20260609105253.19510-1-baojun.xu@ti.com [Test Plan] On HP Zbook with a TAS2781 amp connected over SPI: $ dmesg | grep -i tas2781 Play audio: $ speaker-test -c 2 -t wav Without patch: dmesg shows "dev sw-reset fail" or "process_block: single write error" / "bulk_write error". No sound from the TAS2781 speakers. With patch: no reset or block errors in dmesg. Speakers play sound. [Where problems could occur] The reset change now runs the software reset on every path, including the gpio reset path. If the software reset is wrong for some amp, the device could fail to come up and stay silent. Both changes are amp init only, so a regression would show up as no sound on TAS2781 SPI systems. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2156556/+subscriptions
[Bug 2161757] Re: Resolute real-time patchset: 7.0.1-rt2
** Changed in: ubuntu-realtime Status: In Progress => Fix Committed ** Changed in: linux (Ubuntu) Status: In Progress => Fix Committed ** Changed in: linux (Ubuntu Resolute) Status: In Progress => Fix Committed ** Changed in: linux-realtime (Ubuntu) Status: In Progress => Fix Committed ** Changed in: linux-realtime (Ubuntu Resolute) Status: In Progress => Fix Committed ** Tags removed: verification-needed-resolute-linux ** Tags added: verification-done-resolute-linux -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161757 Title: Resolute real-time patchset: 7.0.1-rt2 Status in ubuntu-realtime: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in linux-realtime package in Ubuntu: Fix Committed Status in linux source package in Resolute: Fix Committed Status in linux-realtime source package in Resolute: Fix Committed Bug description: [Impact] Starting in resolute, the patches from the PREEMPT_RT patchset are applied to generic so they can be inherited by derivative kernels and flavors that need real-time. PREEMPT_RT 7.0-rc1-rt1 patchset was previously applied ( https://bugs.launchpad.net/ubuntu- realtime/+bug/2143181 ). The patches have been updated with patchset 7.0.1-rt2. This set of patches will be filtered to only ones that apply where we support real-time, including amd64 and arm64. Of those, only two have changed. They were previously dropped due to conflicts, so this effort will reapply the new versions of the patches. [Fix] For kernel 7.0, the upstream PREEMPT_RT patchset 7.0.1-rt2 has been released. https://cdn.kernel.org/pub/linux/kernel/projects/rt/7.0/ The following patches were previously applied and have not changed: UBUNTU: SAUCE: sysfs: Add /sys/kernel/realtime entry UBUNTU: SAUCE: Revert "drm/i915: Depend on !PREEMPT_RT." UBUNTU: SAUCE: drm/i915: Consider RCU read section as atomic. UBUNTU: SAUCE: drm/i915/guc: Consider also RCU depth in busy loop. UBUNTU: SAUCE: drm/i915: Drop the irqs_disabled() check UBUNTU: SAUCE: drm/i915/gt: Use spin_lock_irq() instead of local_irq_disable() + spin_lock() UBUNTU: SAUCE: drm/i915: Disable tracing points on PREEMPT_RT UBUNTU: SAUCE: drm/i915: Don't disable interrupts on PREEMPT_RT during atomic updates UBUNTU: SAUCE: drm/i915: Use preempt_disable/enable_rt() where recommended These patches have been updated and will be applied as part of this patchset: UBUNTU: SAUCE: Reapply "serial: 8250: Revert "drop lockdep annotation from serial8250_clear_IER()"" UBUNTU: SAUCE: Reapply "serial: 8250: Switch to nbcon console" [Test Case] Compile and boot test [Where things could go wrong] These patches primarily apply to the 8250 serial driver, so they may cause minor performance differences in these drivers even when PREEMPT_RT is disabled. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-realtime/+bug/2161757/+subscriptions
[Bug 2164516] Re: [UBUNTU 22.04] s390/topology: Use zero-based numbering
Thanks for reporting. Patch sent to KTML: https://lists.ubuntu.com/archives/kernel-team/2026-August/171074.html ** Changed in: linux (Ubuntu Jammy) Status: New => In Progress ** Changed in: linux (Ubuntu Noble) Status: New => In Progress ** Changed in: linux (Ubuntu Resolute) Status: New => In Progress ** Changed in: ubuntu-z-systems Status: Triaged => In Progress -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2164516 Title: [UBUNTU 22.04] s390/topology: Use zero-based numbering Status in Linux: Triaged Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: In Progress Status in linux source package in Noble: In Progress Status in linux source package in Resolute: In Progress Bug description: [Impact] s390/topology: Use zero-based numbering for containing entities Start the numbering scheme for higher-level topology structures (like socket, book, drawer) at zero, matching the convention for other hardware identifiers like e.g. CPU numbers. Hardware documentation, the Hardware Management Console and other tools like zmemtopo also use zero-based numbering for these containing entities. Aligning the numbering in sysfs, procfs, and tools like lscpu improves user experience by making it easier to correlate topology information across different interfaces. If available, Linux on s390 derives this physical topology information from the stsi function code 15 store_topology instruction, which is defined to start at 1 for the lowest numbered container id. Subtract one, so drawer_id, book_id and socket_id in cpu_topology[] start with 0 for the lowest numbered entity; and /proc/cpuinfo and tools like 'lscpu -ye' display the expected values. Display only, no functional change intended. [Fix] Cherry pick commit: - 540f4a4f6ef8 ("s390/topology: Use zero-based numbering for containing entities") [Test Plan] Run 'lscpu -ye' to make sure that zero-based numbering is used for socket, book, drawer, etc. [Regression Potential] No functional change intended. Regression potential is very low. --- Description: s390/topology: Use zero-based numbering Symptom: Ids displayed by 'lscpu -ye' don't match HW Ids Problem: Hardware documentation, the Hardware Management Console and other tools like zmemtopo use zero-based numbering for socket, book, drawer. But the linux kernel displays one-based numbering in sysfs, procfs and lscpu. Reproduction: 'lscpu -ye' Affected Distros: Ubuntu 22.04, 24.04, 26.04 Solution: Correct the indices the kernel gets from HW sysinfo. Upstream-ID: 540f4a4f6ef806a28e794001bb4beac4840a6090 To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/2164516/+subscriptions
[Bug 2164785] Re: mt7921e: drv_own timeout → chip reset failed → kernel page fault (hard lock); regression since 22.04→24.04, still on 26.04/7.0.0-29
** Description changed: # Bug report: mt7921e oops after chip reset failed - Collected and prepared in **Cursor** by **Cursor Grok 4.6 (extra high)**. - جمعآوری و آمادهسازی این گزارش در Cursor توسط مدل Cursor Grok 4.6 (extra high) انجام شده است. + **Filed:** https://bugs.launchpad.net/bugs/2164785 (Ubuntu `linux`) + + Collected and prepared in Cursor by Cursor Grok 4.6 (extra high). File against Ubuntu package **linux**. Also relevant: LP#2154385 (s2idle only), Discourse [mt7921 disappears on 26.04 / 7.0.0-27](https://discourse.ubuntu.com/t/mediatek-mt7921-wi-fi- intermittently-disappears-on-ubuntu-26-04-works-on-kernel-7-0-0-22-but- not-reliably-on-7-0-0-27/85118), kernel bz [#220353](https://bugzilla.kernel.org/show_bug.cgi?id=220353). --- ## Title mt7921e: drv_own timeout → chip reset failed → kernel page fault (hard lock); regression since 22.04→24.04, still on 26.04/7.0.0-29 ## Summary Internal MediaTek **MT7921** (`mt7921e`, PCI `14c3:7961`) hard-locks the machine. Sequence: 1. `driver own failed` / `Timeout for driver own` (MCU ownership handshake) 2. `chip reset failed` 3. `BUG: unable to handle page fault` — supervisor write, not-present page (`error_code 0x0002`) A firmware timeout must not panic the box. The oops is on the **reset- failure path**. **Regression timeline (this host):** - Ubuntu **22.04**: same NIC, years without this lockup - After upgrade to **24.04** (still **not** kernel 7.x): the hang appeared - Ubuntu **26.04** kernel **7.0.0-29-generic**: same hang, now captured as a kernel #PF So this is not a 7.0-only regression. 24.04 already used 6.8 HWE `mt7921e`. ## Hardware - ASUS TUF Gaming F17 `FX706HE_FX706HE`, BIOS `FX706HE.316` (2025-06-17; latest ASUS 316) - Tiger Lake-H + i915 + NVIDIA GA107M (RTX 3050 Ti Mobile) - Wi-Fi: `0000:2e:00.0` **14c3:7961** Filogic 330, subsystem AzureWave **1a3b:4680** - Parent: `0000:00:1c.0` Intel `8086:43bf` - Combo BT USB: IMC **13d3:3563** `Wireless_Device` (`btusb`) ## Software ``` Ubuntu 26.04 LTS (resolute), upgraded path 22.04 → 24.04 → 26.04 Linux 7.0.0-29-generic #29-Ubuntu SMP PREEMPT_DYNAMIC Fri Jul 17 20:52:35 UTC 2026 x86_64 linux-firmware 20260319.git217ca6e4.1ubuntu ``` Firmware loaded: ``` ASIC revision: 79610010 HW/SW Version: 0x8a108a10, Build Time: 20260224110909a WM Firmware Version: ____010000, Build Time: 20260224110949 ``` On-disk: ``` WIFI_MT7961_patch_mcu_1_2_hdr.bin.zst sha256 1cad8c509ded3d60567ec8b8665db85a0982591341f46175d1fc94a82b988b58 WIFI_RAM_CODE_MT7961_1.bin.zst sha256 b99a525d7921bf430fe4648ccadb9ce8fd282118cf11a834651016ee4256371d ``` ACPI FADT: ASPM unsupported; `mt7921e: disabling ASPM L1` then `can't disable ASPM; OS doesn't have ASPM control`. Default suspend was s2idle; `mem_sleep_default=deep` was applied later. **Awake oopses still happened** on 7.0.0-29 (not only after resume). LP#2154385 is related but not sufficient. ## Reproduction On 7.0.0-29 with `mt7921e` bound: 1. Associate to an AP 2. Idle ~15s–2 min, or toggle Wi-Fi radio, or warm-reboot after a firmware wedge 3. `driver own failed` storm (~1 Hz, ~23s) → `chip reset failed` → #PF → hard lock (power button) Warm reboot after wedge: ``` pci 0000:00:1c.0: broken device, retraining non-functional downstream link at 2.5GT/s pci 0000:00:1c.0: retraining failed ``` Device missing from lspci until full **Shut Down** or PCI rescan. Rescan can restore the device and oops again within minutes. ## Kernel log (2026-08-21 16:09:24 +0330) Healthy probe ~16:09:25. Then: ``` mt7921e 0000:2e:00.0: driver own failed mt7921e 0000:2e:00.0: Timeout for driver own … repeats … mt7921e 0000:2e:00.0: chip reset failed BUG: unable to handle page fault for address: ffffd3a042d64ff0 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page ``` RIP/Call Trace often **not flushed**. Another oops the same day: fault address `ffffd37941ac9ff0`. ## Why not “just install a newer Ubuntu kernel” Official **resolute** archives (2026-08-22): newest **generic** is **7.0.0-30.30**. Changelog for linux-signed 7.0.0-30.30 is packaging resync only; **no mt76/mt7921 entries**. There is **no 7.1/7.2** in Ubuntu apt. Mainline 7.1/7.2 exist only as **unsigned** kernels on kernel.ubuntu.com (Secure Boot must be off). One Discourse user said 7.2-rc2 helped **MT7922**; that is not a verified fix for this MT7921 #PF, and it is not an Ubuntu-supported kernel. `disable_aspm=1`, `pcie_aspm=force`, unbind-on-error, and PCI rescan were tried; they do not stop the oops (unbind can D-state; rescan re- triggers). ## Request 1. Treat reset-failure #PF as a kernel bug: `chip reset failed` must not take down the machine. 2. Bisect 22.04-stable vs 24.04 6.8 HWE mt76/mt7921 (regression started at 24.04 on this laptop). 3. Consider SRU / note 7.0.0-27+ reports vs 7.0.0-22 on 26.04 (other users). ## Current workaround `modprobe.blacklist=mt7921e`, bind `14c3:7961` to `pci-stub`, USB `13d3:3563` unauthorized. USB Ethernet. Internal Wi-Fi not loaded on 7.0.0-29. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2164785 Title: mt7921e: drv_own timeout → chip reset failed → kernel page fault (hard lock); regression since 22.04→24.04, still on 26.04/7.0.0-29 Status in linux package in Ubuntu: New Bug description: # Bug report: mt7921e oops after chip reset failed **Filed:** https://bugs.launchpad.net/bugs/2164785 (Ubuntu `linux`) Collected and prepared in Cursor by Cursor Grok 4.6 (extra high). File against Ubuntu package **linux**. Also relevant: LP#2154385 (s2idle only), Discourse [mt7921 disappears on 26.04 / 7.0.0-27](https://discourse.ubuntu.com/t/mediatek-mt7921-wi-fi- intermittently-disappears-on-ubuntu-26-04-works-on- kernel-7-0-0-22-but-not-reliably-on-7-0-0-27/85118), kernel bz [#220353](https://bugzilla.kernel.org/show_bug.cgi?id=220353). --- ## Title mt7921e: drv_own timeout → chip reset failed → kernel page fault (hard lock); regression since 22.04→24.04, still on 26.04/7.0.0-29 ## Summary Internal MediaTek **MT7921** (`mt7921e`, PCI `14c3:7961`) hard-locks the machine. Sequence: 1. `driver own failed` / `Timeout for driver own` (MCU ownership handshake) 2. `chip reset failed` 3. `BUG: unable to handle page fault` — supervisor write, not-present page (`error_code 0x0002`) A firmware timeout must not panic the box. The oops is on the **reset- failure path**. **Regression timeline (this host):** - Ubuntu **22.04**: same NIC, years without this lockup - After upgrade to **24.04** (still **not** kernel 7.x): the hang appeared - Ubuntu **26.04** kernel **7.0.0-29-generic**: same hang, now captured as a kernel #PF So this is not a 7.0-only regression. 24.04 already used 6.8 HWE `mt7921e`. ## Hardware - ASUS TUF Gaming F17 `FX706HE_FX706HE`, BIOS `FX706HE.316` (2025-06-17; latest ASUS 316) - Tiger Lake-H + i915 + NVIDIA GA107M (RTX 3050 Ti Mobile) - Wi-Fi: `0000:2e:00.0` **14c3:7961** Filogic 330, subsystem AzureWave **1a3b:4680** - Parent: `0000:00:1c.0` Intel `8086:43bf` - Combo BT USB: IMC **13d3:3563** `Wireless_Device` (`btusb`) ## Software ``` Ubuntu 26.04 LTS (resolute), upgraded path 22.04 → 24.04 → 26.04 Linux 7.0.0-29-generic #29-Ubuntu SMP PREEMPT_DYNAMIC Fri Jul 17 20:52:35 UTC 2026 x86_64 linux-firmware 20260319.git217ca6e4.1ubuntu ``` Firmware loaded: ``` ASIC revision: 79610010 HW/SW Version: 0x8a108a10, Build Time: 20260224110909a WM Firmware Version: ____010000, Build Time: 20260224110949 ``` On-disk: ``` WIFI_MT7961_patch_mcu_1_2_hdr.bin.zst sha256 1cad8c509ded3d60567ec8b8665db85a0982591341f46175d1fc94a82b988b58 WIFI_RAM_CODE_MT7961_1.bin.zst sha256 b99a525d7921bf430fe4648ccadb9ce8fd282118cf11a834651016ee4256371d ``` ACPI FADT: ASPM unsupported; `mt7921e: disabling ASPM L1` then `can't disable ASPM; OS doesn't have ASPM control`. Default suspend was s2idle; `mem_sleep_default=deep` was applied later. **Awake oopses still happened** on 7.0.0-29 (not only after resume). LP#2154385 is related but not sufficient. ## Reproduction On 7.0.0-29 with `mt7921e` bound: 1. Associate to an AP 2. Idle ~15s–2 min, or toggle Wi-Fi radio, or warm-reboot after a firmware wedge 3. `driver own failed` storm (~1 Hz, ~23s) → `chip reset failed` → #PF → hard lock (power button) Warm reboot after wedge: ``` pci 0000:00:1c.0: broken device, retraining non-functional downstream link at 2.5GT/s pci 0000:00:1c.0: retraining failed ``` Device missing from lspci until full **Shut Down** or PCI rescan. Rescan can restore the device and oops again within minutes. ## Kernel log (2026-08-21 16:09:24 +0330) Healthy probe ~16:09:25. Then: ``` mt7921e 0000:2e:00.0: driver own failed mt7921e 0000:2e:00.0: Timeout for driver own … repeats … mt7921e 0000:2e:00.0: chip reset failed BUG: unable to handle page fault for address: ffffd3a042d64ff0 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page ``` RIP/Call Trace often **not flushed**. Another oops the same day: fault address `ffffd37941ac9ff0`. ## Why not “just install a newer Ubuntu kernel” Official **resolute** archives (2026-08-22): newest **generic** is **7.0.0-30.30**. Changelog for linux-signed 7.0.0-30.30 is packaging resync only; **no mt76/mt7921 entries**. There is **no 7.1/7.2** in Ubuntu apt. Mainline 7.1/7.2 exist only as **unsigned** kernels on kernel.ubuntu.com (Secure Boot must be off). One Discourse user said 7.2-rc2 helped **MT7922**; that is not a verified fix for this MT7921 #PF, and it is not an Ubuntu-supported kernel. `disable_aspm=1`, `pcie_aspm=force`, unbind-on-error, and PCI rescan were tried; they do not stop the oops (unbind can D-state; rescan re- triggers). ## Request 1. Treat reset-failure #PF as a kernel bug: `chip reset failed` must not take down the machine. 2. Bisect 22.04-stable vs 24.04 6.8 HWE mt76/mt7921 (regression started at 24.04 on this laptop). 3. Consider SRU / note 7.0.0-27+ reports vs 7.0.0-22 on 26.04 (other users). ## Current workaround `modprobe.blacklist=mt7921e`, bind `14c3:7961` to `pci-stub`, USB `13d3:3563` unauthorized. USB Ethernet. Internal Wi-Fi not loaded on 7.0.0-29. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2164785/+subscriptions
[Bug 2164785] [NEW] mt7921e: drv_own timeout → chip reset failed → kernel page fault (hard lock); regression since 22.04→24.04, still on 26.04/7.0.0-29
Public bug reported: # Bug report: mt7921e oops after chip reset failed Collected and prepared in **Cursor** by **Cursor Grok 4.6 (extra high)**. جمعآوری و آمادهسازی این گزارش در Cursor توسط مدل Cursor Grok 4.6 (extra high) انجام شده است. File against Ubuntu package **linux**. Also relevant: LP#2154385 (s2idle only), Discourse [mt7921 disappears on 26.04 / 7.0.0-27](https://discourse.ubuntu.com/t/mediatek-mt7921-wi-fi- intermittently-disappears-on-ubuntu-26-04-works-on-kernel-7-0-0-22-but- not-reliably-on-7-0-0-27/85118), kernel bz [#220353](https://bugzilla.kernel.org/show_bug.cgi?id=220353). --- ## Title mt7921e: drv_own timeout → chip reset failed → kernel page fault (hard lock); regression since 22.04→24.04, still on 26.04/7.0.0-29 ## Summary Internal MediaTek **MT7921** (`mt7921e`, PCI `14c3:7961`) hard-locks the machine. Sequence: 1. `driver own failed` / `Timeout for driver own` (MCU ownership handshake) 2. `chip reset failed` 3. `BUG: unable to handle page fault` — supervisor write, not-present page (`error_code 0x0002`) A firmware timeout must not panic the box. The oops is on the **reset- failure path**. **Regression timeline (this host):** - Ubuntu **22.04**: same NIC, years without this lockup - After upgrade to **24.04** (still **not** kernel 7.x): the hang appeared - Ubuntu **26.04** kernel **7.0.0-29-generic**: same hang, now captured as a kernel #PF So this is not a 7.0-only regression. 24.04 already used 6.8 HWE `mt7921e`. ## Hardware - ASUS TUF Gaming F17 `FX706HE_FX706HE`, BIOS `FX706HE.316` (2025-06-17; latest ASUS 316) - Tiger Lake-H + i915 + NVIDIA GA107M (RTX 3050 Ti Mobile) - Wi-Fi: `0000:2e:00.0` **14c3:7961** Filogic 330, subsystem AzureWave **1a3b:4680** - Parent: `0000:00:1c.0` Intel `8086:43bf` - Combo BT USB: IMC **13d3:3563** `Wireless_Device` (`btusb`) ## Software ``` Ubuntu 26.04 LTS (resolute), upgraded path 22.04 → 24.04 → 26.04 Linux 7.0.0-29-generic #29-Ubuntu SMP PREEMPT_DYNAMIC Fri Jul 17 20:52:35 UTC 2026 x86_64 linux-firmware 20260319.git217ca6e4.1ubuntu ``` Firmware loaded: ``` ASIC revision: 79610010 HW/SW Version: 0x8a108a10, Build Time: 20260224110909a WM Firmware Version: ____010000, Build Time: 20260224110949 ``` On-disk: ``` WIFI_MT7961_patch_mcu_1_2_hdr.bin.zst sha256 1cad8c509ded3d60567ec8b8665db85a0982591341f46175d1fc94a82b988b58 WIFI_RAM_CODE_MT7961_1.bin.zst sha256 b99a525d7921bf430fe4648ccadb9ce8fd282118cf11a834651016ee4256371d ``` ACPI FADT: ASPM unsupported; `mt7921e: disabling ASPM L1` then `can't disable ASPM; OS doesn't have ASPM control`. Default suspend was s2idle; `mem_sleep_default=deep` was applied later. **Awake oopses still happened** on 7.0.0-29 (not only after resume). LP#2154385 is related but not sufficient. ## Reproduction On 7.0.0-29 with `mt7921e` bound: 1. Associate to an AP 2. Idle ~15s–2 min, or toggle Wi-Fi radio, or warm-reboot after a firmware wedge 3. `driver own failed` storm (~1 Hz, ~23s) → `chip reset failed` → #PF → hard lock (power button) Warm reboot after wedge: ``` pci 0000:00:1c.0: broken device, retraining non-functional downstream link at 2.5GT/s pci 0000:00:1c.0: retraining failed ``` Device missing from lspci until full **Shut Down** or PCI rescan. Rescan can restore the device and oops again within minutes. ## Kernel log (2026-08-21 16:09:24 +0330) Healthy probe ~16:09:25. Then: ``` mt7921e 0000:2e:00.0: driver own failed mt7921e 0000:2e:00.0: Timeout for driver own … repeats … mt7921e 0000:2e:00.0: chip reset failed BUG: unable to handle page fault for address: ffffd3a042d64ff0 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page ``` RIP/Call Trace often **not flushed**. Another oops the same day: fault address `ffffd37941ac9ff0`. ## Why not “just install a newer Ubuntu kernel” Official **resolute** archives (2026-08-22): newest **generic** is **7.0.0-30.30**. Changelog for linux-signed 7.0.0-30.30 is packaging resync only; **no mt76/mt7921 entries**. There is **no 7.1/7.2** in Ubuntu apt. Mainline 7.1/7.2 exist only as **unsigned** kernels on kernel.ubuntu.com (Secure Boot must be off). One Discourse user said 7.2-rc2 helped **MT7922**; that is not a verified fix for this MT7921 #PF, and it is not an Ubuntu-supported kernel. `disable_aspm=1`, `pcie_aspm=force`, unbind-on-error, and PCI rescan were tried; they do not stop the oops (unbind can D-state; rescan re- triggers). ## Request 1. Treat reset-failure #PF as a kernel bug: `chip reset failed` must not take down the machine. 2. Bisect 22.04-stable vs 24.04 6.8 HWE mt76/mt7921 (regression started at 24.04 on this laptop). 3. Consider SRU / note 7.0.0-27+ reports vs 7.0.0-22 on 26.04 (other users). ## Current workaround `modprobe.blacklist=mt7921e`, bind `14c3:7961` to `pci-stub`, USB `13d3:3563` unauthorized. USB Ethernet. Internal Wi-Fi not loaded on 7.0.0-29. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: kernel-bug regression ** Tags added: kernel-bug regression -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2164785 Title: mt7921e: drv_own timeout → chip reset failed → kernel page fault (hard lock); regression since 22.04→24.04, still on 26.04/7.0.0-29 Status in linux package in Ubuntu: New Bug description: # Bug report: mt7921e oops after chip reset failed Collected and prepared in **Cursor** by **Cursor Grok 4.6 (extra high)**. جمعآوری و آمادهسازی این گزارش در Cursor توسط مدل Cursor Grok 4.6 (extra high) انجام شده است. File against Ubuntu package **linux**. Also relevant: LP#2154385 (s2idle only), Discourse [mt7921 disappears on 26.04 / 7.0.0-27](https://discourse.ubuntu.com/t/mediatek-mt7921-wi-fi- intermittently-disappears-on-ubuntu-26-04-works-on- kernel-7-0-0-22-but-not-reliably-on-7-0-0-27/85118), kernel bz [#220353](https://bugzilla.kernel.org/show_bug.cgi?id=220353). --- ## Title mt7921e: drv_own timeout → chip reset failed → kernel page fault (hard lock); regression since 22.04→24.04, still on 26.04/7.0.0-29 ## Summary Internal MediaTek **MT7921** (`mt7921e`, PCI `14c3:7961`) hard-locks the machine. Sequence: 1. `driver own failed` / `Timeout for driver own` (MCU ownership handshake) 2. `chip reset failed` 3. `BUG: unable to handle page fault` — supervisor write, not-present page (`error_code 0x0002`) A firmware timeout must not panic the box. The oops is on the **reset- failure path**. **Regression timeline (this host):** - Ubuntu **22.04**: same NIC, years without this lockup - After upgrade to **24.04** (still **not** kernel 7.x): the hang appeared - Ubuntu **26.04** kernel **7.0.0-29-generic**: same hang, now captured as a kernel #PF So this is not a 7.0-only regression. 24.04 already used 6.8 HWE `mt7921e`. ## Hardware - ASUS TUF Gaming F17 `FX706HE_FX706HE`, BIOS `FX706HE.316` (2025-06-17; latest ASUS 316) - Tiger Lake-H + i915 + NVIDIA GA107M (RTX 3050 Ti Mobile) - Wi-Fi: `0000:2e:00.0` **14c3:7961** Filogic 330, subsystem AzureWave **1a3b:4680** - Parent: `0000:00:1c.0` Intel `8086:43bf` - Combo BT USB: IMC **13d3:3563** `Wireless_Device` (`btusb`) ## Software ``` Ubuntu 26.04 LTS (resolute), upgraded path 22.04 → 24.04 → 26.04 Linux 7.0.0-29-generic #29-Ubuntu SMP PREEMPT_DYNAMIC Fri Jul 17 20:52:35 UTC 2026 x86_64 linux-firmware 20260319.git217ca6e4.1ubuntu ``` Firmware loaded: ``` ASIC revision: 79610010 HW/SW Version: 0x8a108a10, Build Time: 20260224110909a WM Firmware Version: ____010000, Build Time: 20260224110949 ``` On-disk: ``` WIFI_MT7961_patch_mcu_1_2_hdr.bin.zst sha256 1cad8c509ded3d60567ec8b8665db85a0982591341f46175d1fc94a82b988b58 WIFI_RAM_CODE_MT7961_1.bin.zst sha256 b99a525d7921bf430fe4648ccadb9ce8fd282118cf11a834651016ee4256371d ``` ACPI FADT: ASPM unsupported; `mt7921e: disabling ASPM L1` then `can't disable ASPM; OS doesn't have ASPM control`. Default suspend was s2idle; `mem_sleep_default=deep` was applied later. **Awake oopses still happened** on 7.0.0-29 (not only after resume). LP#2154385 is related but not sufficient. ## Reproduction On 7.0.0-29 with `mt7921e` bound: 1. Associate to an AP 2. Idle ~15s–2 min, or toggle Wi-Fi radio, or warm-reboot after a firmware wedge 3. `driver own failed` storm (~1 Hz, ~23s) → `chip reset failed` → #PF → hard lock (power button) Warm reboot after wedge: ``` pci 0000:00:1c.0: broken device, retraining non-functional downstream link at 2.5GT/s pci 0000:00:1c.0: retraining failed ``` Device missing from lspci until full **Shut Down** or PCI rescan. Rescan can restore the device and oops again within minutes. ## Kernel log (2026-08-21 16:09:24 +0330) Healthy probe ~16:09:25. Then: ``` mt7921e 0000:2e:00.0: driver own failed mt7921e 0000:2e:00.0: Timeout for driver own … repeats … mt7921e 0000:2e:00.0: chip reset failed BUG: unable to handle page fault for address: ffffd3a042d64ff0 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page ``` RIP/Call Trace often **not flushed**. Another oops the same day: fault address `ffffd37941ac9ff0`. ## Why not “just install a newer Ubuntu kernel” Official **resolute** archives (2026-08-22): newest **generic** is **7.0.0-30.30**. Changelog for linux-signed 7.0.0-30.30 is packaging resync only; **no mt76/mt7921 entries**. There is **no 7.1/7.2** in Ubuntu apt. Mainline 7.1/7.2 exist only as **unsigned** kernels on kernel.ubuntu.com (Secure Boot must be off). One Discourse user said 7.2-rc2 helped **MT7922**; that is not a verified fix for this MT7921 #PF, and it is not an Ubuntu-supported kernel. `disable_aspm=1`, `pcie_aspm=force`, unbind-on-error, and PCI rescan were tried; they do not stop the oops (unbind can D-state; rescan re- triggers). ## Request 1. Treat reset-failure #PF as a kernel bug: `chip reset failed` must not take down the machine. 2. Bisect 22.04-stable vs 24.04 6.8 HWE mt76/mt7921 (regression started at 24.04 on this laptop). 3. Consider SRU / note 7.0.0-27+ reports vs 7.0.0-22 on 26.04 (other users). ## Current workaround `modprobe.blacklist=mt7921e`, bind `14c3:7961` to `pci-stub`, USB `13d3:3563` unauthorized. USB Ethernet. Internal Wi-Fi not loaded on 7.0.0-29. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2164785/+subscriptions
Re: [Bug 2161309] Re: Backlight regression
Issue is not fixed in 7.0 for my device. Going back to 6.17.0-35-generic verification-failed-resolute-linux-nvidia-bos On Wed, Aug 19, 2026 at 12:30 PM Prince Benedict Wachira < 2161309@bugs.launchpad.net> wrote: > Ohh I wanted to inform the necessary parties that I was able to fix my > earlier started issue. Thanks for the feedback > > On Wed, 19 Aug 2026 at 19:01, Krystian Kaniewski < > 2161309@bugs.launchpad.net> > wrote: > > > ** Also affects: linux (Ubuntu Resolute) > > Importance: Undecided > > Status: New > > > > ** Also affects: linux-hwe-7.0 (Ubuntu Resolute) > > Importance: Undecided > > Status: New > > > > ** Also affects: linux (Ubuntu Noble) > > Importance: Undecided > > Status: New > > > > ** Also affects: linux-hwe-7.0 (Ubuntu Noble) > > Importance: Undecided > > Status: New > > > > ** Changed in: linux (Ubuntu Resolute) > > Status: New => Fix Committed > > > > ** Changed in: linux (Ubuntu Resolute) > > Assignee: (unassigned) => Krystian Kaniewski (kkaniewski) > > > > ** Changed in: linux-hwe-7.0 (Ubuntu Noble) > > Status: New => Fix Committed > > > > ** Changed in: linux-hwe-7.0 (Ubuntu Noble) > > Importance: Undecided => Critical > > > > ** Changed in: linux-hwe-7.0 (Ubuntu Noble) > > Assignee: (unassigned) => Krystian Kaniewski (kkaniewski) > > > > ** Changed in: linux (Ubuntu Noble) > > Status: New => Invalid > > > > ** Changed in: linux-hwe-7.0 (Ubuntu Resolute) > > Status: New => Invalid > > > > ** Changed in: linux (Ubuntu Noble) > > Assignee: (unassigned) => Krystian Kaniewski (kkaniewski) > > > > ** Changed in: linux-hwe-7.0 (Ubuntu Resolute) > > Assignee: (unassigned) => Krystian Kaniewski (kkaniewski) > > > > ** Changed in: linux (Ubuntu Resolute) > > Importance: Undecided => Critical > > > > ** Changed in: linux (Ubuntu Resolute) > > Importance: Critical => High > > > > ** Changed in: linux-hwe-7.0 (Ubuntu Noble) > > Importance: Critical => High > > > > -- > > You received this bug notification because you are subscribed to a > > duplicate bug report (2163479). > > 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 > > > > > > -- > You received this bug notification because you are subscribed to a > duplicate bug report (2162922). > 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 > > -- -Steven H. Kelty -- 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 2164516] Re: [UBUNTU 22.04] s390/topology: Use zero-based numbering
** Description changed: - Description: + [Impact] + + s390/topology: Use zero-based numbering for containing entities + + Start the numbering scheme for higher-level topology structures (like + socket, book, drawer) at zero, matching the convention for other hardware + identifiers like e.g. CPU numbers. + + Hardware documentation, the Hardware Management Console and other tools + like zmemtopo also use zero-based numbering for these containing entities. + Aligning the numbering in sysfs, procfs, and tools like lscpu improves + user experience by making it easier to correlate topology information + across different interfaces. + + If available, Linux on s390 derives this physical topology information from + the stsi function code 15 store_topology instruction, which is defined to + start at 1 for the lowest numbered container id. Subtract one, so + drawer_id, book_id and socket_id in cpu_topology[] start with 0 for the + lowest numbered entity; and /proc/cpuinfo and tools like 'lscpu -ye' + display the expected values. + + Display only, no functional change intended. + + [Fix] + + Cherry pick commit: + - 540f4a4f6ef8 ("s390/topology: Use zero-based numbering for containing entities") + + [Test Plan] + + Run 'lscpu -ye' to make sure that zero-based numbering is used for + socket, book, drawer, etc. + + [Regression Potential] + + No functional change intended. + Regression potential is very low. + + + --- + + Description: s390/topology: Use zero-based numbering - Symptom: + Symptom: Ids displayed by 'lscpu -ye' don't match HW Ids - Problem: + Problem: Hardware documentation, the Hardware Management Console and other tools like zmemtopo use zero-based numbering for socket, book, drawer. But the linux kernel displays one-based numbering in sysfs, procfs and lscpu. - Reproduction: + Reproduction: 'lscpu -ye' - Affected Distros: + Affected Distros: Ubuntu 22.04, 24.04, 26.04 - Solution: + Solution: Correct the indices the kernel gets from HW sysinfo. - Upstream-ID: + Upstream-ID: 540f4a4f6ef806a28e794001bb4beac4840a6090 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2164516 Title: [UBUNTU 22.04] s390/topology: Use zero-based numbering Status in Linux: Triaged Status in Ubuntu on IBM z Systems: Triaged Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: New Status in linux source package in Noble: New Status in linux source package in Resolute: New Bug description: [Impact] s390/topology: Use zero-based numbering for containing entities Start the numbering scheme for higher-level topology structures (like socket, book, drawer) at zero, matching the convention for other hardware identifiers like e.g. CPU numbers. Hardware documentation, the Hardware Management Console and other tools like zmemtopo also use zero-based numbering for these containing entities. Aligning the numbering in sysfs, procfs, and tools like lscpu improves user experience by making it easier to correlate topology information across different interfaces. If available, Linux on s390 derives this physical topology information from the stsi function code 15 store_topology instruction, which is defined to start at 1 for the lowest numbered container id. Subtract one, so drawer_id, book_id and socket_id in cpu_topology[] start with 0 for the lowest numbered entity; and /proc/cpuinfo and tools like 'lscpu -ye' display the expected values. Display only, no functional change intended. [Fix] Cherry pick commit: - 540f4a4f6ef8 ("s390/topology: Use zero-based numbering for containing entities") [Test Plan] Run 'lscpu -ye' to make sure that zero-based numbering is used for socket, book, drawer, etc. [Regression Potential] No functional change intended. Regression potential is very low. --- Description: s390/topology: Use zero-based numbering Symptom: Ids displayed by 'lscpu -ye' don't match HW Ids Problem: Hardware documentation, the Hardware Management Console and other tools like zmemtopo use zero-based numbering for socket, book, drawer. But the linux kernel displays one-based numbering in sysfs, procfs and lscpu. Reproduction: 'lscpu -ye' Affected Distros: Ubuntu 22.04, 24.04, 26.04 Solution: Correct the indices the kernel gets from HW sysinfo. Upstream-ID: 540f4a4f6ef806a28e794001bb4beac4840a6090 To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/2164516/+subscriptions
[Bug 2161309] Re: Backlight regression
Hi guys, I have tested the proposed kernel on my system and can confirm that the regression is fixed. Hardware & System Details: - Device: Dell Precision M4800 - OS: Ubuntu 26.04 LTS - Graphics: Hybrid / Dual GPU (Intel HD Graphics + NVIDIA Quadro K1100M on nouveau) - Tested Kernel Version: linux-image-7.0.0-31-generic (7.0.0-31.31) from -proposed Test Results: 1. Backlight / Brightness Regulation: Works properly via Fn keyboard shortcuts as well as the GUI slider. 2. Suspend & Resume: The black screen issue is completely resolved. Upon waking from suspend, the screen backlight turns back on immediately. Thank you for fixing this issue! ***** PS, Just as an aside note: AI was very helpful - guide how to install linux-image-7.0.0-31-generic https://aistudio.google.com/ 2 minutes for me -- 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
четверг
Re: [Bug 2161098] Re: Random hard freezes caused by i915 kernel page fault in eb_relocate_parse_slow on MacBookAir6,2 (Intel HD 5000)acBookAir6,2 (Intel HD 5000)
MacBookAir6,2 – long-standing issue across multiple kernel versions Hi Alice, Thank you for investigating this and for preparing the test kernel with the proposed fix. I have the same MacBookAir6,2 with Intel Haswell HD Graphics 5000, and I am very interested in testing this patch. One important point from my experience is that this has not appeared to be specific to Ubuntu 26.04 or the 7.0 kernel series. I have experienced essentially the same hard-freeze problem with this MacBook across multiple Ubuntu releases and kernel generations, including Ubuntu 20, 22, 24 and 26, and kernels going back to the 5.15 series. I have also reproduced the problem with other Linux distributions. My MacBook is currently running Ubuntu 24.04 with kernel 6.8. Given that history, I would be very interested to know whether the underlying issue you identified can also affect the older i915 code in the 6.8 kernel. Would it be possible to provide a 6.8-based test kernel containing this patch, or otherwise advise me on the best way to test the patch on Ubuntu 24.04? I would be happy to test it extensively and report whether the freezes disappear. Best regards, Khaled On 19/08/2026 21:48, Alice C. Munduruca wrote: > Hi again, > > The test package I created has just finished building. It also contains > some changes on top of the currently released kernel version, but those > should not affect the fix patch I applied. > > You can install it as follows > > $ sudo add-apt-repository ppa:canonical-kernel-team/ppa > $ sudo apt upgrade # This will install other 7.0.0-31-generic packages required > $ sudo apt install path/to/linux-image-unsigned-7.0.0-31-generic_7.0.0-31.31~lp2161098_amd64.deb \ > path/to/linux-modules-7.0.0-31-generic_7.0.0-31.31~lp2161098_amd64.deb # DOWNLOADED FROM [1] > > Don't forget to uninstall the PPA and packages once you're done testing. > Some of the commands remove some packages you'll need to reinstall as > well, and differ if you want to have the evental HWE kernel (the default > for desktops) or the stable kernel. (default for servers) > > $ sudo apt remove linux-*-7.0.0-31-generic > $ sudo add-apt-repository --remove ppa:canonical-kernel-team/ppa > > # IF YOU WANT THE EVENTUAL HWE KERNELS > $ sudo apt install linux-image-generic-hwe-26.04 linux-headers-generic > > # IF YOU WANT THE STABLE KERNEL > $ sudo apt install linux-image-generic linux-headers-generic > > Please test to see if this fixes the issue and/or creates any new > bugs/instability when running typical tasks on your machine. > > [1]: > https://launchpad.net/~cremfuelled/+archive/ubuntu/kernel/+build/33514389 > -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161098 Title: Random hard freezes caused by i915 kernel page fault in eb_relocate_parse_slow on MacBookAir6,2 (Intel HD 5000)acBookAir6,2 (Intel HD 5000) Status in linux package in Ubuntu: In Progress Bug description: Hardware: - Apple MacBookAir6,2 - Intel Haswell HD Graphics 5000 (i915) Software: - Ubuntu 26.10 - Mesa 26.0.3 - Kernel 7.0.0-27 and 7.0.0-28 affected - Currently testing kernel 7.0.0-14 Problem: The system randomly hard freezes. The display remains unchanged with no graphical corruption, but the keyboard and mouse become completely unresponsive and only a hard power-off recovers the system. The freezes are not tied to any particular application. One crash happened while running Papers, but other freezes have occurred during normal desktop use. The previous boot journal contains the following kernel oops: BUG: unable to handle page fault Call trace: kfree() eb_relocate_parse_slow [i915] i915_gem_do_execbuffer [i915] i915_gem_execbuffer2_ioctl [i915] The same MacBook Air hardware is completely stable under macOS (including Big Sur), suggesting this is a Linux kernel regression rather than a hardware fault. The issue has occurred multiple times on kernels 7.0.0-27 and 7.0.0-28. I am now testing kernel 7.0.0-14 to determine whether the regression was introduced after that version. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-14-generic 7.0.0-14.14 ProcVersionSignature: Ubuntu 7.0.0-14.14-generic 7.0.0 Uname: Linux 7.0.0-14-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: khaled 2072 F.... wireplumber /dev/snd/controlC0: khaled 2072 F.... wireplumber /dev/snd/seq: khaled 2048 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Jul 17 16:19:07 2026 InstallationDate: Installed on 2026-07-14 (3 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) IwDevWlp3s0Link: Error: command ['iw', 'dev', 'wlp3s0', 'link'] failed with exit code 255: command failed: Operation not permitted (-1) Connected to <hidden-mac> (on wlp3s0) SSID: <hidden> freq: 5280.0 MachineType: Apple Inc. MacBookAir6,2 ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-14-generic root=UUID=b8679823-0d43-482e-99df-035663cbd8cf 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/13/2023 dmi.bios.release: 0.1 dmi.bios.vendor: Apple Inc. dmi.bios.version: 478.0.0.0.0 dmi.board.asset.tag: Base Board Asset Tag# dmi.board.name: Mac-7DF21CB3ED6977E5 dmi.board.vendor: Apple Inc. dmi.board.version: MacBookAir6,2 dmi.chassis.type: 10 dmi.chassis.vendor: Apple Inc. dmi.chassis.version: Mac-7DF21CB3ED6977E5 dmi.modalias: dmi:bvnAppleInc.:bvr478.0.0.0.0:bd01/13/2023:br0.1:svnAppleInc.:pnMacBookAir6,2:pvr1.0:rvnAppleInc.:rnMac-7DF21CB3ED6977E5:rvrMacBookAir6,2:cvnAppleInc.:ct10:cvrMac-7DF21CB3ED6977E5:skuSystemSKU#:pfaMacBookAir: dmi.product.family: MacBook Air dmi.product.name: MacBookAir6,2 dmi.product.sku: System SKU# dmi.product.version: 1.0 dmi.sys.vendor: Apple Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161098/+subscriptions
[Bug 2156556] Re: Fix no audio from right built-in speaker on HP ZBook with TAS2781 amplifier
This bug is awaiting verification that the linux-azure- fde-7.0/7.0.0-1013.13~24.04.1 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-noble-linux- azure-fde-7.0' to 'verification-done-noble-linux-azure-fde-7.0'. If the problem still exists, change the tag 'verification-needed-noble-linux- azure-fde-7.0' to 'verification-failed-noble-linux-azure-fde-7.0'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-noble-linux-azure-fde-7.0-v2 verification-needed-noble-linux-azure-fde-7.0 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2156556 Title: Fix no audio from right built-in speaker on HP ZBook with TAS2781 amplifier 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: Fix Released Status in linux source package in Resolute: Fix Released Status in linux-oem-6.17 source package in Resolute: New Bug description: [Impact] The TI TAS2781 smart amp fails to initialize when connected over SPI on the new HP HP ZBook. The right built-in speaker will fail to output after reboot [Fix] Two changes in one commit: 1. Always run the software reset sequence for the amp, not just in the no-gpio path. This resets device-0 even when its hardware reset pin has no effect. 2. Ignore -EXDEV during block processing when the device is on SPI. The driver keeps iterating through the blocks and adds up the total block size correctly. Upstream commit (in tiwai/sound for-next, not yet in a released tag): 513480da5e9c ALSA: hda/tas2781: Fix device-0 reset issue and handle -EXDEV in block data processing https://patch.msgid.link/20260609105253.19510-1-baojun.xu@ti.com [Test Plan] On HP Zbook with a TAS2781 amp connected over SPI: $ dmesg | grep -i tas2781 Play audio: $ speaker-test -c 2 -t wav Without patch: dmesg shows "dev sw-reset fail" or "process_block: single write error" / "bulk_write error". No sound from the TAS2781 speakers. With patch: no reset or block errors in dmesg. Speakers play sound. [Where problems could occur] The reset change now runs the software reset on every path, including the gpio reset path. If the software reset is wrong for some amp, the device could fail to come up and stay silent. Both changes are amp init only, so a regression would show up as no sound on TAS2781 SPI systems. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2156556/+subscriptions
[Bug 2156559] Re: Fix no sound output device on Dell GhostRider PTL no camera SKU
This bug is awaiting verification that the linux-azure- fde-7.0/7.0.0-1013.13~24.04.1 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-noble-linux- azure-fde-7.0' to 'verification-done-noble-linux-azure-fde-7.0'. If the problem still exists, change the tag 'verification-needed-noble-linux- azure-fde-7.0' to 'verification-failed-noble-linux-azure-fde-7.0'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-noble-linux-azure-fde-7.0-v2 verification-needed-noble-linux-azure-fde-7.0 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2156559 Title: Fix no sound output device on Dell GhostRider PTL no camera SKU 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: Fix Released Status in linux source package in Resolute: Fix Released Status in linux-oem-6.17 source package in Resolute: Fix Committed Bug description: [Impact] SoundWire audio can come up with the wrong topology on Intel SOF systems. Playback or capture paths may not work as expected. Intel SoundWire (SDW) audio codecs may load the wrong topology. [Fix] Always append the dai_type to the DAI link and stream name. Upstream commit c84179a1d36b ("ASoC: Intel: sof_sdw: append dai type to dai link name unconditionally") fix this problem [Test Plan] On the Dell GhostRider PTL no Camera SKU: $ dmesg | grep -i sof $ aplay -l $ arecord -l Play and record audio: $ speaker-test -c 2 -t wav $ arecord -d 5 -f cd /tmp/test.wav && aplay /tmp/test.wav Without patch: wrong or missing topology selection on some configs; playback or capture path does not work as expected. With patch: correct topology loads; playback and capture work. [Where problems could occur] The change makes the dai_type suffix unconditional and drops the old name format. If a topology file still expects the old non-suffixed stream name, partial matching could miss and that topology would fail to bind. The change is limited to DAI link naming in one board driver, so a regression would be no/incorrect audio, not a kernel crash. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2156559/+subscriptions
[Bug 2164692] Re: kernel 7.0.0-30
*** This bug is a duplicate of bug 2161309 *** https://bugs.launchpad.net/bugs/2161309 You can try the 7.0.0-31 kernel in -proposed. ** This bug has been marked a duplicate of bug 2161309 Backlight regression -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2164692 Title: kernel 7.0.0-30 Status in linux package in Ubuntu: New Bug description: On lenovo t480 still does not recover after going on standby. (closing laptop lid. after openit screen remains dark. last working kernel is 7.0.0-14) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2164692/+subscriptions