https://bugzilla.suse.com/show_bug.cgi?id=1203748 https://bugzilla.suse.com/show_bug.cgi?id=1203748#c3 --- Comment #3 from Stefan Dirsch --- Yes, I'm using XFCE. thermald is installed but apparently not running (doesn't occur in 'ps' output) upowerd is indeed running /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor is set to 'powersave', not matter if the laptop runs powered or on battery.

About the cpufreq, Arch has a nice web page: https://wiki.archlinux.org/title/CPU_frequency_scaling

Thanks! -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1203748 https://bugzilla.suse.com/show_bug.cgi?id=1203748#c6 --- Comment #6 from Takashi Iwai --- Try to disable intel_idle by passing intel_idle.max_cstate=0 boot option. This should avoid the deep state. If it works, something doesn't work as expected in the intel_idle. You can try to compare the behavior of SLE15-SP4 kernel and the recent upstream kernel from OBS Kernel:stable:Backport. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1203748 Michal Suchanek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |giovanni.gherdovich@suse.co | |m, msuchanek@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1203748 https://bugzilla.suse.com/show_bug.cgi?id=1203748#c17 --- Comment #17 from Takashi Iwai --- Interesting. Giovanni, any clue about the behavior? Also, Stefan, please give the hardware details of your machine (e.g. hwinfo). -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1203748 Frank Kr�ger changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fkrueger@mailbox.org | -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1203748 https://bugzilla.suse.com/show_bug.cgi?id=1203748#c21 Giovanni Gherdovich changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(sndirsch@suse.com | |) --- Comment #21 from Giovanni Gherdovich --- Hello Stefan, I'd like two pieces of information: (1) Boot with dynamic debugging enabled on cpufreq drivers (intel_pstate in fact) adding this to the kernel command line: dyndbg="file drivers/cpufreq/* +pf" Then try to trigger both the good behavior (fast laptop, AC power) and bad behavior (slow laptop, on battery) and attach the kernel logs here. (2) install the tool "turbostat" from the package "cpupower" if you don't have it already, and run the following command twice, i.e. --> when the laptop is on AC power (not battery) and is running well --> when the laptop is on battery and is running slow command: turbostat --interval 1 --num_iterations 10 2>&1 | tee turbostat.$(date +%F.%H-%M-%S).txt Then attach the resulting turbostat.XXX.txt files here. This will collect 10 samples, one sample per second, of frequency and power activity. Actually more importantly it will collect all power management settings from various MSR in the header of the output. I want to examine and compare the MSR values during the good and bad behavior. This is the reasoning: What I think is happening is that when you disconnect the AC power, then the firmware sends an ACPI message to the driver that limits the speed of the processor; this could happen via the ACPI _PPC object (Performance Present Capabilites). That's essentially a table of values that the driver uses to update min and max clock frequencies. It wouldn't make much sense for the firmware to limit the driver at 400 MHz when on battery, but lets see what the kernel log says with dynamic debugging enabled, and the power management config shown by turbostat. Your i7-7600U CPU is a Kaby Lake from 2017, which has autonomous frequency scaling (the feature is called HWP, or Intel Speed Shift). The governor and driver don't do much, other than setting some value at boot in an MSR and letting it do its thing. That's why I think it's reacting to an ACPI event, and the data contained in the ACPI object isn't very good. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1203748 https://bugzilla.suse.com/show_bug.cgi?id=1203748#c23 --- Comment #23 from Takashi Iwai --- (In reply to Stefan Dirsch from comment #22)

Thanks for looking into this. I definitely wrote

dyndbg="file drivers/cpufreq/* +pf"

in grub during boot. Unfortunately this results in

# cat /proc/cmdline BOOT_IMAGE=/vmlinuz-6.0.0-lp153.3.g1195759-default root=/dev/mapper/system-root resume=/dev/system/swap splash=silent quiet showopts intel_idle.max_cstate=0 "dyndbg=file drivers/cpufreq/* +pf"

So the following results might be completely useless. :-(

This should be fine, it's just how the kernel handles. Check the dmesg output -- now you must have more lines about cpufreq there. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1203748 https://bugzilla.suse.com/show_bug.cgi?id=1203748#c25 --- Comment #25 from Stefan Dirsch --- Created attachment 863066 --> https://bugzilla.suse.com/attachment.cgi?id=863066&action=edit dmesg-bad-battery.log dmesg - After switching to battery - in a bad/slow state (unfortunately no relevant difference in dmesg to good state) -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1203748 https://bugzilla.suse.com/show_bug.cgi?id=1203748#c26 --- Comment #26 from Stefan Dirsch --- Created attachment 863067 --> https://bugzilla.suse.com/attachment.cgi?id=863067&action=edit turbostat-good-ac.2022-11-23.15-52-25.txt turbostat in good state -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1203748 https://bugzilla.suse.com/show_bug.cgi?id=1203748#c28 --- Comment #28 from Stefan Dirsch --- (In reply to Stefan Dirsch from comment #25)

Created attachment 863066 [details] dmesg-bad-battery.log

dmesg - After switching to battery - in a bad/slow state (unfortunately no relevant difference in dmesg to good state)

Maybe I was wrong. There is at least this -[ 2200.120064] perf: interrupt took too long (2540 > 2500), lowering kernel.perf_event_max_sample_rate to 78500 -[ 2307.480111] perf: interrupt took too long (3242 > 3175), lowering kernel.perf_event_max_sample_rate to 61500 Maybe that's related. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1203748 https://bugzilla.suse.com/show_bug.cgi?id=1203748#c30 --- Comment #30 from Giovanni Gherdovich --- Hi Stefan, question: did this laptop ever work well (wrt this problem)? Initially I was thinking the problem could be a kernel update but I'm trying to validate that assumption. If it used to work in the past, do you recall any hardware or software update that happened before it broke? From your dmesg and turbostat attachments the problem looks both serious and difficult to solve. I've found this thread from 2017 in the Lenovo forum that seems to describe exactly your symptoms: "T470 Heavy CPU Throttling on Battery" https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T/T470-Heavy-CPU-T... For posterity I'll copy-paste both the question and the alleged solution from that thread (update the BIOS to at least version 1.42, currently the latest is 1.72) ;; Hi, ;; ;; My CPU has been throttling down to 400 MHz when on battery. This does not ;; necessarily happen on low battery - it sometimes happens when I have over ;; 50% battery life left (albeit the removable battery is low), and sometimes ;; when i have less than 25% battery life left. ;; ;; My temperatures appear to be good (according to Core Temp), usually around ;; 40-50C. ;; ;; Has anyone encountered this problem before? All of my drivers are up to ;; date according to Lenovo companion, and I have placed power settings in ;; windows to High Performance, and changed the Intel Speedstep settings in ;; the BIOS to max performance as well. ;; Dear all, ;; ;; ThinkPad T470 development team identified the root cause and released the ;; fix as the latest BIOS Update package at the Lenovo web site; ;; ;; https://pcsupport.lenovo.com/us/en/products/Laptops-and-netbooks/ThinkPad-T-... ;; ;; UEFI: 1.42 / ECP: 1.27 ;; ;; (New) Support interface of TPM firmware update. ;; (New) Updated the Diagnostics module to version 03.11.001. ;; (New) Updated the CPU microcode. ;; (Fix) Fixed an issue where CPU clock stays low with FRU P/N 01AV452 battery. The forum mentions the external battery, part number 01AV452, which I can see in your hwinfo output: P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:18/PNP0C09:00/PNP0C0A:01/power_supply/BAT1 L: 0 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:18/PNP0C09:00/PNP0C0A:01/power_supply/BAT1 E: SUBSYSTEM=power_supply E: POWER_SUPPLY_NAME=BAT1 E: POWER_SUPPLY_TYPE=Battery E: POWER_SUPPLY_STATUS=Full E: POWER_SUPPLY_PRESENT=1 E: POWER_SUPPLY_TECHNOLOGY=Li-poly E: POWER_SUPPLY_CYCLE_COUNT=866 E: POWER_SUPPLY_VOLTAGE_MIN_DESIGN=11460000 E: POWER_SUPPLY_VOLTAGE_NOW=12715000 E: POWER_SUPPLY_POWER_NOW=0 E: POWER_SUPPLY_ENERGY_FULL_DESIGN=24000000 E: POWER_SUPPLY_ENERGY_FULL=19870000 E: POWER_SUPPLY_ENERGY_NOW=19870000 E: POWER_SUPPLY_CAPACITY=100 E: POWER_SUPPLY_CAPACITY_LEVEL=Full E: POWER_SUPPLY_MODEL_NAME=01AV452 ^^^^^^^ E: POWER_SUPPLY_MANUFACTURER=SMP E: POWER_SUPPLY_SERIAL_NUMBER= 1935 I archived the T470 parts diagram here in the corporate confluence, you should recognize the optional external battery: (requires confluence login) https://confluence.suse.com/download/attachments/515801221/t470-system-servi... So, in case you have a firmware version older than 1.42, I think updating it is worth a shot. When I do that on my laptop I use "fwupdmgr" command (from within Linux!) which makes it all very smooth, see https://wiki.archlinux.org/title/fwupd , it generally it's a matter of fwupdmgr get-devices fwupdmgr refresh fwupdmgr get-updates fwupdmgr update Regarding your turbostat and dmesg attachments: the first this I did is comparing the header of the turbostat output (all the power management settings). They're identical in both "good" and "bad". Only the temperature reading changes (MSR_IA32_PACKAGE_THERM_STATUS), and that doesn't mean much. The settings I looked at are: MSR_PM_ENABLE: 0x00000001 (HWP) which means the CPU is doing autonomous frequency scaling (no OS involved) and MSR_HWP_REQUEST: 0x80002704 (min 4 max 39 des 0 epp 0x80 window 0x0 pkg 0x0) which means the configuration allows the CPU the full range of speeds, from "min 4" (400 MHz) to "max 39" (3900 MHz). What I was suspecting was a situation like "min 4" and "max 4" in the "bad" situation, but it isn't like that. In both scenarios the full range is allowed. "epp 0x80" is also important, as that's a number between 0x0 (maximum performance setting) to 0xff (maximum efficiency). Again, you have 0x80 in both cases as expected, which is mid-range, nothing to see there. Yet turbostat shows your clock squarely at 400 MHz when on battery which is a serious problem. As per dmesg, as you observed, we have some cpufreq messages at booth (showing the dyndbg parameter works) but no logs during normal operations. If the intel_pstate driver was to impose some limits on the frequency it would write something in the logs. One minor remark, unrelated to your problem: I see you have intel_idle.max_cstate=0 in your command line. Are you aware that this parameter prevents the intel_idle driver from loading, falling back to the acpi_idle driver? Generally people think "=0" means "don't go idle", but unfortunately the parameter works differently. intel_idle.max_cstate= [KNL,HW,ACPI,X86] 0 disables intel_idle and fall back on acpi_idle. 1 to 9 specify maximum depth of C-state. In case the intent is to not go idle, the correct parameter is "idle=poll". Let me know if you have a BIOS version <1.42 on the T470 and what happens if you update it. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1203748 https://bugzilla.suse.com/show_bug.cgi?id=1203748#c32 --- Comment #32 from Stefan Dirsch --- I think I never updated the BIOS. # fwupdmgr get-updates WARNING: Firmware can not be updated in legacy BIOS mode See https://github.com/fwupd/fwupd/wiki/PluginFlag:legacy-bios for more information. So I'm still running either in legacy BIOS or CSM UEFI BIOS in "CSM compatibility mode". And switching to UEFI would probably mean I would need to reinstall the whole system. So I guess I need to update the BIOS by other means. Hope I can still find an update somewhere. Maybe this is then doable by a USB stick with FreeDOS on it. But first I need to make a backup of my data. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1203748 https://bugzilla.suse.com/show_bug.cgi?id=1203748#c34 --- Comment #34 from Stefan Dirsch --- I removed intel_idle.max_cstate=0 option. It was Takashi's first idea to try to address the issue (comment#6). I forgot to remove it again. Done now. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1203748 Stefan Dirsch changed: What |Removed |Added ---------------------------------------------------------------------------- CC|msuchanek@suse.com, | |tiwai@suse.com | Component|Kernel |Other Assignee|kernel-bugs@opensuse.org |sndirsch@suse.com Summary|Laptop very slow in battery |Laptop very slow in battery |mode (Lenovo Thinkpad T470) |mode (Lenovo Thinkpad T470) | |- needs BIOS update to | |version >= 1.42 QA Contact|qa-bugs@suse.de |sndirsch@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1203748 https://bugzilla.suse.com/show_bug.cgi?id=1203748#c36 --- Comment #36 from Stefan Dirsch --- Takashi had a good proposal. Creating a Live Image for a USB stick with fwupdmgr/fwupdate included, so I can switch to UEFI mode in firmware and boot with this Live image in UEFI mode and run fwupdmgr/fwupdate. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1203748 https://bugzilla.suse.com/show_bug.cgi?id=1203748#c38 Stefan Dirsch changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #38 from Stefan Dirsch --- (In reply to Stefan Dirsch from comment #37)

(In reply to Stefan Dirsch from comment #36)

...

Takashi had a good proposal. Creating a Live Image for a USB stick with fwupdmgr/fwupdate included, so I can switch to UEFI mode in firmware and boot with this Live image in UEFI mode and run fwupdmgr/fwupdate.

So this became my hackweek project. ;-)

https://hackweek.opensuse.org/22/projects/thinkpad-t470-bios-update-in-live- system

Successfully done. :-) Closing ... -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1203748 https://bugzilla.suse.com/show_bug.cgi?id=1203748#c40 --- Comment #40 from Stefan Dirsch --- (In reply to Giovanni Gherdovich from comment #39)

To recap: your system is legacy BIOS,

Yes, kind of, i.e. openSUSE Leap 15.3 was still using legacy BIOS for installation, in more detail. It runs on CSM mode, i.e. the legacy BIOS compatibily layer on top of UEFI. At least that's how I understood it.

the vendor offers BIOS updates only via UEFI capsules and their only documented update method is with the Linux tool fwupdate(1). fwupdate doesn't work if the system uses legacy mode. So what you did is use a (uefi) live image from a USB disk with fwupdate, run the update, and then continue use legacy mode on an update firmware. Am I getting this right?

Yes, in legacy BIOS compatibility mode CSM. See above.

This kind of shows that there is only one firmware; I somehow always assumed there are two, one legacy and one uefi. But apparently you're always running the uefi BIOS, only it has a thin compatibility layer on top so you can keep using the old interface. Does that make sense?

Yes, definitely. Only one (UEFI) BIOS. Well, in more detail. It was first installed an update for ECP (Embedded Controller Program) . On top of that the update for the UEFI BIOS (first step to an intermediate version). Then another update for UEFI BIOS (second and last step to the final version). For all these a boot entry was generated and the update didn't happen before selecting this boot entry. Then also the firmware for the NVME has been updated. This happened immediately. -- You are receiving this mail because: You are on the CC list for the bug.