☰

Intel Bay Trail CPU 问题会在 17.04 中修复吗？

tag-icon • tag-icon kernel intel
Intel Bay Trail CPU 问题会在 17.04 中修复吗？

许多人在使用 Ubuntu 14.04、16.04 和 16.10 时都遇到系统完全冻结的问题，我也是其中之一。

在我尝试下载并测试它之前，我想知道 Ubuntu 17.04 是否会修复该问题，以及它是否已经在 17.04 的试用版 ISO 映像上修复。

答案1

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 错误很长一段时间。2017 年 1 月，Mika Kuoppala 补充道此补丁到线程。显然，它恢复了导致问题的早期提交。该补丁名为

drm/i915/byt: Avoid tweaking evaluation thresholds

测试表明，此补丁的效果非常好，该补丁于 1 月 25 日提交给 i915 驱动程序所有者。如果一切顺利，它可能会合并到 4.11 窗口中。4.11 内核可能会在四月底左右发布。 该补丁的一个版本已在 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 状态冻结，这比早期版本有了很大的改进。

最安全的做法是使用启动参数。根据我的研究，我预计该错误将在 17.10（以及今年晚些时候发布的其他发行版）中得到修复，该版本将使用 >=4.11 的内核，但不是在 17.04。

但是，Ubuntu 内核团队始终有可能自己修补它。如果您可以忍受偶尔运行不稳定的系统，您可以通过运行定期更新 ( sudo apt update && sudo apt full-upgrade) 并在新内核到达时对其进行测试（不带启动参数）来观察进度。您还可以安装新软件包时阅读变更日志或者（同样，如果你能忍受不稳定性）安装主线内核。

答案2

有一个修复这个问题的如何设置 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 是否需要此修复。

答案3

根据评论# 1013错误报告现已修复：

我很久没有检查过这个帖子了，但我认为我应该发布我的发现，以防它对任何人有用。

一台搭载 Intel N2807 的低端计算机，在我没有设置 ...max_cstates=1 时，从未运行超过 30 分钟而不崩溃，但现在在原版内核 v. 5.3.1 或 4.19.75 下运行良好。我使用每个版本运行了几天，没有任何问题。平均功耗也下降了 10% 多一点。

修复这个于 2015 年 12 月 8 日首次报告的漏洞花了大约四年时间。

相关内容