linux-kernel - Re: [BUG] ThinkPad T520 overheating with P-State driver

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 07 May 2015 10:20:22 +0200
From:	Martin Steigerwald <martin@...htvoll.de>
To:	Doug Smythies <dsmythies@...us.net>
Cc:	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
	'Kristen Carlson Accardi' <kristen@...ux.intel.com>
Subject: Re: [BUG] ThinkPad T520 overheating with P-State driver

Am Mittwoch, 6. Mai 2015, 19:51:19 schrieb Doug Smythies:
> On 2015.05.06 13:37 Martin Steigerwald wrote:
> > I get frequencies like:
> > 
> > 3080566
> > 3068945
> > 3009082
> > 2999902
> 
> Please know that the intel_pstate driver reports actual CPU frequencies
> over the last sample interval. In terms of heat, they don't mean anything,
> you would have to look at how much time the CPU spent in the C0 and other
> states.

Okay, so that would be 

merkaba:/sys/devices/system/cpu/cpu0/cpufreq> ls stats
time_in_state  total_trans

for acpi-cpufreq, and for Intel P-State I suppose there is something 
similar?

Powertop can show this as well I think. Can these value be resetted so I 
could test just for this workload?

> > Yet with acpi-cpufreq without limiting maximum performance at all, I get
> > the following with the *same* workload:
> > 
> > 2501000
> > 2501000
> > 1000000
> > 1000000
> 
> Please know that the acpi-cpufreq driver reports what frequency (pstate)
> It is asking for, not what might actually be happening.
> If your CPU 2 and 3 were ever active during that sample time
> They would be at the same frequency as your turbostate CPU 0 or 1,
> which ever is higher.

Okay. So I can´t see anything from it.

What I experience tough it that the workload of playing PlaneShift works 
*much* better with acpi-cpufreq on this machine.

I bet the machine may need a fan replacement, or cleaning, but last time I 
looked it appeared to be clean enough. Yet there is a huge difference between 
hitting forced throttling each 2 minutes or just three or four times during 
an evening.

Also it stayed longer in forced throttling state, with acpi-cpufreq it was 
there quite shortly. And the room was one degree warmer even.

So at least under my conditions acpi-cpufreq appears to work way better, 
cause hitting forced throttling as much as it hits with P-State actually 
makes things slower, way slower. In my understanding it should avoid hitting 
this forced throttling.

I tried thermald then, but it injected idle states up to the point where the 
machine became basically unusable.

I am quite full with things, but I once I have a bit more time I would like 
to gather some debug data. Would state statistics be enough or would 
anything else be needed?

Of course, if you just say, Intel P-State does a better job at ultilizing 
maximum power and is not supposed to work on aged hardware with some cooling 
deficiences, I can spare my time. Still then it would be good it it respected 
the no_turbo setting.

Also it seems to somewhat respect max_perf_pct, but if there is work to do 
it exceeds it as well. It would be good to have a way to tell it "Hey, this 
machine is a bit old, it doesn´t do the cooling as well as it when it was 
new and it could hit the CPU for 3,2 GHz (instead of 2,5 GHz) for half an 
hour without ever overheating, so please be a bit more gentle with it, until 
I eventually replaced fan or did whatever is needed to bring it back to full 
cooling functionality".

> > There is also some other bug report about this:
> > Please change intel_pstate default to disable
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1188647
> > appears to be quite old, but still seems unresolved.
> 
> That bug report is very old, and is closed.
> I made a late entry on that bug report on 2014.06.08,
> and have submitted a patch set to deal with, among other things,
> the long duration issue.

Oh, I thought it was just closed by disabling Intel P-State, I didn´t see 
any actual fix to the issue in there. Ah, okay, your last comment mentioned 
fixed, I was not sure whether they really fixed the issue from reading your 
comment.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/