Hide Forgot
Created attachment 1056936 [details] screenshot of guest Description of problem: display mess when boot a win2012-r2-64 guest with -vga std, if with -vga qxl/cirrus, the issue is gone. Version-Release number of selected component (if applicable): 3.10.0-297.el7.x86_64 qemu-kvm-rhev-2.3.0-13.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.boot a win2012-r2-64 guest with -vga std /usr/libexec/qemu-kvm -M pc -cpu Opteron_G3 -m 4096 -smp 4,sockets=2,cores=2,threads=1 \ -drive if=none,id=drive-disk,cache=none,file=/mnt/win2012-64r2-virtio-scsi.qcow2,format=qcow2,aio=native -device virtio-scsi-pci,id=scsi0,bus=pci.0 -device scsi-hd,bus=scsi0.0,drive=drive-disk,id=disk \ -monitor stdio -spice port=5900,disable-ticketing -vga std \ -netdev tap,id=hostnet0,vhost=on,queues=8 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:42:0a:00,vectors=17,mq=on 2.remote-viewer spice://10.66.106.66:5900 3. Actual results: display mess in guest, see attachment. Expected results: display normally Additional info: if with -vga qxl/cirrus, the issue is gone
Given that spice+qxl is working and spice+vga-std is giving a corrupted display, I'd look at a vga-std bug first... Is this happening with vnc too (vnc + vga-std) ?
(In reply to Christophe Fergeau from comment #5) > Given that spice+qxl is working and spice+vga-std is giving a corrupted > display, I'd look at a vga-std bug first... Is this happening with vnc too > (vnc + vga-std) ? vnc+vga-std works well, does not hit the issue.
Hi All, I've spent a little time looking at this issue. We found the same artifacts when we tested a Windows 10 (build 9926) running on Fedora 22. However, the same build of Windows 10 running on RHEL-6 had *no* artifacts. When I've seen screen corruption similar to this, it has often been a problem of dirty pixel tracking in QEMU. And, in fact, I have a vague memory of just such an issue at another company a few years ago when we started testing the new Windows driver model WDDM (vs XPDM). So my SWAG here is that the issue is related to the way the newer driver model and QEMU interact. Sandy
based on the comment #8 moving to qemu-kvm for further investigation. David
I don't think it is something with the vga emulation, given that things work just fine with vnc. What happens if you close and restart remote-viewer? Corruption still there?
(In reply to Gerd Hoffmann from comment #10) > I don't think it is something with the vga emulation, > given that things work just fine with vnc. > > What happens if you close and restart remote-viewer? > Corruption still there? yes, corruption still there when I close and restart remote-viewer.
Possibly related: bug 1257025 Does it still happen with '-spice port=5900,disable-ticketing,image-compression=off,zlib-glz-wan-compression=off,streaming-video=off' ?
The corruptions looks like partial scan lines are slow to update. In fact, sometimes just waiting a bit the corruption clears up. I think that updates to the framebuffer being missed by qemu.
(In reply to Gerd Hoffmann from comment #12) > Possibly related: bug 1257025 > > Does it still happen with '-spice > port=5900,disable-ticketing,image-compression=off,zlib-glz-wan- > compression=off,streaming-video=off' ? yes, it still happen with '-spice port=5900,disable-ticketing,image-compression=off,zlib-glz-wan-compression=never,streaming-video=off -vga std'
(In reply to Sandy Stutsman from comment #13) > The corruptions looks like partial scan lines are slow to update. In fact, > sometimes just waiting a bit the corruption clears up. I think that updates > to the framebuffer being missed by qemu. Puzzling that it seems to happen with spice only though. You can start a guest with both spice and vnc btw (by simply passing both -spice and -vnc args to qemu), then connect with via both vnc and spice at the same time. What happens then? Do you have a usb-tablet connected to the guest? If not: any change in behaviour if you do? Upgraded my win8 guest to win10, tried to reproduce, failed. "Microsoft Basic Display Adapter" in use according to Device Manager. Same for you?
*** Bug 1257843 has been marked as a duplicate of this bug. ***
(In reply to Gerd Hoffmann from comment #15) > (In reply to Sandy Stutsman from comment #13) > > The corruptions looks like partial scan lines are slow to update. In fact, > > sometimes just waiting a bit the corruption clears up. I think that updates > > to the framebuffer being missed by qemu. > > Puzzling that it seems to happen with spice only though. > > You can start a guest with both spice and vnc btw (by simply passing both > -spice and -vnc args to qemu), then connect with via both vnc and spice at > the same time. What happens then? If start a guest with both spice and vnc (-spice port=5900,disable-ticketing -vnc :2 -vga std) and connect with via both vnc and spice at the same time. remote-viewer vnc://10.66.106.85:5902----> works well remote-viewer spice://10.66.106.85:5900------>corruption still there > > Do you have a usb-tablet connected to the guest? > If not: any change in behaviour if you do? no usb-tablet. after connecting the guest via spice, open *This PC* or other windows, move mouse in *This PC* window, the corruption will appear. if moving mouse in the Desktop, it works well. > > Upgraded my win8 guest to win10, tried to reproduce, failed. "Microsoft > Basic Display Adapter" in use according to Device Manager. Same for you? Yes, "Microsoft Basic Display Adapter" in use according to Device Manager.
> Upgraded my win8 guest to win10, tried to reproduce, failed. "Microsoft > Basic Display Adapter" in use according to Device Manager. Same for you? Checked again, now it reproduces. Strange. Bisected to commit "0002a51 ui/spice: Support shared surface for most pixman formats" Actual root cause is commit "555e72f spice: rework mirror allocation, add no-resize fast path" though.
https://patchwork.ozlabs.org/patch/519231/
http://people.redhat.com/ghoffman/bz1247479/
Fix included in qemu-kvm-rhev-2.3.0-27.el7
***Reproduced***: Host: Kernel:3.10.0-320.el7.x86_64 qemu-kvm-rhev:qemu-kvm-rhev-2.3.0-23.el7.x86_64 Guest:win2012r2 Steps: 1.1 boot guest with '-vag std', the screen of guest displays mess # /usr/libexec/qemu-kvm -name win2012r2 -machine pc-i440fx-rhel7.2.0,accel=kvm \ -cpu SandyBridge -m 4G,slots=256,maxmem=40G -numa node \ -smp 4,sockets=2,cores=2,threads=1 \ -uuid 82b1a01e-5f6c-4f5f-8d27-3855a74e6b6b \ -netdev tap,id=hostnet0 \ -device virtio-net-pci,netdev=hostnet0,id=net0,mac=12:54:00:5c:88:6d \ -vga std \ -spice port=5900,addr=0.0.0.0,disable-ticketing,image-compression=off,seamless-migration=on \ -monitor stdio \ -serial unix:/tmp/monitor,server,nowait \ -qmp tcp:0:5555,server,nowait \ -drive file=/home/win2012r2,if=none,id=drive-scsi-disk0,format=qcow2,cache=none,werror=stop,rerror=stop \ -device virtio-scsi-pci,id=scsi0 \ -device scsi-hd,drive=drive-scsi-disk0,bus=scsi0.0,scsi-id=0,lun=0,id=scsi-disk0 \ 1.2. boot guest with '-vga qxl', the guest screen is OK. So this bug has been reproduced. ***Verified***: Host: Kernel:3.10.0-320.el7.x86_64 qemu-kvm-rhev:qemu-kvm-rhev-2.3.0-27.el7.x86_64 Guest:win2012r2 Steps: 2.1 boot guest with '-vag std', the guest screen is OK. same step with step 1.1. The guest screen works well, So this bug has been fixed.
According to comment25, set this issue as verified.
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/RHBA-2015-2546.html