[Bug 2127044] Re: MT7925 wifi is hard blocked on HP's machine

Still got hard blocked even roll back to 2.21 firmware.

ubuntu@localhost:~$ uname -a
Linux localhost 6.14.0-1018-oem #18-Ubuntu SMP PREEMPT_DYNAMIC Wed Dec 10 09:33:29 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@localhost:~$ rfkill list
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: yes
ubuntu@localhost:~$ dpkg -l | grep linux-firmware
ii linux-firmware 20240318.git3b128b60-0ubuntu2.21 amd64 Firmware for Linux kernel drivers

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2127044

Title:
MT7925 wifi is hard blocked on HP's machine

Status in HWE Next:
New
Status in linux package in Ubuntu:
Invalid
Status in linux-firmware package in Ubuntu:
Invalid
Status in linux-oem-6.14 package in Ubuntu:
Invalid
Status in linux-oem-6.17 package in Ubuntu:
Invalid
Status in linux source package in Noble:
Invalid
Status in linux-firmware source package in Noble:
In Progress
Status in linux-oem-6.14 source package in Noble:
Fix Released
Status in linux-oem-6.17 source package in Noble:
In Progress
Status in linux source package in Questing:
In Progress
Status in linux-firmware source package in Questing:
In Progress
Status in linux-oem-6.14 source package in Questing:
Invalid
Status in linux-oem-6.17 source package in Questing:
Invalid

Bug description:
[Impact]
The wifi is hard blocked and can't be used randomly.

[Fix]
The issue is introduced by commit 085749115fd37 ("wifi: mt76: mt7925: add rfkill_poll for hardware rfkill")
The machine doesn't support this feature may lead to undefined behavior, and MTK will submit a firmware to fix this issue in the near feature.

For short-term solution, we made a DMI quick to list the machines that
doesn't support this feature.

[Test]
1. Boot up HP Z2 Mini G1a Workstation
2. Run `rfkill list` to check wlan0 block state
3. Re-plug power cord and then check rfkill state again
4. The wlan0 should not be hard blocked.

[Where problems could occur]
Should be pretty safe to return the function call directly, since the machine doesn't support it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/2127044/+subscriptions

[Bug 2131732] Re: RTL8922A BT USB: Bluetooth: hci0: RTL: download fw command failed (-13)

** Tags added: stella

** Tags added: jira-stella-2222

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2131732

Title:
RTL8922A BT USB: Bluetooth: hci0: RTL: download fw command failed
(-13)

Status in linux package in Ubuntu:
In Progress
Status in linux-firmware package in Ubuntu:
Fix Committed
Status in linux-oem-6.17 package in Ubuntu:
Invalid
Status in linux source package in Noble:
Won't Fix
Status in linux-firmware source package in Noble:
Fix Committed
Status in linux-oem-6.17 source package in Noble:
In Progress
Status in linux source package in Plucky:
Won't Fix
Status in linux-firmware source package in Plucky:
Won't Fix
Status in linux-oem-6.17 source package in Plucky:
Invalid
Status in linux source package in Questing:
In Progress
Status in linux-firmware source package in Questing:
Fix Committed
Status in linux-oem-6.17 source package in Questing:
Invalid
Status in linux source package in Resolute:
In Progress
Status in linux-firmware source package in Resolute:
Fix Committed
Status in linux-oem-6.17 source package in Resolute:
Invalid

Bug description:
[SRU Justification]

[ Impact ]

New Bluetooth component may failed with dmesg error:
```
Bluetooth: hci0: RTL: download fw command failed (-13)
```

The proposed fixes, linux-firmware commit fcf22f506bf5 ("rtl_bt:
Update RTL8922A BT USB firmware to 0x41C0_C905") under upstream tag
20251111, along with kernel v6.18-rc6 commit cd8dbd9ef600 ("Bluetooth:
btrtl: Avoid loading the config file on security"), support signature
key for secure boot.

[ Test Plan ]

Re-run checkbox test case:
```
$ sudo checkbox-cli run com.canonical.certification::bluetooth/detect-output
```

[ Where problems could occur ]

Opaque binary blob. May cause problem whatever possible.

[ Other Info ]

RTL8922A kernel driver was supported since v6.12-rc1, and the
corresponding firmware binaries were included in linux-firmware/noble
and on. Nominate for N, Q, R.

============ original bug report ============

[Summary]
bluetooth/detect-output failed
certification_status: blocker

[I/O log]

BT hardware not available

[Reproduce Steps]
1. sudo checkbox-cli run com.canonical.certification::bluetooth/detect-output

[Results]
failed

[Additional Information]
Manifest: canonical-oem-stella-noble-oem-24.04c 20251022-94
BIOS Version: B.08
SKU: BANTEI-PV-C10
BIOS ID: 0PESKU8#ABA
Tester: auto-sanity-bot

Proposed fixes are:
* https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=fcf22f506bf5c290742cdc5260d0633c95e6f284 ("rtl_bt: Update RTL8922A BT USB firmware to 0x41C0_C905") under upstream tag 20251111.
* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=cd8dbd9ef600435439bb0e70af0a1d9e2193aecb ("Bluetooth: btrtl: Avoid loading the config file on security") in v6.18-rc6.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2131732/+subscriptions

[Bug 2137448] Re: System doesn't response with mt76 call trace

** Description changed:

[Impact]
On Dell systems with MediaTek MT7925 WiFi cards (mt7925e driver), the system becomes unresponsive during firmware testing and high-load situations due to a deadlock in the mt76 driver. The system shows "workqueue hogging CPU" messages followed by system hang, preventing completion of certification testing.

The issue occurs because:
1. Two workqueue functions (ps_work and mac_work) attempt to cancel each other using cancel_delayed_work_sync()
2. In high-load situations, both works get queued but cannot execute until CPUs are available
3. When CPUs become available, both work functions may run simultaneously, each trying to synchronously cancel the other, resulting in a deadlock

The call path that creates the circular dependency is:
  mt792x_mac_work() -> ... -> cancel_delayed_work_sync(&pm->ps_work);
  mt792x_pm_power_save_work() -> cancel_delayed_work_sync(&mphy->mac_work);

[Fix]
Replace cancel_delayed_work_sync() with cancel_delayed_work() in the mt792x_pm_power_save_work() function to eliminate the deadlock condition.

Upstream commit (submitted to linux-wireless):
https://patchwork.kernel.org/project/linux-wireless/patch/20251215122231.3180648-1-leon.yen@mediatek.com/

The non-synchronous cancel is safe here because:
- The work cancellation is part of the power-save flow, not a critical cleanup path
- Avoiding synchronous wait prevents the circular dependency that causes the deadlock
- The code becomes simpler and easier to maintain

[Test Plan]
On a Dell system with MediaTek MT7925 WiFi (or similar affected platform):

- 1. Run the Checkbox certification test suite that triggers the issue:
-    $ checkbox-cli run com.canonical.certification::client-cert-desktop-24-04-automated
+ 1. Install fwts if not already available:
+ $ sudo apt-get install fwts

- 2. Specifically execute the firmware test cases that previously triggered the deadlock:
-    - firmware/fwts_desktop_diagnosis
-    - firmware/fwts_wakealarm.*
-    - firmware/fwts_uefirtvariable.*
-    - miscellanea/oops
+ 2. Monitor system logs in a separate terminal:
+ $ sudo dmesg -w

- 3. Monitor system logs for the previously observed symptoms:
-    $ sudo dmesg -w
+ 3. Run the firmware test cases that previously triggered the deadlock:

-    Without the fix, you would see:
-    - "Message 00020080 (seq N) timeout" from mt7925e
-    - "workqueue: vmstat_update hogged CPU for >10000us" warnings
-    - "workqueue: psi_avgs_work hogged CPU for >10000us" warnings
-    - WARNING traces in iommu_dma_unmap_page
-    - System becoming unresponsive
+ $ sudo fwts wakealarm
+ $ sudo fwts uefirtvariable
+ $ sudo fwts oops

-    With the fix, these symptoms should not occur and the system should
+ Or run a comprehensive diagnostic test:
+ $ sudo fwts --log-level=high -r stdout
+
+ 4. Check for symptoms during and after the tests:
+
+ Without the fix, you would see:
+ - "Message 00020080 (seq N) timeout" from mt7925e
+ - "workqueue: vmstat_update hogged CPU for >10000us" warnings
+ - "workqueue: psi_avgs_work hogged CPU for >10000us" warnings
+ - WARNING traces in iommu_dma_unmap_page
+ - System becoming unresponsive
+
+ With the fix, these symptoms should not occur and the system should
remain responsive.

- 4. Run extended stress testing with WiFi activity during high CPU load:
-    $ stress-ng --cpu 128 --timeout 300s &
-    $ ping -f <router_ip> # flood ping to generate WiFi traffic
+ 5. Run extended stress testing with WiFi activity during high CPU load:
+ $ stress-ng --cpu 128 --timeout 300s &
+ $ ping -f <router_ip> # flood ping to generate WiFi traffic

-    The system should remain stable without deadlocks.
-
- 5. Verify WiFi power management still functions correctly:
-    $ iw dev <interface> get power_save
-    $ # Enable/disable power save and verify WiFi connectivity remains stable
-    $ sudo iw dev <interface> set power_save on
-    $ ping -c 100 <router_ip>
+ The system should remain stable without deadlocks.

[Where problems could occur]
This change affects the MediaTek MT792x WiFi driver's power management and workqueue interaction on systems with mt7925e and similar chipsets.

Potential issues if the non-synchronous cancel is not safe in this context:
- If there are assumptions in the code that mac_work must be fully stopped before proceeding, using non-synchronous cancel might allow mac_work to run concurrently with subsequent operations, potentially causing race conditions
- The mac_work might access hardware or data structures that ps_work assumes are quiescent after the cancel call, leading to unexpected behavior or crashes
- Power management state transitions might become inconsistent if mac_work completes after ps_work has already proceeded with its power-save operations

However, these risks are mitigated by:
- The change is intentional and authored by MediaTek engineers who maintain the driver
- The alternative (synchronous cancel) creates a known deadlock issue with 60% reproduction rate
- The workqueue subsystem provides inherent protection against most race conditions
- Similar patterns are used elsewhere in the kernel where work items need to coordinate

The impact is limited to:
- Systems with MediaTek MT792x series WiFi chipsets (mt7921, mt7925, etc.)
- Primarily affects high-load scenarios where both work items are queued simultaneously
- Does not affect other wireless drivers or systems without these chipsets

[Other Info]
Upstream submission: https://patchwork.kernel.org/project/linux-wireless/patch/20251215122231.3180648-1-leon.yen@mediatek.com/

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2137448

Title:
System doesn't response with mt76 call trace

Status in linux package in Ubuntu:
In Progress
Status in linux-oem-6.14 package in Ubuntu:
Invalid
Status in linux-oem-6.17 package in Ubuntu:
Invalid
Status in linux source package in Noble:
In Progress
Status in linux-oem-6.14 source package in Noble:
In Progress
Status in linux-oem-6.17 source package in Noble:
In Progress
Status in linux source package in Questing:
In Progress
Status in linux-oem-6.14 source package in Questing:
Invalid
Status in linux-oem-6.17 source package in Questing:
Invalid
Status in linux source package in Resolute:
In Progress
Status in linux-oem-6.14 source package in Resolute:
Invalid
Status in linux-oem-6.17 source package in Resolute:
Invalid

Bug description:
[Impact]
On Dell systems with MediaTek MT7925 WiFi cards (mt7925e driver), the system becomes unresponsive during firmware testing and high-load situations due to a deadlock in the mt76 driver. The system shows "workqueue hogging CPU" messages followed by system hang, preventing completion of certification testing.

The issue occurs because:
1. Two workqueue functions (ps_work and mac_work) attempt to cancel each other using cancel_delayed_work_sync()
2. In high-load situations, both works get queued but cannot execute until CPUs are available
3. When CPUs become available, both work functions may run simultaneously, each trying to synchronously cancel the other, resulting in a deadlock

The call path that creates the circular dependency is:
  mt792x_mac_work() -> ... -> cancel_delayed_work_sync(&pm->ps_work);
  mt792x_pm_power_save_work() -> cancel_delayed_work_sync(&mphy->mac_work);

[Fix]
Replace cancel_delayed_work_sync() with cancel_delayed_work() in the mt792x_pm_power_save_work() function to eliminate the deadlock condition.

Upstream commit (submitted to linux-wireless):
https://patchwork.kernel.org/project/linux-wireless/patch/20251215122231.3180648-1-leon.yen@mediatek.com/

The non-synchronous cancel is safe here because:
- The work cancellation is part of the power-save flow, not a critical cleanup path
- Avoiding synchronous wait prevents the circular dependency that causes the deadlock
- The code becomes simpler and easier to maintain

[Test Plan]
On a Dell system with MediaTek MT7925 WiFi (or similar affected platform):

1. Install fwts if not already available:
$ sudo apt-get install fwts

2. Monitor system logs in a separate terminal:
$ sudo dmesg -w

3. Run the firmware test cases that previously triggered the deadlock:

$ sudo fwts wakealarm
$ sudo fwts uefirtvariable
$ sudo fwts oops

Or run a comprehensive diagnostic test:
$ sudo fwts --log-level=high -r stdout

4. Check for symptoms during and after the tests:

Without the fix, you would see:
- "Message 00020080 (seq N) timeout" from mt7925e
- "workqueue: vmstat_update hogged CPU for >10000us" warnings
- "workqueue: psi_avgs_work hogged CPU for >10000us" warnings
- WARNING traces in iommu_dma_unmap_page
- System becoming unresponsive

With the fix, these symptoms should not occur and the system should
remain responsive.

5. Run extended stress testing with WiFi activity during high CPU load:
$ stress-ng --cpu 128 --timeout 300s &
$ ping -f <router_ip> # flood ping to generate WiFi traffic

The system should remain stable without deadlocks.

[Where problems could occur]
This change affects the MediaTek MT792x WiFi driver's power management and workqueue interaction on systems with mt7925e and similar chipsets.

Potential issues if the non-synchronous cancel is not safe in this context:
- If there are assumptions in the code that mac_work must be fully stopped before proceeding, using non-synchronous cancel might allow mac_work to run concurrently with subsequent operations, potentially causing race conditions
- The mac_work might access hardware or data structures that ps_work assumes are quiescent after the cancel call, leading to unexpected behavior or crashes
- Power management state transitions might become inconsistent if mac_work completes after ps_work has already proceeded with its power-save operations

However, these risks are mitigated by:
- The change is intentional and authored by MediaTek engineers who maintain the driver
- The alternative (synchronous cancel) creates a known deadlock issue with 60% reproduction rate
- The workqueue subsystem provides inherent protection against most race conditions
- Similar patterns are used elsewhere in the kernel where work items need to coordinate

The impact is limited to:
- Systems with MediaTek MT792x series WiFi chipsets (mt7921, mt7925, etc.)
- Primarily affects high-load scenarios where both work items are queued simultaneously
- Does not affect other wireless drivers or systems without these chipsets

[Other Info]
Upstream submission: https://patchwork.kernel.org/project/linux-wireless/patch/20251215122231.3180648-1-leon.yen@mediatek.com/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2137448/+subscriptions

[Bug 2137448] [NEW] System doesn't response with mt76 call trace

Public bug reported:

[Impact]
On Dell systems with MediaTek MT7925 WiFi cards (mt7925e driver), the system becomes unresponsive during firmware testing and high-load situations due to a deadlock in the mt76 driver. The system shows "workqueue hogging CPU" messages followed by system hang, preventing completion of certification testing.

The issue occurs because:
1. Two workqueue functions (ps_work and mac_work) attempt to cancel each other using cancel_delayed_work_sync()
2. In high-load situations, both works get queued but cannot execute until CPUs are available
3. When CPUs become available, both work functions may run simultaneously, each trying to synchronously cancel the other, resulting in a deadlock

The call path that creates the circular dependency is:
  mt792x_mac_work() -> ... -> cancel_delayed_work_sync(&pm->ps_work);
  mt792x_pm_power_save_work() -> cancel_delayed_work_sync(&mphy->mac_work);

[Fix]
Replace cancel_delayed_work_sync() with cancel_delayed_work() in the mt792x_pm_power_save_work() function to eliminate the deadlock condition.

Upstream commit (submitted to linux-wireless):
https://patchwork.kernel.org/project/linux-wireless/patch/20251215122231.3180648-1-leon.yen@mediatek.com/

The non-synchronous cancel is safe here because:
- The work cancellation is part of the power-save flow, not a critical cleanup path
- Avoiding synchronous wait prevents the circular dependency that causes the deadlock
- The code becomes simpler and easier to maintain

[Test Plan]
On a Dell system with MediaTek MT7925 WiFi (or similar affected platform):

1. Run the Checkbox certification test suite that triggers the issue:
   $ checkbox-cli run com.canonical.certification::client-cert-desktop-24-04-automated

2. Specifically execute the firmware test cases that previously triggered the deadlock:
   - firmware/fwts_desktop_diagnosis
   - firmware/fwts_wakealarm.*
   - firmware/fwts_uefirtvariable.*
   - miscellanea/oops

3. Monitor system logs for the previously observed symptoms:
   $ sudo dmesg -w

   Without the fix, you would see:
   - "Message 00020080 (seq N) timeout" from mt7925e
   - "workqueue: vmstat_update hogged CPU for >10000us" warnings
   - "workqueue: psi_avgs_work hogged CPU for >10000us" warnings
   - WARNING traces in iommu_dma_unmap_page
   - System becoming unresponsive

   With the fix, these symptoms should not occur and the system should
remain responsive.

4. Run extended stress testing with WiFi activity during high CPU load:
   $ stress-ng --cpu 128 --timeout 300s &
   $ ping -f <router_ip> # flood ping to generate WiFi traffic

   The system should remain stable without deadlocks.

5. Verify WiFi power management still functions correctly:
   $ iw dev <interface> get power_save
   $ # Enable/disable power save and verify WiFi connectivity remains stable
   $ sudo iw dev <interface> set power_save on
   $ ping -c 100 <router_ip>

[Where problems could occur]
This change affects the MediaTek MT792x WiFi driver's power management and workqueue interaction on systems with mt7925e and similar chipsets.

Potential issues if the non-synchronous cancel is not safe in this context:
- If there are assumptions in the code that mac_work must be fully stopped before proceeding, using non-synchronous cancel might allow mac_work to run concurrently with subsequent operations, potentially causing race conditions
- The mac_work might access hardware or data structures that ps_work assumes are quiescent after the cancel call, leading to unexpected behavior or crashes
- Power management state transitions might become inconsistent if mac_work completes after ps_work has already proceeded with its power-save operations

However, these risks are mitigated by:
- The change is intentional and authored by MediaTek engineers who maintain the driver
- The alternative (synchronous cancel) creates a known deadlock issue with 60% reproduction rate
- The workqueue subsystem provides inherent protection against most race conditions
- Similar patterns are used elsewhere in the kernel where work items need to coordinate

The impact is limited to:
- Systems with MediaTek MT792x series WiFi chipsets (mt7921, mt7925, etc.)
- Primarily affects high-load scenarios where both work items are queued simultaneously
- Does not affect other wireless drivers or systems without these chipsets

[Other Info]
Upstream submission: https://patchwork.kernel.org/project/linux-wireless/patch/20251215122231.3180648-1-leon.yen@mediatek.com/

** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: AceLan Kao (acelankao)
Status: In Progress

** Affects: linux-oem-6.14 (Ubuntu)
Importance: Undecided
Status: Invalid

** Affects: linux-oem-6.17 (Ubuntu)
Importance: Undecided
Status: Invalid

** Affects: linux (Ubuntu Noble)
Importance: Undecided
Assignee: AceLan Kao (acelankao)
Status: In Progress

** Affects: linux-oem-6.14 (Ubuntu Noble)
Importance: Undecided
Assignee: AceLan Kao (acelankao)
Status: In Progress

** Affects: linux-oem-6.17 (Ubuntu Noble)
Importance: Undecided
Assignee: AceLan Kao (acelankao)
Status: In Progress

** Affects: linux (Ubuntu Questing)
Importance: Undecided
Assignee: AceLan Kao (acelankao)
Status: In Progress

** Affects: linux-oem-6.14 (Ubuntu Questing)
Importance: Undecided
Status: Invalid

** Affects: linux-oem-6.17 (Ubuntu Questing)
Importance: Undecided
Status: Invalid

** Affects: linux (Ubuntu Resolute)
Importance: Undecided
Assignee: AceLan Kao (acelankao)
Status: In Progress

** Affects: linux-oem-6.14 (Ubuntu Resolute)
Importance: Undecided
Status: Invalid

** Affects: linux-oem-6.17 (Ubuntu Resolute)
Importance: Undecided
Status: Invalid

** Also affects: linux-oem-6.14 (Ubuntu)
Importance: Undecided
Status: New

** Also affects: linux-oem-6.17 (Ubuntu)
Importance: Undecided
Status: New

** Also affects: linux (Ubuntu Questing)
Importance: Undecided
Status: New

** Also affects: linux-oem-6.14 (Ubuntu Questing)
Importance: Undecided
Status: New

** Also affects: linux-oem-6.17 (Ubuntu Questing)
Importance: Undecided
Status: New

** Also affects: linux (Ubuntu Resolute)
Importance: Undecided
Status: New

** Also affects: linux-oem-6.14 (Ubuntu Resolute)
Importance: Undecided
Status: New

** Also affects: linux-oem-6.17 (Ubuntu Resolute)
Importance: Undecided
Status: New

** Also affects: linux (Ubuntu Noble)
Importance: Undecided
Status: New

** Also affects: linux-oem-6.14 (Ubuntu Noble)
Importance: Undecided
Status: New

** Also affects: linux-oem-6.17 (Ubuntu Noble)
Importance: Undecided
Status: New

** Changed in: linux-oem-6.14 (Ubuntu Questing)
Status: New => Invalid

** Changed in: linux-oem-6.14 (Ubuntu Resolute)
Status: New => Invalid

** Changed in: linux-oem-6.17 (Ubuntu Questing)
Status: New => Invalid

** Changed in: linux-oem-6.17 (Ubuntu Resolute)
Status: New => Invalid

** Changed in: linux (Ubuntu Noble)
Status: New => In Progress

** Changed in: linux (Ubuntu Noble)
Assignee: (unassigned) => AceLan Kao (acelankao)

** Changed in: linux (Ubuntu Questing)
Status: New => In Progress

** Changed in: linux (Ubuntu Questing)
Assignee: (unassigned) => AceLan Kao (acelankao)

** Changed in: linux (Ubuntu Resolute)
Status: New => In Progress

** Changed in: linux (Ubuntu Resolute)
Assignee: (unassigned) => AceLan Kao (acelankao)

** Changed in: linux-oem-6.14 (Ubuntu Noble)
Status: New => In Progress

** Changed in: linux-oem-6.14 (Ubuntu Noble)
Assignee: (unassigned) => AceLan Kao (acelankao)

** Changed in: linux-oem-6.17 (Ubuntu Noble)
Status: New => In Progress

** Changed in: linux-oem-6.17 (Ubuntu Noble)
Assignee: (unassigned) => AceLan Kao (acelankao)

** Description changed:

[Impact]
- On Dell Brickyard systems with MediaTek MT7925 WiFi cards (mt7925e driver), the system becomes unresponsive during firmware testing and high-load situations due to a deadlock in the mt76 driver. The system shows "workqueue hogging CPU" messages followed by system hang, preventing completion of certification testing.
+ On Dell systems with MediaTek MT7925 WiFi cards (mt7925e driver), the system becomes unresponsive during firmware testing and high-load situations due to a deadlock in the mt76 driver. The system shows "workqueue hogging CPU" messages followed by system hang, preventing completion of certification testing.

The issue occurs because:
1. Two workqueue functions (ps_work and mac_work) attempt to cancel each other using cancel_delayed_work_sync()
2. In high-load situations, both works get queued but cannot execute until CPUs are available
3. When CPUs become available, both work functions may run simultaneously, each trying to synchronously cancel the other, resulting in a deadlock

The call path that creates the circular dependency is:
- mt792x_mac_work() -> ... -> cancel_delayed_work_sync(&pm->ps_work);
- mt792x_pm_power_save_work() -> cancel_delayed_work_sync(&mphy->mac_work);
+   mt792x_mac_work() -> ... -> cancel_delayed_work_sync(&pm->ps_work);
+   mt792x_pm_power_save_work() -> cancel_delayed_work_sync(&mphy->mac_work);

This affects Dell Pro Max Tower T4/T6 systems during firmware tests
(FWTS) and other certification testing, with a failure rate of 3/5
attempts, making it a critical issue for platform certification.

[Fix]
Replace cancel_delayed_work_sync() with cancel_delayed_work() in the mt792x_pm_power_save_work() function to eliminate the deadlock condition.

Upstream commit (submitted to linux-wireless):
https://patchwork.kernel.org/project/linux-wireless/patch/20251215122231.3180648-1-leon.yen@mediatek.com/

The non-synchronous cancel is safe here because:
- The work cancellation is part of the power-save flow, not a critical cleanup path
- Avoiding synchronous wait prevents the circular dependency that causes the deadlock
- The code becomes simpler and easier to maintain

[Test Plan]
On a Dell Brickyard system with MediaTek MT7925 WiFi (or similar affected platform):

1. Run the Checkbox certification test suite that triggers the issue:
- $ checkbox-cli run com.canonical.certification::client-cert-desktop-24-04-automated
+    $ checkbox-cli run com.canonical.certification::client-cert-desktop-24-04-automated

2. Specifically execute the firmware test cases that previously triggered the deadlock:
- - firmware/fwts_desktop_diagnosis
- - firmware/fwts_wakealarm.*
- - firmware/fwts_uefirtvariable.*
- - miscellanea/oops
+    - firmware/fwts_desktop_diagnosis
+    - firmware/fwts_wakealarm.*
+    - firmware/fwts_uefirtvariable.*
+    - miscellanea/oops

3. Monitor system logs for the previously observed symptoms:
- $ sudo dmesg -w
+    $ sudo dmesg -w

- Without the fix, you would see:
- - "Message 00020080 (seq N) timeout" from mt7925e
- - "workqueue: vmstat_update hogged CPU for >10000us" warnings
- - "workqueue: psi_avgs_work hogged CPU for >10000us" warnings
- - WARNING traces in iommu_dma_unmap_page
- - System becoming unresponsive
+    Without the fix, you would see:
+    - "Message 00020080 (seq N) timeout" from mt7925e
+    - "workqueue: vmstat_update hogged CPU for >10000us" warnings
+    - "workqueue: psi_avgs_work hogged CPU for >10000us" warnings
+    - WARNING traces in iommu_dma_unmap_page
+    - System becoming unresponsive

- With the fix, these symptoms should not occur and the system should
+    With the fix, these symptoms should not occur and the system should
remain responsive.

4. Run extended stress testing with WiFi activity during high CPU load:
- $ stress-ng --cpu 128 --timeout 300s &
- $ ping -f <router_ip> # flood ping to generate WiFi traffic
+    $ stress-ng --cpu 128 --timeout 300s &
+    $ ping -f <router_ip> # flood ping to generate WiFi traffic

- The system should remain stable without deadlocks.
+    The system should remain stable without deadlocks.

5. Verify WiFi power management still functions correctly:
- $ iw dev <interface> get power_save
- $ # Enable/disable power save and verify WiFi connectivity remains stable
- $ sudo iw dev <interface> set power_save on
- $ ping -c 100 <router_ip>
+    $ iw dev <interface> get power_save
+    $ # Enable/disable power save and verify WiFi connectivity remains stable
+    $ sudo iw dev <interface> set power_save on
+    $ ping -c 100 <router_ip>

[Where problems could occur]
This change affects the MediaTek MT792x WiFi driver's power management and workqueue interaction on systems with mt7925e and similar chipsets.

Potential issues if the non-synchronous cancel is not safe in this context:
- If there are assumptions in the code that mac_work must be fully stopped before proceeding, using non-synchronous cancel might allow mac_work to run concurrently with subsequent operations, potentially causing race conditions
- The mac_work might access hardware or data structures that ps_work assumes are quiescent after the cancel call, leading to unexpected behavior or crashes
- Power management state transitions might become inconsistent if mac_work completes after ps_work has already proceeded with its power-save operations

However, these risks are mitigated by:
- The change is intentional and authored by MediaTek engineers who maintain the driver
- The alternative (synchronous cancel) creates a known deadlock issue with 60% reproduction rate
- The workqueue subsystem provides inherent protection against most race conditions
- Similar patterns are used elsewhere in the kernel where work items need to coordinate

The impact is limited to:
- Systems with MediaTek MT792x series WiFi chipsets (mt7921, mt7925, etc.)
- Primarily affects high-load scenarios where both work items are queued simultaneously
- Does not affect other wireless drivers or systems without these chipsets

[Other Info]
Upstream submission: https://patchwork.kernel.org/project/linux-wireless/patch/20251215122231.3180648-1-leon.yen@mediatek.com/

** Description changed:

[Impact]
On Dell systems with MediaTek MT7925 WiFi cards (mt7925e driver), the system becomes unresponsive during firmware testing and high-load situations due to a deadlock in the mt76 driver. The system shows "workqueue hogging CPU" messages followed by system hang, preventing completion of certification testing.

The issue occurs because:
1. Two workqueue functions (ps_work and mac_work) attempt to cancel each other using cancel_delayed_work_sync()
2. In high-load situations, both works get queued but cannot execute until CPUs are available
3. When CPUs become available, both work functions may run simultaneously, each trying to synchronously cancel the other, resulting in a deadlock

The call path that creates the circular dependency is:
  mt792x_mac_work() -> ... -> cancel_delayed_work_sync(&pm->ps_work);
  mt792x_pm_power_save_work() -> cancel_delayed_work_sync(&mphy->mac_work);
-
- This affects Dell Pro Max Tower T4/T6 systems during firmware tests
- (FWTS) and other certification testing, with a failure rate of 3/5
- attempts, making it a critical issue for platform certification.

[Fix]
Replace cancel_delayed_work_sync() with cancel_delayed_work() in the mt792x_pm_power_save_work() function to eliminate the deadlock condition.

Upstream commit (submitted to linux-wireless):
https://patchwork.kernel.org/project/linux-wireless/patch/20251215122231.3180648-1-leon.yen@mediatek.com/

The non-synchronous cancel is safe here because:
- The work cancellation is part of the power-save flow, not a critical cleanup path
- Avoiding synchronous wait prevents the circular dependency that causes the deadlock
- The code becomes simpler and easier to maintain

[Test Plan]
- On a Dell Brickyard system with MediaTek MT7925 WiFi (or similar affected platform):
+ On a Dell system with MediaTek MT7925 WiFi (or similar affected platform):

1. Run the Checkbox certification test suite that triggers the issue:
   $ checkbox-cli run com.canonical.certification::client-cert-desktop-24-04-automated

2. Specifically execute the firmware test cases that previously triggered the deadlock:
   - firmware/fwts_desktop_diagnosis
   - firmware/fwts_wakealarm.*
   - firmware/fwts_uefirtvariable.*
   - miscellanea/oops

3. Monitor system logs for the previously observed symptoms:
   $ sudo dmesg -w

   Without the fix, you would see:
   - "Message 00020080 (seq N) timeout" from mt7925e
   - "workqueue: vmstat_update hogged CPU for >10000us" warnings
   - "workqueue: psi_avgs_work hogged CPU for >10000us" warnings
   - WARNING traces in iommu_dma_unmap_page
   - System becoming unresponsive

   With the fix, these symptoms should not occur and the system should
remain responsive.

4. Run extended stress testing with WiFi activity during high CPU load:
   $ stress-ng --cpu 128 --timeout 300s &
   $ ping -f <router_ip> # flood ping to generate WiFi traffic

   The system should remain stable without deadlocks.

5. Verify WiFi power management still functions correctly:
   $ iw dev <interface> get power_save
   $ # Enable/disable power save and verify WiFi connectivity remains stable
   $ sudo iw dev <interface> set power_save on
   $ ping -c 100 <router_ip>

[Where problems could occur]
This change affects the MediaTek MT792x WiFi driver's power management and workqueue interaction on systems with mt7925e and similar chipsets.

Potential issues if the non-synchronous cancel is not safe in this context:
- If there are assumptions in the code that mac_work must be fully stopped before proceeding, using non-synchronous cancel might allow mac_work to run concurrently with subsequent operations, potentially causing race conditions
- The mac_work might access hardware or data structures that ps_work assumes are quiescent after the cancel call, leading to unexpected behavior or crashes
- Power management state transitions might become inconsistent if mac_work completes after ps_work has already proceeded with its power-save operations

However, these risks are mitigated by:
- The change is intentional and authored by MediaTek engineers who maintain the driver
- The alternative (synchronous cancel) creates a known deadlock issue with 60% reproduction rate
- The workqueue subsystem provides inherent protection against most race conditions
- Similar patterns are used elsewhere in the kernel where work items need to coordinate

The impact is limited to:
- Systems with MediaTek MT792x series WiFi chipsets (mt7921, mt7925, etc.)
- Primarily affects high-load scenarios where both work items are queued simultaneously
- Does not affect other wireless drivers or systems without these chipsets

[Other Info]
Upstream submission: https://patchwork.kernel.org/project/linux-wireless/patch/20251215122231.3180648-1-leon.yen@mediatek.com/

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2137448

Title:
System doesn't response with mt76 call trace

Status in linux package in Ubuntu:
In Progress
Status in linux-oem-6.14 package in Ubuntu:
Invalid
Status in linux-oem-6.17 package in Ubuntu:
Invalid
Status in linux source package in Noble:
In Progress
Status in linux-oem-6.14 source package in Noble:
In Progress
Status in linux-oem-6.17 source package in Noble:
In Progress
Status in linux source package in Questing:
In Progress
Status in linux-oem-6.14 source package in Questing:
Invalid
Status in linux-oem-6.17 source package in Questing:
Invalid
Status in linux source package in Resolute:
In Progress
Status in linux-oem-6.14 source package in Resolute:
Invalid
Status in linux-oem-6.17 source package in Resolute:
Invalid

Bug description:
[Impact]
On Dell systems with MediaTek MT7925 WiFi cards (mt7925e driver), the system becomes unresponsive during firmware testing and high-load situations due to a deadlock in the mt76 driver. The system shows "workqueue hogging CPU" messages followed by system hang, preventing completion of certification testing.

The issue occurs because:
1. Two workqueue functions (ps_work and mac_work) attempt to cancel each other using cancel_delayed_work_sync()
2. In high-load situations, both works get queued but cannot execute until CPUs are available
3. When CPUs become available, both work functions may run simultaneously, each trying to synchronously cancel the other, resulting in a deadlock

The call path that creates the circular dependency is:
  mt792x_mac_work() -> ... -> cancel_delayed_work_sync(&pm->ps_work);
  mt792x_pm_power_save_work() -> cancel_delayed_work_sync(&mphy->mac_work);

[Fix]
Replace cancel_delayed_work_sync() with cancel_delayed_work() in the mt792x_pm_power_save_work() function to eliminate the deadlock condition.

Upstream commit (submitted to linux-wireless):
https://patchwork.kernel.org/project/linux-wireless/patch/20251215122231.3180648-1-leon.yen@mediatek.com/

The non-synchronous cancel is safe here because:
- The work cancellation is part of the power-save flow, not a critical cleanup path
- Avoiding synchronous wait prevents the circular dependency that causes the deadlock
- The code becomes simpler and easier to maintain

[Test Plan]
On a Dell system with MediaTek MT7925 WiFi (or similar affected platform):

1. Run the Checkbox certification test suite that triggers the issue:
   $ checkbox-cli run com.canonical.certification::client-cert-desktop-24-04-automated

2. Specifically execute the firmware test cases that previously triggered the deadlock:
   - firmware/fwts_desktop_diagnosis
   - firmware/fwts_wakealarm.*
   - firmware/fwts_uefirtvariable.*
   - miscellanea/oops

3. Monitor system logs for the previously observed symptoms:
   $ sudo dmesg -w

   Without the fix, you would see:
   - "Message 00020080 (seq N) timeout" from mt7925e
   - "workqueue: vmstat_update hogged CPU for >10000us" warnings
   - "workqueue: psi_avgs_work hogged CPU for >10000us" warnings
   - WARNING traces in iommu_dma_unmap_page
   - System becoming unresponsive

   With the fix, these symptoms should not occur and the system should
remain responsive.

4. Run extended stress testing with WiFi activity during high CPU load:
   $ stress-ng --cpu 128 --timeout 300s &
   $ ping -f <router_ip> # flood ping to generate WiFi traffic

   The system should remain stable without deadlocks.

5. Verify WiFi power management still functions correctly:
   $ iw dev <interface> get power_save
   $ # Enable/disable power save and verify WiFi connectivity remains stable
   $ sudo iw dev <interface> set power_save on
   $ ping -c 100 <router_ip>

[Where problems could occur]
This change affects the MediaTek MT792x WiFi driver's power management and workqueue interaction on systems with mt7925e and similar chipsets.

Potential issues if the non-synchronous cancel is not safe in this context:
- If there are assumptions in the code that mac_work must be fully stopped before proceeding, using non-synchronous cancel might allow mac_work to run concurrently with subsequent operations, potentially causing race conditions
- The mac_work might access hardware or data structures that ps_work assumes are quiescent after the cancel call, leading to unexpected behavior or crashes
- Power management state transitions might become inconsistent if mac_work completes after ps_work has already proceeded with its power-save operations

However, these risks are mitigated by:
- The change is intentional and authored by MediaTek engineers who maintain the driver
- The alternative (synchronous cancel) creates a known deadlock issue with 60% reproduction rate
- The workqueue subsystem provides inherent protection against most race conditions
- Similar patterns are used elsewhere in the kernel where work items need to coordinate

The impact is limited to:
- Systems with MediaTek MT792x series WiFi chipsets (mt7921, mt7925, etc.)
- Primarily affects high-load scenarios where both work items are queued simultaneously
- Does not affect other wireless drivers or systems without these chipsets

[Other Info]
Upstream submission: https://patchwork.kernel.org/project/linux-wireless/patch/20251215122231.3180648-1-leon.yen@mediatek.com/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2137448/+subscriptions

[Bug 2127044] Re: MT7925 wifi is hard blocked on HP's machine

The firmware leads to regression, so we need to carry the sauce patch to 6.17 kernel.
6.17-OEM - https://kernel.ubuntu.com/forgejo/kernel/noble-linux-oem/pulls/350
6.17-Q - https://lists.ubuntu.com/archives/kernel-team/2026-January/165070.html

** Changed in: linux-oem-6.17 (Ubuntu Noble)
Status: Fix Released => In Progress

** Changed in: linux-oem-6.17 (Ubuntu Noble)
Assignee: (unassigned) => AceLan Kao (acelankao)

** Also affects: linux-firmware (Ubuntu Questing)
Importance: Undecided
Status: New

** Also affects: linux-oem-6.14 (Ubuntu Questing)
Importance: Undecided
Status: New

** Also affects: linux-oem-6.17 (Ubuntu Questing)
Importance: Undecided
Status: New

** Changed in: linux-firmware (Ubuntu Questing)
Status: New => In Progress

** Changed in: linux-firmware (Ubuntu Questing)
Assignee: (unassigned) => AceLan Kao (acelankao)

** Changed in: linux-oem-6.17 (Ubuntu Questing)
Status: New => Invalid

** Changed in: linux-oem-6.14 (Ubuntu Questing)
Status: New => Invalid

** Changed in: linux-firmware (Ubuntu Noble)
Status: Fix Released => In Progress

** Changed in: linux-firmware (Ubuntu Noble)
Assignee: (unassigned) => AceLan Kao (acelankao)

** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New

** Changed in: linux (Ubuntu Noble)
Status: New => Invalid

** Changed in: linux (Ubuntu Questing)
Status: New => In Progress

** Changed in: linux (Ubuntu Questing)
Assignee: (unassigned) => AceLan Kao (acelankao)

** Changed in: linux (Ubuntu)
Status: New => Invalid

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2127044

Title:
MT7925 wifi is hard blocked on HP's machine

Status in HWE Next:
New
Status in linux package in Ubuntu:
Invalid
Status in linux-firmware package in Ubuntu:
Invalid
Status in linux-oem-6.14 package in Ubuntu:
Invalid
Status in linux-oem-6.17 package in Ubuntu:
Invalid
Status in linux source package in Noble:
Invalid
Status in linux-firmware source package in Noble:
In Progress
Status in linux-oem-6.14 source package in Noble:
Fix Released
Status in linux-oem-6.17 source package in Noble:
In Progress
Status in linux source package in Questing:
In Progress
Status in linux-firmware source package in Questing:
In Progress
Status in linux-oem-6.14 source package in Questing:
Invalid
Status in linux-oem-6.17 source package in Questing:
Invalid

Bug description:
[Impact]
The wifi is hard blocked and can't be used randomly.

[Fix]
The issue is introduced by commit 085749115fd37 ("wifi: mt76: mt7925: add rfkill_poll for hardware rfkill")
The machine doesn't support this feature may lead to undefined behavior, and MTK will submit a firmware to fix this issue in the near feature.

For short-term solution, we made a DMI quick to list the machines that
doesn't support this feature.

[Test]
1. Boot up HP Z2 Mini G1a Workstation
2. Run `rfkill list` to check wlan0 block state
3. Re-plug power cord and then check rfkill state again
4. The wlan0 should not be hard blocked.

[Where problems could occur]
Should be pretty safe to return the function call directly, since the machine doesn't support it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/2127044/+subscriptions

[Bug 2137438] [NEW] SteelSeries Rival 3 Wireless does not start after reboot

Public bug reported:

If I connect the SteelSeries Rival 3 Wireless USB receiver while the
computer is running, the mouse works, using the receiver (using the 2.4G
radio connection).

If I boot with the receiver installed, the mouse does not work. To work,
I have to remove and insert the receiver again. Soon as I insert the
receiver, it works.

Receiver:

Bus 003 Device 009: ID 1038:1830 SteelSeries ApS SteelSeries Rival 3
Wireless

ProblemType: Bug
DistroRelease: Ubuntu 25.04
Package: linux-image-6.14.0-37-generic 6.14.0-37.37
ProcVersionSignature: Ubuntu 6.14.0-37.37-generic 6.14.11
Uname: Linux 6.14.0-37-generic x86_64
ApportVersion: 2.32.0-0ubuntu5.3
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC1: jgr 3753 F.... wireplumber
/dev/snd/controlC0: jgr 3753 F.... wireplumber
/dev/snd/seq: jgr 3748 F.... pipewire
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Sun Jan 4 23:34:53 2026
InstallationDate: Installed on 2025-05-22 (227 days ago)
InstallationMedia: Ubuntu 25.04 "Plucky Puffin" - Release amd64 (20250415.3)
MachineType: LENOVO 83F5
ProcFB:
0 i915drmfb
1 nvidia-drmdrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.14.0-37-generic root=UUID=d2080f2c-985b-4356-960e-a76a474cea62 ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M vt.handoff=7
RelatedPackageVersions:
linux-restricted-modules-6.14.0-37-generic N/A
linux-backports-modules-6.14.0-37-generic N/A
linux-firmware 20250317.git1d4c88ee-0ubuntu1.11
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/07/2025
dmi.bios.release: 1.33
dmi.bios.vendor: LENOVO
dmi.bios.version: Q7CN33WW
dmi.board.asset.tag: NO Asset Tag
dmi.board.name: LNVNB161216
dmi.board.vendor: LENOVO
dmi.board.version: NO DPK
dmi.chassis.asset.tag: NO Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Legion Pro 7 16IAX10H
dmi.ec.firmware.release: 1.33
dmi.modalias: dmi:bvnLENOVO:bvrQ7CN33WW:bd04/07/2025:br1.33:efr1.33:svnLENOVO:pn83F5:pvrLegionPro716IAX10H:rvnLENOVO:rnLNVNB161216:rvrNODPK:cvnLENOVO:ct10:cvrLegionPro716IAX10H:skuLENOVO_MT_83F5_BU_idea_FM_LegionPro716IAX10H:
dmi.product.family: Legion Pro 7 16IAX10H
dmi.product.name: 83F5
dmi.product.sku: LENOVO_MT_83F5_BU_idea_FM_Legion Pro 7 16IAX10H
dmi.product.version: Legion Pro 7 16IAX10H
dmi.sys.vendor: LENOVO

** Affects: linux (Ubuntu)
Importance: Undecided
Status: New


** Tags: amd64 apport-bug plucky wayland-session

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2137438

Title:
SteelSeries Rival 3 Wireless does not start after reboot

Status in linux package in Ubuntu:
New

Bug description:
If I connect the SteelSeries Rival 3 Wireless USB receiver while the
computer is running, the mouse works, using the receiver (using the
2.4G radio connection).

If I boot with the receiver installed, the mouse does not work. To
work, I have to remove and insert the receiver again. Soon as I insert
the receiver, it works.

Receiver:

Bus 003 Device 009: ID 1038:1830 SteelSeries ApS SteelSeries Rival 3
Wireless

ProblemType: Bug
DistroRelease: Ubuntu 25.04
Package: linux-image-6.14.0-37-generic 6.14.0-37.37
ProcVersionSignature: Ubuntu 6.14.0-37.37-generic 6.14.11
Uname: Linux 6.14.0-37-generic x86_64
ApportVersion: 2.32.0-0ubuntu5.3
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC1: jgr 3753 F.... wireplumber
/dev/snd/controlC0: jgr 3753 F.... wireplumber
/dev/snd/seq: jgr 3748 F.... pipewire
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Sun Jan 4 23:34:53 2026
InstallationDate: Installed on 2025-05-22 (227 days ago)
InstallationMedia: Ubuntu 25.04 "Plucky Puffin" - Release amd64 (20250415.3)
MachineType: LENOVO 83F5
ProcFB:
0 i915drmfb
1 nvidia-drmdrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.14.0-37-generic root=UUID=d2080f2c-985b-4356-960e-a76a474cea62 ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M vt.handoff=7
RelatedPackageVersions:
linux-restricted-modules-6.14.0-37-generic N/A
linux-backports-modules-6.14.0-37-generic N/A
linux-firmware 20250317.git1d4c88ee-0ubuntu1.11
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/07/2025
dmi.bios.release: 1.33
dmi.bios.vendor: LENOVO
dmi.bios.version: Q7CN33WW
dmi.board.asset.tag: NO Asset Tag
dmi.board.name: LNVNB161216
dmi.board.vendor: LENOVO
dmi.board.version: NO DPK
dmi.chassis.asset.tag: NO Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Legion Pro 7 16IAX10H
dmi.ec.firmware.release: 1.33
dmi.modalias: dmi:bvnLENOVO:bvrQ7CN33WW:bd04/07/2025:br1.33:efr1.33:svnLENOVO:pn83F5:pvrLegionPro716IAX10H:rvnLENOVO:rnLNVNB161216:rvrNODPK:cvnLENOVO:ct10:cvrLegionPro716IAX10H:skuLENOVO_MT_83F5_BU_idea_FM_LegionPro716IAX10H:
dmi.product.family: Legion Pro 7 16IAX10H
dmi.product.name: 83F5
dmi.product.sku: LENOVO_MT_83F5_BU_idea_FM_Legion Pro 7 16IAX10H
dmi.product.version: Legion Pro 7 16IAX10H
dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2137438/+subscriptions

[Bug 2137423] Re: reboot=pci required for HP EliteBook Folio 9480m

** Tags added: kernel-daily-bug

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2137423

Title:
reboot=pci required for HP EliteBook Folio 9480m

Status in linux package in Ubuntu:
New

Bug description:
Without reboot=pci in the kernel command line, the laptop hangs on a
black screen after userspace shuts down. Using reboot=pci, it shuts
down as expected.

ProblemType: Bug
DistroRelease: Ubuntu 25.10
Package: linux-image-6.17.0-8-generic 6.17.0-8.8
ProcVersionSignature: Ubuntu 6.17.0-8.8-generic 6.17.2
Uname: Linux 6.17.0-8-generic x86_64
ApportVersion: 2.33.1-0ubuntu3
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: KDE
Date: Sun Jan 4 23:11:53 2026
InstallationDate: Installed on 2026-01-04 (0 days ago)
InstallationMedia: Kubuntu 25.10 "Questing Quokka" - Release amd64 (20251007)
MachineType: Hewlett-Packard HP EliteBook Folio 9480m
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.17.0-8-generic root=UUID=d9fd0c36-1019-4498-98d0-35b91ee2efb6 ro quiet splash reboot=pci vt.handoff=7
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
firmware-sof N/A
linux-firmware 20250901.git993ff19b-0ubuntu1.4
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/03/2014
dmi.bios.release: 1.1
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: M85 Ver. 01.01
dmi.board.name: 22DA
dmi.board.vendor: Hewlett-Packard
dmi.board.version: KBC Version 92.12
dmi.chassis.asset.tag: 5CG4413FC3
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.ec.firmware.release: 146.18
dmi.modalias: dmi:bvnHewlett-Packard:bvrM85Ver.01.01:bd07/03/2014:br1.1:efr146.18:svnHewlett-Packard:pnHPEliteBookFolio9480m:pvrA3009DD10303:rvnHewlett-Packard:rn22DA:rvrKBCVersion92.12:cvnHewlett-Packard:ct10:cvr:skuK6E34UC#ABA:
dmi.product.family: 103C_5336AN G=N L=BUS B=HP S=ELI
dmi.product.name: HP EliteBook Folio 9480m
dmi.product.sku: K6E34UC#ABA
dmi.product.version: A3009DD10303
dmi.sys.vendor: Hewlett-Packard

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2137423/+subscriptions

[Bug 2137434] Re: Suspend / resume failure on Kubuntu 24.04, NVME with OPAL encryption

** Tags added: kernel-daily-bug

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2137434

Title:
Suspend / resume failure on Kubuntu 24.04, NVME with OPAL encryption

Status in linux package in Ubuntu:
New

Bug description:
Suspend / resume failure on Kubuntu 24.04 with NVMe root filesystem
(Micron 3400) leading to NVMe I/O errors and EXT4 journal abort

System information

Machine: Lenovo IdeaPad 5 Pro 16ARH7

CPU platform: AMD (AMD-VI / IOMMU present)

Distribution: Kubuntu 24.04.3 LTS (Ubuntu 24.04 "noble")

Kernel (running):

6.14.0-37-generic


Kernel type: generic / HWE

Installed kernels:

linux-image-6.14.0-27-generic
linux-image-6.14.0-37-generic
linux-image-generic-hwe-24.04


Boot mode: UEFI

Dual boot: Yes (Windows + Linux)

Root filesystem: EXT4 on NVMe

Suspend mode: s2idle only

$ cat /sys/power/mem_sleep
[s2idle]


Hibernate: Not supported

systemctl hibernate
→ Sleep verb 'hibernate' is not configured or configuration is not supported by kernel Or i might have disabled something here in my attempts to fix the problem.

Storage device

NVMe controller: Micron 3400 NVMe SSD (Hendrix)

Firmware: 1006P7LN

PCI ID: 04:00.0

Kernel driver: nvme

Encryption configuration

NVMe drive encryption enabled via drive firmware (OPAL) / BIOS (pre-
boot authentication).

No Linux userspace encryption layer (e.g. no LUKS).

BIOS option disabling the password prompt was tested; behavior did not
change.

Problem description

When the system is suspended (s2idle) and later resumed:

The system does not recover cleanly.

The NVMe root filesystem becomes unavailable.

Kernel logs show NVMe, AMD-VI (IOMMU), and EXT4 errors.

The root filesystem is remounted read-only or the system becomes
unusable. (chat gpts working hypothesis eg no cd no ls in the console
window i still have open (if system wakes with gui) both commands (cd,
ls) just give io errors.)

A reboot (eg powercut) is required to recover. This is always the case
only how much is recovered when waking changes.

This occurs consistently when suspending from Linux.

The same hardware resumes successfully from suspend under Windows on
the same system.

Steps to reproduce

Boot Kubuntu normally.

Log in and allow the system to reach an idle state.

Trigger suspend (e.g. close lid or systemctl suspend).

Resume the system.

Expected result

System resumes normally.

NVMe device remains available.

Root filesystem remains writable.

No I/O or filesystem errors.

Actual result

Resume fails.

NVMe device reports errors.

EXT4 journal aborts.

Root filesystem remounts read-only or system becomes unusable.

Relevant kernel log excerpts (after failed resume)

Logs copied from a photographed console after resume failure;
formatting artifacts may be present.

USB / ACPI
ucsi_acpi USB0000:00: ucsi_handle_connector_change:
GET CONNECTOR STATUS failed (-110)

IOMMU (AMD-VI)
AMD-VI: Event logged [IO_PAGE_FAULT domain=0x0 address=0x71687000 flags=0x0000]
AMD-VI: Event logged [IO_PAGE_FAULT domain=0x0 address=0x716e7040 flags=0x0000]

NVMe
nvme 0000:04:00.0: Device not ready: aborting reset, CSTS=0x1

EXT4 filesystem (root device nvme0n1p5)
EXT4-fs error (device nvme0n1p5): ext4_find_entry: reading directory block
Buffer I/O error on device nvme0n1p5
Aborting journal on device nvme0n1p5
EXT4-fs error (device nvme0n1p5): Journal has aborted
EXT4-fs error (device nvme0n1p5): ext4_dirty_inode: Journal has aborted
EXT4-fs (nvme0n1p5): Remounting filesystem read-only
EXT4-fs (nvme0n1p5): I/O error while writing superblock


Multiple repeated buffer I/O errors follow for different logical blocks.

Additional observations

Disabling the pre-boot password prompt in BIOS does not change
behavior.

The system only supports s2idle; deeper sleep states are not
available.

Windows on the same hardware resumes from suspend successfully.


Reproducibility

Reproducible on every suspend/resume attempt under Linux.

Not observed under Windows on the same system.

Attachments / additional data available

Full nvme id-ctrl output

Full lspci -vv output for the NVMe device

/etc/default/grub

Additional kernel logs I hope I orderd the logs from most usefull to
most detailed as I can only attach a single file.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2137434/+subscriptions

[Bug 2137024] Re: Lenovo Legion 5 Pro (AMD Ryzen 7 8745HX + NVIDIA GeForce RTX 5060) wakes immediately from S3 suspend, wake IRQ 7 (`pinctrl_amd`), Ubuntu 25.10 kernel 6.17.0-8-generic

### Workaround found: ignore problematic ACPI GPIO interrupts (pins @2
and @4)

**Workaround:** Add a kernel boot parameter to ignore the specific ACPI
GPIO interrupts reported as problematic on this machine:

1. Edit GRUB config:
```bash
sudo nano /etc/default/grub

Add this to GRUB_CMDLINE_LINUX_DEFAULT (keep your existing quiet
splash etc.):

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash gpiolib_acpi.ignore_interrupt=AMDI0030:00@2,AMDI0030:00@4"
```
Apply + reboot:

```bash
sudo update-grub
sudo reboot
```

After adding
`gpiolib_acpi.ignore_interrupt=AMDI0030:00@2,AMDI0030:00@4`, the problem
stopped occurring for me (so far). If anyone else tests this, please
reply with your model, kernel version, and whether it fixes/changes
suspend+resume behaviour.

Note: this is a workaround. It would be great to identify why these GPIO
interrupts are being mis-handled on this platform so it can be fixed in
firmware/kernel rather than requiring a boot parameter.

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2137024

Title:
Lenovo Legion 5 Pro (AMD Ryzen 7 8745HX + NVIDIA GeForce RTX 5060)
wakes immediately from S3 suspend, wake IRQ 7 (`pinctrl_amd`), Ubuntu
25.10 kernel 6.17.0-8-generic

Status in linux package in Ubuntu:
New

Bug description:
# Lenovo Legion 5 Pro (AMD + NVIDIA) wakes immediately from S3
suspend, wake IRQ 7 (`pinctrl_amd`), Ubuntu 25.10 kernel
6.17.0-8-generic

On a Lenovo Legion 5 Pro (AMD + NVIDIA hybrid graphics) running Ubuntu
25.10 with kernel `6.17.0-8-generic`, suspend to RAM in "deep" (S3)
enters S3 but resumes immediately with no user input.

## System

- **Distro:** Ubuntu 25.10
- **Kernel:** `6.17.0-8-generic`
- **Machine:** Lenovo Legion 5 Pro 16ADR10
- **CPU:** AMD Ryzen 7 8745HX with Radeon Graphics
- **GPU:** NVIDIA GeForce RTX 5060
- **BIOS/EC:** `RLCN31WW`
- **Secure Boot:** DISABLED

## Problem

Using `systemctl suspend` with `mem_sleep=deep`:

- The system logs `PM: suspend entry (deep)` and `Preparing to enter system sleep state S3`.
- CPUs are taken offline and the ACPI EC is stopped as expected.
- Almost immediately, the kernel logs `ACPI: PM: Low-level resume complete` and the system resumes, without any user input (no keypress, no lid open, power button not pressed).

Representative `dmesg` snippet around suspend/resume:

```log
[ 1170.268659] PM: suspend entry (deep)
[ 1170.802727] ACPI: PM: Preparing to enter system sleep state S3
...
[ 1170.846860] smpboot: CPU 1 is now offline
[ 1170.848398] ACPI: PM: Low-level resume complete
[ 1170.848398] ACPI: EC: EC started
[ 1170.848398] ACPI: PM: Restoring platform NVS memory
...
[ 1170.866674] ACPI: PM: Waking up from system sleep state S3
...
[ 1172.282508] PM: suspend exit
```

So S3 is reached but a wake event fires immediately.

## Wake Source Data

After an instant‑wake, `/sys/power/pm_wakeup_irq` consistently
contains: `7` and `/proc/interrupts` shows:

```shell
$ grep "^ *7:" /proc/interrupts
7: <counts> 0 ... IR-IO-APIC 7-fasteoi pinctrl_amd
```

So the wake IRQ is 7, handled by `pinctrl_amd`

With `pm_trace` enabled for one suspend, the next boot shows in
`dmesg`:

```log
[ 0.516634] PM: Magic number: 5:610:555
[ 0.516661] clockevents clockevent6: hash matches
[ 0.516691] acpi PNP0C0F:06: hash matches
```

This suggests an ACPI/clockevent/GPIO‑style wake source rather than a
simple PCI/USB device.

## Wake Configuration

Before tuning, the following were wake‑enabled.

**`/proc/acpi/wakeup`:**

```shell
Device S-state Status Sysfs node
GPP0 S4 *enabled pci:0000:00:01.1
GPP1 S3 *enabled pci:0000:00:01.2
GPP3 S3 *enabled pci:0000:00:02.2
GPP4 S3 *disabled
GPP5 S3 *enabled pci:0000:00:03.3
GP17 S3 *enabled pci:0000:00:08.1
XHC0 S3 *enabled pci:0000:05:00.3
XHC1 S3 *enabled pci:0000:05:00.4
XHC2 S3 *enabled pci:0000:06:00.0
```

**Sysfs wake flags:**

```shell
$ grep enabled /sys/devices/**/power/wakeup

/sys/devices/LNXSYSTM:00/LNXPWRBN:00/power/wakeup:enabled
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2d/PNP0C09:00/PNP0C0A:00/power/wakeup:enabled
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/power/wakeup:enabled
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/power/wakeup:enabled
/sys/devices/pci0000:00/0000:00:01.1/power/wakeup:enabled
/sys/devices/pci0000:00/0000:00:01.2/power/wakeup:enabled
/sys/devices/pci0000:00/0000:00:02.2/power/wakeup:enabled
/sys/devices/pci0000:00/0000:00:03.3/power/wakeup:enabled
/sys/devices/pci0000:00/0000:00:08.1/0000:05:00.3/power/wakeup:enabled
/sys/devices/pci0000:00/0000:00:08.1/0000:05:00.4/power/wakeup:enabled
/sys/devices/pci0000:00/0000:00:08.1/0000:05:00.4/usb3/3-2/3-2.4/power/wakeup:enabled
/sys/devices/pci0000:00/0000:00:08.1/power/wakeup:enabled
/sys/devices/pci0000:00/0000:00:08.3/0000:06:00.0/power/wakeup:enabled
/sys/devices/platform/ACPI0003:00/power_supply/ADP0/power/wakeup:enabled
/sys/devices/platform/USBC000:00/power_supply/ucsi-source-psy-USBC000:001/power/wakeup:enabled
/sys/devices/platform/USBC000:00/power_supply/ucsi-source-psy-USBC000:002/power/wakeup:enabled
/sys/devices/platform/USBC000:00/power_supply/ucsi-source-psy-USBC000:003/power/wakeup:enabled
/sys/devices/pnp0/00:01/power/wakeup:enabled
/sys/devices/pnp0/00:01/rtc/rtc0/alarmtimer.0.auto/power/wakeup:enabled
```

## What Has Been Tried

1. ACPI wake toggles

Disabled the following entries in `/proc/acpi/wakeup` (toggled from
`*enabled` to `*disabled`):

- `GPP0`, `GPP1`, `GPP3`, `GPP5`, `GP17`
- `XHC0`, `XHC1`, `XHC2`

After each change and various combinations, `systemctl suspend` still
results in an instant wake, and `pm_wakeup_irq` remains `7`.

1. Sysfs `power/wakeup` toggles

Disabled wake on:

- PCIe bridges and devices under `pci0000:00`, including:
`0000:00:01.1`, `0000:00:01.2`, `0000:00:02.2`, `0000:00:03.3`, `0000:00:08.1`, `0000:05:00.3`, `0000:05:00.4`, `0000:06:00.0`.
- USB endpoints:
`/sys/devices/pci0000:00/0000:00:08.1/0000:05:00.4/usb3/3-2/3-2.2` and `/3-2.4`.
- Power‑supply / USB‑C power events:
`/sys/devices/platform/ACPI0003:00/power_supply/ADP0`,
`/sys/devices/platform/USBC000:00/power_supply/ucsi-source-psy-USBC000:00{1,2,3}`.

With all of these disabled (leaving effectively only the power button
and RTC as wake sources), the machine still wakes immediately from S3
and `pm_wakeup_irq` is still `7` (`pinctrl_amd`).

1. I2C-HID devices / AMD Serial IO

- I2C HID devices found: `ELAN06FA:00` and `IDEA5003:00`, at:
- `/sys/devices/platform/AMDI0010:00/i2c-0/i2c-ELAN06FA:00`
- `/sys/devices/platform/AMDI0010:03/i2c-2/i2c-IDEA5003:00`
- These nodes do **not** expose a `power/wakeup` attribute on this kernel. Attempts to disable wake via `/sys/class/wakeup/wakeup{45,46}/device{,/physical_node}/power/wakeup` fail because the `power/wakeup` file does not exist there (and cannot be created).
- The Lenovo AMD Serial IO (SIO) driver is a Windows‑only `.exe` and cannot be used on Linux to alter `pinctrl_amd` behaviour.

1. `amd_pmc` module

- Unloading and/or blacklisting `amd_pmc` has no effect on the
behaviour; suspend still instantly resumes with wake IRQ 7.

1. Different sleep types (`mem_sleep`)

- `mem_sleep=deep` (S3) exhibits the instant‑wake problem described.
- `mem_sleep=s2idle` was tested; behaviour is `<fill in: e.g. "works correctly / different issue / also wakes instantly">`.

1. Secure Boot / lockdown

- Secure Boot disabled in firmware and via `mokutil --disable-validation`.
- `/sys/kernel/security/lockdown` reports `[none] integrity confidentiality`, meaning lockdown mode is `none`.
- Missing/blocked `power/wakeup` writes are due to absent attributes, not lockdown restrictions.

## Expected vs Actual

- **Expected:** With wake sources limited (only power button and optionally lid/RTC), S3 `deep` suspend should keep the system asleep until an explicit wake event.
- **Actual:** Even with all obvious wake sources disabled, the system immediately resumes from S3; wake IRQ is consistently 7 (`pinctrl_amd`), and there is no user input.

## Request

This appears to be an issue in the AMD GPIO / `pinctrl_amd`
suspend/wake handling on this platform (a spurious or unmasked GPIO
interrupt causing immediate wake from S3).

Please:

- Confirm whether this is a known issue for this Legion 5 Pro / AMD platform on 6.17.
- Advise on any additional debug flags or patches to test (e.g. `pinctrl_amd` debug, ACPI/GPIO tracing, experimental patches).
- If appropriate, route this to the relevant AMD/platform maintainers.

I am happy to:

- Test proposed or mainline kernels,
- Try additional boot parameters,
- Capture further logs as requested on this machine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2137024/+subscriptions

[Bug 2137434] [NEW] Suspend / resume failure on Kubuntu 24.04, NVME with OPAL encryption

Public bug reported:

Suspend / resume failure on Kubuntu 24.04 with NVMe root filesystem
(Micron 3400) leading to NVMe I/O errors and EXT4 journal abort

System information

Machine: Lenovo IdeaPad 5 Pro 16ARH7

CPU platform: AMD (AMD-VI / IOMMU present)

Distribution: Kubuntu 24.04.3 LTS (Ubuntu 24.04 "noble")

Kernel (running):

6.14.0-37-generic


Kernel type: generic / HWE

Installed kernels:

linux-image-6.14.0-27-generic
linux-image-6.14.0-37-generic
linux-image-generic-hwe-24.04


Boot mode: UEFI

Dual boot: Yes (Windows + Linux)

Root filesystem: EXT4 on NVMe

Suspend mode: s2idle only

$ cat /sys/power/mem_sleep
[s2idle]


Hibernate: Not supported

systemctl hibernate
→ Sleep verb 'hibernate' is not configured or configuration is not supported by kernel Or i might have disabled something here in my attempts to fix the problem.

Storage device

NVMe controller: Micron 3400 NVMe SSD (Hendrix)

Firmware: 1006P7LN

PCI ID: 04:00.0

Kernel driver: nvme

Encryption configuration

NVMe drive encryption enabled via drive firmware (OPAL) / BIOS (pre-boot
authentication).

No Linux userspace encryption layer (e.g. no LUKS).

BIOS option disabling the password prompt was tested; behavior did not
change.

Problem description

When the system is suspended (s2idle) and later resumed:

The system does not recover cleanly.

The NVMe root filesystem becomes unavailable.

Kernel logs show NVMe, AMD-VI (IOMMU), and EXT4 errors.

The root filesystem is remounted read-only or the system becomes
unusable. (chat gpts working hypothesis eg no cd no ls in the console
window i still have open (if system wakes with gui) both commands (cd,
ls) just give io errors.)

A reboot (eg powercut) is required to recover. This is always the case
only how much is recovered when waking changes.

This occurs consistently when suspending from Linux.

The same hardware resumes successfully from suspend under Windows on the
same system.

Steps to reproduce

Boot Kubuntu normally.

Log in and allow the system to reach an idle state.

Trigger suspend (e.g. close lid or systemctl suspend).

Resume the system.

Expected result

System resumes normally.

NVMe device remains available.

Root filesystem remains writable.

No I/O or filesystem errors.

Actual result

Resume fails.

NVMe device reports errors.

EXT4 journal aborts.

Root filesystem remounts read-only or system becomes unusable.

Relevant kernel log excerpts (after failed resume)

Logs copied from a photographed console after resume failure; formatting
artifacts may be present.

USB / ACPI
ucsi_acpi USB0000:00: ucsi_handle_connector_change:
GET CONNECTOR STATUS failed (-110)

IOMMU (AMD-VI)
AMD-VI: Event logged [IO_PAGE_FAULT domain=0x0 address=0x71687000 flags=0x0000]
AMD-VI: Event logged [IO_PAGE_FAULT domain=0x0 address=0x716e7040 flags=0x0000]

NVMe
nvme 0000:04:00.0: Device not ready: aborting reset, CSTS=0x1

EXT4 filesystem (root device nvme0n1p5)
EXT4-fs error (device nvme0n1p5): ext4_find_entry: reading directory block
Buffer I/O error on device nvme0n1p5
Aborting journal on device nvme0n1p5
EXT4-fs error (device nvme0n1p5): Journal has aborted
EXT4-fs error (device nvme0n1p5): ext4_dirty_inode: Journal has aborted
EXT4-fs (nvme0n1p5): Remounting filesystem read-only
EXT4-fs (nvme0n1p5): I/O error while writing superblock


Multiple repeated buffer I/O errors follow for different logical blocks.

Additional observations

Disabling the pre-boot password prompt in BIOS does not change behavior.

The system only supports s2idle; deeper sleep states are not available.

Windows on the same hardware resumes from suspend successfully.


Reproducibility

Reproducible on every suspend/resume attempt under Linux.

Not observed under Windows on the same system.

Attachments / additional data available

Full nvme id-ctrl output

Full lspci -vv output for the NVMe device

/etc/default/grub

Additional kernel logs I hope I orderd the logs from most usefull to
most detailed as I can only attach a single file.

** Affects: linux (Ubuntu)
Importance: Undecided
Status: New


** Tags: suspend-resume

** Attachment added: "All kinds of logs I collected including a OCRd foto of the screen of the brokenly waked system"
https://bugs.launchpad.net/bugs/2137434/+attachment/5937324/+files/LogCollectionAndMore

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2137434

Title:
Suspend / resume failure on Kubuntu 24.04, NVME with OPAL encryption

Status in linux package in Ubuntu:
New

Bug description:
Suspend / resume failure on Kubuntu 24.04 with NVMe root filesystem
(Micron 3400) leading to NVMe I/O errors and EXT4 journal abort

System information

Machine: Lenovo IdeaPad 5 Pro 16ARH7

CPU platform: AMD (AMD-VI / IOMMU present)

Distribution: Kubuntu 24.04.3 LTS (Ubuntu 24.04 "noble")

Kernel (running):

6.14.0-37-generic


Kernel type: generic / HWE

Installed kernels:

linux-image-6.14.0-27-generic
linux-image-6.14.0-37-generic
linux-image-generic-hwe-24.04


Boot mode: UEFI

Dual boot: Yes (Windows + Linux)

Root filesystem: EXT4 on NVMe

Suspend mode: s2idle only

$ cat /sys/power/mem_sleep
[s2idle]


Hibernate: Not supported

systemctl hibernate
→ Sleep verb 'hibernate' is not configured or configuration is not supported by kernel Or i might have disabled something here in my attempts to fix the problem.

Storage device

NVMe controller: Micron 3400 NVMe SSD (Hendrix)

Firmware: 1006P7LN

PCI ID: 04:00.0

Kernel driver: nvme

Encryption configuration

NVMe drive encryption enabled via drive firmware (OPAL) / BIOS (pre-
boot authentication).

No Linux userspace encryption layer (e.g. no LUKS).

BIOS option disabling the password prompt was tested; behavior did not
change.

Problem description

When the system is suspended (s2idle) and later resumed:

The system does not recover cleanly.

The NVMe root filesystem becomes unavailable.

Kernel logs show NVMe, AMD-VI (IOMMU), and EXT4 errors.

The root filesystem is remounted read-only or the system becomes
unusable. (chat gpts working hypothesis eg no cd no ls in the console
window i still have open (if system wakes with gui) both commands (cd,
ls) just give io errors.)

A reboot (eg powercut) is required to recover. This is always the case
only how much is recovered when waking changes.

This occurs consistently when suspending from Linux.

The same hardware resumes successfully from suspend under Windows on
the same system.

Steps to reproduce

Boot Kubuntu normally.

Log in and allow the system to reach an idle state.

Trigger suspend (e.g. close lid or systemctl suspend).

Resume the system.

Expected result

System resumes normally.

NVMe device remains available.

Root filesystem remains writable.

No I/O or filesystem errors.

Actual result

Resume fails.

NVMe device reports errors.

EXT4 journal aborts.

Root filesystem remounts read-only or system becomes unusable.

Relevant kernel log excerpts (after failed resume)

Logs copied from a photographed console after resume failure;
formatting artifacts may be present.

USB / ACPI
ucsi_acpi USB0000:00: ucsi_handle_connector_change:
GET CONNECTOR STATUS failed (-110)

IOMMU (AMD-VI)
AMD-VI: Event logged [IO_PAGE_FAULT domain=0x0 address=0x71687000 flags=0x0000]
AMD-VI: Event logged [IO_PAGE_FAULT domain=0x0 address=0x716e7040 flags=0x0000]

NVMe
nvme 0000:04:00.0: Device not ready: aborting reset, CSTS=0x1

EXT4 filesystem (root device nvme0n1p5)
EXT4-fs error (device nvme0n1p5): ext4_find_entry: reading directory block
Buffer I/O error on device nvme0n1p5
Aborting journal on device nvme0n1p5
EXT4-fs error (device nvme0n1p5): Journal has aborted
EXT4-fs error (device nvme0n1p5): ext4_dirty_inode: Journal has aborted
EXT4-fs (nvme0n1p5): Remounting filesystem read-only
EXT4-fs (nvme0n1p5): I/O error while writing superblock


Multiple repeated buffer I/O errors follow for different logical blocks.

Additional observations

Disabling the pre-boot password prompt in BIOS does not change
behavior.

The system only supports s2idle; deeper sleep states are not
available.

Windows on the same hardware resumes from suspend successfully.


Reproducibility

Reproducible on every suspend/resume attempt under Linux.

Not observed under Windows on the same system.

Attachments / additional data available

Full nvme id-ctrl output

Full lspci -vv output for the NVMe device

/etc/default/grub

Additional kernel logs I hope I orderd the logs from most usefull to
most detailed as I can only attach a single file.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2137434/+subscriptions

[Bug 1635851] Re: When browsing Google Map's Satellite view in Chrome or Firefox the screen freezes and goes black, occasionally control is returned to user

@juergh this can be closed. I have not reproduced this for many years.

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/1635851

Title:
When browsing Google Map's Satellite view in Chrome or Firefox the
screen freezes and goes black, occasionally control is returned to
user

Status in linux package in Ubuntu:
Confirmed

Bug description:
Affects Ubuntu 14.04.1, resolved 16.10

When viewing the satellite view in Google Maps with Google Chrome or
Firefox the screen will become unresponsive and then go black. This
occurs on other websites too but this is the most reproducible.
Occasionally the screen returns and control is given back to the user,
but often only the mouse works and desktop elements will not move
around the screen when clicked and dragged.

I have a Radeon 390x graphics card, a MSI Z97 Gaming 5 Motherboard and
am running Kubuntu 16.04.1 LTS. This is a dual boot device with
Windows 10 and have not seen any hardware issues in the Event Viewer.
I filed this log here as the file that appeared in the dmesg log is
part of the linux project
"/build/linux-R0TiM8/linux-4.4.0/drivers/gpu/drm/radeon/radeon_object.c".

This is resolved when upgrading to Ubuntu 16.10 (uses kernel 4.8), so
perhaps the commit that resolves this is not backported to Ubuntu's
16.04.1's 4.4 kernel.

Bug I also filed on kernel.org's Bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=177041

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1635851/+subscriptions

[Bug 2137423] [NEW] reboot=pci required for HP EliteBook Folio 9480m

Public bug reported:

Without reboot=pci in the kernel command line, the laptop hangs on a
black screen after userspace shuts down. Using reboot=pci, it shuts down
as expected.

ProblemType: Bug
DistroRelease: Ubuntu 25.10
Package: linux-image-6.17.0-8-generic 6.17.0-8.8
ProcVersionSignature: Ubuntu 6.17.0-8.8-generic 6.17.2
Uname: Linux 6.17.0-8-generic x86_64
ApportVersion: 2.33.1-0ubuntu3
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: KDE
Date: Sun Jan 4 23:11:53 2026
InstallationDate: Installed on 2026-01-04 (0 days ago)
InstallationMedia: Kubuntu 25.10 "Questing Quokka" - Release amd64 (20251007)
MachineType: Hewlett-Packard HP EliteBook Folio 9480m
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.17.0-8-generic root=UUID=d9fd0c36-1019-4498-98d0-35b91ee2efb6 ro quiet splash reboot=pci vt.handoff=7
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
firmware-sof N/A
linux-firmware 20250901.git993ff19b-0ubuntu1.4
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/03/2014
dmi.bios.release: 1.1
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: M85 Ver. 01.01
dmi.board.name: 22DA
dmi.board.vendor: Hewlett-Packard
dmi.board.version: KBC Version 92.12
dmi.chassis.asset.tag: 5CG4413FC3
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.ec.firmware.release: 146.18
dmi.modalias: dmi:bvnHewlett-Packard:bvrM85Ver.01.01:bd07/03/2014:br1.1:efr146.18:svnHewlett-Packard:pnHPEliteBookFolio9480m:pvrA3009DD10303:rvnHewlett-Packard:rn22DA:rvrKBCVersion92.12:cvnHewlett-Packard:ct10:cvr:skuK6E34UC#ABA:
dmi.product.family: 103C_5336AN G=N L=BUS B=HP S=ELI
dmi.product.name: HP EliteBook Folio 9480m
dmi.product.sku: K6E34UC#ABA
dmi.product.version: A3009DD10303
dmi.sys.vendor: Hewlett-Packard

** Affects: linux (Ubuntu)
Importance: Undecided
Status: New


** Tags: amd64 apport-bug questing wayland-session

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2137423

Title:
reboot=pci required for HP EliteBook Folio 9480m

Status in linux package in Ubuntu:
New

Bug description:
Without reboot=pci in the kernel command line, the laptop hangs on a
black screen after userspace shuts down. Using reboot=pci, it shuts
down as expected.

ProblemType: Bug
DistroRelease: Ubuntu 25.10
Package: linux-image-6.17.0-8-generic 6.17.0-8.8
ProcVersionSignature: Ubuntu 6.17.0-8.8-generic 6.17.2
Uname: Linux 6.17.0-8-generic x86_64
ApportVersion: 2.33.1-0ubuntu3
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: KDE
Date: Sun Jan 4 23:11:53 2026
InstallationDate: Installed on 2026-01-04 (0 days ago)
InstallationMedia: Kubuntu 25.10 "Questing Quokka" - Release amd64 (20251007)
MachineType: Hewlett-Packard HP EliteBook Folio 9480m
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.17.0-8-generic root=UUID=d9fd0c36-1019-4498-98d0-35b91ee2efb6 ro quiet splash reboot=pci vt.handoff=7
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
firmware-sof N/A
linux-firmware 20250901.git993ff19b-0ubuntu1.4
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/03/2014
dmi.bios.release: 1.1
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: M85 Ver. 01.01
dmi.board.name: 22DA
dmi.board.vendor: Hewlett-Packard
dmi.board.version: KBC Version 92.12
dmi.chassis.asset.tag: 5CG4413FC3
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.ec.firmware.release: 146.18
dmi.modalias: dmi:bvnHewlett-Packard:bvrM85Ver.01.01:bd07/03/2014:br1.1:efr146.18:svnHewlett-Packard:pnHPEliteBookFolio9480m:pvrA3009DD10303:rvnHewlett-Packard:rn22DA:rvrKBCVersion92.12:cvnHewlett-Packard:ct10:cvr:skuK6E34UC#ABA:
dmi.product.family: 103C_5336AN G=N L=BUS B=HP S=ELI
dmi.product.name: HP EliteBook Folio 9480m
dmi.product.sku: K6E34UC#ABA
dmi.product.version: A3009DD10303
dmi.sys.vendor: Hewlett-Packard

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2137423/+subscriptions

[Bug 2012830] Re: Audio speed up on HDMI, with 4K resolution and refresh rate 60Hz

[Expired for linux (Ubuntu) because there has been no activity for 60
days.]

** Changed in: linux (Ubuntu)
Status: Incomplete => Expired

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2012830

Title:
Audio speed up on HDMI, with 4K resolution and refresh rate 60Hz

Status in linux package in Ubuntu:
Expired

Bug description:
lsb_release -rd
Description: Ubuntu 22.10
Release: 22.10

Wayland

5.19.9000-37-generic

(please refer to bug-report
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2009136. My
installed SW is the result of the fixed Problem by Koba, No HDMI audio
if e.g. RX560 will be used, since 5.19.0-35)

The audio speed up does mean, that the audio will be played with
"speed=2x" (or something like that)

5.19.9000-37-generic, 3840x2180, refresh rate 60Hz, audio speed up issue
5.19.9000-37-generic, 1920x1080, refresh rate 60Hz, no audio speed up issue
5.19.9000-37-generic, 3840x2180, refresh rate 30Hz, no audio speed up issue


But I did test it on different releases :
5.19.0-21-generic, 3840x2180, refresh rate 60Hz, audio speed up issue
5.19.0-21-generic, 1920x1080, refresh rate 60Hz, no audio speed up issue
5.19.0-21-generic, 3840x2180, refresh rate 30Hz, no audio speed up issue

5.19.0-32-generic, 3840x2180, refresh rate 60Hz, audio speed up issue
5.19.0-32-generic, 1920x1080, refresh rate 60Hz, no audio speed up issue
5.19.0-32-generic, 3840x2180, refresh rate 30Hz, no audio speed up issue

01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Baffin HDMI/DP Audio [Radeon RX 550 640SP / RX 560/560X] [1002:aae0]
Subsystem: ASUSTeK Computer Inc. Baffin HDMI/DP Audio [Radeon RX 550 640SP / RX 560/560X] [1043:aae0]
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

For more detailed information about my system (please refer to bug-
report : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2009815

("Ubuntu-bug linux" didn't work with the following message : "The
problem can not be reported : This report is about a package that is
not installed)

What I expect :
Normal understandable audio if Resolution=3840x2180 and refresh rate=60Hz,
What happened instead :
Audio speed up, it sounds like chirps.
---
ProblemType: Bug
ApportVersion: 2.23.1-0ubuntu3
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC0: richard 1516 F.... wireplumber
/dev/snd/controlC1: richard 1516 F.... wireplumber
/dev/snd/seq: richard 1513 F.... pipewire
CRDA: N/A
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
DistroRelease: Ubuntu 22.10
InstallationDate: Installed on 2023-03-04 (22 days ago)
InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Release amd64 (20221020)
IwConfig:
lo no wireless extensions.

enp3s0 no wireless extensions.
MachineType: System manufacturer System Product Name
Package: linux (not installed)
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=de_DE.UTF-8
SHELL=/bin/bash
ProcFB: 0 amdgpudrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.19.9000-37-generic root=UUID=df59b1c2-c5b9-483d-b033-7c6b2264dc75 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 5.19.9000-37.38~22.04.1-generic 5.19.17
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
linux-restricted-modules-5.19.9000-37-generic N/A
linux-backports-modules-5.19.9000-37-generic N/A
linux-firmware 20220923.gitf09bebf3-0ubuntu1.4
RfKill:

Tags: wayland-session kinetic
Uname: Linux 5.19.9000-37-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 09/18/2013
dmi.bios.release: 4.6
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 4802
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: P8H61-M PRO
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev x.0x
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4802:bd09/18/2013:br4.6:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnP8H61-MPRO:rvrRevx.0x:cvnChassisManufacture:ct3:cvrChassisVersion:skuSKU:
dmi.product.family: To be filled by O.E.M.
dmi.product.name: System Product Name
dmi.product.sku: SKU
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2012830/+subscriptions