On 07/21/2012 08:06 PM, Andrew Cathrow wrote: > Have a look here > > https://bugzilla.redhat.com/show_bug.cgi?id=804224 Thanks, Andrew. That's definitely it. I upgraded to qemu 1.1.1 and it now boots with modern CPU support. Appreciate the quick response. I did run into another problem after making this change, though it's not related to my original problem. Wanted to mention it, though, in case anyone else runs into it: Once I made this change, with the previous CPU definition I was using libvirt/qemu booted CentOS 6.3 with "-cpu Westmere" (plus a bunch of individual features). When this happened, CentOS would will hang shortly into the bootup process, as soon as it detects the CPU. Here are the last few lines I get before the hang: Setting APIC routing to flat ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 CPU0: Intel Westmere E56xx/L56xx/X56xx (Nehalem-C) stepping 01 Performance Events: Westmere events, Intel PMU driver. ... version: 2 ... bit width: 48 ... generic registers: 4 ... value mask: 0000ffffffffffff ... max period: 000000007fffffff ... fixed-purpose events: 3 ... event mask: 000000070000000f NMI watchdog enabled, takes one hw-pmu counter. If I set CPU=Nehalem and leave all other features in tact, and also add in the aes feature (which I think is the only difference between the two definition-wise), CentOS boots perfectly fine. There's clearly a bug here somewhere but I honestly have no idea where it lies. Setting CPU to Nehalem (which I planned to do anyway) is an easy workaround for me, so I'm not going to pursue this any further. If anyone does want to follow up on this, though, let me know and I'll be happy to assist where possible. P.S. As I was typing this I got one additional line on the console after a few minutes: Booting Node 0, Processors #1 Ok. Then, after a few more minutes I got a proper kernel dump: BUG: soft lockup - CPU#0 stuck for 67s! [swapper:1] Modules linked in: CPU 0 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.32-279.el6.x86_64 #1 Bochs Bochs <SNIP> I'll spare everyone the call trace details, but again, if anyone's interested in pursuing this just let me know and I'll be happy to provide all the details. -- Jared -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list