Red Hat Bugzilla – Bug 821377
Guest for win2k8-R2 with -smp 64 and -m 256GB often stuck after resuming from S4.
Last modified: 2015-03-04 00:47:59 EST
Description of problem:
Found this issue when running job "Common Scenario Stress With IO" for svvp, guest for win2k8-R2 with -smp 64 and -m 256GB often stuck after resuming from S4.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Summarize the main steps for job "Common Scenario Stress With IO" for svvp as following:
1. Disable/Enable driver repeatedly for almost 10 times.
2. Do simpeIOStress
3. S4 after IO stress work done.
4. Resuming from S4.
5. Repeate 1-4 steps for many times, such as 12 times.
Guest stuck after resuming from S4,mainly happened in the first several times for S4,please refer to the attached "System_stuck_afterResumingFromS4_1.png".
Guest should resume successfully after S4.
When system_reset from qemu monitor, guest will prompt if "continue with system resume", if select it, you can continue resuming successfully,please refer to the attached "System_stuck_afterResumingFromS4_2.png".
Created attachment 584307 [details]
Created attachment 584308 [details]
For job "Common Scenario Stress With IO" for svvp, if there is some mistakes in the steps described in the bug,please correct me, thanks!
I don't see any mistake in your description.
Could you please export the System Event Log to a file and upload it as an
Please also provide the guest configuration - are virtio drivers used?
(In reply to comment #6)
> Please also provide the guest configuration - are virtio drivers used?
Yes ,We use virtio drivers ,We hit this When we run SVVP Test -(system)Sleep stress with IO job .
Created attachment 584534 [details]
/usr/libexec/qemu-kvm -m 256G -smp 64 -cpu cpu64-rhel6,+x2apic,family=0xf -usb -device usb-tablet -drive file=Intel_Max_Sut.raw,format=raw,if=none,id=drive-virtio0,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio0,id=virtio-blk-pci0,bootindex=1 -netdev tap,sndbuf=0,id=hostnet0,vhost=on,script=/etc/qemu-ifup0,downscript=no -device virtio-net-pci,netdev=hostnet0,mac=00:10:1a:75:50:01,bus=pci.0,addr=0x4,id=virtio-net-pci0 -uuid e8bfe003-1426-4924-b0ac-bd42360a1c36 -rtc base=localtime,clock=host,driftfix=slew -no-kvm-pit-reinjection -chardev socket,id=111a,path=/tmp/intel-max-sut,server,nowait -mon chardev=111a,mode=readline -name intel-max-sut -vnc :1 -drive file=en_windows_server_2008_r2_standard_enterprise_datacenter_and_web_with_sp1_x64_dvd_617601.iso,media=cdrom,id=cdrom,if=none -device ide-drive,drive=cdrom
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development. This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
Might be the same issue as Bug 820112
This is a tough bug that requires a lot of time and patience.
The price-performance of working on it currently is not good, with all the Win8/HCK issues.
Deferring to 6.5.
There were so many changes since RHEL6.4. Please recheck.
(In reply to Ronen Hod from comment #20)
> There were so many changes since RHEL6.4. Please recheck.
Can you handle this?
(In reply to juzhang from comment #21)
> (In reply to Ronen Hod from comment #20)
> > QE,
> > There were so many changes since RHEL6.4. Please recheck.
> Hi Xiangchun,
> Can you handle this?
> Best Regards,
I will find a machine to re-test it.
As QE didn't find big memory machine. so Re-test it with -m 12G -smp 64.
According to comment 0.
S4 pass, resume pass.
QE will continue to it when finding big memory machine. and update test result it asap.