首頁 探索 說明
登入
zhensolid
/
obsidian
1
0
複刻 0
Files 問題管理 0 合併請求 0 Wiki
分支: master
分支列表 標籤列表
obsidian
/
99-归档
/
PVE原始笔记
/
PVE一长三短报警与核显死机排障记录.md

PVE一长三短报警与核显死机排障记录.md 12 KB
永久連結 文件歷史 原始文件

updated: 2026-10-13

tags: [PVE, 排错, 排障, iGPU, 蜂鸣, 倍控]

PVE (VUModule / 10.10.10.254) 一长三短报警与核显死机排障记录

与 [[PVE-显卡欺骗器与状态检测指令]]、[[PVE]] 相关

[!warning] 本页已于 2026-10-13 按实测同步 改掉了两处错的：「KSM 已禁用」不成立（从来没锁住）、「往 /etc/default/grub 里 sed 重加」是已废弃的做法。 现行参数与操作口径以《家庭网络部署与运维手册》（工作目录 CLAUDE.md §3.3）为准。

设备档案

  • 主机：VUModule = 10.10.10.254（root 免密 SSH）
  • 品牌：倍控（深圳市倍控工控 / BKIPC，官网 https://www.bkipc.com）——与 CWWK/Topton/HUNSN 同源的白牌 ODM
  • 硬件：Intel Core 3 N355（FCBGA-1264 N 系列）迷你主机（AMI BIOS 5.27 / 2025-03-20，UEFI）；单条 Samsung DDR5-4800 16GB；Kingston SNV2S500G；HDMI 欺骗器常插（HDMI-A-1）
  • 系统：pve-manager 9.2.21（Debian 13），内核 7.0.14-20-pve（2026-10-06 升级；旧记录里的 9.2.11 / 9.2.20 已过时），厂商 VUM 系统（/usr/.vum、vum-claw、AIfix）
  • VM：100 iKuai（主路由，直通4网卡）/ 101 OpenWrt / 102 WireGuard(1G) / 103 Lucky / 104 Centos10(6G) / 105 HAOS；每日 01:00 vzdump 到 local
  • 备注：6 台 VM 均不使用核显（无直通/无 VF，i915.max_vfs 运行时=0），核显仅服务宿主机显示输出

症状（含 2026-09-09 确认细节）

  1. 运行期整机瞬死（用户未操作、凌晨低负载备份时也会发生）：日志戛然而止无任何记录（9/9 01:03 备份 VM104 中途），整个网络全断 = 主机+6 台 VM 全死
  2. 之后按开机键：BIOS 一长三短，长按关机再开仍报
  3. 蜂鸣时硬盘读取红灯不亮 → BIOS 卡在引导之前（内存/SoC 初始化阶段失败，没轮到读硬盘）
  4. 必须拔市电（彻底放电）才能正常启动；欺骗器在位时频率从"约每天一次"降到"数月一次"
  5. 发生日期：2026-07-12（Hermes 处理）、2026-09-09（本次）

✅ 蜂鸣会不会响：2026-10-06 有实测口径了

正常重启不会响。 2026-10-06 内核升级后走的是 systemd-reboot（软重启，待机电路不断电），日志干净收尾（Finished systemd-reboot.service → Reached target reboot.target，无 panic / watchdog / Oops），全程无蜂鸣、无硬盘灯异常。

⇒ 蜂鸣只跟着「运行期瞬死之后的冷启动」出现，普通 reboot / 计划内重启不触发。所以升级、改配置这类主动重启不用怕响，怕的是它自己先死。

确认的故障模型（为什么换内存/加风扇/换 6A 电源都没用）

运行期硬件挂起（整机瞬死，网络全断）
  ↓  待机电路留下"脏电源状态"
下次冷启动 → 内存训练从脏状态开始 → 自检早期失败
  → 一长三短 + 硬盘灯不亮 + 必须拔电才能恢复
  • 头号嫌疑 = 核显/显示子系统电源状态 bug（DC 省电睡死）：Hermes 2026-07-12 诊断"Intel iGPU 电源管理"；欺骗器（改变显示子系统状态）把频率从每天压到数月；i915.enable_dc=0 生效后自 9/9 01:26 稳定运行
  • ⚠️ 第二嫌疑（2026-10-06 新增，未证实）= KSM：ksmtuned 一直在跑，随时能把 KSM 打开（详见下方专节）。KSM 合并页面正是能瞬间搞坏 VM 内存的那类操作。验证办法 = 彻底关掉 ksmtuned 后观察瞬死是否消失。
  • 已排除：内存条（换过无效）、散热（40℃级+自加2风扇）、电源（4A→6A 最好电源无效）、负载（凌晨低负载照样犯）
  • 结论：板级/固件缺陷，属倍控等白牌 N 系列软路由通病，非个例非操作问题

一长三短蜂鸣的含义

  • 该类白牌 AMI 板 1长3短 = 内存未检测/训练失败（ServetheHome 同款 CWWK/Topton 机型多例：拔内存条也报同样声）
  • 蜂鸣在 BIOS 阶段，OS/内核参数管不到；enable_dc=0 治的是上游"运行期死机"，不是蜂鸣本身
  • "硬盘灯不亮"佐证：失败发生在引导设备选择之前

关键结论：不是只有这台会这样（通病）

白牌 Intel N 系列软路由（N95/N100/N305/N355，倍控/CWWK/Topton/HUNSN 同源）在 headless + 软路由 + 核显活跃场景下：iGPU DC 省电死机 + 冷启动 1长3短 需拔电，均为社区公认问题；个体品控只影响频率。参考：https://forums.servethehome.com/index.php?threads/cwwk-topton-n95-n100-n200-n305-quad-nic-router-5-bios-error-beeps-and-black-screen-error.40333/

Hermes 三项改动核实（2026-09-09 记录，2026-10-13 复核修正）

改动 现状
① i915.enable_dc=0（iGPU 修复，7/12 08:59 加，备份 grub.bak-20260712） ✅ 2026-10-06 内核升级后仍在（三条复查全绿）。注意：现在参数是放在 /etc/default/grub.d/99-i915-enable-dc.cfg，不是主文件
② KSM 禁用（该内核写 KSM sysfs 会宕机） ❌ 原记录「仍在 ✅」是错的 —— 当时只是把 run 置成 0，没有任何持久化，ksmtuned 每次开机自启、随时能把它打开。2026-10-06 才真正用 systemctl mask ksmtuned 锁死
③ VM 内存：Centos10 8G→6G、WireGuard 2G→1G 仍在（104=6144MB、102=1024MB）✅

🔧 2026-10-06 复核实测（本轮升级后逐条查实）

升级内容：apt full-upgrade 09:44:09–09:44:46，pve-manager 9.2.20→9.2.21、内核 7.0.14-19→7.0.14-20；10:53 重启，6 台 VM 全部 onboot 自启恢复。

三条复查全绿：/proc/cmdline 含 i915.enable_dc=0 ✅ ｜ /sys/module/i915/parameters/enable_dc = 0 ✅ ｜ /sys/kernel/mm/ksm/run = 0 ✅

为什么固化文件以后不会再丢（证据，不再靠猜）

  1. grub-mkconfig 确实会读它：/usr/sbin/grub-mkconfig 第 163 行就是 for x in ${sysconfdir}/default/grub.d/*.cfg ; do —— 任何一次 update-grub（内核 postinst 会触发）都会把 .cfg 里的参数重新拼进 GRUB_CMDLINE_LINUX_DEFAULT。
  2. .cfg 不属于任何 deb 包，升级不碰它：同目录里的 proxmox-ve.cfg（2023-05-03）是 Proxmox 自己放的 —— 这是厂商也在用的正规位置，不是野路子。本次升级后 .cfg 的 mtime 仍是 2026-09-22 14:45:10，一动没动。
  3. 会被重写的恰恰是主文件：/etc/default/grub 的 mtime 是 2026-10-06 09:44:48（正是升级那一分钟，且目录与文件 mtime 相同到纳秒 = 文件被替换过，不只是被读）。

⚠️ 更正旧口径：「升级重生成 /etc/default/grub 把参数删了」

不准确。 实测该文件现存 5 份副本（/etc/default/grub.bak-20260712 / -20260719 / -20260909 / -20260922 + 当前）md5 完全一致（ff62eb423b734b0e14ee5c191e3cc4b0），里面从来就没有 enable_dc；且 dpkg -S /etc/default/grub 显示它不属于任何包。 ⇒ 当年丢的更可能是直接写进 /boot/grub/grub.cfg 的临时改动，被 update-grub 重新生成时冲掉。结论不变（固化路径对「主文件被替换」和「grub.cfg 被重生成」两种机制都免疫），但原因要按这条记。

✅ KSM：原来那句「已禁用」是假的，现已真正锁死

原状：ksmtuned.service 是 enabled + active（unit 来自 /usr/lib/systemd/system/ksmtuned.service，preset: enabled）⇒ 每次开机自己起来；/usr/sbin/ksmtuned 第 70 行就是 echo 1 > /sys/kernel/mm/ksm/run（它有权打开 KSM）；而 /etc/systemd/system/ksmtuned.service.d/ 不存在、没有 mask、/etc/ksmtuned.conf 全是注释无生效设置。 run=0 仅仅因为它恰好满足自己的「停 KSM」条件：(committed + thres < total) AND (free > thres)，其中 thres = total×20%、free = MemFree+Buffers+Cached。

量 当时实测值 触发线 余量
free（脚本口径） 3666 MB 3152 MB 只差 513 MB
committed（各 qemu VmRSS 合计） 10606 MB 12610 MB 只差 2003 MB

⇒ 宿主内存再紧 513 MB，ksmtuned 就会自己写 1。 6 台 VM 共分配 13 GB、宿主实有 15.7 GB，01:00 备份、VM 迁移这类时段轻松吃掉这个余量。

修复动作（2026-10-06 11:13 执行并核验）：

systemctl mask --now ksmtuned
# Created symlink '/etc/systemd/system/ksmtuned.service' → '/dev/null'

核验：is-enabled = masked、is-active = inactive、ksm/run = 0、pages_shared = 0，手动 systemctl start ksmtuned 被拒（Unit ksmtuned.service is masked.）。6 台 VM 全 running、内存无变化。

  • 为什么用 mask 不用 disable：disable 只摘自启链接，依赖或 preset 可能把它拉回来；mask 指向 /dev/null，连手动启动都拒绝，包升级也扛得住。
  • 代价：不再做 KSM 内存去重（当前 swap 20GB 占用 0，可接受）；将来若加 VM / 内存吃紧需重新评估。

厂商（倍控）官方 BIOS 更新渠道

  • 官网刷写教程：https://www.bkipc.com/cn/new/BIOS-Update.html
  • 固件需向厂商索取（官网不直接挂 BIOS 文件）：淘宝店铺客服 / 邮箱 info@bkipc.com / 电话 13636923655（陈女士 18659912363）
  • 索取话术：报"N355 多网口小主机，BIOS 5.27（2025-03-20）。无显示器/只用欺骗器时：运行中会整机瞬死、重启卡一长三短、必须拔电源。有没有新版 BIOS 修复显示/电源状态问题？请发 bin 固件+UEFI 引导文件。"
  • 刷写要点（官网流程）：FAT32 空 U 盘（DISKGenius 格式化）→ 放 UEFI 引导文件 + XXXX.bin → 移除机器上所有硬盘只插 U 盘 → 开机 Del 进 BIOS 选 U 盘启动 → fs0: → dir → fpt -X XXXX.bin → 等待自动重启；⚠️ 刷机过程严禁断电

排查/验证命令（升级后必查三条）

grep enable_dc /proc/cmdline              # 应看到 i915.enable_dc=0
cat /sys/module/i915/parameters/enable_dc # 应为 0；若为 -1 说明防护已失效
cat /sys/kernel/mm/ksm/run                # 应为 0（ksmtuned 已 mask，正常恒为 0；若变 1 说明有东西绕过 mask）
ip route get 10.10.10.253                 # 旁路由侧：应仍为 dev br-lan（查 ZeroTier 有没有抢路由）

备份文件：/etc/default/grub.bak-20260712、grub.bak-20260719、grub.bak-20260909、grub.bak-20260922（均为无参原始版）

✅ 重加/回滚方法（2026-10-13 换成正确做法）

⚠️ 旧版这里的 sed -i 直接改 /etc/default/grub 已废弃 —— 那是会被升级替换掉的文件，参数放进去迟早丢。

# 正确做法：写进 grub.d 固化文件（幂等，升级不会碰它）
cat > /etc/default/grub.d/99-i915-enable-dc.cfg <<'EOF'
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT i915.enable_dc=0"
EOF
update-grub            # 必须执行，否则文件写了也进不了 grub.cfg
# 重启宿主后核对：grep enable_dc /proc/cmdline

# 回滚（去掉这个参数）
rm /etc/default/grub.d/99-i915-enable-dc.cfg && update-grub

⚠️ 待办（2026-10-13 更新）

  • 对照实验（区分核显 bug vs 板级死锁）：进 BIOS 找"Internal Graphics/禁用核显 → Disabled"，关掉跑 2–4 周 → 从此不死=实锤核显 bug 一劳永逸；无该选项或照死=板级问题 → 走倍控售后换机（6 台 VM 都不用核显，可放心关）
  • 兜底（主路由刚需，9/9 已确认网全断）：BIOS 设 Restore on AC Power Loss = Always On + 智能插座 → 远程断电送电 = 远程拔电，半夜犯病不用爬过去
  • 找倍控要新版 BIOS / 谈售后（渠道与话术见上）
  • PVE 内核升级后复查 enable_dc → 已固化到 /etc/default/grub.d/，2026-10-06 内核升级实测扛住；仍建议每次升级后跑一遍「必查三条」
  • 2026-09-09 01:26 enable_dc=0 重加重启生效；9/9 10:00 复查：运行时=0，机器稳定
  • 2026-10-06 复核：三条全绿、KSM 已 mask（见上）
  • 观察 KSM 假设：mask 掉 ksmtuned 之后，"运行期整机瞬死"是否还犯 —— 若几个月不再犯，KSM 就是共犯甚至主犯
  • memtest86+：优先级低（症状=运行期挂起而非内存内容错误），想彻底排除可跑