Hello, I was using kernel 6.19.3-1 and installed 6.19.5-1, later 6.19.5-2.
Power usage has been considerably and consistently higher when booted into either of the two. I have often been experiencing firmware crashes when booting, preventing the use of Wi-Fi. This, however, has also occurred in a 6.19.3-1 snapshot. More recently, I too have been encountering the same xdg-desktop-portal crashing error as others.
I still have 6.19.3-1 in /boot/efi, but it no longer appears in the boot menu (GRUB).
Thanks in advance for any help.
@GeckoGeek Seems to be affecting a few Desktop Environments (all good here on GNOME, no crashes).
It will get rolled back in the next snapshot, see https://forums.opensuse.org/t/xdg-desktop-portal-crashing-on-latest-tumbleweed-snapshot-20260306/192332
1 Like
I can confirm the high energy consumption om AMD CPU (Thinkpad t14 - AMD Ryzen 7 PRO 8840U w/ Radeon 780M Graphics).
No firmware crash on my Thinkpad and with rollback to xdg-desktop-portal-1.20.3 (no more xdg errors).
The AMD-CPU dont use the lower C-States when idle (with kernel 6.19.5). My old Laptop with intel-CPU has no problems with 6.19.5 and C-States.
With the 6.19.5 consumes the Laptop 5.13 Watts (IDLE Desktop) instead of 2.72 Watts with kernel 6.19.3 (measured with powerstat). Powertop also recognizes no C-States at all with 6.19.5 in contrast to 6.19.3.
High power conumptions also on suspend2ram (s2idle). On LID close consumes 470 mW with kernel 6.19.3 and 4443 mW with kernel 6.19.5.
The only difference I have found so far is an inconspicuous message in dmesg:
6.19.3 reports: “Monitor-Mwait will be used to enter C-1 state”
but no such report with kernel 6.19.5
The CPU issue was introduced by commit 0089ce1c056a (“ACPI: processor: Update cpuidle driver check in __acpi_processor_start()”), which has been reverted in kernel 6.19.6 (e.g. from https://build.opensuse.org/project/show/Kernel:stable):
commit a88cbd6cc28aca28695292f652cfcc19edfab510
Author: Sasha Levin sashal@kernel.org
Date: Sat Feb 28 10:35:45 2026 -0500
Revert "ACPI: processor: Update cpuidle driver check in __acpi_processor_start()"
This reverts commit 0089ce1c056aee547115bdc25c223f8f88c08498 which is
upstream commit 6cfed39c2ce64ac024bbde458a9727105e0b8c66.
This commit is causing a suspend regression on systems such as the Asus
Zephyrus G14 (GA402RJ) with Ryzen 7 6700H: when suspending, the display
turns off but the device fails to fully power down. This is not seen
with v7.0-rc1 which indicates that there are changes missing. Therefore,
revert this change.
2 Likes
JFYI: kernel 6.19.6 is part of TW20260308
@fkrueger You’re really good
I can confirm that TW20260308 with kernel 6.19.6 works fine.
The power consumption on thinkpad (Ryzen 7 8840U) is normal again.
ACPI C-States are regulary in use (power consumption in IDLE back to normal)
Power consumption has certainly been better overall compared to 6.19.5. The rate is very low when asleep, as it should be. When awake, it is generally decent, but there have been a few jumps on my end (not to say earlier versions never spiked either). Measured with powertop, the idle rate generally appears to be on par with 6.19.3, but there was an instance when it suddenly jumped from 4.10 W to 9.30. Once, it went to around ~6.5 W after waking, then over 7, before declining. I will continue monitoring it.
My hardware is a ThinkPad P14s Gen 5 AMD, 8840HS with Radeon 780M Graphics.
Regarding the firmware crashes, I had one upon first booting the system today, keeping me from updating until later. It does not occur on the other distribution I have installed. Upon booting back into Tumbleweed numerous hours later, it was fine, so I updated. I rebooted to test the new kernel, and of course the firmware crashed again. This remained true with other boot options. Tried quickly switching between operating systems again, and Tumbleweed remained down. Tried again a moderate amount of time later, and it is working again.
Here is an output of sudo dmesg -T | grep -i ath11k | tail n -30 during a crash:
[Mon Mar 9 12:01:03 2026] [ T1112] ath11k_pci 0000:02:00.0: BAR 0 [mem 0x90600000-0x907fffff 64bit]: assigned
[Mon Mar 9 12:01:03 2026] [ T1112] ath11k_pci 0000:02:00.0: enabling device (0000 -> 0002)
[Mon Mar 9 12:01:03 2026] [ T1112] ath11k_pci 0000:02:00.0: MSI vectors: 32
[Mon Mar 9 12:01:03 2026] [ T1112] ath11k_pci 0000:02:00.0: wcn6855 hw2.1
[Mon Mar 9 12:01:04 2026] [ T1676] ath11k_pci 0000:02:00.0: chip_id 0x12 chip_family 0xb board_id 0xff soc_id 0x400c1211
[Mon Mar 9 12:01:04 2026] [ T1676] ath11k_pci 0000:02:00.0: fw_version 0x11088c35 fw_build_timestamp 2024-04-17 08:34 fw_build_id WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41
[Mon Mar 9 12:01:04 2026] [ T1484] ath11k_pci 0000:02:00.0: firmware crashed: MHI_CB_EE_RDDM
[Mon Mar 9 12:01:04 2026] [ T1675] ath11k_pci 0000:02:00.0: ignore reset dev flags 0x8000
[Mon Mar 9 12:01:14 2026] [ T1676] ath11k_pci 0000:02:00.0: failed to wait wlan mode request (mode 0): -110
[Mon Mar 9 12:01:14 2026] [ T1676] ath11k_pci 0000:02:00.0: qmi failed to send wlan fw mode: -110
[Mon Mar 9 12:01:14 2026] [ T1676] ath11k_pci 0000:02:00.0: failed to send firmware start: -110
[Mon Mar 9 12:01:14 2026] [ T1676] ath11k_pci 0000:02:00.0: failed to start firmware: -110
Power consumption seems to be normal. It seems that the firmware crashes occur if the system is plugged in while booting. It never seems to occur after it has already booted.
I do not yet know if ath11k crashes are an issue with this distribution, or later kernel versions. While a workaround has been found, I am not sure if I should mark the discussion as solved, since it is probably a bug that needs to be fixed.