Giovanni Gherdovich changed bug 1203748
What Removed Added
Flags   needinfo?(sndirsch@suse.com)

Comment # 21 on bug 1203748 from
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: