Bug 966908 - [virtio-win][serial]The original terminal can not receive data after S4
[virtio-win][serial]The original terminal can not receive data after S4
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virtio-win (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity medium
: rc
: 7.0
Assigned To: Gal Hammer
Virtualization Bugs
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-24 05:02 EDT by guo jiang
Modified: 2014-03-13 10:46 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-03-13 10:46:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description guo jiang 2013-05-24 05:02:53 EDT
Description of problem:
  The original terminal can not receive data after resuming from S4.

Version-Release number of selected component (if applicable):
   * Red Hat Enterprise Linux Server release 6.4 (Santiago)
   * kernel-2.6.32-381.el6.x86_64    
   * qemu-img-rhev-0.12.1.2-2.369.el6.x86_64
   * virtio-win-prewhql-0.1-62
   * spice-server-0.12.0-12.el6.x86_64
   * seabios-0.6.1.2-27.el6.x86_64
   * vgabios-0.6b-3.7.el6.noarch
   * winxp-32   

How reproducible:
 100%

Steps to Reproduce:
1.Start guest w/ 1 virtio-serial-pci & 2 virtio-serial-port
  /usr/libexec/qemu-kvm -M rhel6.4.0 -m 2G -smp 2,cores=2 -cpu Penryn,+x2apic -usb -device usb-tablet -drive file=winxp-32.qcow2,format=qcow2,if=none,id=drive-ide0-0-0,werror=stop,rerror=stop,cache=none -device ide-drive,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device rtl8139,netdev=hostnet0,mac=00:13:49:17:42:C6,id=net0,addr=0x4 -uuid f85688f1-24f3-4e73-8545-7b67d4a0d82f -rtc-td-hack -no-kvm-pit-reinjection -rtc base=localtime,clock=host,driftfix=slew -chardev socket,id=111a,path=/tmp/monitor-winxp-32-serial,server,nowait -mon chardev=111a,mode=readline -name winxp-32-serial-62 -spice port=5930,disable-ticketing,id=on -vga qxl -bios /usr/share/seabios/bios.bin -device virtio-serial-pci,id=virtio-serial0,max_ports=31 -chardev socket,id=channel0,path=/tmp/port1,server,nowait -device virtserialport,chardev=channel0,name=com.redhat.rhevm.port1,bus=virtio-serial0.0,id=port0,nr=1 -chardev socket,id=channel1,path=/tmp/port2,server,nowait -device virtserialport,chardev=channel1,name=com.redhat.rhevm.port2,bus=virtio-serial0.0,id=port1,nr=2 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -monitor stdio

2.Transfering data from host to guest via port1 in a loop
 in guest:for /l %i in (1,1,150) do python  VirtIOChannel_guest_reieve.py com.redhat.rhevm.port2
 in host: run loop-guest-recieve.sh
  for((i=1;i<=150;i++))
  do
    echo $i;
    python serial-host-send.py /tmp/port2;
    sleep 1;
  done

3.hibernate guest

4.resume the guest with the same commandline in step1


Actual results:
The script was running on host after resuming but the terminal froze in the guest,can not receive data.

Expected results:
the script on guest could run and data could be transferred normally.

Additional info:
1.After killing the original terminal and running step2's guest script again, Guest could receive data. 
2.win7-64 is ok.
Comment 2 guo jiang 2013-05-26 23:32:25 EDT
Today, I try five times, only 4 times have be reproduced.
Comment 3 Gal Hammer 2013-06-16 09:44:14 EDT
I'm unable to reproduce with build 64. Can you please confirm? Thanks.

BTW: You might see an error message which say "The systen cannot message text for message number 0x13d in the message file for System.". It is probably caused by an error code returned by the driver which doesn't have an error string in Windows XP. It probably won't be fixed and is not considered as an error.
Comment 4 guo jiang 2013-06-18 02:04:51 EDT
Hi,Gal
 
  I only encountered in winxp, resuming after s4, the guest's original terminal stop there and no error report. After killing it and restart another script, could receive data again.

Thanks,
 Guo Jiang
Comment 5 Gal Hammer 2013-06-18 06:26:35 EDT
(In reply to guo jiang from comment #4)
> Hi,Gal
>  
>   I only encountered in winxp, resuming after s4, the guest's original
> terminal stop there and no error report. After killing it and restart
> another script, could receive data again.

This didn't answer my question. I was unable to reproduce it on Windows XP with build 64. Can you please confirm?

Thanks, Gal.
 
> Thanks,
>  Guo Jiang
Comment 6 Gal Hammer 2013-07-23 06:02:32 EDT
Can you please reply to my previous comment #5?

And another question. Were you able to reproduce it with other version of Windows, or is it just a Windows XP issue?
Comment 7 guo jiang 2013-07-23 21:11:50 EDT
Hi, Gal

QE could only reproduce it on windows-XP guest. Win7, Win8 and Win2012 don't hit this issue.

Thanks, Jiang.
Comment 8 Gal Hammer 2013-07-25 09:53:25 EDT
Closing as Windows XP support for S3/S4 is at low priority.
Comment 9 lijin 2013-12-03 22:24:20 EST
reopen this bug as win2012R2 hit the same issue.

package info:
    qemu-kvm-rhev-0.12.1.2-2.415.el6_5.3.x86_64
    kernel-2.6.32-433.el6.x86_64
    seabios-0.6.1.2-28.el6.x86_64
    virtio-win-prewhql-74

steps to reproduce:
1./usr/libexec/qemu-kvm -drive file=win2k12R2.qcow2,if=none,cache=none,media=disk,format=qcow2,id=drive-ide0-0-1 -device ide-drive,id=ide0-0-1,drive=drive-ide0-0-1,bootindex=0 -usb -device usb-tablet -spice disable-ticketing,port=5901 -vga qxl -global qxl-vga.revision=3 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -netdev tap,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:7f:f9:F6,bus=pci.0 -chardev file,path=/root/console.log,id=serial1 -device isa-serial,chardev=serial1,id=s1 -cpu Penryn -M rhel6.5.0 -monitor stdio -name win2012R2-balloon-74 -smp 4,maxcpus=4,cores=2,threads=2,sockets=1 -m 4G -enable-kvm -cdrom /usr/share/rhev-guest-tools-iso/rhev-tools-setup.iso -device virtio-serial-pci,id=virtio-serial0,max_ports=16 -chardev socket,path=/tmp/tt0,server,nowait,id=chardev0 -device virtserialport,chardev=chardev0,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port0 -chardev socket,path=/tmp/tt1,server,nowait,id=chardev1 -device virtserialport,chardev=chardev1,name=com.redhat.rhevm.vdsm1,bus=virtio-serial0.0,id=port1
2.Transfering data from host to guest via port1 in a loop
eg:in the guest # for ((;;)) ;do python VirtIOChannel_guest_reieve.py com.redhat.rhevm.vdsm; done
on the host # for ((;;)) ;do python serial-host-send.py /tmp/tt0 ; done
3.hibernate Guest
4.resume the guest w/ the same commandline in step1

After step4,the original cmd terminal in guest froze,and cannot receive any data from,ctrl+C also deosn't work;
After close the original terminal,then reopen a new one and run the script,serialport works nornally.

Excepted result:
the original terminal should keep receiving data without reopen a new cmd.
Comment 10 RHEL Product and Program Management 2013-12-09 03:25:32 EST
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.
Comment 11 Gal Hammer 2013-12-11 09:23:45 EST
(In reply to lijin from comment #9)
> reopen this bug as win2012R2 hit the same issue.
> 
> package info:
>     qemu-kvm-rhev-0.12.1.2-2.415.el6_5.3.x86_64
>     kernel-2.6.32-433.el6.x86_64
>     seabios-0.6.1.2-28.el6.x86_64
>     virtio-win-prewhql-74

I was unable to reproduce it.
 
> steps to reproduce:
> 1./usr/libexec/qemu-kvm -drive
> file=win2k12R2.qcow2,if=none,cache=none,media=disk,format=qcow2,id=drive-
> ide0-0-1 -device ide-drive,id=ide0-0-1,drive=drive-ide0-0-1,bootindex=0 -usb
> -device usb-tablet -spice disable-ticketing,port=5901 -vga qxl -global
> qxl-vga.revision=3 -global PIIX4_PM.disable_s3=0 -global
> PIIX4_PM.disable_s4=0 -netdev tap,id=hostnet0 -device
> e1000,netdev=hostnet0,id=net0,mac=52:54:00:7f:f9:F6,bus=pci.0 -chardev
> file,path=/root/console.log,id=serial1 -device
> isa-serial,chardev=serial1,id=s1 -cpu Penryn -M rhel6.5.0 -monitor stdio
> -name win2012R2-balloon-74 -smp 4,maxcpus=4,cores=2,threads=2,sockets=1 -m
> 4G -enable-kvm -cdrom /usr/share/rhev-guest-tools-iso/rhev-tools-setup.iso
> -device virtio-serial-pci,id=virtio-serial0,max_ports=16 -chardev
> socket,path=/tmp/tt0,server,nowait,id=chardev0 -device
> virtserialport,chardev=chardev0,name=com.redhat.rhevm.vdsm,bus=virtio-
> serial0.0,id=port0 -chardev socket,path=/tmp/tt1,server,nowait,id=chardev1
> -device
> virtserialport,chardev=chardev1,name=com.redhat.rhevm.vdsm1,bus=virtio-
> serial0.0,id=port1
> 2.Transfering data from host to guest via port1 in a loop
> eg:in the guest # for ((;;)) ;do python VirtIOChannel_guest_reieve.py
> com.redhat.rhevm.vdsm; done
> on the host # for ((;;)) ;do python serial-host-send.py /tmp/tt0 ; done
> 3.hibernate Guest

How did you put the guest into hibernate? Did you install QXL driver?

> 4.resume the guest w/ the same commandline in step1
> 
> After step4,the original cmd terminal in guest froze,and cannot receive any
> data from,ctrl+C also deosn't work;
> After close the original terminal,then reopen a new one and run the
> script,serialport works nornally.
> 
> Excepted result:
> the original terminal should keep receiving data without reopen a new cmd.
Comment 12 lijin 2013-12-11 21:12:28 EST
(In reply to Gal Hammer from comment #11)
> (In reply to lijin from comment #9)
> > reopen this bug as win2012R2 hit the same issue.
> > 
> > package info:
> >     qemu-kvm-rhev-0.12.1.2-2.415.el6_5.3.x86_64
> >     kernel-2.6.32-433.el6.x86_64
> >     seabios-0.6.1.2-28.el6.x86_64
> >     virtio-win-prewhql-74
> 
> I was unable to reproduce it.
>  
> > steps to reproduce:
> > 1./usr/libexec/qemu-kvm -drive
> > file=win2k12R2.qcow2,if=none,cache=none,media=disk,format=qcow2,id=drive-
> > ide0-0-1 -device ide-drive,id=ide0-0-1,drive=drive-ide0-0-1,bootindex=0 -usb
> > -device usb-tablet -spice disable-ticketing,port=5901 -vga qxl -global
> > qxl-vga.revision=3 -global PIIX4_PM.disable_s3=0 -global
> > PIIX4_PM.disable_s4=0 -netdev tap,id=hostnet0 -device
> > e1000,netdev=hostnet0,id=net0,mac=52:54:00:7f:f9:F6,bus=pci.0 -chardev
> > file,path=/root/console.log,id=serial1 -device
> > isa-serial,chardev=serial1,id=s1 -cpu Penryn -M rhel6.5.0 -monitor stdio
> > -name win2012R2-balloon-74 -smp 4,maxcpus=4,cores=2,threads=2,sockets=1 -m
> > 4G -enable-kvm -cdrom /usr/share/rhev-guest-tools-iso/rhev-tools-setup.iso
> > -device virtio-serial-pci,id=virtio-serial0,max_ports=16 -chardev
> > socket,path=/tmp/tt0,server,nowait,id=chardev0 -device
> > virtserialport,chardev=chardev0,name=com.redhat.rhevm.vdsm,bus=virtio-
> > serial0.0,id=port0 -chardev socket,path=/tmp/tt1,server,nowait,id=chardev1
> > -device
> > virtserialport,chardev=chardev1,name=com.redhat.rhevm.vdsm1,bus=virtio-
> > serial0.0,id=port1
> > 2.Transfering data from host to guest via port1 in a loop
> > eg:in the guest # for ((;;)) ;do python VirtIOChannel_guest_reieve.py
> > com.redhat.rhevm.vdsm; done
> > on the host # for ((;;)) ;do python serial-host-send.py /tmp/tt0 ; done
> > 3.hibernate Guest
> 
> How did you put the guest into hibernate? Did you install QXL driver?
> 
> > 4.resume the guest w/ the same commandline in step1
> > 
> > After step4,the original cmd terminal in guest froze,and cannot receive any
> > data from,ctrl+C also deosn't work;
> > After close the original terminal,then reopen a new one and run the
> > script,serialport works nornally.
> > 
> > Excepted result:
> > the original terminal should keep receiving data without reopen a new cmd.

Yes,I installed the qxl driver.

Actually I found this issue also happened on other OS,at least I tried win2k8-64,win2012,win7-32.Most occur after resume from s4,sometimes after resume from s3.

It's easy to reproduce it for me,the terminal is not totally froze,I can scroll the cmd terminal in guest,but the receive script didn't work,it kept still,and cannot use ctrl+c to stop the script.Close the terminal and rerun the script,it works again.
Comment 13 Mike Cao 2013-12-12 01:28:18 EST
I can reproduce this issue as well on win8-64 with VNC steps same as comment #9 ,the terminal I use is cygwin
Comment 14 Gal Hammer 2013-12-12 04:23:53 EST
(In reply to Mike Cao from comment #13)
> I can reproduce this issue as well on win8-64 with VNC steps same as comment
> #9 ,the terminal I use is cygwin

win7-32 w/spice works for me.

Are you using qemu-kvm-0.12.1.2-2.415.el6.x86_64 or qemu-kvm-rhev-0.12.1.2-2.415.el6_5.3.x86_64?
Comment 15 Mike Cao 2013-12-12 05:29:37 EST
(In reply to Gal Hammer from comment #14)
> (In reply to Mike Cao from comment #13)
> > I can reproduce this issue as well on win8-64 with VNC steps same as comment
> > #9 ,the terminal I use is cygwin
> 
> win7-32 w/spice works for me.
> 
> Are you using qemu-kvm-0.12.1.2-2.415.el6.x86_64 or
> qemu-kvm-rhev-0.12.1.2-2.415.el6_5.3.x86_64?

Sorry ,I am using RHEL7 host with 3.10.0-50.el7.x86_64
qemu-kvm-rhev-1.5.3-19.el7.x86_64
Comment 16 Gal Hammer 2013-12-31 10:45:52 EST
(In reply to Mike Cao from comment #15)
> (In reply to Gal Hammer from comment #14)
> > (In reply to Mike Cao from comment #13)
> > > I can reproduce this issue as well on win8-64 with VNC steps same as comment
> > > #9 ,the terminal I use is cygwin
> > 
> > win7-32 w/spice works for me.
> > 
> > Are you using qemu-kvm-0.12.1.2-2.415.el6.x86_64 or
> > qemu-kvm-rhev-0.12.1.2-2.415.el6_5.3.x86_64?
> 
> Sorry ,I am using RHEL7 host with 3.10.0-50.el7.x86_64
> qemu-kvm-rhev-1.5.3-19.el7.x86_64

I was unable to reproduce on a RHEL-7 host (kernel-3.10.0-64.el7.x86_64) with qemu-kvm-1.5.3-30.el7.x86_64 and a Windows 7 32-bit guest (virtio-win build 74).

Can you please update your qemu-kvm package and test again?
Comment 18 Mike Cao 2014-02-28 01:24:39 EST
lijin, pls retest it on latest virtio-win /qemu-kvm/seabios according to commen t#9 ?
Comment 19 lijin 2014-03-02 22:24:10 EST
(In reply to Mike Cao from comment #18)
> lijin, pls retest it on latest virtio-win /qemu-kvm/seabios according to
> commen t#9 ?

win7-32 guest still hit this issue with the latest package.

package info:
qemu-kvm-rhev-1.5.3-50.el7.x86_64
kernel-3.10.0-98.el7.x86_64
seabios-1.7.2.2-11.el7.x86_64
virtio-win-1.6.8-4.el6.noarch

1.boot guest with qemu command:
/usr/libexec/qemu-kvm \
-M pc -m 2G -smp 2,cores=2 \
-drive file=big.qcow2,format=qcow2,media=disk,if=none,cache=none,id=drive-scsi,serial=scsi1 \
-device ide-drive,drive=drive-scsi,id=ide-scsi-pci1,bootindex=1 \
-rtc base=localtime,clock=host,driftfix=slew -no-kvm-pit-reinjection \
-name win7-32 \
-global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 \
-usb -device usb-tablet \
-monitor stdio \
-spice disable-ticketing,port=5902 -vga qxl -global qxl-vga.revision=3 \
-netdev tap,id=hostnet1,script=/etc/qemu-ifup,downscript=no -device e1000,netdev=hostnet1,id=net1,mac=00:52:22:16:54:48,bus=pci.0 \
-cdrom /usr/share/virtio-win/virtio-win.iso \
-fda /usr/share/virtio-win/virtio-win_x86.vfd \
-device virtio-serial-pci,id=virtio-serial0,max_ports=16 -chardev socket,path=/tmp/tt0,server,nowait,id=chardev0 -device virtserialport,chardev=chardev0,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port0,nr=1 -chardev socket,path=/tmp/tt1,server,nowait,id=chardev1 -device virtserialport,chardev=chardev1,name=com.redhat.rhevm.vdsm1,bus=virtio-serial0.0,id=port1

2.Transfering data from host to guest via port1 in a loop
on the guest 
# for /l %i in (1.1.1000) do python VirtIOChannel_guest_reieve.py com.redhat.rhevm.vdsm
on the host
# for ((j=1;j<=1000;j++));
do python serial-host-send.py /tmp/tt0;
sleep 1;
done;

3.hibernate Guest
4.resume the guest w/ the same commandline in step1

actual result:
guest stop receiving data,the script running in cmd window hang,"ctrl+c" does not work.
close this cmd window and open a new one,then run the receive script,guest can receive data again.

excepted result:
guest can receive data without closing the original cmd window.
Comment 20 Gal Hammer 2014-03-13 10:46:50 EDT
Closing after failing to reproduce w/qemu-kvm-1.5.3-52.el7.x86_64 on a RHEL-7 host.

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