英特尔Bay Trail CPU问题是否可以在17.04中解决？

许多人在Ubuntu 14.04、16.04和16.10上遇到问题，这些问题导致系统完全死机，我就是其中之一。

我想知道Ubuntu 17.04是否可以解决该问题，是否已经在17.04的试用ISO映像上解决了该问题，然后再尝试下载并对其进行测试。

TL; DR-我的研究表明，该问题并未在17.04 beta映像或发行版中得到修复，但我对17.10寄予厚望。

当处理器尝试进入内核不支持的低功耗状态（c状态）时，就会发生这些冻结。这个问题是由

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

这是内核4.2的上游问题，自那时以来我们一直遇到问题。如heynnema的回答（以及本人试图整理信息的文章）所述，有一个直接有效的解决方法，传递一个禁用低功耗状态的启动参数。

当前可用的beta版本17.04使用4.9（据我了解，它基于上游4.9.6），到4月发布该版本时，我相信它将使用4.10。这些内核中仍然存在该问题，因此我得出的结论是，到目前为止，该问题尚未解决。我检查了Ubuntu内核的变更日志，却一无所获，但是如果我错了，请更正我。

我已经在kernel.org上跟踪了c状态错误很长时间了。2017年1月，Mika Kuoppala将这个补丁添加到了线程中。显然，它还原了导致问题的早期提交。该补丁称为

drm/i915/byt: Avoid tweaking evaluation thresholds

测试表明，此修补程序的结果非常好，该修补程序已于1月25日提交给i915驱动程序所有者。 一切都很好，它可以在4.11窗口中合并。4.11内核可能会在4月底左右发布。 此修补程序的一个版本已在4.11窗口中合并，并且报告指出该错误已在4.11中修复。

每个麻烦的BayTrail处理器在每个不同的内核上的行为都有些不同。在16.04（4.4内核）中，没有intel_idle参数的Atom Z3735F的正常运行时间大约是冻结前15分钟。我在实时模式下测试了beta 17.04 ISO，但在90分钟内没有死机，所以我似乎很幸运使用此内核。您可以执行相同的操作来测试系统上的任何映像-只需制作一个可引导的USB并“尝试不安装Ubuntu”并对其进行尽可能长的测试。

当17.04发布时，我安装了它，并且在头两个星期中我在没有intel_idle参数的情况下运行了它，但我只有三个c状态冻结，这是对早期版本的巨大改进。

最安全的操作是使用boot参数。根据我的研究，我期望该错误将在17.10（以及今年晚些时候的其他发行版）中修复，该错误将使用> = 4.11的内核，但在17.04中不会。

但是，Ubuntu内核团队总是有可能自己对其进行修补。如果您可以容忍偶尔运行不稳定的系统，则可以通过运行常规更新（sudo apt update && sudo apt full-upgrade）并测试每个没有引导参数的新内核来监视进度。您还可以在安装新软件包时阅读更改日志，或者（同样，如果可以忍受不稳定的话）安装主线内核。

如何设置intel_idle.max_cstate = 1中对此有一个修复。

在中terminal，输入：

gksudo gedit /etc/default/grub

并更改此行：

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

包括以下内容：

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"

然后做：

sudo update-grub
reboot

这是英特尔的问题，不是Ubuntu的问题，但是谢天谢地，我们已经解决了问题。

没人知道Ubuntu 17.04是否需要此修复程序。

根据错误报告中的注释1013，现在已修复：

我已经很长时间没有检查过此线程了，但是我认为我应该发布我的发现，以防万一它对任何人都有用。

一台搭载Intel N2807的低端计算机，在我未设置... max_cstates = 1时，其工作时间从未超过3000万而不崩溃，现在与5.3.1或4.19.75版本的内核完美兼容。我在每个版本上都运行了几天，没有任何问题。平均功耗也下降了10％多一点。

最早于2015年12月8日报告此错误，大约花了四年的时间来解决。