☰

使用 Intel Bay Trail 时系统完全冻结

tag-icon • tag-icon 16.04 kernel intel
使用 Intel Bay Trail 时系统完全冻结

我的系统会随机、频繁地完全冻结。我在 Ubuntu 14.04 中开始遇到同样的问题，但最近升级到 16.04 后没有任何改善，事实上似乎更糟了。

当这种情况发生时，什么都做不了。我已经尝试了这个帖子中的所有方法：Ubuntu 死机时该怎么办但什么都不起作用，我不得不硬重置。我已经阅读了所有系统日志，journalctl但没有任何信息可以帮助诊断问题。

这是与 Windows 10 的双启动系统，没有任何问题，所以不是硬件缺陷。

我的笔记本电脑配有英特尔 Bay Trail 处理器（奔腾 N3540）

答案1

您的处理器受到c 状态错误

当 CPU 尝试进入不受支持的睡眠状态时，这会导致完全冻结。这是许多 Bay Trail 设备的问题，尤其是采用较新 (4.*) 内核的设备。

据我所知受影响的处理器：

Atom Z3735F (Asus X205TA, Acer Aspire Switch 10, Lenovo MIIX 3 1030) 
Atom Z3735G
Celeron J1900 (Asus ET2325IUK, shuttle XS35V4)
Celeron N2940 (Acer Aspire ES1-711, Chromebook)
Celeron N2840 (Acer Aspire ES1-311)
Celeron N2930 (Jetway JBC311U93, Zotac Nano CI320)
Pentium N3520 
Pentium N3530 (Acer V3-111P)
Pentium N3540 (Dell Inspiron 15 3000, Lenovo G50, ASUS X550MJ)

（如果受到影响，请（建议）编辑以添加您自己的设备）

完整的 Bay Trail 处理器列表可在此处找到

在问题得到上游正确修复之前，有一个简单的解决方法。

你只需要通过内核启动参数随机冻结将完全停止。此参数可能会稍微增加电池消耗，但会为您提供可用的系统。

您可以通过编辑 GRUB 的配置文件来完成此操作：

启动 Ubuntu 并按Ctrl+ Alt+打开终端T，然后输入

sudo nano /etc/default/grub

找到以GRUB_CMDLINE_LINUX_DEFAULT=

这需要更改为包括intel_idle.max_cstate=1

因此，编辑后的内容如下

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"

quiet和splash是 Ubuntu Desktop 的默认参数 - 无需更改它们或任何其他预先存在的参数

ctrl现在按+保存文件，o然后enter按ctrl+退出x

现在运行

sudo update-grub

然后重新启动。

如果在系统挂起之前没有足够的时间执行此操作，该怎么办

没问题。正如我之前链接的帮助页面中所述，您可以在启动之前将参数添加到 GRUB。请注意，这只会传递当前启动的参数，因此您仍必须/etc/default/grub在启动后进行编辑以使更改永久生效。

你需要到达GRUB 菜单shift。如果您是双启动，它无论如何都会出现，如果没有，您必须在按下电源按钮后按住（或点击）才能打开。

当您到达此屏幕时选择Ubuntu 的高级选项。您可以将光标移至其他内核，或将其保留在原处以编辑默认选项。不要按enter，而是按e，您将进入编辑模式，看起来类似于这。

将光标向下移动到显示的位置quiet splash，在 splash 后留一个空格，然后小心输入，intel_idle.max_cstate=1确保其后也有一个空格。

现在按F10或Ctrl+x来启动。

答案2

Bay Trail 和 Braswell 处理器上的 Linux 会随机因内置视频设备而冻结。

问题出在温度控制上。只需删除 thermald 模块：

sudo apt-get remove thermald

答案3

对于关注此错误的人来说，这里有一个更新。前往：Bug 109051 - baytrail 上需要 intel_idle.max_cstate=1 来防止崩溃并按下End键。如有必要，按Page Up发送消息 #1013。

根据评论#1013，该问题已在最近的内核中得到修复：

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

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

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

相关内容