一、故障描述

接到客户通知，一台SuSE12SP5内核版本为4.12.14-122.54-default的机器宕机自动重启，业务受到影响，OS重启后正常进入系统，业务恢复，需要分析宕机原因。

二、故障分析

1、收集信息

联系客户收集supportconfig日志，在supportconfig中看到，系统在宕机时刻在/var/crash目录下面生成了2023-01-07-09:18目录，由此可见系统在出现问题的时候生成了dump文件，需要从生成的dump文件去分析，并将客户的2023-01-07-09:18目录上传到分析kdump的机器上。

2、准备工具

（1）安装crash

安装crash工具前要先做好本地的zypper源或网络源

# zypper in crash

（2）准备kernel文件

#要分析SuSE的kdump准备两个内核文件且这两个文件要与客户生成kdump文件的内核版本一致，将两个文件传到2023-01-07-09:18目录中：

kernel-default-base-4.12.14-122.54.1.x86_64.rpm

kernel-default-debuginfo-4.12.14-122.54.1.x86_64.rpm

（3）提取文件

# cd 2023-01-07-09:18

#rpm2cpio kernel-default-base-4.12.14-122.54.1.x86_64.rpm |cpio -idum \*vmlinux\*

# cd boot/

# gunzip vmlinux-4.12.14-122.54-default.gz

# cd ..

# ln -n boot/vmlinux-4.12.14-122.54-default .

# rpm2cpio kernel-default-debuginfo-4.12.14-122.54.1.x86_64.rpm |cpio -idum \*vmlinux\*

# ln -s usr/lib/debug/boot/vmlinux-4.12.14-122.54-default.debug.

（4）分析crash

# crash vmlinux-4.12.14-122.54-default vmcore

KERNEL: vmlinux-4.12.14-122.54-default                          

DEBUGINFO: ./vmlinux-4.12.14-122.54-default.debug

DUMPFILE: vmcore  [PARTIAL DUMP]

CPUS: 24

DATE: Sat Jan  7 17:18:04 2023

UPTIME: 368 days, 13:19:23

LOAD AVERAGE: 1.66, 1.56, 1.50

TASKS: 3668

NODENAME: HQtPVL-BQ2O-A04

RELEASE: 4.12.14-122.54-default

VERSION: #1 SMP Tue Dec 1 09:01:51 UTC 2020 (1120534)

MACHINE: x86_64  (2100 Mhz)

MEMORY: 96 GB

PANIC: "Kernel panic - not syncing: Machine halted."

PID: 17868

COMMAND: "top"

TASK: ffff94e467524cc0  [THREAD_INFO: ffff94e467524cc0]

CPU: 7

STATE: TASK_RUNNING (PANIC)

根据上面输出得到如下信息：    在执行 "top" 命令时发生了双重故障（double fault）导致系统崩溃。双重故障通常表示处理器执行两次异常处理过程，其中第二次异常处理过程发生在第一次异常处理过程的上下文中，导致系统无法恢复正常运行。

crash> bt

PID: 17868  TASK: ffff94e467524cc0  CPU: 7   COMMAND: "top"

 #0 [fffffe000013cd98] machine_kexec at ffffffffb40668f2

 #1 [fffffe000013cde8] __crash_kexec at ffffffffb412b21a

 #2 [fffffe000013cea8] panic at ffffffffb41c9d3a

 #3 [fffffe000013cf20] df_debug at ffffffffb406aa7d

 #4 [fffffe000013cf30] do_double_fault at ffffffffb40307e5

 #5 [fffffe000013cf50] double_fault at ffffffffb480104e

[exception RIP: do_page_fault+6]

RIP: ffffffffb4076cf6  RSP: fffffe000013c000  RFLAGS: 00010093

RAX: 00000000b4800a60  RBX: 0000000000000000  RCX: ffffffffb4800a60

RDX: ffffffffb43b6ae3  RSI: 0000000000000000  RDI: fffffe000013c018

RBP: 0000000000000000   R8: 0000000000000000   R9: 0000000000000000

R10: 0000000000000000  R11: 0000000000000000  R12: 0000000000000000

R13: 0000000000000000  R14: 0000000000000000  R15: 0000000000000000

ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018

--- ---

#6 [fffffe000013c000] do_page_fault at ffffffffb4076cf6

[ DOUBLEFAULT exception stack recursion: prior stack location overwritten ]

根据 backtrace（bt）信息，内核崩溃的原因是在执行do_page_fault函数时发生了异常，导致双重故障。do_page_fault是一个用于处理页面故障（page fault）异常的内核函数，它被用来处理在内存访问时发生的页面错误。（比如缺页异常）

crash> dis -l  do_page_fault+6

/usr/src/debug/kernel-default-4.12.14/linux-4.12/linux-obj/../arch/x86/mm/fault.c: 1506

0xffffffffb4076cf6 :  push%rbx

通过dis查到这个函数在内存中的地址为ffffffffb4076cf6，看到实际CPU操作的是push %rbx，将寄存器%rbx中的数据入栈，入栈地址为fffffe000013c000，但%rbx的地址全部为0，为空数据，所以有可能是内存硬件存在问题。

三、故障处理

后续通过检查硬件发现：内存存在异常告警，更换内存后现象消失，宕机重启现象不再出现。

四、经验总结

当我们不能完全确定是物理内存出现问题时，建议可以从以下几个方面配合检查：

1、检查物理内存是否存在

2、存储设备是否正常

3、处理器是否正常

4、第三方内核模块是否有异常