RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1001487 - host call trace when booting win2k8-64 guest with large memory and multiple vcpu
Summary: host call trace when booting win2k8-64 guest with large memory and multiple vcpu
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Luiz Capitulino
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-27 07:13 UTC by Xu Han
Modified: 2013-09-10 01:34 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-09-10 01:34:50 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
host dmesg log (70.28 KB, text/plain)
2013-08-27 07:24 UTC, Xu Han 		no flags Details
View All

Description Xu Han 2013-08-27 07:13:46 UTC 
Description of problem:
host call trace when booting win2k8-64 guest with large memory and multiple vcpu and guest boot take more than 10min.
win2k8r2-64 hit this issue, but win2k3-32/64, win8-32/64, win2012-64 won't

I added dmesg log to attachment.

Version-Release number of selected component (if applicable):
kernel:3.10.0-11.el7.x86_64
qemu:qemu-kvm-1.5.2-4.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.verify mem and cpu in host
#free -g
             total       used       free     shared    buffers     cached
Mem:           503         67        435          0          0         62
-/+ buffers/cache:          5        498
Swap:            3          0          3

#cat /proc/cpuinfo(total 48 cores) 

....
processor       : 47
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 9
model name      : AMD Opteron(tm) Processor 6172


2.clear dmesg
#dmesg -c

3.boot guest(not overcommit)
#/usr/libexec/qemu-kvm -name vm1 -nodefaults \
-m 420G \
-smp 32,cores=8,threads=1,sockets=4 \
-M pc-i440fx-rhel7.0.0 -cpu Opteron_G3 -rtc base=utc,clock=host,driftfix=slew -k en-us -boot menu=on -monitor stdio -vnc :2 -spice disable-ticketing,port=5932 -vga qxl -qmp tcp:0:5556,server,nowait -drive file=/home/win2008-x64.qcow2,if=none,id=disk,format=qcow2,cache=none,werror=stop,rerror=stop -device ide-hd,drive=disk,bus=ide.1,unit=0,id=disk0,bootindex=1 -balloon virtio

Actual results:
guest boot take more than 10min and host call trace

Expected results:
guest can boot with no errors

Additional info:
I will update test result in Intel host later
Comment 1 Xu Han 2013-08-27 07:24:03 UTC 
Created attachment 790810 [details]
host dmesg log
Comment 3 Luiz Capitulino 2013-09-05 13:53:27 UTC 
The host kernel seems to be spinning on a spinlock for 22s!

Is that machine on virtlab? I don't have any machine that big around, so I'll have to look for one to try to reproduce the issue.

Something you could do, is to get a kernel dump, store in it in the machine itself and let me log in.
Comment 4 juzhang 2013-09-06 01:31:10 UTC 
(In reply to Luiz Capitulino from comment #3)
> The host kernel seems to be spinning on a spinlock for 22s!
> 
> Is that machine on virtlab? I don't have any machine that big around, so
> I'll have to look for one to try to reproduce the issue.
> 
> Something you could do, is to get a kernel dump, store in it in the machine
> itself and let me log in.

Hi Hanxu,

Can you reply this info?
Comment 7 Luiz Capitulino 2013-09-09 14:16:47 UTC 
There's a number of fixes between kernels 3.10.0-11.el7 and 3.10.0-15.el7. If you really can't get the issue anymore with latest kernel, then I think you should close this bz as WORKSFORME.
Comment 8 Xu Han 2013-09-10 01:34:50 UTC 
According to comment 6 and comment 7, set this bug as WORKSFORME.
Note You need to log in before you can comment on or make changes to this bug.