How can i set intel idle max cstate to 1 and how can i check when it will done. i have a freeze problem because of bay trail cores.

i tried kernel 4.5 4.1.12 4.4 but freeze problem still continue. at the moment 4.4 is my kernel version.

  • As of now (8/2019) this thread does not actually states that setting the intel_idle.max_cstate=1 is an official resolution to the bug published in 2011. Since in my case it is (had to duplicate) an intermittent problem, before I ADD intel_idle.max_cstate=1 to my GRUB, I like to get some documentation stating that. The original Bugzilla doc are unclear to that effect. Can some participant in this forum kindly help me to officially verify this “fix”?
    – user580382
    Aug 12, 2019 at 19:36

4 Answers 4


If using GRUB:

With sudo, edit /etc/default/grub and edit the GRUB_CMDLINE_LINUX_DEFAULT line adding intel_idle.max_cstate=1 to whatever might already be there. After saving the file run sudo update-grub, then re-boot. Suggest that you save a copy of your original grub file first.

To check that your cstate is not going deeper than 1 use turbostat (package: linux-tools-common).

Example (where there is already something on the GRUB_CMDLINE_LINUX_DEFAULT):

Before (edited):

$ sudo turbostat -S --debug sleep 10
 Avg_MHz   %Busy Bzy_MHz TSC_MHz     SMI  CPU%c1  CPU%c3  CPU%c6  CPU%c7 CoreTmp  PkgTmp Pkg%pc2 Pkg%pc3 Pkg%pc6 PkgWatt CorWatt GFXWatt
       1    0.04    1654    3411       0    0.12    0.03   99.82    0.00      29      29    0.07    0.03   99.51    3.85    0.20    0.23
10.001629 sec

Make the change (using my method for configuration control):

~/config/etc/default$ cp /etc/default/grub ./
~/config/etc/default$ cp grub grub.original
~/config/etc/default$ nano grub

Change this:


To this:

GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 intel_idle.max_cstate=1"

And update:

~/config/etc/default$ sudo cp grub /etc/default
~/config/etc/default$ sudo update-grub
~/config/etc/default$ sudo reboot -r now

Now check (edited):

$ sudo turbostat -S --debug sleep 10
 Avg_MHz   %Busy Bzy_MHz TSC_MHz     SMI  CPU%c1  CPU%c3  CPU%c6  CPU%c7 CoreTmp  PkgTmp Pkg%pc2 Pkg%pc3 Pkg%pc6 PkgWatt CorWatt GFXWatt
       0    0.02    1920    3411       0   99.98    0.00    0.00    0.00      39      39    0.00    0.00    0.00   10.49    6.66    0.23
10.001079 sec

Your should also see these messages in dmesg and var/log/kern.log (edited):

~$ dmesg | grep intel_idle
[    1.019709] intel_idle: max_cstate 1 reached

$ grep intel_idle /var/log/kern.log
Mar 23 08:10:32 s15 kernel: [    1.019709] intel_idle: max_cstate 1 reached
  • I wonder what value, in the output of turbostat, is showing that the cstate is not going deeper than 1. What do you mean with deeper? What to do differently if it does go deeper?
    – Stephane
    Jun 28, 2017 at 21:18
  • 1
    @Stephane : By "deeper", I meant higher c states than 1. if you have set the grub command line properly, it shouldn't go to cstate deeper (higher than) 1. You can observe the CPU and Package, cstates greater than 1 show 0.00% time in those states on the turbostat output line. Jun 29, 2017 at 4:29
  • 1
    My Thinkpad X201i was doing hard restarts every hour. I enabled the intel_idle.max_cstate=1in the grub like GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"with a grub update sudo update-grub and restarted the machine. No hard restarts occur any more. I(m glad I solved my issue. I wonder what exactly is this property telling the CPU though.
    – Stephane
    Jun 29, 2017 at 8:36
  • FYI I've been following this bug report for about a year and it may interest you too: bugzilla.kernel.org/show_bug.cgi?id=109051. Also here in AU: askubuntu.com/questions/803640/… Jul 30, 2017 at 22:44

After having the same freeze-problems with linux and my asrock Q2900 I found on a German IT website the solution/workaround provided by Intel. (https://www.golem.de/news/intel-einfrieren-bei-intels-bay-trail-socs-durch-patch-abgefedert-1609-123546.html) There is a general problem with Bay-Trail-SoCs from Intel. The link to the patch: https://bugzilla.kernel.org/attachment.cgi?id=223851

Further information: This patch/script does obtain the power saving mode. The topic-solution above does remove this mode at all.

  • Welcome to Ask Ubuntu! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the links for reference.
    – Elder Geek
    Sep 18, 2017 at 13:56

There is no need to update grub anymore if you switch to a most recent kernel.

According to comment# 1013 in bug report it is now fixed:

I haven't checked this thread in a long time, but I thought I should post my findings just in case it is of any use to anyone.

A low end computer powered with an Intel N2807 which never worked more than 30 mn without crashing when I didn't set ...max_cstates=1 now works perfectly well with a stock kernel v. 5.3.1 or 4.19.75. I ran it for a couple of days with each version without any issues. The average power consumption was also down by a little over 10%.

It has taken about four years to fix this bug first reported December 8, 2015.

  • Can confirm it's no longer required on Ubuntu22.10 on a Dell XPS 9370 at least
    – tomodachi
    Oct 25, 2022 at 8:37

Edit /etc/defaults/grub:



shutdown -r now

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .