[Virtual-pkg-base-maintainers] Bug#774743: base: processor uses maximum multiplier after resume from suspend

Stathis Zavvos stathis.bugreports at gmail.com
Wed Jan 7 01:43:15 UTC 2015


Package: base
Severity: normal



-- System Information:
Debian Release: 8.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Hello. 

I am using a Dell M4800 laptop with an Intel i7 4710MQ.
The intel_pstate driver works well on this processor.

My problem is that after resuming from suspend, the processor's
multiplier is mainly stuck to the highest frequency set in 
/sys/devices/system/cpu/intel_pstate/max_perf_pct .

This happens for quite some time after which it seems to revert
to normal operation (maybe even an hour or so). The processor
doesn't seem to be in c0 state, and switches states correctly
up to c7 when idle. It's just that the clock isn't going down.
Voltage also seems to be at normal levels for idle, as I can't 
notice a difference in heat levels, but I assume it does 
increase somewhat to sustain the clock compared to a true  idle state. 

I have double and triple checked and the processor retains its
settings well after resume.

I am using pm-utils and nothing else, and set the frequencies
and the governor via echoes to the respective system properties.
I load this script at boot (to detect if I am on AC or on battery)
in order to set the desired settings. These are passed correctly
to the respective properties and are also retained after resume. 
Finally I monitor the processor with i7z.

This situation leads me to believe that it is not an intel_pstate
issue, but a general issue with the system's state when it resumes.
This may indicate to my opinion that the processor asks continuously
for a change in the P state, which it doesn't get for some reason.

This bug also exists in later kernel.org kernels from what I found over the 
internet and has not been resolved yet in 3.17 or in 3.19 from 
what I know. 

As such, I would kindly ask you to look into it if possible. 
I know it may possibly be a large subject and difficult to locate,
but I just want you to have it in mind as this version makes the
transition to a stable one. It does not affect the stability of
the system, but I have noticed a difference in power consumption
levels which degrade the life of the battery somewhat and also 
will degrade the lifetime of the processor if it is clocked
constantly in maximum turbo boost. This also happens when
I have turbo boost turned off by the way. It just sticks to the 
max frequency I have set.

Thank you and have a nice day,

Stathis Z.



More information about the Virtual-pkg-base-maintainers mailing list