ylin's blog
0%

RHEL7-kernel-问题记录-1

发表于 更新于 分类于

RHEL 7 kernel 问题记录-1

    1. kernel panic内容: kernel BUG at fs/xfs/xfs_aops.c:1062!
    • 调查
      通过检查 vmcore 即可发现
      [1004630.854317] kernel BUG at fs/xfs/xfs_aops.c:1062!
    • 修复
      • 对于RHEL 7升级内核版本至kernel-3.10.0-693.el7及以上
      • 对于RHEL 7.3升级内核版本至kernel-3.10.0-514.16.1.el7及以上
      • 缓解办法： 如果客户机上 Java JVM 中使用hsperf功能，请禁用
    • 参考文档
      RHEL7: kernel crash in xfs_vm_writepage - kernel BUG at fs/xfs/xfs_aops.c:1062!
    1. slub内存泄露SLUB: Unable to allocate memory on node -1 (gfp=0x80d0)
    • 调查
      检查/var/log/messages可以发现
      $ grep "Unable to allocate\|mock" var/log/messages
kernel: SLUB: Unable to allocate memory on node -1 (gfp=0x80d0)
kernel: SLUB: Unable to allocate memory on node -1 (gfp=0x80d0)
kernel: SLUB: Unable to allocate memory on node -1 (gfp=0x80d0)
    • 修复
      • 对于RHEL 7升级内核版本至kernel-3.10.0-1062.4.1.el7及以上
      • 缓解办法：完全关闭内存“kernel memory accounting altogether”
        在内核启动参数中添加以下参数cgroup.memory=nokmem
    • 参考文档
      SLUB: Unable to allocate memory on node -1 (gfp=0x20)
    1. vmcore中检测到mem_cgroup_css_offline崩溃
    • 调查
      调查vmcore
      [344254.090710] BUG: unable to handle kernel NULL pointer dereference at 00000000000000b8
[344254.090865] IP: [] mem_cgroup_css_offline+0xfb/0x140   <<<
... ...
[344254.093838] RIP: 0010:[]  [] mem_cgroup_css_offline+0xfb/0x140  <<<
    • 修复
      • 对于RHEL 7.7将内核版本升级至kernel-3.10.0-1062.4.1.el7及以上
      • 对于RHEL 7.6将内核版本升级至kernel-3.10.0-957.38.1.el7及以上
      • 对于RHEL 7.5将内核版本升级至kernel-3.10.0-862.44.2.el7及以上
      • 对于RHEL 7.4将内核版本升级至kernel-3.10.0-693.61.1.el7及以上
    • 参考文档
      Kernel panic with exception RIP: mem_cgroup_css_offline caused by a possible slab leak
    1. kernel bug: “kernel BUG at mm/mmap.c:738!”
    • 调查
      vmcore中显示：
      RELEASE: 3.10.0-693.5.2.el7.x86_64                 <--- 
VERSION: #1 SMP Fri Oct 13 10:46:25 EDT 2017
MACHINE: x86_64  (1995 Mhz)
MEMORY: 511.8 GB
PANIC: "kernel BUG at mm/mmap.c:738!"              <---
    • 修复
      • 对于RHEL 7将内核版本升级至kernel-3.10.0-957.el7及以上
      • 对于RHEL 7.5将内核版本升级至kernel-3.10.0-862.20.2.el7及以上
      • 对于RHEL 7.4将内核版本升级至kernel-3.10.0-693.46.1.el7及以上
    • 参考文档
      System unexpectedly reboots or panics with “kernel BUG at mm/mmap.c:738”
    1. 系统重启于fsnotify()
    • 调查
      vmcore显示：
      [exception RIP: fsnotify+0x24b]
... ...
#4 [ffff96b6b5a13df0] fsnotify at ffffffffb306186b
    • 修复
      • 对于RHEL 7.6将内核版本升级至kernel-3.10.0-957.el7及以上
      • 对于RHEL 7.5将内核版本升级至kernel-3.10.0-862.9.1.el7及以上
      • 可以将内核版本降低到kernel-3.10.0-862
    • 参考文档
      Soft lockups occur in fsnotify() after updating to RHEL 7.5
    1. 系统出现'BUG: Bad page state in process'并崩溃在down_read_trylock之前
    • 调查
      检查vmcore
      [589570.661039] BUG: Bad page state in process cas  pfn:2207dff
[625759.760775] BUG: Bad page map in process python  pte:80003fddf8200904 pmd:205c25d067
[625759.880053] BUG: Bad page state in process python  pfn:2207dff
[625760.834004] WARNING: CPU: 19 PID: 76354 at lib/list_debug.c:62 __list_del_entry+0x82/0xd0
... ...
[531007.980839] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 [531008.020282] IP: [] down_read_trylock+0x9/0x50
    • 修复
      • 对于RHEL 7将内核版本升级至kernel-3.10.0-1062.el7及以上
      • 对于RHEL 7.6将内核版本升级至kernel-3.10.0-957.27.2.el7及以上
      • 对于RHEL 7.5将内核版本升级至kernel-3.10.0-862.37.1.el7及以上
      • 对于RHEL 7.4将内核版本升级至kernel-3.10.0-693.55.1.el7及以上
      • 对于RHEL 7.3将内核版本升级至kernel-3.10.0-514.66.2.el7及以上
      • 对于RHEL 7.2将内核版本升级至kernel-3.10.0-327.79.2.el7及以上
    • 参考文档
      ‘BUG: Bad page state in process’ event is logged just before crash in down_read_trylock, Red Hat Enterprise Linux 7
    1. 系统kmem_cache_alloc 从 mempool_alloc_slab 引用无效内存地址引起crash
    • 调查
      • 检查vmcore
        [14787601.353261] RIP: 0010:[]  [] kmem_cache_alloc+0x75/0x1d0
... ...
[14787601.353705]  [] mempool_alloc_slab+0x15/0x20
[14787601.353728]  [] mempool_alloc+0x69/0x170
      • 这是由于内核中的驱动模块（internal模块以及第三方模块）的”use-after-free”或者”double-free”的bug所导致
    • 修复
      • 对于RHEL 7将内核版本升级至最新
      • 继续调查这个问题，内核启动参数中添加”slub_debug=FZP”，开启slub debug功能。注意，这会造成主机生产减缓
      • 内核启动参数中添加”slub_debug=F”作为一个绕行方案，这样当再次出现freelist指针损坏的问题时，系统不会panic重启
    • 参考文档
      Kernel panic due to “kmem_cache_alloc+117 from mempool_alloc_slab” on RHEL 7
    1. 内核由于BUGkernel BUG at drivers/ata/libata-sff.c:1350!引起重启
    1. 由于模块fileaccess_mod分配slab 内存时在kmem_cache_alloc内核panic
    • 调查
      检查vmcore
      
# crash> bt
[exception RIP: kmem_cache_alloc+118]
... ...
#12 [ffff8817d196be80] scanCache_init at ffffffffa044a4c0 [fileaccess_mod]
#13 [ffff8817d196bea0] hook_init at ffffffffa0444b83 [fileaccess_mod]
#14 [ffff8817d196bec0] init_module at ffffffffa005a072 [fileaccess_mod]
# crash> mod -t
NAME                       TAINTS
fileaccess_mod_1005031646  OE
    • 修复
      • 对于fileaccess_mod模块为McAfee模块，联系厂商调查
    • 参考文档
      Server panics at kmem_cache_alloc while allocating slab memory due to unsigned kernel module fileaccess_mod
    1. 系统由于not syncing: Fatal Machine check or Machine Check Exception 重启
    • 调查
      检查vmcore
      Hardware event. This is not a software error.
Corrected error
Transaction: Memory scrubbing error
Memory ECC error occurred during scrub
Memory corrected error count (CORE_ERR_CNT): 1
Memory DIMM ID of error: 1
Memory channel ID of error: 2
Hardware event. This is not a software error.
    • 修复
      • 联系硬件厂商进行调查
        1
        2
        3
        4
        5
        6
        7
        内存 DIMM 故障。
           内存控制器故障（通常是板载的）。
           主板内存线故障。
           BIOS 故障。
           过热系统。
           RAM 潜在连接故障（来自用户的静电放电）。
           电源问题或短路。
      • 检查系统BIOS，升级至最新
      • 参考文档进行内存检测
    • 参考文档
      “Kernel panic - not syncing: Fatal Machine check or Machine Check Exception (MCE)” in /var/log/messages
    1. 系统由于硬件CPU运行问题重启
    • 调查
      检查vmcore
       crash> bt
[exception RIP: skb_release_head_state+0x18]
对该函数进行反汇编skb_release_head_state，并无0x18偏移量
crash> dis -rl ffffffffafc3c178
/usr/src/debug/kernel-3.10.0-1127.el7/linux-3.10.0-1127.el7.x86_64/include/net/dst.h: 300
... ...
0xffffffffafc3c17a :    je     0xffffffffafc3c208
    • 修复
      • 该问题只可能由于CPU硬件运行故障或计算错误引起，硬件厂商对CPU深入检查
    • 参考文档
      Intel microcode for Skylake/Cascade Lake CPUs can cause stability issues
    1. 内核中出现以下告警WARNING: at fs/xfs/xfs_aops.c:1244 xfs_vm_releasepage
    1. 系统hung死前日志记录e1000e 0000:00:1f.6 enp0s31f6: Detected Hardware Unit Hang:
    • 调查
      检查系统message日志
      [963569.248045] e1000e 0000:00:1f.6 enp0s31f6: Detected Hardware Unit Hang:
... ...
[963691.387160] e1000e 0000:00:1f.6 enp0s31f6: Detected Hardware Unit Hang:
    • 修复
      • 对于RHEL 7.8将内核版本升级至kernel-3.10.0-1127.el7及以上
      • 强制 PCIe ASPM 进入 Performance 模式可以避免这个问题。在内核启动参数中添加以下配置
        1
        pcie_aspm=force pcie_aspm.policy=performance
    • 参考文档
      log message ‘e1000e Detected Hardware Unit Hang’ before system hangs
    1. 系统重现出现日志Power key pressed
    • 调查
      检查系统message日志
      localhost systemd-logind: Power key pressed.
... ...
localhost systemd-logind: Powering Off...
... ...
localhost systemd-logind: System is powering down.
    • 修复
      • 检查系统是否被故意关闭
      • 检查硬件控制台是否有关闭、报错相关日志
    • 参考文档
      Server shutdown/reboot with “Power key pressed” messages
    1. 内核位于inet_twsk_schedule()崩溃
    • 调查
      检查vmcore
      # crash> bt
... ...
[exception RIP: inet_twsk_schedule+177]
    • 修复
      • 对于RHEL 7.4将内核版本升级至kernel-3.10.0-693.el7及以上
      • 对于RHEL 6.10将内核版本升级至kernel-2.6.32-754.el6及以上
      • 缓解办法，使用sysctl添加以下内核参数
        1
        net.ipv4.tcp_tw_recycle = 0
    • 参考文档
      RHEL: Kernel crash in inet_twsk_schedule()
    1. 系统由于第三方内核模块重启
    • 调查
      检查vmcore
      crash> bt
[exception RIP: pal_lru_find_dirty_sippet+0x5a]
crash> sym pal_lru_find_dirty_sippet
ffffffffc0b2e1a0 (t) pal_lru_find_dirty_sippet [pal] 
crash> mod -t
NAME             TAINTS
... ...
pal              POE    <==
    • 修复
      • 联系第三方模块供应商进行排查
    1. 系统日志中记录Abort command Issued
    • 调查
      检查系统message日志
      kernel: qla2xxx 0000:46:00.0: scsi(1:0:105): Abort command issued -- 1 3e7bbc46 2002.
    • 修复
      • 该报错为SAN环境返回报错
      • 检查SAN环境中设备 FC 交换机、FC 布线、分区或存储阵列是否存在任何问题
      • 存储供应商查看交换机日志，以验证 FC 交换机日志中是否有任何错误计数器、CRC 错误
    • 参考文档
      “Abort command Issued” messages appear in /var/log/messages file
    1. 内核由于not syncing: GAB: Port d halting system due to network failure at [XX:XXXX]引起恐慌
    • 调查
      检查vmcore
      LLT INFO V-14-1-10205 link 0 (eth1) node 0 in trouble LLT INFO V-14-1-10205 link 1 (eth3) node 0 in trouble LLT INFO V-14-1-10032 link 0 (eth1) node 0 inactive 8 sec (696686965) LLT INFO V-14-1-10032 link 1 (eth3) node 0 inactive 8 sec (696614993) LLT INFO V-14-1-10032 link 0 (eth1) node 0 inactive 9 sec (696686965) LLT INFO V-14-1-10032 link 1 (eth3) node 0 inactive 9 sec (696614993) LLT INFO V-14-1-10032 link 0 (eth1) node 0 inactive 10 sec (696686965) LLT INFO V-14-1-10032 link 1 (eth3) node 0 inactive 10 sec (696614993) LLT INFO V-14-1-10032 link 0 (eth1) node 0 inactive 11 sec (696686965) LLT INFO V-14-1-10032 link 1 (eth3) node 0 inactive 11 sec (696614993) LLT INFO V-14-1-10032 link 0 (eth1) node 0 inactive 12 sec (696686965) LLT INFO V-14-1-10032 link 1 (eth3) node 0 inactive 12 sec (696614993) LLT INFO V-14-1-10032 link 0 (eth1) node 0 inactive 13 sec (696686965) LLT INFO V-14-1-10510 sent hbreq (NULL) on link 0 (eth1) node 0. 4 more to go.
LLT INFO V-14-1-10510 sent hbreq (NULL) on link 0 (eth1) node 0. 3 more to go.
... ...
GAB INFO V-15-1-20040 Port h[GAB_USER_CLIENT (refcount 0)] gen   263813    visible 0
GAB INFO V-15-1-20033 Port d[GAB_LEGACY_CLIENT (refcount 0)] nid 0     [3:0:0:0]    [3:0:0:0]    [3:0:0:0]    [1:0:0:0]    [0:0:0:0]  22   26380f   20 9
GAB INFO V-15-1-20033 Port d[GAB_LEGACY_CLIENT (refcount 0)] nid 1     [3:0:0:0]    [3:0:0:0]    [3:0:0:0]    [2:0:0:0]    [0:0:0:0]  22   26380f   20 37
Kernel panic - not syncing: GAB: Port d halting system due to network failure at [14:2166] [..]
    • 修复
      • 验证系统上的所有网络配置。
      • 检查任何有故障的网络接口卡 (NIC)、交换机端口或电缆
      • 联系VCSVeritas Cluster Server供应商进行进一步检查
    • 参考文档
      Kernel panic - not syncing: GAB: Port d halting system due to network failure at [XX:XXXX]
    1. 虚拟机汇报软锁定soft lockup
    • 调查
      检查系统的message日志
      有以下记录
1-> BUG: soft lockup - CPU#0 stuck for 64s! [proceessname:15789]
2-> kernel: NMI watchdog: BUG: soft lockup - CPU#6 stuck for 25s! [ksoftirqd/6:38]
3-> hrtimer: interrupt took NUMBER ns
    • 修复
      • 检查主机或虚拟机管理程序是否有工作过载的情况
      • 为避免重启，将kernel.softlockup_panic值设置为0
      • 增加软锁定报告时间的阈值，上限60S
        kernel.watchdog_thresh
旧版RHEL为 kernel.softlockup_thresh
    • 参考文档
      Virtual machine reports a “BUG: soft lockup” (or multiple at the same time)
    1. 升级RHEL7.6后，QLogic FC HBA 的系统引导时崩溃，通过 QLogic 提供的LUN无法被识别
    • 调查
      检查系统启动日志
      kernel: scsi host15: qla2xxx
kernel: qla2xxx [0000:2f:00.0]-00fb:15: QLogic QLE2692 - QLogic 16Gb FC Dual-port HBA.
kernel: qla2xxx [0000:2f:00.0]-00fc:15: ISP2261: PCIe (8.0GT/s x8) @ 0000:2f:00.0 hdma+ host#=15  fw=8.08.05 (d0d5).
...
kernel: TECH PREVIEW: NVMe over FC may not be fully supported.
    • 修复
      • 对于RHEL 7.6将内核版本升级至RHEL 7.8及以上
      • 升级HBA固件到v8.08.204或更高版本
      • 有三种缓解办法
          1. 使用RHEL 7.5 的内核启动
          1. 将 QLogic HBA 卡的固件降级到以前的版本
          1. 修改内核模块配置
          • 3.1 为内核模块添加以下参数
            1
            2
            $ cat > /etc/modprobe.d/qla2xxx.conf
                  options qla2xxx ql2xnvmeenable=0
          • 3.2 重新生成initramfs文件
          • 3.3 使用新创建的initramfs启动系统
    • 参考文档
      After upgrading to RHEL 7.6, systems with QLogic FC HBA crash on boot, OR LUNs presented to QLogic are only partially discovered or not at all
    1. vim崩溃后ABRT导致内核泄露
    • 调查
      检查系统日志
      abrt-hook-ccpp: Process  (vim) of user  killed by SIGSEGV - dumping core
    • 修复
      • 将VIM版本升级至vim-7.4.160-5.el及以上
      • 将ABRT版本升级至abrt-2.1.11-55.el7及以上
    • 参考文档
      ABRT causes out-of-memory condition after vim crash
    1. 内核BUGmm/huge_memory.c:1989!
    • 调查
      检查vmcore
      [22320502.735528] mapcount 0 page_mapcount 1
[22320502.735572] ------------[ cut here ]------------
[22320502.735587] kernel BUG at mm/huge_memory.c:1989!
... ...
[22320502.740331] RIP  [] __split_huge_page+0x738/0x750
    • 修复
      • 对于RHEL 7将内核版本升级至kernel-3.10.0-1127.el7及以上
      • 缓解办法：关闭Huge Pages，添加以下内容到grub启动内核参数中并重建grub.cfg文件，重启系统
        1
        GRUB_CMDLINE_LINUX="... transparent_hugepage=never"
    • 参考文档
      System crash due to kernel BUG at mm/huge_memory.c:1989!
    1. 内核由于驱动导致panicintel_pstate_timer_func()
    • 调查
      检查vmcore
      [4067605.161646] divide error: 0000 [#1] SMP 
... ...
[4067605.162343] RIP: 0010:[]  [] intel_pstate_timer_func+0x179/0x3d0
    • 修复
      • 对于RHEL 7.1将内核版本升级至kernel-3.10.0-229.20.1.el7及以上
      • 对于RHEL 7.2将内核版本升级至kernel-3.10.0-327.el7及以上
      • 对于RHEL 6将内核版本升级至kernel-2.6.32-642.el6及以上
    • 参考文档
      Divide by zero error in intel_pstate_timer_func() [ inline s64 div_s64_rem() ]
    1. 内核位于prb_retire_rx_blk_timer_expired出现软锁导致崩溃
    1. 内核由于crash_save_cpu+0x92/0x1d0崩溃
    • 调查
      检查vmcore
      dmesg logs :
[121730736.448991] BUG: unable to handle kernel NULL pointer dereference at           (null)
[121730736.448996] IP: [] crash_save_cpu+0x92/0x1d0
crash> bt
[exception RIP: intel_idle+213]
NMI exception stack
#12 [ffff8b00fb16fe20] intel_idle at ffffffff816ab6a5
    • 修复
      • 缓解办法如下
        1 设置 numa=off
2 关闭 Transparent Hugepage
3 移除 3rd party modules
4 升级内核至 kernel-3.10.0-862.el7 或更高
    • 参考文档
      Kernel panic with RIP crash_save_cpu+0x92/0x1d0
    1. 内核BUGkernel BUG at block/blk-core.c:2500!
    • 调查
      检查vmcore
      [536700.120045] kernel BUG at block/blk-core.c:2500!
    • 修复
      • 对于RHEL 7将内核版本升级至kernel-3.10.0-229.el7.x86_64及以上
      • 对于RHEL 7.0将内核版本升级至kernel-3.10.0-123.13.1.el7.x86_64及以上
    • 参考文档
      [RHEL7] kernel BUG at block/blk-core.c:2500!
    1. 内核位于not syncing: Timeout: Not all CPUs entered broadcast exception handler崩溃
    • 调查
      检查vmcore
      PANIC: "Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler"
crash> bt
... ...
 #3 [ffff9fc6fe8cbdc8] mce_panic at ffffffffad248c45        <<< 
... ...
 #7 [ffff9fc6fe8cbf50] machine_check at ffffffffad96b7ae    <<< machine_check() 在正常情况下不会发生。当它被调用时，意味着硬件级别有问题。
[exception RIP: cpu_idle_poll+73]
    • 修复
      • 联系硬件供应商检查CPU
      • 如果是虚拟机，联系虚拟化供应商检查Hypervisor
    • 参考文档
      System keeps crashing with message “Timeout: Not all CPUs entered broadcast exception handler”
    1. 系统日志中记录rsyslogd was HUPed
    • 调查
      检查vmcore
      grep -i "rsyslogd was HUPed" /var/log/messages
rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="1457" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="22972" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="22972" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
    • 修复
      • HUP是logrotate服务发送的信号
      • 向syslogd进程发出HUP信号以告知写入新文件，因为旧日志文件现在已被重命名。这是预期的行为。
    • 参考文档
      Getting messages ‘rsyslogd was HUPed’ in /var/log messages
    1. 内核恐慌not syncing: Machine check
    1. 内核日志SLUB: Unable to allocate memory on node -1
    • 调查
      检查系统messages日志
      SLUB: Unable to allocate memory on node -1 (gfp=0x200020)
SLUB: Unable to allocate memory on node -1 (gfp=0x20)
SLUB: Unable to allocate memory on node -1 (gfp=0x20)
    • 修复
      • 对于RHEL 7将内核版本升级至kernel-3.10.0-1062.4.1.el7及以上
      • 缓解办法：完全禁用内存记账，添加如下grub内核参数，重建grub后并启动
        1
        cgroup.memory=nokmem
    • 参考文档
      SLUB: Unable to allocate memory on node -1 (gfp=0x20)
    1. 使用GPFS的系统7.3频繁重启
    • 调查
      检查vmcore
      crash> ps -p 6318 
PID: 0      TASK: c000000001358180  CPU: 0   COMMAND: "swapper/0"
 PID: 1      TASK: c000001ef9d00000  CPU: 31  COMMAND: "systemd"
PID: 41045  TASK: c000000e9e8d5300  CPU: 10  COMMAND: "runmmfs"
 PID: 68294  TASK: c000000e9f766670  CPU: 12  COMMAND: "mmfsd"        <
PID: 6296   TASK: c000000f4da56830  CPU: 66  COMMAND: "mmcommon"
 PID: 6317   TASK: c000001ee9befac0  CPU: 41  COMMAND: "umount"
  PID: 6318   TASK: c000001dc63779e0  CPU: 57  COMMAND: "umount.nfs"     <
    • 修复
      • 联系GPFS供应商进行进一步分析，gpfs​​模块mmfs26和 mmfslinux 涉及崩溃上下文
    • 参考文档
      GPFS (Spectrum Scale) 7.3 ppc64 lpars are crashing

仅用作经验记录