Bug 1017955 - qemu: display during grub prompt is garbled
qemu: display during grub prompt is garbled
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: spice-gtk (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Marc-Andre Lureau
Fedora Extras Quality Assurance
:
: 1029390 1031232 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-10 16:38 EDT by Zbigniew Jędrzejewski-Szmek
Modified: 2013-11-23 22:26 EST (History)
20 users (show)

See Also:
Fixed In Version: spice-gtk-0.21-5.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-23 22:26:59 EST
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)
screenshot of fedora boot menu under qemu after forced restart (632.46 KB, image/png)
2013-10-10 16:38 EDT, Zbigniew Jędrzejewski-Szmek
no flags Details
Busted screenshot (212.40 KB, image/png)
2013-10-31 18:37 EDT, Cole Robinson
no flags Details
garbled boot screen with F19 guest after forced reset (673.56 KB, image/png)
2013-11-04 09:45 EST, Zbigniew Jędrzejewski-Szmek
no flags Details
grub2 configuration from F20 guest (4.61 KB, text/plain)
2013-11-04 09:46 EST, Zbigniew Jędrzejewski-Szmek
no flags Details

  None (edit)
Description Zbigniew Jędrzejewski-Szmek 2013-10-10 16:38:37 EDT
Created attachment 810739 [details]
screenshot of fedora boot menu under qemu after forced restart

Description of problem:
I installed a F20 test machine following test day instructions: https://fedoraproject.org/wiki/QA:Testcase_Virtualization_URL_Guest_Install, virt-install part.
development/20/x86_64/os/

When the virtual machine is started, virt-manager uses the following command-line:

/usr/bin/qemu-system-x86_64 -machine accel=kvm -name test-day-vm -S -machine pc-i440fx-1.6,accel=kvm,usb=off -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid ab8a6f57-e12d-48a7-ad60-cc82189b8f14 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/test-day-vm.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -no-kvm-pit-reinjection -no-hpet -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/var/lib/libvirt/images/test-day-vm.img,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e4:71:da,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5901,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7

If I restart the VM (by selecting Virtual machine → Shutdown → Force reset), it looks
in the grub prompt like in the attached screenshot. When I press keys, parts of the screen get cleared. Looks like some part of memory is not initialized properly. I have never seen grub garble the screen in *this* way (and I have seen it garble the screen more often than not :)), so I'm assuming that this is somehow connected to spice/qemu.

Version-Release number of selected component (if applicable):
qemu-1.6.0-9.fc20.x86_64
spice-gtk3-0.21-3.fc20.x86_64
spice-server-0.12.4-2.fc20.x86_64

How reproducible:
~20% of forced restarts.

Steps to Reproduce:
1. boot vm
2. wait until it gets to gdm prompt
3. select shutdown → power off
4. wait for the machine to hang during poweroff
5. select Virtual machine → Shutdown → Force reset from the qemu menu
Comment 1 Cole Robinson 2013-10-31 18:37:14 EDT
Created attachment 818077 [details]
Busted screenshot

Here's mine, safe reproducer as Comment #0. The grey in that image is the grey from F20 gdm: not sure if this is qemu, guest, spice, or client issue. Ccing some folks that might be able to answer
Comment 2 Cole Robinson 2013-10-31 18:37:50 EDT
(In reply to Cole Robinson from comment #1)
> Created attachment 818077 [details]
> Busted screenshot
> 
> Here's mine, safe reproducer as Comment #0. The grey in that image is the
> grey from F20 gdm: not sure if this is qemu, guest, spice, or client issue.
> Ccing some folks that might be able to answer

Actually CCing
Comment 3 Gerd Hoffmann 2013-11-04 06:08:13 EST
Looks pretty much like the video memory wasn't cleared after setting the video mode.  I'll bet on a guest bug.

Does F19 show this too?
How does grub2.conf (of the installed guest) look like?
Comment 4 Zbigniew Jędrzejewski-Szmek 2013-11-04 09:44:15 EST
(In reply to Gerd Hoffmann from comment #3)
> Looks pretty much like the video memory wasn't cleared after setting the
> video mode.  I'll bet on a guest bug.
Yeah, the question is who should clear it.

> Does F19 show this too?
Yes, seems to be identical (screenshot attached).

> How does grub2.conf (of the installed guest) look like?
I didn't do any configuration whatsoever, so this is standard from anaconda.
Attached.
Comment 5 Zbigniew Jędrzejewski-Szmek 2013-11-04 09:45:41 EST
Created attachment 819196 [details]
garbled boot screen with F19 guest after forced reset
Comment 6 Zbigniew Jędrzejewski-Szmek 2013-11-04 09:46:53 EST
Created attachment 819197 [details]
grub2 configuration from F20 guest
Comment 7 Gerd Hoffmann 2013-11-04 11:57:01 EST
Hmm, grub2 runs in *text mode* by default.(In reply to Zbigniew Jędrzejewski-Szmek from comment #4)
> (In reply to Gerd Hoffmann from comment #3)
> > Looks pretty much like the video memory wasn't cleared after setting the
> > video mode.  I'll bet on a guest bug.
> Yeah, the question is who should clear it.

Hmm, grub2 uses no graphic mode by default (cfg file confirms this),
so it is *text mode* looking this way.  Strange.  And it makes a guest
bug rather unlikely.

> > Does F19 show this too?
> Yes, seems to be identical (screenshot attached).

Tried F19 guest, doesn't reproduce for me :-(
Havn't a F20 host at hand, compiled qemu 1.6.0 from git.

How did you create the snapshot?  Using the gnome snapshot utility?  Or using virt-manager/guest-window/virtualmachine/take-snapshot?

Any change when using vnc instead of spice?
Any change when using stdvga instead of qxl?
Comment 8 Zbigniew Jędrzejewski-Szmek 2013-11-04 12:37:26 EST
(In reply to Gerd Hoffmann from comment #7)
> Hmm, grub2 runs in *text mode* by default.(In reply to Zbigniew
> Jędrzejewski-Szmek from comment #4)
> > (In reply to Gerd Hoffmann from comment #3)
> > > Looks pretty much like the video memory wasn't cleared after setting the
> > > video mode.  I'll bet on a guest bug.
> > Yeah, the question is who should clear it.
> 
> Hmm, grub2 uses no graphic mode by default (cfg file confirms this),
> so it is *text mode* looking this way.  Strange.  And it makes a guest
> bug rather unlikely.
> 
> > > Does F19 show this too?
> > Yes, seems to be identical (screenshot attached).
> 
> Tried F19 guest, doesn't reproduce for me :-(
> Havn't a F20 host at hand, compiled qemu 1.6.0 from git.
> 
> How did you create the snapshot?  Using the gnome snapshot utility?  Or
> using virt-manager/guest-window/virtualmachine/take-snapshot?
The first one, using gimp. The second one from guest-window/take-snapshot.

> Any change when using vnc instead of spice?
With "Display Spice" removed, and "Display VNC" added, I cannot reproduce this (5 or 6 tries).

(Before I wrote that reproducibility is 30%, but actually, at least now, it is very close to 100%. In some cases there's just a bit of color noise in one of the corners, but it's clear that there's something random. With VNC, the grub prompt is always clean black.)

> Any change when using stdvga instead of qxl?
With "Video QXL" changed to "Video VGA, 9MB", and display back at "Display Spice", the corruption seems to be less visible but it's there, often just in the corner, but sometimes full-screen.
Comment 9 Gerd Hoffmann 2013-11-05 02:01:04 EST
> > How did you create the snapshot?  Using the gnome snapshot utility?  Or
> > using virt-manager/guest-window/virtualmachine/take-snapshot?
> The first one, using gimp. The second one from guest-window/take-snapshot.

Cole?  How is take-screenshot implemented?  Write out window content?  Or go through libvirt and ask qemu to write out a screendump that way?
Comment 10 Gerd Hoffmann 2013-11-05 02:08:24 EST
> > Any change when using vnc instead of spice?
> With "Display Spice" removed, and "Display VNC" added, I cannot reproduce
> this (5 or 6 tries).
> 
> (Before I wrote that reproducibility is 30%, but actually, at least now, it
> is very close to 100%. In some cases there's just a bit of color noise in
> one of the corners, but it's clear that there's something random. With VNC,
> the grub prompt is always clean black.)
> 
> > Any change when using stdvga instead of qxl?
> With "Video QXL" changed to "Video VGA, 9MB", and display back at "Display
> Spice", the corruption seems to be less visible but it's there, often just
> in the corner, but sometimes full-screen.

Thanks.  That strongly hints the problem is somewhere in spice.

What happens if you close and re-open the guest window while grub2 is running?  Corruption still visible after reopening?
Comment 11 Cole Robinson 2013-11-05 11:16:26 EST
(In reply to Gerd Hoffmann from comment #9)
> > > How did you create the snapshot?  Using the gnome snapshot utility?  Or
> > > using virt-manager/guest-window/virtualmachine/take-snapshot?
> > The first one, using gimp. The second one from guest-window/take-snapshot.
> 
> Cole?  How is take-screenshot implemented?  Write out window content?  Or go
> through libvirt and ask qemu to write out a screendump that way?

It's not through qemu, just grabbing the window content from gtk. I can confirm at least that my screenshot matched what I was seeing on the screen at the time.
Comment 12 Zbigniew Jędrzejewski-Szmek 2013-11-05 11:23:20 EST
(In reply to Gerd Hoffmann from comment #10)
> What happens if you close and re-open the guest window while grub2 is
> running?  Corruption still visible after reopening?
Nope, nice and clean in the reopened window.
Comment 13 Gerd Hoffmann 2013-11-06 02:57:49 EST
(In reply to Zbigniew Jędrzejewski-Szmek from comment #12)
> (In reply to Gerd Hoffmann from comment #10)
> > What happens if you close and re-open the guest window while grub2 is
> > running?  Corruption still visible after reopening?
> Nope, nice and clean in the reopened window.

So it is a spice client issue most likely.  Reassigning to spice-gtk.
Comment 14 Marc-Andre Lureau 2013-11-06 03:59:16 EST
this is probably fixed by
http://cgit.freedesktop.org/spice/spice-gtk/commit/?id=32b123f44fc79eaad388d6be09f103457f35d734

Could you try the git version? thanks
Comment 15 Cole Robinson 2013-11-06 09:09:18 EST
I verified that the issue is fixed using spice-gtk git, thanks Marc-Andre !
Comment 16 Cole Robinson 2013-11-12 08:46:34 EST
*** Bug 1029390 has been marked as a duplicate of this bug. ***
Comment 17 Cole Robinson 2013-11-16 16:07:43 EST
*** Bug 1031232 has been marked as a duplicate of this bug. ***
Comment 18 Fedora Update System 2013-11-17 14:30:10 EST
spice-gtk-0.21-5.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/spice-gtk-0.21-5.fc20
Comment 19 Fedora Update System 2013-11-18 15:19:50 EST
Package spice-gtk-0.21-5.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing spice-gtk-0.21-5.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-21630/spice-gtk-0.21-5.fc20
then log in and leave karma (feedback).
Comment 20 Fedora Update System 2013-11-23 22:26:59 EST
spice-gtk-0.21-5.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

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