Unable to set max_cstate without rebooting (since hardy)

[yop]

On earlier kernels I could set the max_cstat to get rid of the hissing/whining noise from the CPU when idle.
echo 2 > /sys/module/processor/parameters/max_cstate

This don't work any mor, and I have not found a solution to this annoying noise from thr CPU

Dell D610 1.6Ghz, 1024RAM, hardy kernel

[Leann Ogasawara (leannogasawara)]

Hi yop,

Just curious if you've tried either of the following:

Add "options processor max_cstate=2" in /etc/modprobe.conf

or

Try the boot option "processor.max_cstate=2".

[yop (yop)]

Yes have tried it = no success.
If I do a cat, I get.
cat: /sys/module/processor/parameters/max_cstate: No such file or director

[yop (yop)]

I did find that if using the server kernel it does not make this annoying noise.

Linux ubuntu 2.6.24-12-server #1 SMP Wed Mar 12 23:34:17 UTC 2008 i686 GNU/Linux = Not whining noise
And have not added any max_cstate setting to any file.

[socketbind (socketbind)]

Please, bring this back, I have no other means to fix the CPU noise on my machine.

[yop (yop)]

@socketbind
Did you try the server kernel? It's not perfect silent, but much less noise then the generic.
At least on my machine

[Marcel Schaal (marcelschaal)]

@yop
the server kernel doesn't change anything on my dell latitude d430. it is as loud as the generic one

anybody had a look at this (2.)?
http://www.mail-archive.com/linux-acpi%40vger.kernel.org/msg10354.html

[Alan Norton (nortona)]

Setting 'options processor max_cstate=2' in /etc/modprobe.d/options did not solve the issue on Dell D420.

I'm going to be compiling a custom kernel for TuxOnIce anyway. Does anyone have any idea what kernel options I might try to get rid of the noise or expose the processor options in /sys/module/processor/parameters/?

[Alan Norton (nortona)]

FYI, passing the kernel boot param 'processor.max_cstate=2' will work ONLY if you have the ACPI Processor compiled into the kernel (aka NOT as a module).
Recompiling the kernel with CONFIG_ACPI_PROCESSOR=y will allow you to set the max_cstate upon boot.

This is probably not an acceptable solution for the majority of users, but it is a workaround.

[Svein Tore (sveint)]

Please fix this. Just upgraded to hardy and the noise makes using the computer a painful experience (the high pitched noise actually gives me headaches after a while).

[Roderick B. Greening (roderick-greening)]

The 2.6.24 kernel has CONFIG_CPU_IDLE=y and apparently the patch for max_cstate only works if this is not set. Not sure why exactly, but presumably the patch will need some re-work (if still possible) to be utilized with this new default.

[yop (yop)]

I did notice that if using a usb mouse, then I get this annoying noise. But if I disconnect it from the Dell D520 it stops.

[jimmy smith (timmy-lea)]

This is a problem on my first generation MacBook (Core2Duo 1.83GHz). The CPU whines unless the power-saving mode is deactivated. When running Mac OS X, I installed ShhhMBP, which does the trick. Under Ubuntu I can't make it go away, even after changing power-saving modes using CPU Frequency Scaling, or Ubuntu Tweak.

I can't emphasize how serious this is. It sounds trivial but it's a show-stopper for those it affects. It makes using the computer borderline unbearable.

I know it's a hardware fault, and that it's a bit galling having to fix somebody else's mistake, but something needs to be done to at least make a tweak possible, even if the user has to intervene. Compiling the kernel is impractical and time-consuming. Ubuntu isn't geared towards hand-made kernels and doing so will break things.

[Robin Stocker (nibor)]

@jimmy smith
Maybe it's possible to turn the power-saving mode off through the BIOS? That's what I have done with my ThinkPad T61.

[Victor Julien (victor-vuurmuur)]

It turns out it's possible to set the max_cstate without recompiling. The reason the processor module isn't using the options is because it's loaded from the initrd image. Luckily we can easily update that image.

Steps:
1. Add "options processor max_cstate=2" to /etc/modprobe.d/options
2. Update your initrd image: "sudo update-initramfs -u"
3. Reboot

I've blogged about it here: http://www.inliniac.net/blog/2008/07/25/fixing-noise-on-ubuntu-hardy-804-aka-setting-max_cstate.html

[tvrusso (russo-bogodyn)]

This issue also impacts use of VMware on certain CPUs.

See, for example,
http://www.phocean.net/?p=10
http://ubuntuforums.org/showthread.php?t=769948
and
https://help.ubuntu.com/community/VMware/Workstation

I find that with Hardy this problem is much less severe than it was in Edgy, Feisty and Gutsy, but it is still present. In those other releases is completely solved by setting max_cstate to 1 while vmware is running. The usual recommendation is to set it to 1 while vmware is running, and back to whatever it had been before when exiting vmware so that the idling can work when it isn't causing problems. That is no longer possible. Setting a low max_cstate at boot time is a very poor substitute for on-the-fly manipulation in this instance.

I add my plea that this useful function be restored.

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Marcel Schaal (marcelschaal)]

Hi,

/sys/module/processor/parameters/max_cstate doesn't exist in 2.6.27-2-generic of intrepid alpha5. Adding "options processor max_cstate=2" to /etc/modprobe.d/options prevents cpu to use c3-state.

[tvrusso (russo-bogodyn)]

Since Marcel states the /sys/module/processor/parameters/max_cstate doesn't exist in the alpha5 version of the kernel in Intrepid, the issue is apparently not resolved,and the only way to get max_cstate set is to set it at boot time with modprobe.d options, just as it was before.

Setting probe options at boot time is not an adequate substitute for the on-the-fly manipulation provided by the max_cstate mechanism. My understanding is that there is a kernel parameter that can be enabled to allow max_cstate to work again, but that it is off by default.

Building the generic kernel with this option enabled would fix the problem, unless of course they've completely removed that option.

For me, I only need max_cstate changed when running vmware on a Pentium-M laptop, because vmware and the higher cstates don't play well together. Rebooting with new options just to run vmware isn't a reasonable "solution." At the moment, the only thing I can do to get vmware to work in a reasonable manner is to run an infinite loop junk process in another shell to keep the system from thinking it can go into higher cstates ("while [ true ] ; do echo foo > /dev/null ; done" does the trick, but at some expense).

The old way of putting "1" into /sys/module/preprocessor/parameters/max_cstate while vmware is running is an annoyance that is clearly a fault of vmware, but it worked better than the infinite loop does.

[Emanuele Olivetti (emanuele-relativita)]

Victor's solution works well and it is straightforward. I'm using it on a Dell D430 and the whining noise disappears. Unfortunately the CPU heating increases too much and causes too active (noisy) fans. For standard use (editing txt) CPU temperature is around 65 Celsius degrees when max_cstate is C2, and only 59 (i.e., no fans) when max_cstate is C8.
So, at least on D430, you have to trade-off fans noise and cpu noise.

[zippidy_josh (redstone)]

It looks like /sys/module/preprocessor/parameters/max_cstate is not available in Intrepid, at least not in 2.6.27-7-generic.
It would be nice to be able to configure max_cstate at run-time. I run ubuntu on my laptop (Lenovo T500) and switch between working in quiet and noisy environments, usually without rebooting (e.g., via suspend). In the quiet environments (like at home), I need to set max_cstate to eliminate annoying whine/crackle due to state C4, and in the noisy environments (on a plane), I prefer longer battery life. It's inconvenient to have to reboot every time I make this transition.
To rephrase, does anyone know of a way to alter max_cstate at runtime in 2.6.27?

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

[Peter Bui (pnutzh4x0r)]

This problem persists in Intrepid and in Jaunty. In fact, in Jaunty you can't even use the /etc/modprobe.d/options method anymore. Is this going to be addressed or are we left with to deal with whining CPUs?

There should be some way that the user can set the max_cstate, whether that is at run-time using /proc or statically by setting the modprobe options.

[Peter Bui (pnutzh4x0r)]

Apparently, you can add 'processor.max_cstate=2' to the kernel line in you grub config and this will work in setting the max_cstate and thus prevent the annoying whine.

[zippidy_josh (redstone)]

I've also heard you can modify the grub config, but that requires rebooting,
and if you're going to reboot, at least on my Lenovo T500, you can disable
higher cstate via a BIOS setting (I think it's under config -> power -> cpu
power management).

I rarely reboot my machine and instead using suspend/resume. It'd be much
more handy if you could change the cstate at runtime.

On Fri, Mar 27, 2009 at 12:32 AM, Peter Bui <email address hidden> wrote:

> Apparently, you can add 'processor.max_cstate=2' to the kernel line in
> you grub config and this will work in setting the max_cstate and thus
> prevent the annoying whine.
>
> --
> Unable to set max_cstate on hardy kernel
> https://bugs.launchpad.net/bugs/206864
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “linux” source package in Ubuntu: Triaged
>
> Bug description:
> On earlier kernels I could set the max_cstat to get rid of the
> hissing/whining noise from the CPU when idle.
> echo 2 > /sys/module/processor/parameters/max_cstate
>
> This don't work any mor, and I have not found a solution to this annoying
> noise from thr CPU
>
> Dell D610 1.6Ghz, 1024RAM, hardy kernel
>

[Alex Tomic (atomic777)]

For anyone trying to get this to work with more recent Ubuntu versions, I can confirm that setting the kernel option works for me on my Thinkpad T43 on Ubuntu 9.04.

Setting the max_cstate=3 was sufficient, and I am noticing little difference in power consumption (when idle with the lowest screen brightness I am at about 15W), so from my perspective this problem is solved.

Applying the setting to /etc/modprobe.d/options did not work for me.

[zippidy_josh (redstone)]

Modifying max_cstate on a running kernel is necessary if you want to be able
to change it without reconfiguring/rebooting. e.g. I use C6 when on
airplanes for longer battery life, but disable it otherwise because it
causes a high-pitched noise on some hardware (my T500 among others). It's
pretty inconvenient to have to reboot every time I want to change it....

Josh

On Sep 22, 2009 8:25 AM, "Alex Tomic" <email address hidden> wrote:

For anyone trying to get this to work with more recent Ubuntu versions,
I can confirm that setting the kernel option works for me on my Thinkpad
T43 on Ubuntu 9.04.

Setting the max_cstate=3 was sufficient, and I am noticing little
difference in power consumption (when idle with the lowest screen
brightness I am at about 15W), so from my perspective this problem is
solved.

Applying the setting to /etc/modprobe.d/options did not work for me.

--

Unable to set max_cstate on hardy kernel
https://bugs.launchpad.net/bugs/206864 You received this bu...
Status in “linux” package in Ubuntu: Triaged

Bug description: On earlier kernels I could set the max_cstat to get rid of
the hissing/whining noi...

[Isaac Dupree (idupree)]

Still an issue on Karmic (and feeling the pain again on my macbook. Having isight.fw loaded so the webcam works used to prevent this noise. In Karmic though, the webcam works for me as usual using isight.fw, but a lot of the time while running my laptop I get this noise anyway!)

[Alessio Bolognino (themolok)]

I can confirm this bug on natty.

[penalvch (penalvch)]

yop, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]