Will the Intel Bay Trail CPU problem be fixed in 17.04?

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.

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:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

to include this:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"

then do:

sudo update-grub
reboot

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.

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.