lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 30 Mar 2016 11:50:35 -0700
From:	"Doug Smythies" <dsmythies@...us.net>
To:	'Jörg Otte' <jrg.otte@...il.com>,
	"'Pandruvada, Srinivas'" <srinivas.pandruvada@...el.com>
Cc:	<rafael@...nel.org>, <linux-kernel@...r.kernel.org>,
	<linux-pm@...r.kernel.org>, <rjw@...ysocki.net>
Subject: RE: [intel-pstate driver regression] processor frequency very high even if in idle

On 2016.03.30 08:52 Jörg Otte wrote:
> 2016-03-30 17:33 GMT+02:00 Pandruvada, Srinivas <srinivas.pandruvada@...el.com>:
>> On Wed, 2016-03-30 at 13:05 +0200, Rafael J. Wysocki wrote:
>>> On Wed, Mar 30, 2016 at 12:17 PM, Jörg Otte <jrg.otte@...il.com>

>>>>>> Now in v4.6-rc1 the characteristic has dramatically changed.
>>>>>> If in idle the processor frequency is more or less a few
>>>>>> MHz around 2500Mhz.
>>>>>> I currently use acpi_cpufreq which works as usual.
>>>>>> Processor: Intel(R) Core(TM) i5-4200M CPU @ 2.50GHz
>>>>>> (family: 0x6, model: 0x3c, stepping: 0x3)

>> I want to reproduce this if I can. Can you give us info about your
>> setup (Linux distribution, laptop model etc.)?

I would like to try to reproduce the issue also.

> Distro: Ubuntu 14.04.4 LTS

Note that with Ubuntu 14.04, I had issues where my CPU
would lock at pstate 24 (not always 24, but usually),
regardless of load.
However, it was always after an S3 suspend, occurred 100%
of the time, and was independent of intel_pstate or
acpi-cpufreq CPU frequency scaling drivers.

Since changing my test server to Ubuntu server edition 16.04
(development version), I have not had those issues. While I have
no proof, I have assumed the issue elimination was somehow related
to the change to systemd.

It might be worth observing both what the intel_pstate is asking for
and what the processor is actually doing.

What is being asked for:
# rdmsr --bitfield 15:8 -d -a 0x199

What is being given:
# rdmsr --bitfield 15:8 -d -a 0x198

An old problematic example from an idle system (mine)
Note, my minimum pstate is 16:

What was being given:
# rdmsr --bitfield 15:8 -d -a 0x198
24
24
24
24
24
24
24
24

What was being asked for:
# rdmsr --bitfield 15:8 -d -a 0x199
16
16
16
16
16
16
16
16

To gain further insight, it might also be worth acquiring
some trace data. On an otherwise idle system, do:

# perf record -a --event=power:pstate_sample sleep 300

If pressed for time, your sleep time can be less than 5 minutes,
but try to get at least 100 seconds.

The resulting perf.data file will be too big to include as an
on-list attachment, but send it (or them) to me off-list for
post processing, and I'll report back.

... Doug


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ