Red Hat Bugzilla – Bug 429969
Rhel 5 xen crashes during boot in a vm
Last modified: 2010-11-09 08:34:30 EST
Description of problem:
Rhel 5.1 Xen does not boot in a VMware workstation 6 vm on some AMD cpus. I do
not see this issue on core 2 cpus.
How reproducible: 100%, you can't boot.
If you install Rhel 5.1, enable virtualization packages, on reboot into xen
after the install, xen crashes early in loading dom0. I've uploaded serial
console ouput with the crash info and cpuinfo.
Created attachment 292720 [details]
Serial console output
Created attachment 292721 [details]
First, this is a RHEL-5 GA kernel log, not RHEL-5.1. But more importantly...
I notice that the cpu flags include "svm". Is vmware really virtualising the
hardware virtualisation capabilities of the CPU?
But beyond that, we seem to be oopsing in dmi_string(), in the dmi decoder.
We'd probably need to see full dmidecode output and boot logs from a non-xen
kernel in the same virtual environment to get a handle on what's going wrong in
the dmi handling, if that's the problem.
Created attachment 292830 [details]
Sorry about that, wires crossed, you're right, it's rhel 5.
The uploaded cpuinfo is *host* cpuinfo, not what the guest sees. dmidecode info
from the host is attached. The host is rhel 4 u6 64-bit btw.
I can upload guest cpuinfo/dmidecode info from booting into rhel 5 w/o xen if
Created attachment 292858 [details]
cpuinfo obtained from the guest (booting w/o xen)
Created attachment 292859 [details]
guest dmidecode info
dmidecode obtained from the guest (booting w/o xen)
RHEL-5.0 contains the Xen 3.0.3 hypervisor. In RHEL-5.1 this was updated to Xen
3.1.0 to fix numerous hypervisor bugs, so attempting to debug problems with the
3.0.3 hypervisor isn't really a productive exercise. Please retry using the
RHEL-5.1 packages in the guest, and try to capture another serial console -
which should show xen-3.1.0 / kernel-xen-2.6.18-53.el5
Created attachment 292915 [details]
serial console output (rhel 5.1)
Uploaded serial output from rhel 5.1 xen. Seems to be a different error, now
it's an unhandled pf in dom0.
This is old and unlikely still a problem. Closing.