https://bugzilla.suse.com/show_bug.cgi?id=1203748 https://bugzilla.suse.com/show_bug.cgi?id=1203748#c21 Giovanni Gherdovich <giovanni.gherdovich@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(sndirsch@suse.com | |) --- Comment #21 from Giovanni Gherdovich <giovanni.gherdovich@suse.com> --- 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.