My system freezes completely at random, frequent intervals. I started to have the same problem in Ubuntu 14.04 but after recent upgrade to 16.04 there is no improvement, in fact it seems worse.

When it happens, it's impossible to do anything. I've tried everything in this thread: What to do when Ubuntu freezes but nothing works, I have to hard reset. I have read all the system logs and journalctl but there is never any information that could help diagnose the problem.

This is a dual-boot system with Windows 10 and there's no problem there, so it's not defective hardware.

My laptop has an Intel Bay Trail processor (Pentium N3540)


3 Answers 3


Your processor is affected by the c-state bug

This causes total freezes when the CPU tries to enter an unsupported sleep state. It's a problem for many Bay Trail devices especially with newer (4.*) kernels.

Affected processors AFAIK:

Atom Z3735F (Asus X205TA, Acer Aspire Switch 10, Lenovo MIIX 3 1030) 
Atom Z3735G
Celeron J1900 (Asus ET2325IUK, shuttle XS35V4)
Celeron N2940 (Acer Aspire ES1-711, Chromebook)
Celeron N2840 (Acer Aspire ES1-311)
Celeron N2930 (Jetway JBC311U93, Zotac Nano CI320)
Pentium N3520 
Pentium N3530 (Acer V3-111P)
Pentium N3540 (Dell Inspiron 15 3000, Lenovo G50, ASUS X550MJ)

(please (suggest an) edit to add your own device if affected)

Complete list of Bay Trail processors may be found here

There is a simple workaround for this until it gets properly fixed upstream.

You just need to pass a kernel boot parameter and the random freezing stops completely. The parameter may increase battery consumption slightly, but it will give you a usable system.

You do this by editing the configuration file for GRUB:

Boot Ubuntu and open a terminal by pressing Ctrl+Alt+T then type

sudo nano /etc/default/grub

Find the line that starts GRUB_CMDLINE_LINUX_DEFAULT=

This needs to be changed to include intel_idle.max_cstate=1

So after your edit it reads something like

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"

quiet and splash are default parameters for Ubuntu Desktop - no need to change them, or any other pre-existing parameters

Now save the file by pressing ctrl+o then enter and exit by pressing ctrl+x

Now run

sudo update-grub

Then reboot.

What to do if you don't have enough time to do this before the system hangs

No problem. As explained on the help page I linked to earlier, you can add the parameter to GRUB before booting. Note that this only passes the parameter for the current boot, so you still have to edit /etc/default/grub once you have booted to make the change permanent.

You need to get to the GRUB menu. If you are dual booting this will appear anyway, if not you have to press and hold (or tap) shift after pressing the power button to turn on.

When you get to this screen select Advanced Options for Ubuntu. You can move the cursor to a different kernel, or leave it in place to edit options for the default. Instead of pressing enter, press e and you will go into edit mode, looking vaguely like this.

Move the cursor down to where it says quiet splash, put a space after splash and carefully type intel_idle.max_cstate=1 making sure there is a space after it as well.

Now press F10 or Ctrl+x to boot.

  • 1
    @Arronical hehe thanks! I have to know this - my system will stay up for ~15 minutes without it, but with the param, it's never frozen once :) All credit to the really awesome hackers who figured it out
    – Zanna
    Jul 27, 2016 at 16:39
  • Thank you! Does this stop the non response to Ctrl Alt REISUB? Also the response to the above GRUB edit was that if Hidden Timeout is set, then the above edit won't work. How does one get around this if problem persists?
    – clr
    Sep 14, 2016 at 12:21
  • @clr the c-state freezes don't respond to magic sysrq REISUB, but this fix stops the c-state freezes. If your system freezes for some other reason, REISUB might work. GRUB_HIDDEN_TIMEOUT has no effect on boot parameters, and you should be able to access the menu by pressing shift at startup. If you cannot, in the case where the system freezes too quickly for you to edit /etc/default/grub, that's a pain, but you can try booting a live session of a version with an older kernel to edit the file - mount the root partition to /mnt and edit /mnt/etc/default/grub to add the parameter.
    – Zanna
    Sep 28, 2016 at 21:12
  • Thanks for clear instructions. I hope this does the trick. I'll report back here if it doesn't. I am currently running 16.10 on a Zotac Nano CI320. I had tried 16.04 and Debian 8 earlier, and also experienced random freezes. I tried 16.10 hoping the problem would just go away with a newer kernel. Interestingly the one time I tried REISUB (I can't remember what OS) it did work -- so it might turn out I'm facing a different problem. Oct 21, 2016 at 19:23
  • 1
    I install Ubuntu 20 on my Intel(R) Pentium(R) CPU N3700 @ 1.60GHz processor, after adding intel_idle.max_cstate=1 to grub, Now freeze is completely gone. Thanks for the answer. May 20, 2022 at 7:33

Linux on Bay Trail and Braswell processors randomly freezes with built-in video devices.

The problem is with temperature control. Just remove the thermald module:

sudo apt-get remove thermald 
  • 4
    I believe the bug for Bay Trail is in the i915 (Intel CPU) driver. The processor constantly tries to go into sleep states that are not supported by it. The problems for Bay Trail users started after a commit to i915, so that's always been blamed. However, maybe there is another cause for some, and I have no idea about the Braswell freezes and it would be great to know they are fixed by some (safe?) action. Do you have any reference for this information, or can you tell us which hardware this was tested on and worked?
    – Zanna
    Apr 7, 2018 at 15:42
  • It seems that this is still a problem with 19.04. Was kind of hoping it would be fixed by now. Has happen on my laptop since after 14.04. 15.10 was almost impossible to fix.
    – crip659
    May 29, 2019 at 0:51

For people following this bug here is an update. Go to: Bug 109051 - intel_idle.max_cstate=1 required on baytrail to prevent crashes and press the End key. If necessary press Page Up to message #1013.

According to comment# 1013 it is now fixed in recent kernels:

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.

  • 1
    I am using kernel 5.4.0-59-generic and I run into the same symptoms once very week or two, have to hard reset and there's absolutely nothing noteworthy in any of the logs. I never used to have this problem on my old i5 processor, it was only after I upgraded to an i7-4790K
    – Coder Guy
    Feb 5, 2021 at 4:56

Not the answer you're looking for? Browse other questions tagged or ask your own question.