(In reply to CongLi from comment #0)
> 1. boot a win2012r2 guest

Please provide more information about this step. Which virtualization method are you using? virt-manager, GNOME Boxes, qemu directly, something else...?

(In reply to Tim Waugh from comment #2)
> (In reply to CongLi from comment #0)
> > 1. boot a win2012r2 guest
> 
> Please provide more information about this step. Which virtualization method
> are you using? virt-manager, GNOME Boxes, qemu directly, something else...?

Use qemu directly.
qemu-kvm-rhev-1.5.3-50.el7.x86_64

Qemu CML:
/home/staf-kvm-devel/autotest-devel/client/tests/virt/qemu/qemu \
    -S  \
    -name 'virt-tests-vm1'  \
    -sandbox off  \
    -M pc  \
    -nodefaults  \
    -vga std  \
    -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20140305-111702-GRV8xGVw,server,nowait \
    -mon chardev=qmp_id_qmpmonitor1,mode=control  \
    -chardev socket,id=serial_id_serial0,path=/tmp/serial-serial0-20140305-111702-GRV8xGVw,server,nowait \
    -device isa-serial,chardev=serial_id_serial0  \
    -chardev socket,id=seabioslog_id_20140305-111702-GRV8xGVw,path=/tmp/seabios-20140305-111702-GRV8xGVw,server,nowait \
    -device isa-debugcon,chardev=seabioslog_id_20140305-111702-GRV8xGVw,iobase=0x402 \
    -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=03 \
    -device virtio-net-pci,mac=9a:9e:9f:a0:a1:a2,id=id4GFcn7,netdev=id376n9J,bus=pci.0,addr=04  \
    -netdev tap,id=id376n9J,vhost=on  \
    -m 4096  \
    -smp 4,maxcpus=4,cores=2,threads=1,sockets=2  \
    -cpu 'SandyBridge',+kvm_pv_unhalt,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
    -vnc :0  \
    -rtc base=localtime,clock=host,driftfix=slew  \
    -boot order=cdn,once=c,menu=off \
    -enable-kvm \
    -monitor stdio \
    -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x05 \
    -drive id=drive_image1,if=none,cache=none,snapshot=off,aio=native,file=/home/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/win2012r2-64-virtio.qcow2 \
    -device scsi-hd,id=image1,drive=drive_image1 \

Thanks,
Cong

Please run this command as root before running vncviewer, to capture all the RFB traffic between vncviewer and qemu:

tcpdump -U -s0 -nilo port 5900 -w rfb.pcap

Then, from a different login, run vncviewer until you get the error messages.  Afterwards, in the session running tcpdump press Ctrl+C to stop traffic capture.

Finally, please attach the resulting rfb.pcap.

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.

I had the same problem in SUSE and found this bug while trying to solve it. The 130 in "XRequest.130" is major opcode, you will most probably find out it belongs to the SHM extension.

This bug can happen when tigervnc (running on remote machine) gets the same shmid as some other client (running on local machine) was already using with X server. This is rare, but can happen. XShmAccess then passes without error and tigervnc decides to use SHM, even that it runs over ssh. XShmPutImage later fails with BadValue, because usually it attempts to upload bigger picture than the one the other local client created.

I am not aware of any proper solution, but there are workarounds to prevent this collisions. Qt4 for example doesn't use SHM at all if display name doesn't look like a local display name.

Michal: I'm not sure I understand. vncviewer, or Xvnc, gets the same shmid as some other client? (or is it x0vncserver?) How can that happen?

Possibly related: bug #914958.

(In reply to Tim Waugh from comment #7)
> Michal: I'm not sure I understand. vncviewer, or Xvnc, gets the same shmid
> as some other client? (or is it x0vncserver?) How can that happen?

Well, this:
"XRequest.130: BadValue (integer parameter out of range for operation) 0x400"

Is not problem between vncviewer and Xvnc, but between vncviewer and the X server on which it displays it's window. I.e. you won't see anything interesting in the capture of VNC protocol, but you would see the error on capture of X11 protocol between vncviewer and X server.

However, in the bug I was solving, the important thing was that vncviewer was started in "ssh -X" session. In that case it can happen that vncviewer gets the same shmid as another client, because they each run on another machine. Now I realized that nothing like that is mentioned here. So if that's not the case here, then I am sorry for confusion.

Michal, thanks, that makes sense.

Original reporter: are you still able to reproduce this problem? If so, could you please run 'xdpyinfo -ext MIT-SHM' to confirm whether the SHM extension is the one complaining?

Can you run 'vncviewer -Log=*:stderr:100 :0' and post the output for a failing session here?

(In reply to Tim Waugh from comment #10)
> Michal, thanks, that makes sense.
> 
> Original reporter: are you still able to reproduce this problem? If so,
> could you please run 'xdpyinfo -ext MIT-SHM' to confirm whether the SHM
> extension is the one complaining?
> 
> Can you run 'vncviewer -Log=*:stderr:100 :0' and post the output for a
> failing session here?

Hi Tim,

I'm sorry that I have not met this problem in recent tests. :(

If I meet this problem again, I will do the above steps that you suggested and update the results here.

Thanks,
Cong

Hi Tim,

I met this problem on version: 
[root@amd-1216-8-4 staf-kvm-devel]# rpm -qa |grep vnc
tigervnc-icons-1.2.80-0.30.20130314svn5065.el7.noarch
tigervnc-1.2.80-0.30.20130314svn5065.el7.x86_64
tigervnc-license-1.2.80-0.30.20130314svn5065.el7.noarch


[root@amd-1216-8-4 staf-kvm-devel]# xdpyinfo -ext MIT-SHM
xdpyinfo:  unable to open display "".
[root@amd-1216-8-4 staf-kvm-devel]# vncviewer -Log=*:stderr:100 :0

TigerVNC Viewer 64-bit v1.2.80 (20140310)
Built on Mar 10 2014 at 12:17:38
Copyright (C) 1999-2011 TigerVNC Team and many others (see README.txt)
See http://www.tigervnc.org for information on TigerVNC.

Wed Sep 10 11:27:10 2014
 CConn:       connected to host localhost port 5900
 CConnection: reading protocol version
 CConnection: Server supports RFB protocol version 3.8
 CConnection: Using RFB protocol version 3.8
 CConnection: processing security types message
 CConnection: Server offers security type None(1)
 CConnection: Choosing security type None(1)
 CConnection: processing security message
 CConnection: processing security result message
 CConnection: Authentication success!
 CConnection: reading server initialisation
 CConnection: initialisation done
Can't open display: 


Thanks,
Chengyou

(In reply to Chengyou Liu from comment #12)
> Hi Tim,
> 
> I met this problem on version: 

Sorry for the error I haven't use ssh with '-X' before.

I hit it again and here is result:

1. [root@amd-1216-8-4 staf-kvm-devel]# vncviewer -Log=*:stderr:100 :0
vnc works well with the above command.

2. Attached is xdpyinfo log.
> 
> Thanks,
> Chengyou

Created attachment 936033 [details]
xdpyinfo log

(In reply to Chengyou Liu from comment #13)
> I hit it again and here is result:

Was the error message "XRequest.130: BadValue", or a different number? It looks like the opcode for MIT-SHM is 140, so this is not related to that in that case. However, if you were using 'ssh -X' to log into the server running Xvnc and running xdpyinfo there, you're only seeing the values from the local X server, not from Xvnc.

To be absolutely sure, I need to see the error message you get, along with output from 'xdpyinfo -display :1 -ext all|grep opcode'. Run this command from logging in with plain ssh (no -X or -Y), and substituting the actual Xvnc display number for ':1'.

(In reply to Tim Waugh from comment #15)
> (In reply to Chengyou Liu from comment #13)
> > I hit it again and here is result:
> 
> Was the error message "XRequest.130: BadValue", or a different number? It
> looks like the opcode for MIT-SHM is 140, so this is not related to that in
> that case. However, if you were using 'ssh -X' to log into the server
> running Xvnc and running xdpyinfo there, you're only seeing the values from
> the local X server, not from Xvnc.
> 
> To be absolutely sure, I need to see the error message you get, along with
> output from 'xdpyinfo -display :1 -ext all|grep opcode'. Run this command
> from logging in with plain ssh (no -X or -Y), and substituting the actual
> Xvnc display number for ':1'.

error message:
[root@amd-1216-8-4 ~]# vncviewer :1

TigerVNC Viewer 64-bit v1.2.80 (20140310)
Built on Mar 10 2014 at 12:17:38
Copyright (C) 1999-2011 TigerVNC Team and many others (see README.txt)
See http://www.tigervnc.org for information on TigerVNC.

Thu Sep 11 11:24:41 2014
 CConn:       connected to host localhost port 5901
 CConnection: Server supports RFB protocol version 3.8
 CConnection: Using RFB protocol version 3.8
 PlatformPixelBuffer: Using default colormap and visual, TrueColor, depth 24.
 CConn:       Using pixel format depth 24 (32bpp) little-endian rgb888
 CConn:       Using Tight encoding
XRequest.140: BadValue (integer parameter out of range for operation) 0x280
XRequest.140: BadValue (integer parameter out of range for operation) 0x280
XRequest.140: BadValue (integer parameter out of range for operation) 0x280
XRequest.140: BadValue (integer parameter out of range for operation) 0x280

$ ssh 10.66.85.205 -l root
root@10.66.85.205's password: 
Last login: Thu Sep 11 11:12:43 2014 from dhcp-9-14.nay.redhat.com
[root@amd-1216-8-4 ~]# xdpyinfo -display :1 -ext all|grep opcode
xdpyinfo:  unable to open display ":1".

correct me if anything wrong.

OK, you need to run 'xdpyinfo -ext all |grep opcode' directly after 'vncviewer :1', same machine, same login. Don't pass '-display'.

The error is coming from the X server that vncviewer is trying to display to, not from Xvnc.

Error info:
XRequest.130: BadValue (integer parameter out of range for operation) 0x400
XRequest.130: BadValue (integer parameter out of range for operation) 0x400
XRequest.130: BadValue (integer parameter out of range for operation) 0x400
XRequest.130: BadValue (integer parameter out of range for operation) 0x400
XRequest.130: BadValue (integer parameter out of range for operation) 0x400
XRequest.130: BadValue (integer parameter out of range for operation) 0x400

# xdpyinfo -ext all |grep opcode
Xlib:  extension "Multi-Buffering" missing on display "localhost:12.0".
MIT-SHM version 1.2 opcode: 130, base event: 65, base error: 128
XKEYBOARD version 1.0 opcode: 135, base event: 85, base error: 137
SHAPE version 1.1 opcode: 129, base event: 64
SYNC version 3.1 opcode: 134, base event: 83, base error: 134
XFree86-DGA version 2.0 opcode: 153, base event: 95, base error: 164
XFree86-VidModeExtension version 2.2 opcode: 152, base error: 157
Xlib:  extension "XFree86-Misc" missing on display "localhost:12.0".
XTEST version 2.2 opcode: 132
DOUBLE-BUFFER version 1.0 opcode: 145, base error: 152
RECORD version 1.13 opcode: 146, base error: 153
XInputExtension version 2.3 opcode: 131, base event: 66, base error: 129
RENDER version 0.11 opcode: 139, base error: 142
XINERAMA version 1.1 opcode: 141

Created attachment 945909 [details]
xdpyinfo log - new

(In reply to CongLi from comment #18)
> Error info:
> XRequest.130: BadValue (integer parameter out of range for operation) 0x400
> XRequest.130: BadValue (integer parameter out of range for operation) 0x400
> XRequest.130: BadValue (integer parameter out of range for operation) 0x400
> XRequest.130: BadValue (integer parameter out of range for operation) 0x400
> XRequest.130: BadValue (integer parameter out of range for operation) 0x400
> XRequest.130: BadValue (integer parameter out of range for operation) 0x400
> 
> # xdpyinfo -ext all |grep opcode
> Xlib:  extension "Multi-Buffering" missing on display "localhost:12.0".
> MIT-SHM version 1.2 opcode: 130, base event: 65, base error: 128
> XKEYBOARD version 1.0 opcode: 135, base event: 85, base error: 137
> SHAPE version 1.1 opcode: 129, base event: 64
> SYNC version 3.1 opcode: 134, base event: 83, base error: 134
> XFree86-DGA version 2.0 opcode: 153, base event: 95, base error: 164
> XFree86-VidModeExtension version 2.2 opcode: 152, base error: 157
> Xlib:  extension "XFree86-Misc" missing on display "localhost:12.0".
> XTEST version 2.2 opcode: 132
> DOUBLE-BUFFER version 1.0 opcode: 145, base error: 152
> RECORD version 1.13 opcode: 146, base error: 153
> XInputExtension version 2.3 opcode: 131, base event: 66, base error: 129
> RENDER version 0.11 opcode: 139, base error: 142
> XINERAMA version 1.1 opcode: 141

Tested on version:
# rpm -qa | grep vnc
tigervnc-icons-1.2.80-0.30.20130314svn5065.el7.noarch
tigervnc-1.2.80-0.30.20130314svn5065.el7.x86_64
tigervnc-license-1.2.80-0.30.20130314svn5065.el7.noarch

(In reply to Michal Srb from comment #6)
> I am not aware of any proper solution, but there are workarounds to prevent
> this collisions. Qt4 for example doesn't use SHM at all if display name
> doesn't look like a local display name.

So I think we'll have to do something like that.

Hi Tim, 

1. The build in comment 22 is unavailable now, could you build a new one?

2. As this bug happened randomly, and not easy to reproduce, is there a stable reproducer?

3. Met similar problem again.
XRequest.130: BadValue (integer parameter out of range for operation) 0x280
XRequest.130: BadValue (integer parameter out of range for operation) 0x280
XRequest.130: BadValue (integer parameter out of range for operation) 0x280
XRequest.130: BadValue (integer parameter out of range for operation) 0x280
XRequest.130: BadValue (integer parameter out of range for operation) 0x280

# xdpyinfo -ext all |grep opcode
Xlib:  extension "Multi-Buffering" missing on display "localhost:12.0".
MIT-SHM version 1.2 opcode: 130, base event: 65, base error: 128
XKEYBOARD version 1.0 opcode: 135, base event: 85, base error: 137
SHAPE version 1.1 opcode: 129, base event: 64
SYNC version 3.1 opcode: 134, base event: 83, base error: 134
Xlib:  extension "XFree86-Misc" missing on display "localhost:12.0".
XFree86-DGA version 2.0 opcode: 153, base event: 95, base error: 164
XFree86-VidModeExtension version 2.2 opcode: 152, base error: 157
XTEST version 2.2 opcode: 132
DOUBLE-BUFFER version 1.0 opcode: 145, base error: 152
RECORD version 1.13 opcode: 146, base error: 153
XInputExtension version 2.3 opcode: 131, base event: 66, base error: 129
RENDER version 0.11 opcode: 139, base error: 142
XINERAMA version 1.1 opcode: 141

Thanks.

Fixed in tigervnc-1.3.1-1.el7.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-2233.html