nc says it's an invalid argument; I tend to think it was a result of a typo in the socket name.  Since you can't reproduce it easily, I'm tempted to just close->notabug.  But I'll wait for a few more days for confirmation, or a recurrence of this bug.  Please keep an eye out for it, and test it a few more times.

(In reply to Amit Shah from comment #2)
> nc says it's an invalid argument; I tend to think it was a result of a typo
> in the socket name.  Since you can't reproduce it easily, I'm tempted to
> just close->notabug.  But I'll wait for a few more days for confirmation, or
> a recurrence of this bug.  Please keep an eye out for it, and test it a few
> more times.

It is not a typo.

After the bug occurs,I kill the VM ,and restart it w/ exactly same commandline ,then use nc -U to connect the exactly same socket ,the issue will gone 

It happened more or less 8 times during my vioserial functional test run ,so report this bug

OK.

We don't really know which syscall returns with -EINVAL in nc's invocation.  You could try strace'ing the nc instance next time.

BTW did qemu get enough time to initialize the socket?  i.e. are you issuing the nc command too quickly, perhaps even before qemu has had a change to init the chardev?  If you're doing this in a script or similar, please try adding a delay between qemu invocation and nc invocation.

(In reply to Amit Shah from comment #4)
> OK.
> 
> We don't really know which syscall returns with -EINVAL in nc's invocation. 
> You could try strace'ing the nc instance next time.
> 
Could you show me more detailed usage about it ?
> BTW did qemu get enough time to initialize the socket?  i.e. are you issuing
> the nc command too quickly, perhaps even before qemu has had a change to
> init the chardev?  If you're doing this in a script or similar, please try
> adding a delay between qemu invocation and nc invocation.

No ,I am doing it manually ,I a mmore I issue the nc command after qemu process start

(In reply to Mike Cao from comment #5)
> (In reply to Amit Shah from comment #4)
> > OK.
> > 
> > We don't really know which syscall returns with -EINVAL in nc's invocation. 
> > You could try strace'ing the nc instance next time.
> > 
> Could you show me more detailed usage about it ?

strace -o nc-strace -f -ff <regular nc cmdline>

Then attach all the nc-strace* files to the bug.

Reproduced it again with following steps ,but not 100% reproduce 

1.Transfering date from guest to host
in the host scripts like #for((;;)) ; do python serialhost-receive.py /tmp/075SRL201264VFE_port0 ;done
2.ctrl-c it 
3.ctrl-z it 

^Z
[1]+  Stopped                 python serial-host-receive.py /tmp/075SRL201264VFE_port0
[root@dhcp-9-181 guest-send]# killall -9 python
[root@dhcp-9-181 guest-send]# nc -U /tmp/075SRL201264VFE_port0
Ncat: Invalid argument.

3.10.0-113.el7.x86_64
qemu-kvm-rhev-1.5.3-53.el7.x86_64

ReTest this issue 
on 3.10.0-121.el7.x86_64
qemu-kvm-1.5.3-62.el7.x86_64

Steps same as comment #8,Still can reproduce this issue

Mike, a few questions:

What happens if you use udp sockets instead of unix or tcp on host chardev?

What do the python scripts do?

Did you manage to get a strace of the nc process as described in comment 6?

(In reply to Amit Shah from comment #12)
> Mike, a few questions:
> 
> What happens if you use udp sockets instead of unix or tcp on host chardev?

I will try to find the cmmandline to retry it 
> 
> What do the python scripts do?

For linux guests there is /dev/vport0p1 in the guest which can be used to read/write data successuflly while windows guest doesn't ,we use python scripts to transferring data from host to guest or guest to host 
> 
> Did you manage to get a strace of the nc process as described in comment 6?
Can you show me the exactly commands ?

Thanks,
Mike

(In reply to Mike Cao from comment #13)
> (In reply to Amit Shah from comment #12)
> > Mike, a few questions:
> > 
> > What happens if you use udp sockets instead of unix or tcp on host chardev?
> 
> I will try to find the cmmandline to retry it 
> > 
> > What do the python scripts do?
> 
> For linux guests there is /dev/vport0p1 in the guest which can be used to
> read/write data successuflly while windows guest doesn't ,we use python
> scripts to transferring data from host to guest or guest to host 

From comment 8, looks like you're using the scripts in the host?

Also, if you use ^Z, the process is only going to be frozen, and the sockets become unavailable for more connections.  That's the reason I'm asking you to try udp sockets.

> > Did you manage to get a strace of the nc process as described in comment 6?
> Can you show me the exactly commands ?

comment 6 has the cmdline; should be sufficient.

Created attachment 918116 [details]
strace.txt

(In reply to Amit Shah from comment #14)
> (In reply to Mike Cao from comment #13)
> > (In reply to Amit Shah from comment #12)
> > > Mike, a few questions:
> > > 
> > > What happens if you use udp sockets instead of unix or tcp on host chardev?
> > 
> > I will try to find the cmmandline to retry it 
> > > 
> > > What do the python scripts do?
> > 
> > For linux guests there is /dev/vport0p1 in the guest which can be used to
> > read/write data successuflly while windows guest doesn't ,we use python
> > scripts to transferring data from host to guest or guest to host 
> 
> From comment 8, looks like you're using the scripts in the host?
> 
> Also, if you use ^Z, the process is only going to be frozen, and the sockets
> become unavailable for more connections.  That's the reason I'm asking you
> to try udp sockets.

after ^Z , I use #fg to active it ,then close it

test with virtio-win-prewhql-90 and qemu-kvm-0.12.1.2-2.441.el6.bz1027181.x86_64:

package info:
qemu-kvm-0.12.1.2-2.441.el6.bz1027181.x86_64
virtio-win-prewhql-90 
2.6.32-486.el6.x86_64

scenario 1:
steps:
1.boot guest with:
/usr/libexec/qemu-kvm -drive file=088SRLWIN864ODX,if=none,cache=none,media=disk,format=raw,id=drive-ide0-0-1 -device ide-drive,id=ide0-0-1,drive=drive-ide0-0-1,bootindex=0 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -spice disable-ticketing,port=5901 -vga qxl -global qxl-vga.revision=3 -usb -device usb-tablet -netdev tap,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=00:52:e2:71:29:46,bus=pci.0 -chardev file,path=/root/console.log,id=serial1 -monitor unix:/tmp/tt,server,nowait -device isa-serial,chardev=serial1,id=s1 -cpu Penryn,hv_relaxed,+sep -M rhel6.5.0 -smp 2,maxcpus=2,cores=2,threads=1,sockets=1 -m 2G -enable-kvm -cdrom /usr/share/virtio-win/virtio-win.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,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.nc -U /tmp/tt1
3.ctrl-c the nc
4.nc -U /tmp/tt1 again

Actual result:
during step2 and step4,nc -U /tmp/tt1 connected successfully

scenario 2:
steps:
1.boot guest the above command;
2.transfer data from guest to host:
eg: on the host # for ((;;)) ; do python serial-host-receive.py /tmp/tt1; done
    in the guest #for ((;;)) ; do python VirtIOChannel_guest_send.py com.redhat.rhevm.vdsm1;done
3.ctrl-c the script on host side
4.rerun the python script again to check  whether host side still can recieve data.

Actual result:
host can receive data during step2 and step4.

(In reply to lijin from comment #17)
> test with virtio-win-prewhql-90 and
> qemu-kvm-0.12.1.2-2.441.el6.bz1027181.x86_64:

This originally is a RHEL7 bug.  The fix in bug 1027181 is targeted for RHEL6.  RHEL7 already has the fix mentioned there.

Looks like a problem somewhere else.  If it still reproduces, please reopen.