Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1197380 - Booting kvm guests hang on smpboot on kernel 4.0rc1 on AMD Athlon(tm) II P340 CPU
Summary: Booting kvm guests hang on smpboot on kernel 4.0rc1 on AMD Athlon(tm) II P340...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 22
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F22BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2015-02-28 22:17 UTC by Mairi Dulaney
Modified: 2015-03-09 23:26 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-09 23:26:20 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

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 2015-03-09 16:29:39 UTC 
Are we talking about 4.0 kernel on the *host* or *guest*?
Comment 4 Adam Williamson 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.
Note You need to log in before you can comment on or make changes to this bug.