跳到主要内容

AI帮我搞定了一个Ubuntu笔记本CPU限频怪问题

阅读需 4 分钟

最近我这台 HP Laptop 14s-cr2xxx 装的 Ubuntu 24.04 出了一个很烦的问题：单核看起来还能冲一下，多核一上来频率就很低，系统会有明显卡顿。

最开始我以为就是普通的省电模式或者功率限制，结果越查越发现这不是一个常规问题，而是一个非常偏门的 Linux 平台兼容问题。更让我感慨的是，这次从排查到拿到可用方案，真的是靠 AI 很快就搞定了。以前这种问题，我大概率会在各种论坛、内核 issue、BIOS 说明文档和驱动资料里翻好几天，而且还不一定能把根因抠出来。

现象很怪​

这台机器的 CPU 是 Intel i7-10510U。在 Windows 里压测时，它的表现其实是正常的：

  • 刚开始能冲到 30W+
  • 温度到 80°C+ 后回落
  • 最后稳定在大约 15W / 1.9GHz / 70°C+

这很像正常的 PL2 -> PL1 行为，说明硬件本体、散热和供电并没有彻底坏掉。

但同一台机器在 Ubuntu 里完全不一样：

  • 多核长期只有大约 7.5W - 7.8W
  • 频率大约只有 1.2GHz - 1.3GHz
  • IA32_THERM_STATUS 一直能看到 power limit status=1
  • 温度却并不高

也就是说，Linux 下不是“热得顶不住”，而是“还没热起来就被某个功耗限制压住了”。

AI是怎么排这个问题的​

这次最有意思的地方，不是最后那条 workaround，而是排查过程本身。

我直接让 AI 在本机终端里动手查。它不是只给我一些泛泛的建议，而是一步一步去做了实际验证：

  1. 检查 powerprofilesctl、intel_pstate、turbo 和 RAPL
  2. 检查第三方限功脚本 throttled
  3. 检查 thermald
  4. 对比 6.17 HWE 和 6.8 GA 两条内核线
  5. 对比接电和电池
  6. 对比 Windows 和 Ubuntu 的持续功耗表现
  7. 用 turbostat、rdmsr、openssl speed -multi 8 做同口径压测
  8. 最后做 Linux 平台热管理模块的 A/B 实验

其中有几个关键结论非常重要：

1. 不是单纯的 governor 问题​

performance 也试过，min_perf_pct=100 也试过，变化不大。

2. 不是单纯的 throttled 问题​

停掉 throttled 之后，单核表现确实改善了，但多核持续功耗还是偏低，主问题仍然存在。

3. 不是某一个 Ubuntu 内核版本单独坏掉​

6.17.0-14、6.17.0-29、6.8.0-117 都测试过，核心问题都还在。

4. 不是硬件彻底坏了​

因为 Windows 下它能稳定跑到 15W / 1.9GHz 左右，这一点非常关键。

真正的瓶颈：processor_thermal​

真正把范围快速缩小的，是一次非常有效的 A/B 测试。

在 Linux 下，AI 临时停掉 thermald 和 throttled，然后运行时卸载 processor_thermal 这一整条平台热管理链，再用同一组命令压测：

sudo turbostat --quiet \
  --show Core,CPU,Avg_MHz,Bzy_MHz,TSC_MHz,Busy%,PkgTmp,PkgWatt,CorWatt,GFXWatt,RAMWatt \
  -i 1 --num_iterations 8 \
  -- bash -lc 'openssl speed -seconds 7 -bytes 8192 -multi 8 sha256 >/dev/null'

结果很直接：

  • 默认 Linux 状态：大约 7.6W - 7.8W / 1.3GHz
  • 只停 throttled：单核好一些，但多核还是不对
  • 卸载 processor_thermal 链后：大约 10W / 1.8GHz

这个提升已经非常明显了，而且测试时温度也没有飙到危险区。

后面还顺手验证了一件事：把 psys 长期限额从 15W 临时提到 20W 基本没收益。所以根因不是简单的 RAPL 数值太保守，而是 Linux 这条 processor_thermal 平台热管理链在这台机器上过于激进。

最后的解决方案​

最终没有走那种很重的 kernel cmdline 或永久屏蔽一堆驱动的做法，而是做了一个更克制的 systemd watchdog service。

它的思路很简单：

  • fast 模式：
    • 停掉 thermald
    • 保持 throttled 停止
    • 卸载 processor_thermal 相关模块
  • safe 模式：
    • 重新加载这些模块
    • 恢复 thermald

切换条件也比较保守：

  • 接电且包温 <= 68°C：进入 fast
  • 包温 >= 78°C：切回 safe
  • 电池模式：强制 safe
  • 轮询间隔：1s

这不是一个“通用优化脚本”，而是针对特定平台问题做的 Linux 侧 workaround。它没有伪装成银弹，而是明确承认自己是平台级折中方案。

最终效果​

我后面又做了一次更长时间的实际测试，结果比短测更有说服力：

  • 温度长期稳定在大约 67°C
  • 频率稳定在大约 1.8GHz

这和前面的短测基本一致，也说明这套方案在我的实际工作场景里是可用的。

它没有把机器拉回 Windows 下的 15W / 1.9GHz，但已经把 Linux 下原本那种 1.3GHz 左右、用起来发卡的状态明显改善了。

为什么这次让我觉得 AI 真的很厉害​

说实话，这件事最让我有感触的，不是“AI 给了我一个命令”，而是它把整个排障流程做得非常像一个真正的工程师：

  • 会先怀疑硬件、BIOS、适配器、内核、电源策略这些不同层次
  • 会主动设计 A/B 测试，而不是停留在猜测
  • 会根据实测结果不断缩小范围
  • 会在“可解释”和“可回退”的前提下给出 workaround
  • 最后还顺手把脚本、文档和安装方式整理好了

以前这种小众问题，尤其还是“某个 HP 笔记本 + Intel U 系列 + Ubuntu + 特定 thermal chain”这种组合，我大概率会花好几天时间：

  • 先怀疑是 BIOS
  • 再怀疑是电源适配器
  • 再怀疑是某个 governor
  • 接着去搜各种论坛帖子
  • 找到一堆彼此矛盾的建议
  • 试一圈后还不一定知道真正问题在哪

现在不一样了。AI 不只是“给答案”，而是能直接在当前环境里做实验、看数据、改脚本、验证结果。很多以前很碎、很脏、很依赖耐心的排障工作，现在真的能被压缩到一两个会话里完成。

这次我最大的感受就是：AI 解决问题这件事，已经不是“未来会很厉害”，而是真的已经很厉害了。

总结​

这次问题最后的结论可以归纳成一句话：

这不是 CPU 坏了，也不是单纯的 Ubuntu 省电模式问题，而是这台机器在 Linux 下被 processor_thermal 平台热管理链压得过于保守。

最终方案不是去蛮力强拉功耗，而是做一个带温度阈值的自动切换 service，在安全边界内换回更合理的持续性能。

更重要的是，这次让我非常直观地感受到，AI 已经可以把“小众问题排查 + 方案实现 + 文档整理”这一整条链路显著提速了。以前几天都不一定搞定的东西，现在真的可以很快搞定。

Loading Comments...