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
[Bug 2164692] [NEW] kernel 7.0.0-30
*** This bug is a duplicate of bug 2161309 *** https://bugs.launchpad.net/bugs/2161309 Public bug reported: 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) ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/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
[Bug 2164686] Re: AMD Mullins/Kabini APU incorrectly defaults to radeon instead of amdgpu
I wouldn't say it's "incorrect" to use radeon as default, since that's what the upstream 7.0 kernel did The 6.19 kernel switched to amdgpu for discrete GPU's only. https://github.com/torvalds/linux/commit/c034426671d0aa3eed9a7cc924bdd2ae3b76fd5d Then, they made amdgpu default for Sea Island's APU's in kernel 7.1 https://github.com/torvalds/linux/commit/d1f188b182c92b71d1bdd03436d7c6b08fbc86be -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2164686 Title: AMD Mullins/Kabini APU incorrectly defaults to radeon instead of amdgpu Status in linux package in Ubuntu: New Bug description: Bug Report: AMD Mullins/Kabini APU incorrectly defaults to radeon instead of amdgpu Summary On Ubuntu 24.04 (kernel 7.0.0-30-generic), my Lenovo system with an AMD Mullins/Kabini APU consistently defaults to the legacy radeon driver. This hardware fully supports amdgpu, and switching to amdgpu results in immediate and significant stability improvements, including correct multi-monitor behaviour and stable GPU acceleration in Chromium-based applications. This suggests the driver-selection heuristics for Sea Islands (CIK) hardware may need updating. My subsystem ID (17aa:369a) may be missing from the amdgpu-preferred list. Hardware - Model: Lenovo desktop - GPU: AMD Mullins / Radeon R4/R5 Graphics - PCI ID: 1002:9851 - Subsystem: 17aa:369a - Generation: Sea Islands (CIK) Incorrect default behaviour On a clean Ubuntu install, the system binds the GPU to the legacy radeon driver: lspci -nnk | grep -A3 VGA Kernel driver in use: radeon Kernel modules: radeon, amdgpu Using radeon causes: - GPU process crashes in Chrome/Chromium - flickering and corrupted text input - unstable multi-monitor behaviour - degraded performance in Electron apps - fallback to software rendering in some cases Correct behaviour after manual override After enabling amdgpu and disabling radeon via kernel parameters: amdgpu.si_support=1 amdgpu.cik_support=1 radeon.si_support=0 radeon.cik_support=0 and blacklisting radeon, the system boots with: Kernel driver in use: amdgpu Kernel modules: radeon, amdgpu Chrome’s GPU diagnostics confirm stable hardware acceleration: - Canvas: Hardware accelerated - Compositing: Hardware accelerated - WebGL: Hardware accelerated - GPU process crash count: 0 Multi-monitor output also becomes stable. Evidence from chrome://gpu Representative lines: GL_RENDERER: ANGLE (AMD Radeon R5 Graphics … Mesa 26.0.8) GPU process crash count: 0 This demonstrates that amdgpu + Mesa 26 is fully functional on this hardware. Kernel logs dmesg shows amdgpu initialising: amdgpu: Virtual CRAT table created for CPU amdgpu: Topology: Add CPU node This indicates the module loads correctly but is not selected by default. Expected behaviour Ubuntu should bind Mullins/Kabini APUs to amdgpu by default when: - the hardware supports it - the module loads cleanly - the modern driver provides significantly better stability This may require: - adding subsystem ID 17aa:369a to amdgpu-preferred lists - adjusting SI/CIK detection heuristics - updating documentation for Mullins/Kabini users Request Please evaluate whether this Lenovo Mullins/Kabini device should default to amdgpu rather than radeon, and whether the driver-selection rules for Sea Islands hardware need updating. I am happy to provide full logs, kernel dumps, or run additional tests if needed. (This report was generated with the assistance of Microsoft Copilot after investigating persistent Chrome flickering and keyboard input corruption on this hardware. Firefox was unaffected. I don’t claim to fully understand the underlying driver behaviour, but the evidence above reflects the results of the investigation.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2164686/+subscriptions
[Bug 2164686] [NEW] AMD Mullins/Kabini APU incorrectly defaults to radeon instead of amdgpu
Public bug reported: Bug Report: AMD Mullins/Kabini APU incorrectly defaults to radeon instead of amdgpu Summary On Ubuntu 24.04 (kernel 7.0.0-30-generic), my Lenovo system with an AMD Mullins/Kabini APU consistently defaults to the legacy radeon driver. This hardware fully supports amdgpu, and switching to amdgpu results in immediate and significant stability improvements, including correct multi-monitor behaviour and stable GPU acceleration in Chromium-based applications. This suggests the driver-selection heuristics for Sea Islands (CIK) hardware may need updating. My subsystem ID (17aa:369a) may be missing from the amdgpu-preferred list. Hardware - Model: Lenovo desktop - GPU: AMD Mullins / Radeon R4/R5 Graphics - PCI ID: 1002:9851 - Subsystem: 17aa:369a - Generation: Sea Islands (CIK) Incorrect default behaviour On a clean Ubuntu install, the system binds the GPU to the legacy radeon driver: lspci -nnk | grep -A3 VGA Kernel driver in use: radeon Kernel modules: radeon, amdgpu Using radeon causes: - GPU process crashes in Chrome/Chromium - flickering and corrupted text input - unstable multi-monitor behaviour - degraded performance in Electron apps - fallback to software rendering in some cases Correct behaviour after manual override After enabling amdgpu and disabling radeon via kernel parameters: amdgpu.si_support=1 amdgpu.cik_support=1 radeon.si_support=0 radeon.cik_support=0 and blacklisting radeon, the system boots with: Kernel driver in use: amdgpu Kernel modules: radeon, amdgpu Chrome’s GPU diagnostics confirm stable hardware acceleration: - Canvas: Hardware accelerated - Compositing: Hardware accelerated - WebGL: Hardware accelerated - GPU process crash count: 0 Multi-monitor output also becomes stable. Evidence from chrome://gpu Representative lines: GL_RENDERER: ANGLE (AMD Radeon R5 Graphics … Mesa 26.0.8) GPU process crash count: 0 This demonstrates that amdgpu + Mesa 26 is fully functional on this hardware. Kernel logs dmesg shows amdgpu initialising: amdgpu: Virtual CRAT table created for CPU amdgpu: Topology: Add CPU node This indicates the module loads correctly but is not selected by default. Expected behaviour Ubuntu should bind Mullins/Kabini APUs to amdgpu by default when: - the hardware supports it - the module loads cleanly - the modern driver provides significantly better stability This may require: - adding subsystem ID 17aa:369a to amdgpu-preferred lists - adjusting SI/CIK detection heuristics - updating documentation for Mullins/Kabini users Request Please evaluate whether this Lenovo Mullins/Kabini device should default to amdgpu rather than radeon, and whether the driver-selection rules for Sea Islands hardware need updating. I am happy to provide full logs, kernel dumps, or run additional tests if needed. (This report was generated with the assistance of Microsoft Copilot after investigating persistent Chrome flickering and keyboard input corruption on this hardware. Firefox was unaffected. I don’t claim to fully understand the underlying driver behaviour, but the evidence above reflects the results of the investigation.) ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Attachment added: "Chrome's about-gpu report after deploying fix." https://bugs.launchpad.net/bugs/2164686/+attachment/5993968/+files/about-gpu-2026-08-20T20-30-40-717Z.txt -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2164686 Title: AMD Mullins/Kabini APU incorrectly defaults to radeon instead of amdgpu Status in linux package in Ubuntu: New Bug description: Bug Report: AMD Mullins/Kabini APU incorrectly defaults to radeon instead of amdgpu Summary On Ubuntu 24.04 (kernel 7.0.0-30-generic), my Lenovo system with an AMD Mullins/Kabini APU consistently defaults to the legacy radeon driver. This hardware fully supports amdgpu, and switching to amdgpu results in immediate and significant stability improvements, including correct multi-monitor behaviour and stable GPU acceleration in Chromium-based applications. This suggests the driver-selection heuristics for Sea Islands (CIK) hardware may need updating. My subsystem ID (17aa:369a) may be missing from the amdgpu-preferred list. Hardware - Model: Lenovo desktop - GPU: AMD Mullins / Radeon R4/R5 Graphics - PCI ID: 1002:9851 - Subsystem: 17aa:369a - Generation: Sea Islands (CIK) Incorrect default behaviour On a clean Ubuntu install, the system binds the GPU to the legacy radeon driver: lspci -nnk | grep -A3 VGA Kernel driver in use: radeon Kernel modules: radeon, amdgpu Using radeon causes: - GPU process crashes in Chrome/Chromium - flickering and corrupted text input - unstable multi-monitor behaviour - degraded performance in Electron apps - fallback to software rendering in some cases Correct behaviour after manual override After enabling amdgpu and disabling radeon via kernel parameters: amdgpu.si_support=1 amdgpu.cik_support=1 radeon.si_support=0 radeon.cik_support=0 and blacklisting radeon, the system boots with: Kernel driver in use: amdgpu Kernel modules: radeon, amdgpu Chrome’s GPU diagnostics confirm stable hardware acceleration: - Canvas: Hardware accelerated - Compositing: Hardware accelerated - WebGL: Hardware accelerated - GPU process crash count: 0 Multi-monitor output also becomes stable. Evidence from chrome://gpu Representative lines: GL_RENDERER: ANGLE (AMD Radeon R5 Graphics … Mesa 26.0.8) GPU process crash count: 0 This demonstrates that amdgpu + Mesa 26 is fully functional on this hardware. Kernel logs dmesg shows amdgpu initialising: amdgpu: Virtual CRAT table created for CPU amdgpu: Topology: Add CPU node This indicates the module loads correctly but is not selected by default. Expected behaviour Ubuntu should bind Mullins/Kabini APUs to amdgpu by default when: - the hardware supports it - the module loads cleanly - the modern driver provides significantly better stability This may require: - adding subsystem ID 17aa:369a to amdgpu-preferred lists - adjusting SI/CIK detection heuristics - updating documentation for Mullins/Kabini users Request Please evaluate whether this Lenovo Mullins/Kabini device should default to amdgpu rather than radeon, and whether the driver-selection rules for Sea Islands hardware need updating. I am happy to provide full logs, kernel dumps, or run additional tests if needed. (This report was generated with the assistance of Microsoft Copilot after investigating persistent Chrome flickering and keyboard input corruption on this hardware. Firefox was unaffected. I don’t claim to fully understand the underlying driver behaviour, but the evidence above reflects the results of the investigation.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2164686/+subscriptions