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 the assignee 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 the assignee for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1203748 https://bugzilla.suse.com/show_bug.cgi?id=1203748#c16 Stefan Dirsch changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(sndirsch@suse.com | |) | --- Comment #16 from Stefan Dirsch --- I also tried with kernel 6.0 meanwhile. About the same results. Still rather often the machine switches in this 400 MHz slow mode. :-( This is sill with "intel_idle.max_cstate=0". -- You are receiving this mail because: You are the assignee for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1203748 https://bugzilla.suse.com/show_bug.cgi?id=1203748#c18 --- Comment #18 from Stefan Dirsch --- Created attachment 862098 --> https://bugzilla.suse.com/attachment.cgi?id=862098&action=edit hwinfo.out -- You are receiving this mail because: You are the assignee 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 the assignee 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 the assignee 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 the assignee 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 the assignee 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 the assignee 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 the assignee 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 the assignee 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 the assignee 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 the assignee for the bug.