0
I have intel servers running CentOS 6.8 as KVM host,and there was an OOPS or BUG occurs.

kernel crash at kernel-2.6.32-642.el6/linux-2.6.32-642.el6.x86_64/mm/vmalloc.c: 630 Did anyone else have this problem and how to solve it.

Here's an exerpt from the dmesg file:

<1>BUG: unable to handle kernel paging request at ffffffffffffffe0
<1>IP: [<ffffffff81167060>] __purge_vmap_area_lazy+0x70/0x1e0
<4>PGD 1a8f067 PUD 1a90067 PMD 0
<4>Oops: 0000 [#1] SMP
<4>last sysfs file: /sys/devices/system/cpu/online
<4>CPU 9
<4>Modules linked in: iptable_filter iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 iptable_raw ip_tables ebt_ip6 ip6_queue ip6table_filter ip6table_raw ip6_tables ebtable_nat ebtable_filter ebt_ip ebt_arp ebtables xt_NOTRACK xt_CHECKSUM ipt_REJECT fuse act_police cls_u32 sch_ingress cls_fw sch_sfq sch_htb tcp_diag inet_diag ip_queue autofs4 bridge stp llc bonding ip6t_REJECT nf_conntrack ipv6 nbd(U) vhost_net macvtap macvlan tun kvm_intel kvm ipmi_devintf power_meter acpi_ipmi ipmi_si ipmi_msghandler microcode iTCO_wdt iTCO_vendor_support dcdbas joydev bnxt_en sb_edac edac_core lpc_ich mfd_core shpchp igb dca i2c_algo_bit i2c_core ptp pps_core sg ext4 jbd2 mbcache sd_mod crc_t10dif ahci megaraid_sas wmi dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ip_tables]
<4>
<4>Pid: 75475, comm: CPU 0/KVM Tainted: G --L------------ 2.6.32-642.el6.x86_64 #1 Dell Inc. PowerEdge R730xd/072T6D
<4>RIP: 0010:[<ffffffff81167060>] [<ffffffff81167060>] __purge_vmap_area_lazy+0x70/0x1e0
<4>RSP: 0018:ffff880c17063958 EFLAGS: 00010207
<4>RAX: 0000000000000000 RBX: ffff880c170639c0 RCX: 0000000000000000
<4>RDX: ffff880c17063968 RSI: ffff880234774600 RDI: ffff8808ca10a800
<4>RBP: ffff880c170639a8 R08: ffff880c17063968 R09: ffff884a8bcb1818
<4>R10: 0000000000000200 R11: 0000000000000000 R12: ffff880c170639b8
<4>R13: ffff880c17063968 R14: ffffffffffffffd0 R15: 0000000000000000
<4>FS: 00007f718d42a700(0000) GS:ffff883129080000(0000) knlGS:0000000000000000
<4>CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
<4>CR2: ffffffffffffffe0 CR3: 00000031dd1d3000 CR4: 00000000001427e0
<4>DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<4>DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
<4>Process CPU 0/KVM (pid: 75475, threadinfo ffff880c17060000, task ffff8802a2245520)
<4>Stack:
<4> ffff880c17063978 00001c9ad0c9c004 ffff882de6d83880 ffff8808ca10a800
<4><d> ffff880c17063b38 000000000000c1db ffff880c17063b38 0000000000000001
<4><d> ffff8834d0c9c000 ffff8831641dc000 ffff880c170639d8 ffffffff81167230
<4>Call Trace:
<4> [<ffffffff81167230>] free_vmap_area_noflush+0x60/0x70
<4> [<ffffffff811672e5>] free_unmap_vmap_area+0x25/0x30
<4> [<ffffffff81167330>] remove_vm_area+0x40/0xa0
<4> [<ffffffff8116744e>] __vunmap+0x2e/0x110
<4> [<ffffffff811675b6>] vfree+0x36/0x80
<4> [<ffffffffa02598b6>] kvm_free_physmem_slot+0x26/0xc0 [kvm]
<4> [<ffffffffa025c3a1>] __kvm_set_memory_region+0x601/0x820 [kvm]
<4> [<ffffffff8103da1e>] ? physflat_send_IPI_mask+0xe/0x10
<4> [<ffffffffa02734a2>] ? kvm_emulate_pio+0x172/0x1c0 [kvm]
<4> [<ffffffffa025c603>] kvm_set_memory_region+0x43/0x70 [kvm]
<4> [<ffffffffa025c64d>] kvm_vm_ioctl_set_memory_region+0x1d/0x30 [kvm]
<4> [<ffffffffa025cf0c>] kvm_vm_ioctl+0x26c/0x1050 [kvm]
<4> [<ffffffffa025e1b8>] ? vcpu_put+0x28/0x30 [kvm]
<4> [<ffffffffa0273a83>] ? kvm_arch_vcpu_ioctl_run+0x593/0x1060 [kvm]
<4> [<ffffffff81242461>] ? avc_has_perm+0x71/0x90
<4> [<ffffffff810bb023>] ? futex_wake+0x93/0x150
<4> [<ffffffffa0259de7>] ? kvm_vcpu_ioctl+0x1e7/0x580 [kvm]
<4> [<ffffffff8106b4c3>] ? perf_event_task_sched_out+0x33/0x70
<4> [<ffffffff81052204>] ? __do_page_fault+0x1f4/0x500
<4> [<ffffffff811af742>] vfs_ioctl+0x22/0xa0
<4> [<ffffffff811afc0a>] do_vfs_ioctl+0x3aa/0x580
<4> [<ffffffff811afe61>] sys_ioctl+0x81/0xa0
<4> [<ffffffff8100b0d2>] system_call_fastpath+0x16/0x1b
<4>Code: e8 a6 37 3e 00 85 c0 0f 84 04 01 00 00 48 8b 05 f7 cc 96 00 c7 45 bc 00 00 00 00 48 3d 40 3d ad 81 4c 8d 70 d0 0f 84 58 01 00 00 <41> f6 46 10 01 74 47 49 8b 06 48 3b 03 73 03 48 89 03 49 8b 46
<1>RIP [<ffffffff81167060>] __purge_vmap_area_lazy+0x70/0x1e0
<4> RSP <ffff880c17063958>
<4>CR2: ffffffffffffffe0

uname -a

Linux xxxxxxxxxx 2.6.32-642.el6.x86_64 #1 SMP Tue May 10 17:27:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

windrd
  • 1
  • I am assuming you just updated the kernel. If yes then it seems the update was not properly completed. To resolve this boot into older kernel and do yum reinstall kernel. Then try booting into new kernel. – errorfetch Aug 17 '18 at 09:45
  • Look for the _previous_ crash. – Michael Hampton Aug 17 '18 at 12:18
  • Comparing the code of Centos 6.8 and Centos 6.10 vmalloc.c is the roughly same, so there is no plan to upgrade the latest kernel. before crash,there is some soft lockup print in demsg. demsg file link: https://github.com/windxrunner/crash_dmesg/blob/master/vmcore-dmesg.txt – windrd Aug 20 '18 at 02:53
  • I think this is like CPU lock kind of situation, kernel upgrade may help. – asktyagi May 03 '19 at 03:31

0 Answers0