Red Hat Bugzilla – Bug 624659
suspend to disk doesn't work.
Last modified: 2014-06-18 05:13:23 EDT
Description of problem:
In guest,do "suspend to disk" and "suspend to memory" operation,
suspend to memory works,but,suspend to disk failed
Version-Release number of selected component (if applicable):
#rpm -q qemu-kvm
Steps to Reproduce:
1.Boot guest,not includes any virtio drivers
#/usr/libexec/qemu-kvm -m 4G -smp 64 -drive file=/root/zhangjunyi/rhel6.0_2.59_64.qcow2,id=test,boot=on,cache=none,format=qcow2 -device ide-drive,drive=test -cpu qemu64,+sse2 -monitor stdio -boot order=cdn,menu=on -vnc :9 -qmp tcp:0:4444,server,nowait -netdev tap,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=22:11:22:45:66:34
2.In guest,suspend to memory
echo mem > /sys/power/state
3.In guest,suspend to disk
echo disk > /sys/power/state
After step3,qemu-kvm was aborted,however,when we boot guest using same command,after guest booted up,we have to input user name and password log in.no difference to boot a guest.
suspend to disk works well.
Retested in rc2 version using qemu-kvm-0.12.1.2-2.113.el6.x86_64.
Can't hit issue any more.so,mark this issue as closed as worksforme.If any one hit this issue again,please reopen it.
This bug does exist on guest running with X11 run level, and does not exist on guest with text mode.
(In reply to comment #2)
> This bug does exist on guest running with X11 run level, and does not exist on
> guest with text mode.
CLI:/usr/libexec/qemu-kvm -M rhel6.0.0 -enable-kvm -m 1024 -smp 2,sockets=2,cores=1,threads=1 -name rhel6-64 -uuid 136e1ef4-8bd0-ff46-bb70-01988aca3796 -nodefconfig -nodefaults -rtc base=utc -boot c -drive file=/mnt/RHEL6-64.img,if=none,id=drive-ide0-0-0,boot=on,format=raw,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:14:32:11:43:87,bus=pci.0,addr=0x9 -usb -spice port=5902,addr=10.66.91.53,disable-ticketing,plaintext-channel=main,plaintext-channel=inputs -vga qxl -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -monitor stdio -soundhw ac97
Does this work without spice? This could actually be a guest kernel issue. What's the guest kernel log messages when you suspend and resume?
(In reply to comment #4)
> Does this work without spice? This could actually be a guest kernel issue.
> What's the guest kernel log messages when you suspend and resume?
1. this bug does not exist when using option -vnc :1 -vga cirrus to connect guest
Attach dmesg log file s4_s3.dmesg in guest
2. this bug does exist when using spice
Attach dmesg log file s4_s3_qxl.dmesg in guest.
Created attachment 455422 [details]
Created attachment 455423 [details]
Can you try this without the balloon device? Please try w/o any virtio devices. (You can add virtio.ko to the guest's blacklist in /etc/modprobe.d/)
(In reply to comment #8)
> Can you try this without the balloon device? Please try w/o any virtio
> devices. (You can add virtio.ko to the guest's blacklist in /etc/modprobe.d/)
Try scenario in comment 5 without any virtio device, we get same result like:
spice- does not work.
Attach dmesg info again.
Created attachment 455432 [details]
Thanks a lot! Assigning to Gerd.
Created attachment 455435 [details]
Created attachment 456879 [details]
X Server log
Guest bug. It is the X-Server crashing, that is the reason you are back to the login screen after suspend-to-disk.
Can you try the latest driver from 6.1 please?
(In reply to comment #14)
> Can you try the latest driver from 6.1 please?
According to Comment #12 and Comment #16 from bz 678208, guest hangs when using latest xorg-x11-drv-qxl (xorg-x11-drv-qxl-0.0.12-5.el6), we will test again once it is fixed. Thanks.
The X server gets SIGSEGV after trying to write to port 0xc040:
Dump of assembler code for function outb:
0x00007f4dbbb7af10 <+0>: push %rbp
0x00007f4dbbb7af11 <+1>: mov %rsp,%rbp
0x00007f4dbbb7af14 <+4>: mov %edi,%edx
0x00007f4dbbb7af16 <+6>: mov %esi,%eax
0x00007f4dbbb7af18 <+8>: mov %dx,-0x4(%rbp)
0x00007f4dbbb7af1c <+12>: mov %al,-0x8(%rbp)
0x00007f4dbbb7af1f <+15>: movzbl -0x8(%rbp),%eax
0x00007f4dbbb7af23 <+19>: movzwl -0x4(%rbp),%edx
=> 0x00007f4dbbb7af27 <+23>: out %al,(%dx)
0x00007f4dbbb7af28 <+24>: leaveq
0x00007f4dbbb7af29 <+25>: retq
End of assembler dump.
(gdb) print /x $rdx
$5 = 0xc040
I don't believe this should happen since the X server does call the system call that enables it to do port output (I forgot which one that is at the moment).
Don't have a fix for 6.1, and not likely to make it. Devnacking.
Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.
Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.
Moving to RHEL 6.3 for now, but to make any kind of progress here, we need confirmation that this bug still exists with the latest kernels (host and guest) and driver.
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
Does this bug reproduce with latest guest and host?
(In reply to comment #25)
> Does this bug reproduce with latest guest and host?
the latest guest and host did not have this issue. We can do "suspend to disk" and "suspend to memory" operation in guest successfully with specify the PIIX4_PM.disable_s3=0 and PIIX4_PM.disable_s4=0 using vnc or spice, and then can resume it correctly.
qemu-kvm command line:
# /usr/libexec/qemu-kvm -M rhel6.4.0 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -usb -device usb-tablet,id=input0 -name sluo-testing -uuid 990ea161-6b67-47b2-b803-19fb01d30d30 -rtc base=localtime,clock=host,driftfix=slew -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x3 -chardev socket,id=channel1,path=/tmp/helloworld1,server,nowait -device virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port1 -chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait -device virtserialport,chardev=channel2,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port2 -drive file=/home/RHEL6.4_Server_x86_64.raw,if=none,id=drive-system-disk,format=raw,cache=none,aio=native,werror=stop,rerror=stop -device ide-drive,drive=drive-system-disk,id=system-disk,bootindex=1 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=BC:96:9D:05:51:EC,bus=pci.0,addr=0x4 -balloon none -spice port=5931,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -serial unix:/tmp/ttyS0,server,nowait -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -boot menu=on -monitor stdio
we can do S3/S4 with vnc or spice successfully and resume it correctly.
Alright, so this was one of the issues that got resolved with the earlier work, closing this.