Description of problem: When booting a kvm guest on my AMD Athlon II P340 based system, guest boot hangs at smpboot: Version-Release number of selected component (if applicable): kernel-4.0.0-0.rc1.git0.1.fc22.x86_64 How reproducible: Always Steps to Reproduce: 1. Attempt to start virtual machine 2. VM boot hangs Actual results: VM hangs Expected results: VM continues to boot. Additional info: Am not able to find any errors in dmesg, vms boot just fine on 3.19 kernel. Am git bisecting to see if I can find the commit that causes the problem, will be reporting the results of that shortly. processor : 1 vendor_id : AuthenticAMD cpu family : 16 model : 6 model name : AMD Athlon(tm) II P340 Dual-Core Processor stepping : 3 microcode : 0x10000c8 cpu MHz : 1600.000 cache size : 512 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate npt lbrv svm_lock nrip_save vmmcall bugs : tlb_mmatch apic_c1e fxsave_leak bogomips : 4388.99 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate
Just realized I forgot to include where it is hanging: [ 0.012018] Initializing cgroup subsys devices [ 0.013005] Initializing cgroup subsys freezer [ 0.013704] Initializing cgroup subsys net_cls [ 0.014004] Initializing cgroup subsys blkio [ 0.015004] Initializing cgroup subsys perf_event [ 0.016005] Initializing cgroup subsys hugetlb [ 0.016859] mce: CPU supports 10 MCE banks [ 0.017083] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127 [ 0.017083] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127 [ 0.017083] tlb_flushall_shift: 6 [ 0.028653] Freeing SMP alternatives: 24k freed [ 0.033805] ACPI: Core revision 20130517 [ 0.035611] ACPI: All ACPI Tables successfully acquired [ 0.036096] ftrace: allocating 23383 entries in 92 pages [ 0.047470] Enabling x2apic [ 0.048000] Enabled x2apic [ 0.048006] Switched APIC routing to physical x2apic. [ 0.051676] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [ 0.052002] smpboot: CPU0: AMD Phenom(tm) 9550 Quad-Core Processor (fam: 10, model: 02, stepping: 03)
Proposed as a Blocker for 22-beta by Fedora user jdulaney using the blocker tracking app because: Fails the self-hosted (actually, all hosted) virt criterion as virtual machines do not boot on the currently shipping kernel.
Are we talking about 4.0 kernel on the *host* or *guest*?
Discussed at 2015-03-09 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2015-03-09/f22-blocker-review.2015-03-09-16.05.log.txt . As it's not yet clear what's going on here or the amount of systems that will be affected, we agreed to delay the decision on this bug and try to collect more information. Kernel team, aside from the bisect is there any other useful information John can provide? Is there any kind of known issue with virt on AMD CPUs in kernel 4.0 ATM? Thanks!
No known issue. Only this report that I'm aware of. Bisect results would be interesting. We did have an issue with some firmware/ACPI and PCI resource allocation that resulted in some odd bugs (like incorrect probing, etc) but I have no idea if that would manifest itself as a virt issue. That problem was fixed in 4.0.0-rc2.git2.1 (or the 4.0-rc3 build that is building now).
Sorry, bisecting is taking a while; kernels take some time to build on this laptop. I haven't tracked down the culprit, yet. The issue is with the host. I have kernel-4.0.0-0.rc2.git0.1.fc22.x86_64 installed that still has the issue, going to give the newer build a shot. Just to be clear: If I run a 4.0 kernel on my *host*, guests hang on booting at smpboot.
4.0.0-0.rc3.git0.1.fc23.x86_64 fixed it. Closing accordingly. Guessing it was the firmware issue.