Many people have problems with Ubuntu 14.04, 16.04 and 16.10 where the system freezes completely, and I am one of them.

I want to know whether Ubuntu 17.04 will fix that issue or not, whether it has already been fixed on the trial ISO image of 17.04, before I try to download it and test it out.


3 Answers 3


TL;DR - my research suggests it's not fixed in the 17.04 beta image or in the release, but I have high hopes for 17.10.

These freezes happen when the processor attempts to enter a low-power state (c-state) that the kernel does not support. This problem was introduced by

commit 8fb55197e64d5988ec57b54e973daeea72c3f2ff
Date:   Tue Apr 7 16:20:28 2015 +0100
drm/i915: Aggressive downclocking on Baytrail

This went upstream in kernel 4.2, and we have been having issues since then. As explained in heynnema's answer (and this post where I have tried to collate information) there is a straightforward and effective workaround, passing a boot parameter that disables the low power states.

The beta version of 17.04 currently available uses 4.9 (it's based on the upstream 4.9.6 as I understand), and by the time the release comes out in April, I believe it will be using 4.10. The problem still exists in these kernels, so I have concluded that it is not fixed as of now. I checked the Ubuntu kernel changelogs, and found nothing, but please correct me if I am wrong.

I have been tracking the c-state bug here on kernel.org for a long time. In January 2017, Mika Kuoppala added this patch to the thread. Apparently, it reverts the earlier commit that caused the problem. The patch is called

drm/i915/byt: Avoid tweaking evaluation thresholds

Testing indicates very good results with this patch, which was submitted to the i915 driver owners on 25th January. All being well, it could be merged in the 4.11 window. The 4.11 kernel may be released around the end of April. A version of this patch was merged in the 4.11 window and reports indicate that the bug is fixed in 4.11.

Each of the troublesome BayTrail processors behaves a little bit differently with each different kernel. In 16.04 (4.4 kernel) my uptime on Atom Z3735F without the intel_idle parameter was around 15 minutes before freezing. I tested the beta 17.04 ISO in live mode, and I didn't get a freeze in 90 minutes, so it seems like I'm lucky with this kernel. You can do the same thing to test any image on your system - just make a bootable USB and "try Ubuntu without installing" and test it for as long as possible.

When 17.04 came out, I installed it, and in the first two weeks I ran it without the intel_idle parameter, I only had three c-state freezes, which is a huge improvement on earlier versions.

The safest thing to do is use the boot parameter. Based on my research I am expecting the bug to be fixed in 17.10 (and in other distro releases later this year) which will be using a kernel >=4.11, but not in 17.04.

However, there's always the possibility that the Ubuntu Kernel Team may patch it themselves. If you can tolerate running an unstable system occasionally, you can watch for progress by running regular updates (sudo apt update && sudo apt full-upgrade) and testing each new kernel without the boot parameter when it arrives. You can also read the changelogs as new packages are installed or (again, if you can tolerate instability) install a mainline kernel.

  • Thank you Zanna, it always happening with the bay trail Gpu , and the code to fix it don't work with many and i am one , so i asked about it, sorry that my question didn't tell that it with Gpu.
    – Bassem
    Feb 17, 2017 at 3:14
  • The problem also as you said with bay trail cpu , it's also with bay trail gpu and at me with the gpu, my cpu is intel pentium, but my gpu is intel bay trail , any way the problem with bay trail cause the same issuse ,freezes
    – Bassem
    Feb 17, 2017 at 3:39
  • @Bassem actually that was my fault, it was my edit to your question - I didn't know about issues with a gpu (btw some of the BayTrail series are Pentium). I think the problem is in the same driver, i915, so likely to be fixed by the same patch, but the bug report is about problems fixed by the intel_idle parameter and if that doesn't work for you it is a different bug according to the kernel folks. Can you please provide a bug report or forum thread (you say others share your problem) where I can find out more, so I can advise you what to do next? (I think you may need to ask a new question)
    – Zanna
    Feb 17, 2017 at 7:21
  • Thank you Zanna , and sorry cause i didn't recieved email by your comments, I don't know why , My profile option is to recieve
    – Bassem
    Feb 17, 2017 at 16:55
  • 1
    The bug report has new comment # 1013 stating bug has been fixed in current kernels. Sep 29, 2019 at 14:30

There is a fix for this in How to set intel_idle.max_cstate=1.

In terminal, type:

gksudo gedit /etc/default/grub

and change this line:


to include this:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"

then do:

sudo update-grub

This is an Intel problem, not a Ubuntu problem, but thank goodness that we've got a fix.

Nobody knows if Ubuntu 17.04 will require this fix or not.

  • This is just a workaround though (and we have many posts about it), I also want to know if it will be fixed in 17.04. It's a kernel problem really, since Intel can't fix hardware retroactively
    – Zanna
    Feb 15, 2017 at 12:42
  • @Zanna - As far as I'm aware, it will never be incorporated into the kernel directly, but be available as a boot flag. From what I can find, there is a lot of debate over it though. There's an open bug on kernel.org. Maybe that can shed some light on the subject? Feb 15, 2017 at 13:02
  • 2
    @ThatGuy tell me about it, I've been following that bug for a year. If you read it, you see that Linus himself wrote a patch for earlier kernels. I also know of, and have tested, a kernel patch written specifically for my device that fixes the problem completely, so I am putting faith in the kernel devs to fix it properly some day.
    – Zanna
    Feb 15, 2017 at 13:12
  • 1
    I agree with Zanna as is often the case :) Feb 15, 2017 at 13:42
  • 1
    No, I don't think so @ThatGuy it will be released with 4.10 and it's 4.9 now (see my answer)
    – Zanna
    Feb 16, 2017 at 21:58

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.

  • For Ubuntu 18.04 you should use the command at the following link because this way here will not work with it <<< askubuntu.com/questions/1048955/ubuntu-18-04-freeze/…
    – Bassem
    Oct 19, 2019 at 5:01
  • It's unfortunately still not fixed, sometimes the system works for a few weeks or even months but sooner or later it freezes :( - even with cstates=1 - I am now trying with cstates=0 to see if that makes any difference. Dec 23, 2021 at 21:17

You must log in to answer this question.

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