Description of problem:
Boot a RHEL6.2 guest installed with 20110907.1 tree, it will hang when booting with spice. If boot with vnc, then works well. Re-installed a guest with 20110823 tree, have no problem.
In 20110823.1 tree: xorg-x11-drv-qxl-0.0.14-5.el6
In 20110907.1 tree: xorg-x11-drv-qxl-0.0.14-6.el6
So, I file the bug against this component. Please correct me if I am wrong.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install a RHEL6.2 guest with 20110907.1 tree and install "Desktop" related packages.
2. Boot guest after finish installation.
Guest should not hang.
At what point does it hang exactly? Is there something displayed on the screen when it hangs?
(In reply to comment #2)
> At what point does it hang exactly? Is there something displayed on the screen
> when it hangs?
Did not see anything displayed. After log on guest, wait on the desktop and do nothing will hit this problem after a while. If we hot plug one disk to guest, will hit this problem at once.
At this moment, guest will consume 100% cpu.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9916 root 20 0 4898m 1.0g 4376 S 100.5 28.4 8:24.39 qemu-kvm
9030 root 20 0 103m 11m 2980 S 1.7 0.3 1:02.24 sshd
59 root 25 5 0 0 0 S 1.3 0.0 0:18.75 ksmd
Could you please provide package versions for qemu-kvm spice-server and spice-client? And also your qemu-kvm cmd-line options.
(In reply to comment #4)
> Could you please provide package versions for qemu-kvm spice-server and
> spice-client? And also your qemu-kvm cmd-line options.
/usr/libexec/qemu-kvm -M rhel6.2.0 -cpu cpu64-rhel6,+x2apic -enable-kvm -m 4096 -smp 4 -name RHEL6.2-64 -uuid 4b695c7e-3e0f-4f16-b1c0-ae1867ce8df6 -monitor stdio -rtc base=localtime -boot c -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x3 -drive file=/home/RHEL6.2-64-virtio.qcow2,if=none,id=virtio-drive-0,format=qcow2,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,bus=pci.0,drive=virtio-drive-0,id=virtio0 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device rtl8139,netdev=hostnet0,id=net0,mac=00:1a:4a:10:20:12,bus=pci.0,addr=0x5 -chardev socket,id=charchannel0,path=/tmp/foo,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -usb -device usb-tablet -spice port=5930,disable-ticketing -k en-us -vga qxl -global qxl-vga.vram_size=67108864
Created attachment 523126 [details]
Xorg log after hangup
diff X.log X.log.after # log before hang and after
> [ 289.348] slots start: 1, slots end: 7
> [ 289.348] done reset
> [ 289.349] primary is 0x1c9d010
Forcing xdriver=vesa does not lead to this issue.
Anyway in my case hang happened right after anaconda gui started. I suppose that you've made text install right?
(In reply to comment #8)
> Anyway in my case hang happened right after anaconda gui started. I suppose
> that you've made text install right?
No, I installed the guest with gui as well, not the text install. Guest did not hang during installation.
Lubos, are you also using xorg-x11-drv-qxl-0.0.14-6.el6 ? If you restart the client, does the hang persist? Or are things back to normal?
I forgot to ask whether this was a single screen configuration, or some kind of multiple screen setup?
(In reply to comment #13)
> I forgot to ask whether this was a single screen configuration, or some kind of
> multiple screen setup?
single screen configuration. After installation, I did nothing configuration. Just booting guest, cause the guest hang.
Any of you tried restarting the client after getting the hang? I'd like to know whether the client becomes responsive again after one (or several restarts). I'm observing something like this, but I have no idea if it's the same bug as the one you're reporting.
(In reply to comment #15)
> Any of you tried restarting the client after getting the hang? I'd like to know
> whether the client becomes responsive again after one (or several restarts).
> I'm observing something like this, but I have no idea if it's the same bug as
> the one you're reporting.
Restarting the client after getting the hang, guest will become responsive again.
I am hitting this bug with xorg-x11-drv-qxl-0.0.14-7.el6, It seems that qxl driver causes Xorg server to end up in infinite loop so that CPU usage jumps to ~100% -> qemu process on host as well. It seems that something wrong about cursor since the cursor is not visible and look at xorg log and bt. It does become responsive after restarting client but only for a while. It prevents to test RHEL guest that's why I am marking as Testblocker and would appreciate any progress.
My xorg log snip:
[ 49.516] [mi] EQ overflowing. The server is probably stuck in an infinite loop.
[ 49.516] 0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x45dda8]
[ 49.516] 1: /usr/bin/Xorg (mieqEnqueue+0x1f4) [0x457b74]
[ 49.516] 2: /usr/bin/Xorg (xf86PostMotionEventM+0x97) [0x47e587]
[ 49.516] 3: /usr/bin/Xorg (xf86PostMotionEventP+0x4f) [0x47e68f]
[ 49.516] 4: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f0ceec7a000+0x5468) [0x7f0ceec7f468]
[ 49.516] 5: /usr/bin/Xorg (0x400000+0x7cf57) [0x47cf57]
[ 49.516] 6: /usr/bin/Xorg (0x400000+0x118543) [0x518543]
[ 49.516] 7: /lib64/libpthread.so.0 (0x3190e00000+0xf490) [0x3190e0f490]
[ 49.516] 8: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f0cf95d9000+0x7fdc) [0x7f0cf95e0fdc]
[ 49.516] 9: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f0cf95d9000+0xb13b) [0x7f0cf95e413b]
[ 49.516] 10: /usr/bin/Xorg (0x400000+0x14cd7b) [0x54cd7b]
[ 49.516] 11: /usr/bin/Xorg (0x400000+0x14b810) [0x54b810]
[ 49.516] 12: /usr/bin/Xorg (miPointerUpdateSprite+0x242) [0x45a162]
[ 49.516] 13: /usr/bin/Xorg (0x400000+0x5a3e4) [0x45a3e4]
[ 49.516] 14: /usr/bin/Xorg (0x400000+0xb1033) [0x4b1033]
[ 49.516] 15: /usr/bin/Xorg (0x400000+0xd7c26) [0x4d7c26]
[ 49.516] 16: /usr/bin/Xorg (0x400000+0x300e9) [0x4300e9]
[ 49.516] 17: /usr/bin/Xorg (WindowHasNewCursor+0x37) [0x430387]
[ 49.516] 18: /usr/bin/Xorg (ChangeWindowAttributes+0xc68) [0x442048]
[ 49.516] 19: /usr/bin/Xorg (0x400000+0x4c934) [0x44c934]
[ 49.516] 20: /usr/bin/Xorg (0x400000+0x4ef41) [0x44ef41]
[ 49.516] 21: /usr/bin/Xorg (0x400000+0x21deb) [0x421deb]
[ 49.517] 22: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x319061ecdd]
[ 49.517] 23: /usr/bin/Xorg (0x400000+0x21979) [0x421979]
#0 qxl_ring_push (ring=0xf43230, new_elt=0x7fff1f266d00) at qxl_ring.c:73
#1 0x00007fdeb682c13b in push_cursor (qxl=<value optimized out>,
cursor=<value optimized out>) at qxl_cursor.c:42
#2 0x00000000004578e9 in mieqProcessInputEvents () at mieq.c:485
#3 0x000000000047d1b9 in ProcessInputEvents () at xf86Events.c:165
#4 0x000000000044eb83 in Dispatch () at dispatch.c:363
#5 0x0000000000421deb in main (argc=9, argv=<value optimized out>,
envp=<value optimized out>) at main.c:287
To summarize the issue:
- Restarting the client, both spice-client and spicy fixes the hang
- From inside the QXL driver, it looks like spice-server has stopped processing cursor commands for no good reason.
Best guess at a component is spice-server, though it could conceivably be in the client code too.
Søren, any comment about the upgrade of qxl?
In 20110823.1 tree: xorg-x11-drv-qxl-0.0.14-5.el6 ok
In 20110907.1 tree: xorg-x11-drv-qxl-0.0.14-6.el6 fail
(In reply to comment #19)
> Søren, any comment about the upgrade of qxl?
> In 20110823.1 tree: xorg-x11-drv-qxl-0.0.14-5.el6 ok
> In 20110907.1 tree: xorg-x11-drv-qxl-0.0.14-6.el6 fail
The bug reproduces with both those drivers.
(In reply to comment #20)
> (In reply to comment #19)
> > Søren, any comment about the upgrade of qxl?
> > In 20110823.1 tree: xorg-x11-drv-qxl-0.0.14-5.el6 ok
> > In 20110907.1 tree: xorg-x11-drv-qxl-0.0.14-6.el6 fail
> The bug reproduces with both those drivers.
Downgrade to xorg-x11-drv-qxl-0.0.14-3 helped in my case.
Reproduced on RHEL6.1 guest with xorg-x11-drv-qxl-0.0.12-9.el6.x86_64
I managed to reproduce with spice-server 0.8.0, 0.8.1 and 0.8.2 when running some tests. I was using qemu 0.15, a RHEL6.1 guest with xorg-x11-drv-qxl-0.0.14-5.el6.
Next I'll try the same thing with xorg-x11-drv-qxl-0.0.12-9.el6.x86_64
At this point, I'd be really surprised if this bug has been present since version 0.8.0 regardless of the xorg-x11-drv-qxl version (or of some other component), I think it would have been noticed earlier if it does not depend on some other condition.
Lubos, are you following some specific steps to reproduce the bug with 0.0.12-9 ?
Back to the qxl driver since Christophe pointed out that a patch had accidentally been dropped in -5 that would cause this issue.
That patch is back in in -9, so marking MODIFIED.
We need acks to add this to the erratum.
I'm experiencing same problem with linux client and win7x64 guest. Screen is not being refreshed in fullscreen (sometimes I'm able to work for a while but then finally after few seconds it screen hangs). Switching from fullscreen helps.
But I'm experiencing various hangs in window mode as well (but not so often). In this case moving spice-client window helps.
I've tried to connect to the guest trough userportal and also manually and I'm experiencing the same issue.
Current setup is laptop connected to an extended display (laptop screen is disabled). So only one display is in use.
Should I clone this bug to rhevm product or is it a different issue?
Sorry issue described in previous post seems to be caused with xorg-x11-drv-intel. Please ignore it
It works with fixed in version but it doesn't work with xorg-x11-drv-qxl-0.0.14-10.el6 from brew was that just some kind of test?
(In reply to comment #31)
> It works with fixed in version but it doesn't work with
> xorg-x11-drv-qxl-0.0.14-10.el6 from brew was that just some kind of test?
No, -10 is supposed to work.
Are you sure you are seeing the same symptoms? Ie., the hang can be worked around by restarting the client.
I and Michal Hasko retested the issue (to make sure) and we do not observe hang anymore with xorg-x11-drv-qxl-0.0.14-10.el6.
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.
*** Bug 741570 has been marked as a duplicate of this bug. ***