Intel Bay Trail CPU问题是否会在17.04修复?

许多人在使用Ubuntu 14.04,16.04和16.10时遇到问题,系统完全死机,我就是其中之一。

我想知道Ubuntu 17.04是否能解决这个问题,是否已经修复了17.04的试用版ISO映像,然后才尝试下载并测试它。

TL; DR – 我的研究表明它并没有固定在17.04测试版或发布版中,但我对17.10寄予厚望。

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

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

这在内核4.2上游,我们从那时起就遇到了问题。 正如heynnema的回答 (以及我试图整理信息的这篇文章)中所解释的那样,有一种简单有效的解决方法,传递一个禁用低功耗状态的启动参数。

目前可用的测试版17.04使用4.9(根据我的理解,它基于上游4.9.6),到4月发布时,我相信它将使用4.10 。 问题仍然存在于这些内核中,所以我得出的结论是它现在还没有修复 。 我检查了Ubuntu内核更改日志,但什么也没找到,但如果我错了请纠正我。

我一直在kernel.org上跟踪c-state bug很长一段时间了。 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 )来检查进度,并在它到达时测试每个没有boot参数的新内核。 您还可以在安装新软件包时读取更改日志,或者(再次,如果您可以容忍不稳定性) 安装主线内核 。

在如何设置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是否需要此修复程序。