Bug 624659 - suspend to disk doesn't work.
suspend to disk doesn't work.
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: xorg-x11-drv-qxl (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Søren Sandmann Pedersen
Desktop QE
: Reopened
Depends On:
Blocks: 580954
  Show dependency treegraph
 
Reported: 2010-08-17 08:05 EDT by juzhang
Modified: 2014-06-18 05:13 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-18 23:46:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
vnc-dmesg (4.23 KB, text/plain)
2010-10-25 04:09 EDT, Shirley Zhou
no flags Details
spice-dmesg (4.73 KB, text/plain)
2010-10-25 04:10 EDT, Shirley Zhou
no flags Details
vnc-dmesg-novirtio (4.00 KB, text/plain)
2010-10-25 04:50 EDT, Shirley Zhou
no flags Details
spice-dmesg-novirtio (4.40 KB, text/plain)
2010-10-25 05:05 EDT, Shirley Zhou
no flags Details
X Server log (36.75 KB, text/plain)
2010-11-01 10:33 EDT, Gerd Hoffmann
no flags Details

  None (edit)
Description juzhang 2010-08-17 08:05:11 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):
Host kernel:
#uname -r
2.6.32-63.el6.x86_64
#rpm -q qemu-kvm
qemu-kvm-0.12.1.2-2.109.el6.x86_64

Guest kernel
#uname -r
2.6.32-59.1.el6.x86_64

How reproducible:


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
  
Actual results:
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.

Expected results:
suspend to disk works well.


Additional info:
Comment 1 juzhang 2010-09-14 22:47:54 EDT
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.
Comment 2 Shirley Zhou 2010-09-16 03:18:25 EDT
This bug does exist on guest running with X11 run level, and does not exist on guest with text mode.
Comment 3 Shirley Zhou 2010-09-16 03:45:33 EDT
(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.

Guest: RHEL6.0-64
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
Comment 4 Amit Shah 2010-10-22 06:27:52 EDT
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?
Comment 5 Shirley Zhou 2010-10-25 04:05:58 EDT
(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?

Hi, Amit

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.
Comment 6 Shirley Zhou 2010-10-25 04:09:40 EDT
Created attachment 455422 [details]
vnc-dmesg
Comment 7 Shirley Zhou 2010-10-25 04:10:08 EDT
Created attachment 455423 [details]
spice-dmesg
Comment 8 Amit Shah 2010-10-25 04:21:50 EDT
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/)
Comment 9 Shirley Zhou 2010-10-25 04:49:52 EDT
(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:

vnc -work
spice- does not work.

Attach dmesg info again.
Comment 10 Shirley Zhou 2010-10-25 04:50:34 EDT
Created attachment 455432 [details]
vnc-dmesg-novirtio
Comment 11 Amit Shah 2010-10-25 05:02:35 EDT
Thanks a lot!  Assigning to Gerd.
Comment 12 Shirley Zhou 2010-10-25 05:05:36 EDT
Created attachment 455435 [details]
spice-dmesg-novirtio
Comment 13 Gerd Hoffmann 2010-11-01 10:33:24 EDT
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.
Comment 14 Søren Sandmann Pedersen 2011-02-15 15:16:17 EST
Can you try the latest driver from 6.1 please?
Comment 15 Chao Yang 2011-03-14 22:40:51 EDT
(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.
Comment 16 Søren Sandmann Pedersen 2011-03-19 15:26:51 EDT
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).
Comment 17 Jonathan Blandford 2011-03-21 10:34:06 EDT
Don't have a fix for 6.1, and not likely to make it.  Devnacking.
Comment 18 RHEL Product and Program Management 2011-04-03 21:43:17 EDT
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.
Comment 21 Søren Sandmann Pedersen 2011-10-28 14:02:43 EDT
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.
Comment 24 Suzanne Yeghiayan 2012-02-14 18:02:18 EST
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
representative.
Comment 25 Amit Shah 2013-02-18 06:12:13 EST
Does this bug reproduce with latest guest and host?
Comment 26 Sibiao Luo 2013-02-18 22:28:17 EST
(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.

host info:
kernel-2.6.32-361.el6.x86_64
qemu-kvm-0.12.1.2-2.357.el6.x86_64
guest info:
kernel-2.6.32-361.el6.x86_64

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

Actual results:
we can do S3/S4 with vnc or spice successfully and resume it correctly.
Comment 27 Amit Shah 2013-02-18 23:46:54 EST
Alright, so this was one of the issues that got resolved with the earlier work, closing this.

Note You need to log in before you can comment on or make changes to this bug.