View Issue Details

IDProjectCategoryView StatusLast Update
0014871CentOS-6kernelpublic2018-06-11 22:38
Status confirmedResolutionopen 
Platformx86_64OSCentOSOS Version6.9
Product Version6.9 
Target VersionFixed in Version 
Summary0014871: KVM VM "PANIC: early exception 0d rip 10:ffffffff810462b6 error 0 cr2 0" on kernel 2.6.32-696.30.1
DescriptionHost: Arch Linux
Host Hardware: AMD FX-6300, Gigabyte GA-990FXA-UD3, 32GB RAM
Virtual Machines: CentOS 6.9 with 2.6.32-696.30.1
Virtual Machine Hardware: 1vCPU, 512MB RAM
# Virtual Machines Affected: 3

Upon boot into 2.6.32-696.30.1, all 3 VMs panic with error "PANIC: early exception 0d rip 10:ffffffff810462b6 error 0 cr2 0"
Choosing 2.6.32-696.28.1 allows a successful boot
Steps To ReproduceBoot into kernel 2.6.32-696.30.1
Additional InformationI came across a very recent Scientific Linux mailing list post in which a user experiences the same error:

The SL mailing list poster and I share the same motherboard, I will try to update my motherboard to the newest BIOS version and test again.

Next steps:
I will attempt to upgrade BIOS to latest offered version


has duplicate 0014934 closedIssue Tracker unable to boot after update to kernel-2.6.32-696.30.1.el6.x86_64 




2018-05-29 12:55

reporter   ~0031941

I have same problem but on an Intel server. Host server and other guests using Centos 7.5 are all running OK
Reverting to 2.6.32-696.28.1 kernel is also OK


2018-05-30 01:55

reporter   ~0031948

We have the same problem across our AMD compute node clusters, although it only kernel panics some of the time, other times the vnc screen is simply blank. We have various Intel clusters where this does not occur.
Host: Ubuntu 16.04
Host Hardware: DELL PowerEdge C6145, AMD Opteron(tm) Processor 6376, 256G RAM
Virtual Machines: CentOS 6.9 with 2.6.32-696.30.1
Virtual Machine Config: various

Tried setting NUMA=off as kernel boot parameter without any luck
Tried VM's of various sizes - in some cases, RAM exceeds that of a simple NUMA cell of host, in some cases not. Only in the cases where it does, is kernel panic evident.


2018-06-11 22:36

manager   ~0032055

This is a known bug. There is a workaround. For more details, see:

Issue History

Date Modified Username Field Change
2018-05-26 21:11 thomas4782 New Issue
2018-05-26 21:11 thomas4782 Tag Attached: 2.6.32-696.30.1
2018-05-29 12:55 bda Note Added: 0031941
2018-05-30 01:55 d.lujanski Note Added: 0031948
2018-06-11 22:35 toracat Relationship added has duplicate 0014934
2018-06-11 22:36 toracat Note Added: 0032055
2018-06-11 22:38 toracat Status new => confirmed