我有一台新的 System76 Lemur Pro 笔记本电脑，装有 Ubuntu 20.04。我真的很想喜欢它，但我发现它每周都会完全死机好几次，这让我心情有些沮丧。我联系了 System76 支持人员，但我也在尝试自己进行一些故障排除。我对 Linux 还不太熟悉，希望不仅能学习如何修复我的机器，还能学到将来有用的一般故障排除步骤。
系统：System76 Lemur Pro，i7，40GB RAM，单 SSD。Ubuntu 20.04。已安装所有更新。唯一的外围设备是插入鼠标和键盘的 USB 集线器，以及通过 USB-C 转 DisplayPort 适配器连接的外接显示器。没什么特别的。
碰撞：每周有几次，我会回到我的笔记本电脑前（通常是在它闲置了一整夜后的早晨），发现它对鼠标/键盘完全没有反应。使用 ALT+F_ 尝试切换到终端没有任何反应。ALT + PRTSCR + REISUB 没有任何反应。按下电源按钮没有任何反应。尝试打开内部 LCD 也没有任何反应。只有按住电源按钮并硬重置机器才能恢复。这种情况只发生过一次，当时我正在使用机器，Gnome 桌面保持可见，鼠标和键盘被锁定，我正在听的歌曲大约有 1/4 秒卡在循环中。只有硬重置才能恢复。
我尝试过的：
- 压力测试 CPU。我在运行压力测试几分钟的同时监控了 CPU 温度。温度从未超过 80 度，并且 CPU 风扇启动以控制温度。考虑到高温/临界温度被列为 100，这似乎是安全的。
- 运行 memtester。循环 5 次，全部通过。
- 安装 Ubuntu 推荐的任何更新。
- 查看系统日志 (/var/log/syslog)。系统挂起时这些日志会变成空白，直到我硬重置它才会恢复空白。崩溃前没有任何内容看起来非常有趣。
- 禁用睡眠。已经禁用了，但我想提一下。
此时，我不太确定下一步该怎么做。还有其他日志可以查看吗？我可以运行其他诊断程序吗？我是否应该假设它是外围设备并一次断开键盘/鼠标/显示器/集线器以尝试隔离？似乎不太可能是常见的外围设备，但谁知道呢。
编辑：根据要求，以下是/var/log/kern.log崩溃发生前的日志。它包含大量有关正在管理的 CPU 节流的信息。但是，当计算机稳定时，此类消息也会定期出现...
Oct 22 07:52:00 system76-pc kernel: [44320.095989] mce: CPU4: Package temperature above threshold, cpu clock throttled (total events = 7775)
Oct 22 07:52:00 system76-pc kernel: [44320.095990] mce: CPU1: Package temperature above threshold, cpu clock throttled (total events = 4669)
Oct 22 07:52:00 system76-pc kernel: [44320.095992] mce: CPU3: Package temperature above threshold, cpu clock throttled (total events = 719)
Oct 22 07:52:00 system76-pc kernel: [44320.095992] mce: CPU6: Package temperature above threshold, cpu clock throttled (total events = 752)
Oct 22 07:52:00 system76-pc kernel: [44320.095994] mce: CPU7: Package temperature above threshold, cpu clock throttled (total events = 752)
Oct 22 07:52:00 system76-pc kernel: [44320.096970] mce: CPU2: Package temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096972] mce: CPU0: Package temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096972] mce: CPU5: Package temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096973] mce: CPU3: Package temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096974] mce: CPU6: Core temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096974] mce: CPU7: Core temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096975] mce: CPU4: Package temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096976] mce: CPU1: Package temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096977] mce: CPU6: Package temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096977] mce: CPU7: Package temperature/speed normal
答案1
这是基于当前信息（包括来自评论的信息）的部分答案。
从日志文件中可以看出，这涉及到高 CPU 温度，以至于系统不断达到其节流温度极限。但是，CPU 压力测试表明没有问题。
作为测试，找到不可能出现 CPU 热问题的系统操作点，并以此方式运行足够长的时间，以确定对系统稳定性的影响。此测试的代价是性能。稍后，应研究适当的热守护程序（thermald、tlp 等），以恢复最大性能。
i7-10510U 的默认 CPU 频率调整驱动程序是 intel_pstate，此答案是针对该驱动程序编写的。通过以下方式检查：
doug@s15:~$ grep . /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu1/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu2/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu3/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu4/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu5/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu6/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu7/cpufreq/scaling_driver:intel_cpufreq
mprime (prime95) 高温酷刑测试被用作 CPU 压力测试，因为它消耗的能量是我测试过的所有 CPU 压力测试中最多的。为了保护我的示例计算机（该计算机没有运行热守护程序），将从低端找到所需的约 80 度的工作点。首先，记下当前的最大 CPU 频率百分比，同时记下最小值（您的值会有所不同）：
cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
doug@s15:~$ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
100
doug@s15:~$ cat /sys/devices/system/cpu/intel_pstate/min_perf_pct
42
如果某个热守护进程已经限制了某些事情，则可能不是 100%。无论如何，我将从 50% 开始：
doug@s15:~$ echo 50 | sudo tee /sys/devices/system/cpu/intel_pstate/max_perf_pct
50
然后逐渐提高最大 CPU 频率百分比，例如以 10% 为增量，并找到约 80 度处理器封装温度的工作点：
doug@s15:~$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,GFXWatt,IRQ --interval 6
Busy% Bzy_MHz IRQ PkgTmp PkgWatt GFXWatt
0.25 1754 725 25 3.81 0.12
0.02 1600 288 26 3.70 0.12
0.06 1600 360 26 3.70 0.12
38.82 1899 7740 39 16.28 0.12
100.00 1900 17594 41 36.20 0.12 <<< mprime torture test started
100.00 1900 17541 42 36.44 0.12
100.00 1900 17552 43 36.39 0.12
100.00 1900 17517 44 36.25 0.12
100.00 1927 17474 48 36.95 0.12
100.00 2300 17389 49 46.51 0.12
100.00 2300 17367 50 46.60 0.12
100.00 2300 17362 52 46.69 0.12
100.00 2300 17438 53 46.77 0.12
100.00 2552 18440 56 54.18 0.12
100.00 2700 17672 58 58.48 0.12
100.00 2700 17590 58 58.59 0.12
100.00 2700 17710 61 58.74 0.12
100.00 2953 17780 66 67.91 0.12
100.00 3100 17876 68 73.38 0.12 <<<< First time at 80%, temp lags.
100.00 3100 17843 69 73.55 0.12
100.00 3100 17860 70 73.64 0.12
100.00 3100 18794 71 73.78 0.12
100.00 3231 17826 77 79.69 0.12
100.00 3500 18305 80 92.33 0.12
100.00 3500 17765 81 92.66 0.12
100.00 3457 17747 80 90.72 0.12
100.00 3300 17720 81 82.62 0.12
100.00 3300 17723 81 82.72 0.12
100.00 3300 17708 80 82.81 0.12
100.00 3300 17712 83 82.95 0.12 <<<< Opps too high
100.00 3300 17788 82 83.08 0.12
100.00 3204 17882 81 79.25 0.12
100.00 3100 17778 80 74.78 0.12
100.00 3100 18571 81 74.83 0.12
100.00 3100 17806 80 74.85 0.12
100.00 3100 17787 80 74.89 0.12 <<<< 80 percent seems stable
100.00 3100 17772 81 74.84 0.12
100.00 3100 17824 81 74.85 0.12
100.00 3100 17777 80 74.89 0.12
100.00 3100 17799 81 74.95 0.12
100.00 3100 17867 81 74.77 0.12
因此，对于我的系统，将 CPU 频率限制为最大值的 80% 将使它们远离任何内置的额外热节流。以这种方式运行系统一段时间。
答案2
这是与 CPU 电源管理相关的内核错误。该问题已在 Ubuntu 20.10 附带的内核 5.8 中修复。我升级到 20.10，关闭了所有解决方法，现在运行稳定。
如果您不想升级到 5.8/20.10，您也可以通过阻止 CPU 进入低功耗状态（这显然会缩短电池寿命）来解决此错误。打开/etc/default/grub并添加intel_idle.max_cstate=1到值的内容GRUB_CMDLINE_LINUX_DEFAULT。保存，运行sudo update-grub，然后重新启动。反向执行该过程以撤消解决方法。
cstate 值高于 1 可能仍然是一种稳定的解决方法，但我从未进行足够的实验来验证。