j3455卡死问题分析解决

root 2025-03-04

缘起

年前稳定运行了很长时间的j3455处理器系统挂了，反复分析折腾了很久才查到具体的原因，以及j3455处理器的显示系统故障问题，因此记录详细的过程，方便回顾以及类似问题的参考。

折腾过程

稳定运行很长时间的系统突然挂了

1月12日早上7点28突然挂了，电源常亮，宿主和各个虚拟机都ping不通，长按关机都不行。

后接入显示器，尝试断电后重新进入，发现bios被重置，重新设置bios后插入usb键盘设置后开机，上午10点多开机，12点多回来发现还是卡死了。

看显示器显示：

kvm [1180]: vcpu2, guest rIP: 0xffffffff8171f127 vmx: unexpected exit reason 0x3

看起来是cpu异常导致卡死了。

下午5点多开机，晚上9点多发现还是死机了，dmesg错误有下面几种：

kvm [1180]: vcpu2, guest rIP: 0xffffffff8171f127 vmx: unexpected exit reason 0x3


corrupted stack end detected inside scheduler 错误

Soft lockup - CPU#0 stuck for 22s 错误

kernel panic错误

后晚上开机多次都不行，13日晚上下班回来继续排查，各种尝试开机都不行。

至此确定不是运行时的偶发问题，而是cpu出现了严重的系统无法恢复的异常。

怀疑kvm的windows虚拟机导致

偶然发现规律是开机等一会开启win虚拟机时存在问题，把win虚拟机关掉不开启发现暂时没问题了，后继续排查，发现是kvm分区磁盘空间满了，只剩下300多MB，清理出来4.xG后再次尝试，发现问题临时解除。

到这里以为发现问题了，其实远远没有发现问题原因，当时以为：

这么看来，应该是在昨天早上，kvm磁盘分区满了，在win虚拟机系统操作磁盘时，出现了异常，报vcpu错误，然后系统就卡死了

最终运行一段时间后，发现还是不行，尝试降低内存从5.5到4.5G，尝试关闭了win10虚拟机的启动，有缓解但没解决。

至此，确定不是windows虚拟机的问题。

怀疑是cpu相关设置导致

参考https://duckgle.in/posts/QTJ1%E5%A4%84%E7%90%86%E5%99%A8-Shutting-down-CPUs-with-NMI/ 设置了启动参数没解决，修改了bios cpu state相关参数、csm兼容性开启，均未解决

这里是参考网上分析是c state导致的cpu异常问题，在系统日志里，也确实发现存在kvm相关的cpu报错。

[1月21 02:31] kvm [47022]: vcpu0, guest rIP: 0xfffff80566611eff vmx: unexpected exit reason 0x3
[  +0.000014] set kvm_intel.dump_invalid_vmcs=1 to dump internal KVM state.
[  +0.000277] kvm [1157]: vcpu3, guest rIP: 0xffffffffb470c5be vmx: unexpected exit reason 0x3
[  +0.000013] set kvm_intel.dump_invalid_vmcs=1 to dump internal KVM state.
[  +0.000602] kvm [1157]: vcpu2, guest rIP: 0xffffffffb470c5be vmx: unexpected exit reason 0x3
[  +0.000014] set kvm_intel.dump_invalid_vmcs=1 to dump internal KVM state.

至此，判断不是cpu的state或者bios相关设置导致的问题。

怀疑是内存异常问题

使用usb启动系统安装盘，使用memtest测试了内存没有任何问题。

至此，也排除了内存的问题。

发现高负载不会死机

因为怀疑是内核问题，1月20日尝试编译新的kernel看看能不能解决，意外发现一直编译内核高负载反而不会出现问题了，尝试搜索低负载死机，发现都是讲关闭cpu cstate的，尝试关闭后不能解决问题。

而从实验情况看，设置cstate并不能解决问题，网络上关于cpu低负载死机，高负载不死机问题的答案，都讲是cpu 的c state的问题。

至此，排除了c state问题。

尝试更新bios

中途也比较巧25年1月15日华擎更新了1.9的bios，结果发现更新bios也没办法解决问题。。。

而此时华擎间隔5年发布bios更新，可能印证了19年j3455的cpu intel发布过存在硬件缺陷的问题，可能是到近期爆发了？可是实验后不能解决问题。。。

至此，也排除了bios的问题。

尝试排查电源问题

1月23日拆机把电源换了，发现不是电源的问题，至此基本上就排除过一遍了，硬件内存、电源都没问题，那就是主板的问题了。。。

最后试了下用万用表量了一下bios电池的电压，只有0.76v，正常应该是有2.9-3.0v的，换了一个电池上去，神奇的就解决了没有问题了，fuck。。。。

此时感觉发现了问题原因，后来以为解决了，放到机箱里又不行了，注意：此时插着显示器

那么问题在哪里呢？是不是bios电池没电导致？不死心的又试了其他的思路。

尝试排除系统问题

试了23年的备份另一个盘的23年的ubuntu系统，发现不行，也会卡死，没有运行virsh虚拟机，也试了不插显示器，也是不行。但是这里有一个点，之前j3455的前几年一直不稳定，一直到23年下半年自己编译的kernel才比较稳定。

买了新的bios电池换上也还是不行，但是长按重启能够正常运行的，因此原始故障里长按不行的问题，bios电池没电也是主要原因。

1月26日使用u盘试了下ubuntu18 desktop系统，试用情况下半天没有死机，于是重装了一个ubunut18 desktop试了下，发现开机花屏进不去系统，设置了bios里显卡的共享内存到64MB，意外的可以进去了，然后在启动界面进行了memtest，看起来内存没有什么异常，memtest目前跑了35分钟没有异常，内存测试了一夜，没有问题。

经过测试，发现desktop接显示器的新安装的系统，新的硬盘，机器还是会出现死机情况。

排查cpu的mce错误

2月1日也使用排除法，把电源、硬盘、系统都换了，均出现问题，所以应该是硬件问题了，而内存没问题，那就是主板或者cpu的问题了。

2月1日，通过测试发现新安装的ubuntu系统，也会出现卡死情况，意外在安装新的ubuntu系统时，启动的时候，会打印mce错误，发现每次都是cpu0报mce错误，通过查询把它屏蔽就好了。

这里安装mcelog（参考后边的参考文档），后发现如下的mcelog硬件报错。

~$ sudo dmesg |grep mce
[    0.044359] mce: CPU supports 7 MCE banks
[    0.062493] mce: [Hardware Error]: Machine check events logged
[    0.062498] mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 4: a600000000020408
[    0.062503] mce: [Hardware Error]: TSC 0 ADDR fef13bc0
[    0.062510] mce: [Hardware Error]: PROCESSOR 0:506c9 TIME 1738456541 SOCKET 0 APIC 0 microcode 3c

通过这个mce的错误看，cpu0看起来有问题，通过isolcpus=0把cpu0禁用掉，经过大半天测试可以解决问题。

至此，以为已经解决了问题。

最终发现是显示系统问题

2月3日坑爹的事情来了，上面禁用了cpu0解决问题后，尝试分析具体的原因，就把cpu隔离去除掉了。

然后惊奇的发现，居然不死机了，而只要插上hdmi显示器，就会死机，否则就是很正常的，这个就非常的奇怪了。

也就是说上面分析到的原因可能还不是根本原因，实际上只要不连接hdmi显示器就可以正常使用，不用屏蔽cpu

而原始的问题，可能就是bios电池没电了，换了电池后，一直连接hdmi导致的不停死机？

但是之前也试过不连接显示器，也不行的，是必须不插hmdi线缆？还是bios更新和intel-microcode更新导致的行为变化？

经过验证，只要连接hdmi显示器，不管是否屏蔽cpu0，都会出现死机的情况，也就是说不插线就能正常的使用，插上hdmi的显示器就不行了。

试了下降级bios，卸载intel-microcode包，微码变为2e了，试了下，仍然是会出现插显示器死机的问题

不插显示器就没问题，所以基本确定是cpu存在问题，插显示器就启动不起来或者运行一段时间卡死，和微码版本也没有关系。

至此，确定整体就是gpu显示系统的问题。现在就是j3455的cpu，gpu或者显示系统已经挂了，只要连接显示器，就会挂掉。

扩展知识-cpu微码

cpu微码可以认为是cpu的微程序，在linux下可以通过bios更新，也可以通过系统的intel-microcode类的软件包更新，其中以最新的为准。

比如bios中微码是12，intel-microcode中是14，那最终以微码14运行。

intel-microcode要研究下，可能和bios和这个软件包有关，更新intel-microcode后，microcode从0x3c升级到0x48了，不知道改了什么，可以研究下intel更新的机制和详细说明。

查了下资料，华擎的bios，25年1月15日更新的2.0bios，微码是3c，时间是21年1月份的，intel-microcode里的是48，21年11月份的，看起来是华擎一直没更新，而intel-microcode一直在不断更新微码，所以之前j3455不稳定，一段时间重启的问题，后来不出现了，除了自行编译内核，微码自动更新了应该也是重要的原因。这里算是解了惑了。

后详细看了下ubuntu系统的intel-microcode更新情况，https://launchpad.net/ubuntu/+source/intel-microcode ，以及之前的博客日志（22年就升级到ubuntu20.04了），20.04带的是 3.20191115.1ubuntu3，微码38，比最近华擎25年1月份更新的3c要低，比华擎在18年的bios的2e要高，直到24年12月才更新了 3.20241112.0ubuntu0.20.04.1，微码更新到了48，而这个微码在intel的微码更新时间是2022年5月。。。中间intel更新的微码，在ubuntu系统上并没有更新过。

也就是说intel更新微码还是比较快的，但是在发行版更新对应的包就很慢了。

这样分析下来之前的j3455在23年6月份之后稳定下来（当时的微码只能是ubuntu20.04的38，在22年就是这样的，要是这个原因应该22年就能稳定下来）不是微码更新的作用了，说不定和23年咸鱼买的旧的显示器坏了有关系呢。。。坏了导致没插显示器，最后反而没问题了。。。。

另外发现也会安装amd-microcode，最终发现是linux-image-generic带的，包含amd和intel的微码包