[Solved] Kernel params for suspend -> overheating(?)

Trilby · 2012-05-18 16:48:28

I had long since given up on getting my Lenovo S10-3 to suspend - or should I say resume from suspend.

But with all the kernel updates I figured it might be time to give it another shot. The traditional methods had the traditional failings, but I found a new suggestion on the Lenovo S10 page of the arch wiki to add these three kernel parameters

hpet=disable highres=off nohz=off

I had tried the first previously, but not all three. I gave it a shot with all three and suspend and resume work perfectly.

I quickly noticed a disturbing side effect though. My netbook got notably hotter; I didn't take any sensor data, but I could feel how hot it was getting. The cpu fan remained on high continuously at idle, where without those three kernel parameters the fan almost never has to run.

I removed and replaced the parameters a few times to verify that this was the cause. Every time they were on the kernel line I had the fan/heat problems; everytime they weren't these problems didn't exist, but I couldn't resume from suspend.

Has anyone had similar issues or know of any way to get the suspend/resume benefit of these parameters without the (seemingly dangerous) side effect?

Google has not helped much on learning about these parameters. I found dozens of pages that limit their explanation to saying that "nohz=off" turns off nohz. Well thats f^%#ing helpful *sarcasm*.

Last edited by Trilby (2012-05-24 23:04:54)

litemotiv · 2012-05-18 16:55:25

Well, i can tell you that "hpet=disable" actually disables hpet, if that's any help?

Trilby · 2012-05-18 17:00:50

Thanks smarta$$

Actually, wikipedia has a decent article on hpet. All three parameters seem to deal with kernel event timing. I just can't get the connection to the heat issues. There was no measureable change in cpu usage between the two settings.

Last edited by Trilby (2012-05-18 17:02:02)

litemotiv · 2012-05-18 17:22:19

Yes sorry for that obviously. I have no clue about your problem, this stuff is really beyond me... Perhaps opening a ticket on the kernel bugzilla could provide some insight?

Gusar · 2012-05-24 22:38:18

The connection to the heart issues is actually easy to establish:

First is nohz aka Tickless System aka Dynamic Ticks. The Arch kernel is configured with 300Hz. Without nohz, the processor will wake up 300 times every second! With nohz, it'll wake up only when it needs to. Down to 30 times when the machine idles, otherwise it depends on the apps you're running, 100-200 is usual I think.

Then we have the other two options, they're disabling high precision timers. This affects the efficiency of the processor, possibly preventing it from entering deep sleep states (C-states) as often as it could, which would save more power (and consequently produce less heat).

Basically, you're taking away means for the processor to efficiently power-manage itself.

Trilby · 2012-05-24 22:44:43

Thanks for the info. But I can't imagine those parameters would be recommended (the nohz option is widely recommended on many forums and wiki's) if they caused such a drastic effect on other people's systems.

Today I realized I was adding these to a CK kernel. And while I'll readily admit complete ignorance to these details, I know the CK patchset changes the CPU scheduler, which I'm guessing might conflict or mix badly with these settings.

I'm going to try these settings tomorrow when booting from the 'vanilla' kernel to see if it is the interaction, or if these kernel parameters really have that bad of an effect on my system.

Gusar · 2012-05-24 22:56:31

Trilby wrote:

But I can't imagine those parameters would be recommended

They're on a wiki. Which everyone can edit. I'm sure this is not the only bad advice there.

I don't think the CK kernel matters in this regard. This scheduler or that scheduler, in both cases you're taking away high precision timers and dynamic ticks. Effective power management is all about C-states. Having the CPU spend as much time as possible in the deepest possible C state.

Trilby · 2012-05-24 23:04:31

Gusar wrote:

They're on a wiki. Which everyone can edit. I'm sure this is not the only bad advice there.

Undoubtedly true. But I've seen them on many wiki's and forums for various distros. I have no delusion that it is good advice, but it is a technique that many are using. I'd be surprised if anyone used it if they got results like I did. Right from powering up I had a "WTF is wrong with my computer" reaction.

But that does answer my question. I'll still try the vanilla kernel tomorrow just in case, as I do still have it installed, but for now I'll put suspend back on the back-burner until I have time to look for better solutions. Working on a quick boot time has made suspending a low priority, but as it's the one thing on this machine that isn't working right I'm like a moth to a flame: "must fix irrelevant problem".

Thanks again for the insight.

UPDATE: Using the vanilla kernel makes no difference: the parameters needed for suspend cause a nasty side effect.

Last edited by Trilby (2012-05-25 15:44:42)

Arch Linux

#1 2012-05-18 16:48:28

[Solved] Kernel params for suspend -> overheating(?)

#2 2012-05-18 16:55:25

Re: [Solved] Kernel params for suspend -> overheating(?)

#3 2012-05-18 17:00:50

Re: [Solved] Kernel params for suspend -> overheating(?)

#4 2012-05-18 17:22:19

Re: [Solved] Kernel params for suspend -> overheating(?)

#5 2012-05-24 22:38:18

Re: [Solved] Kernel params for suspend -> overheating(?)

#6 2012-05-24 22:44:43

Re: [Solved] Kernel params for suspend -> overheating(?)

#7 2012-05-24 22:56:31

Re: [Solved] Kernel params for suspend -> overheating(?)

#8 2012-05-24 23:04:31

Re: [Solved] Kernel params for suspend -> overheating(?)

Board footer