EN 正规买球app加入我们
典型案例
您现在的位置:首页 > 典型案例
【正规买球app】SuSE12SP5宕机分析报告



一、故障描述


接到客户通知,一台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、第三方内核模块是否有异常


版权所有 正规买球app 备案号:京ICP备17074963号-1
技术支持:创世网络