Bassem Asked: 2017-02-15 16:21:32 +0800 CST2017-02-15 16:21:32 +0800 CST 2017-02-15 16:21:32 +0800 CST Intel Bay Trail CPU 问题会在 17.04 中修复吗？ 772 许多人在使用 Ubuntu 14.04、16.04 和 16.10 时系统完全冻结，我就是其中之一。 在我尝试下载并测试之前，我想知道 Ubuntu 17.04 是否会修复该问题，是否已经在 17.04 的试用版 ISO 映像上修复。 kernel 3 个回答 Voted Best Answer Zanna 2017-02-17T11:23:32+08:002017-02-17T11:23:32+08:00 TL;DR - 我的研究表明它在 17.04 测试版映像或发行版中并未修复，但我对 17.10 寄予厚望。 当处理器尝试进入内核不支持的低功耗状态（c-state）时，就会发生这些冻结。这个问题是由 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 分钟。我在 live 模式下测试了 beta 17.04 ISO，在 90 分钟内我没有冻结，所以看起来我对这个内核很幸运。你可以做同样的事情来测试你系统上的任何映像——只需制作一个可引导的 USB 并“在不安装的情况下尝试 Ubuntu”并尽可能长时间地对其进行测试。 当 17.04 出来的时候，我安装了它，前两周我在没有intel_idle参数的情况下运行它，我只有 3 次 c-state freeze，这对早期版本来说是一个巨大的改进。 最安全的做法是使用引导参数。根据我的研究，我预计该错误将在 17.10（以及今年晚些时候的其他发行版）中修复，该版本将使用 >=4.11 的内核，但不会在 17.04 中修复。 但是，Ubuntu 内核团队总是有可能自己修补它。如果您可以容忍偶尔运行不稳定的系统，您可以通过运行定期更新sudo apt update && sudo apt full-upgrade（您还可以在安装新软件包或（再次，如果您可以容忍不稳定性）安装主线内核时阅读更改日志。 heynnema 2017-02-15T16:37:03+08:002017-02-15T16:37:03+08:00 如何设置 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 这是 Intel 的问题，不是 Ubuntu 的问题，但谢天谢地，我们已经解决了。 没人知道 Ubuntu 17.04 是否需要这个修复。 WinEunuuchs2Unix 2019-09-30T06:28:46+08:002019-09-30T06:28:46+08:00 根据错误报告中的评论# 1013，它现在已修复： 我很久没有检查这个帖子了，但我想我应该发布我的发现，以防万一它对任何人有用。 一台搭载 Intel N2807 的低端计算机在我没有设置 ...max_cstates=1 时从未运行超过 3000 万次而不会崩溃，现在它与库存内核 v. 5.3.1 或 4.19.75 完美配合。每个版本我都运行了几天，没有任何问题。平均功耗也下降了10%多一点。 2015 年 12 月 8 日首次报告的这个 bug 花了大约四年的时间来修复。
TL;DR - 我的研究表明它在 17.04 测试版映像或发行版中并未修复，但我对 17.10 寄予厚望。
当处理器尝试进入内核不支持的低功耗状态（c-state）时，就会发生这些冻结。这个问题是由
这在内核 4.2 中进入了上游，从那时起我们就遇到了问题。正如heynnema 的回答（以及我试图整理信息的这篇文章）中所解释的，有一个简单有效的解决方法，传递一个禁用低功耗状态的引导参数。
目前可用的 17.04 测试版使用 4.9 （据我了解，它基于上游 4.9.6 ），到 4 月发布时，我相信它将使用 4.10。这些内核中仍然存在问题，所以我得出的结论是它现在还没有修复。我检查了 Ubuntu 内核更改日志，但一无所获，但如果我错了，请纠正我。
我一直在 kernel.org 上跟踪 c-state 错误很长时间。2017 年 1 月，Mika Kuoppala将此补丁添加到线程中。显然，它恢复了导致问题的早期提交。该补丁称为
测试表明此补丁的效果非常好，该补丁已于 1 月 25 日提交给 i915 驱动程序所有者。
一切顺利，它可以合并到 4.11 窗口中。4.11 内核可能会在四月底左右发布。此补丁的一个版本已合并到 4.11 窗口中，并且报告表明该错误已在 4.11 中修复。每个麻烦的 BayTrail 处理器对每个不同的内核的行为都略有不同。在 16.04（4.4 内核）中，我在没有 intel_idle 参数的情况下在 Atom Z3735F 上的正常运行时间大约是冻结前 15 分钟。我在 live 模式下测试了 beta 17.04 ISO，在 90 分钟内我没有冻结，所以看起来我对这个内核很幸运。你可以做同样的事情来测试你系统上的任何映像——只需制作一个可引导的 USB 并“在不安装的情况下尝试 Ubuntu”并尽可能长时间地对其进行测试。
当 17.04 出来的时候，我安装了它，前两周我在没有
intel_idle参数的情况下运行它，我只有 3 次 c-state freeze，这对早期版本来说是一个巨大的改进。最安全的做法是使用引导参数。根据我的研究，我预计该错误将在 17.10（以及今年晚些时候的其他发行版）中修复，该版本将使用 >=4.11 的内核，但不会在 17.04 中修复。
但是，Ubuntu 内核团队总是有可能自己修补它。如果您可以容忍偶尔运行不稳定的系统，您可以通过运行定期更新
sudo apt update && sudo apt full-upgrade（您还可以在安装新软件包或（再次，如果您可以容忍不稳定性）安装主线内核时阅读更改日志。如何设置 intel_idle.max_cstate=1对此有一个修复。
在
terminal中，键入：并更改此行：
包括这个：
然后做：
这是 Intel 的问题，不是 Ubuntu 的问题，但谢天谢地，我们已经解决了。
没人知道 Ubuntu 17.04 是否需要这个修复。
根据错误报告中的评论# 1013，它现在已修复：
2015 年 12 月 8 日首次报告的这个 bug 花了大约四年的时间来修复。