Bug 753590 - RHEL5 guest is not rendered (blank screen) after migration in spice client
Summary: RHEL5 guest is not rendered (blank screen) after migration in spice client
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xorg-x11-drv-qxl
Version: 5.8
Hardware: Unspecified
OS: Linux
medium
high
Target Milestone: rc
: ---
Assignee: Søren Sandmann Pedersen
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-13 17:07 UTC by Marian Krcmarik
Modified: 2014-06-18 09:14 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-16 10:43:57 UTC
Target Upstream Version:


Attachments (Terms of Use)
Xorg.log (53.44 KB, text/plain)
2011-11-13 17:09 UTC, Marian Krcmarik
no flags Details

Description Marian Krcmarik 2011-11-13 17:07:22 UTC
Description of problem:
RHEL5 guest is not rendered (ends up in blank sreen on guest side) after migration. Only parts of screen which are rerendered are visible (flashing cursor, time displayed in gnome panel). This does not happen with RHEL6 guests or Windows guests. It does not happen with vesa driver, that's why I blame qxl driver. Attached xorg log. 

Version-Release number of selected component (if applicable):
RHEL5.8 guest on RHEVM3 Beta4 (ic147)
xorg-x11-drv-qxl-0.0.12-2.el5

How reproducible:
always

Steps to Reproduce:
1. Connect to a RHEL5 guest with spice client.
2. Migrate the guest
  
Actual results:
Spice client displays only blank screen after migration

Expected results:
Spice client displays guest environment corretly 

Additional info:

Comment 1 Marian Krcmarik 2011-11-13 17:09:00 UTC
Created attachment 533386 [details]
Xorg.log

Comment 2 Alon Levy 2011-12-09 08:15:19 UTC
when a new client connects to a server the server sends it an image for each display. The server is RHEL 6? if so the client does a reconnection, so I would assume somehow the framebuffer address after migration is wrong and when the server sends the image it sends a blank image?


1. what does info qtree before and after migration give (only the part for qxl)?
2. does screendump work correctly after? or does it show the same thing the client shows, black with some renders on top?
3. does printscreen from within the client (you can use scrot, yum install scrot) show up correctly after migration?

If I'm right then 1 might show a difference, or maybe not, and 2 and 3 would both fail. I think :)

Could you also provide the output when running with cmdlog=1? It's a little large, not sure if it would show anything worth it, but out of ideas.

Comment 3 Marian Krcmarik 2011-12-09 18:42:54 UTC
(In reply to comment #2)
> when a new client connects to a server the server sends it an image for each
> display. The server is RHEL 6? 

Yes, It is RHEL6.

>if so the client does a reconnection, so I would
> assume somehow the framebuffer address after migration is wrong and when the
> server sends the image it sends a blank image?
> 
> 
> 1. what does info qtree before and after migration give (only the part for
> qxl)?

It looks same:
BEFORE:
dev: qxl-vga, id ""
        dev-prop: ram_size = 67108864
        dev-prop: vram_size = 67108864
        dev-prop: revision = 3
        dev-prop: debug = 0
        dev-prop: guestdebug = 0
        dev-prop: cmdlog = 0
        bus-prop: addr = 02.0
        bus-prop: romfile = "vgabios-qxl.bin"
        bus-prop: rombar = 1
        bus-prop: multifunction = off
        class VGA controller, addr 00:02.0, pci id 1b36:0100 (sub 1af4:1100)
        bar 0: mem at 0xf0000000 [0xf3ffffff]
        bar 1: mem at 0x50000000 [0x53ffffff]
        bar 2: mem at 0xf4000000 [0xf4001fff]
        bar 3: i/o at 0xc040 [0xc05f]
        bar 6: mem at 0xffffffffffffffff [0xfffe]
AFTER
dev: qxl-vga, id ""
        dev-prop: ram_size = 67108864
        dev-prop: vram_size = 67108864
        dev-prop: revision = 3
        dev-prop: debug = 0
        dev-prop: guestdebug = 0
        dev-prop: cmdlog = 0
        bus-prop: addr = 02.0
        bus-prop: romfile = "vgabios-qxl.bin"
        bus-prop: rombar = 1
        bus-prop: multifunction = off
        class VGA controller, addr 00:02.0, pci id 1b36:0100 (sub 1af4:1100)
        bar 0: mem at 0xf0000000 [0xf3ffffff]
        bar 1: mem at 0x50000000 [0x53ffffff]
        bar 2: mem at 0xf4000000 [0xf4001fff]
        bar 3: i/o at 0xc040 [0xc05f]
        bar 6: mem at 0xffffffffffffffff [0xfffe]

> 2. does screendump work correctly after? or does it show the same thing the
> client shows, black with some renders on top?
It does show the same thing - black with some renders on top.

> 3. does printscreen from within the client (you can use scrot, yum install
> scrot) show up correctly after migration?
It does not show up correctly, It show the same as screendump - blank with some renders on top.

> 
> If I'm right then 1 might show a difference, or maybe not, and 2 and 3 would
> both fail. I think :)
> 
> Could you also provide the output when running with cmdlog=1? It's a little
> large, not sure if it would show anything worth it, but out of ideas.

Moreover I've noticed in target qemu output this error:
reds_accept_ssl_connection: SSL_accept failed, error=5

Comment 6 RHEL Program Management 2012-10-26 18:19:08 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Comment 7 RHEL Program Management 2014-03-07 13:38:51 UTC
This bug/component is not included in scope for RHEL-5.11.0 which is the last RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX (at the end of RHEL5.11 development phase (Apr 22, 2014)). Please contact your account manager or support representative in case you need to escalate this bug.

Comment 8 Ondrej Vasik 2014-06-16 10:43:57 UTC
Closing WONTFIX, as this doesn't sound as a blocker in production phase 3 and was not escalated.


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