Bug 1197380

Summary:	Booting kvm guests hang on smpboot on kernel 4.0rc1 on AMD Athlon(tm) II P340 CPU
Product:	[Fedora] Fedora	Reporter:	Mairi Dulaney <jdulaney>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED NEXTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	22	CC:	awilliam, gansalmon, itamar, jdulaney, jonathan, kernel-maint, madhu.chinakonda, mchehab, robatino
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-09 23:26:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1043125

Description Mairi Dulaney 2015-02-28 22:17:21 UTC

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

Comment 1 Mairi Dulaney 2015-02-28 22:22:53 UTC

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)

Comment 2 Fedora Blocker Bugs Application 2015-03-08 22:49:55 UTC

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.

Comment 3 Adam Williamson (Red Hat non-Fedora) 2015-03-09 16:29:39 UTC

Are we talking about 4.0 kernel on the *host* or *guest*?

Comment 4 Adam Williamson (Red Hat non-Fedora) 2015-03-09 16:31:26 UTC

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!

Comment 5 Josh Boyer 2015-03-09 16:56:26 UTC

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).

Comment 6 Mairi Dulaney 2015-03-09 22:23:12 UTC

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.

Comment 7 Mairi Dulaney 2015-03-09 23:26:20 UTC

4.0.0-0.rc3.git0.1.fc23.x86_64 fixed it.  Closing accordingly.

Guessing it was the firmware issue.