RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1029130 - Guest screen hangs after migration.
Summary: Guest screen hangs after migration.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: xorg-x11-drv-qxl
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Søren Sandmann Pedersen
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-11 17:47 UTC by Marian Krcmarik
Modified: 2014-06-18 09:16 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-19 14:55:59 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Xorg log (44.13 KB, text/plain)
2013-11-11 17:47 UTC, Marian Krcmarik 		no flags Details
View All

Description Marian Krcmarik 2013-11-11 17:47:13 UTC 
Created attachment 822507 [details]
Xorg log

Description of problem:
The guest screen is non responsive (hangs) after migration of the guest, The qemu-kvm process is responsive - monitor returns some output, ssh session is alive and is usable, just the screen is not responsive and Xorg complains about being  EQ overflowing (will attach Xorg log).

Version-Release number of selected component (if applicable):
RHEL7 guest/client/host with following components:
qemu-img-1.5.3-17.el7.x86_64
qemu-kvm-1.5.3-17.el7.x86_64
spice-server-0.12.4-3.el7.x86_64
spice-gtk3-0.20-6.el7.x86_64
kernel-3.10.0-42.el7.x86_64
xorg-x11-drv-qxl-0.1.1-5.el7.x86_64

How reproducible:
Almost always

Steps to Reproduce:
1. Start RHEL7 guest with spice display and qxl driver in use.
2. Migrate the guest.

Actual results:
Guest screen hangs

Additional info:
Bt from Xorg
Thread 1 (Thread 0x7fd3914579c0 (LWP 610)):
#0  0x00007fd38eed5297 in ioctl () from /lib64/libc.so.6
#1  0x00007fd38ffba6c4 in drmIoctl (fd=10, request=request@entry=1075340355, 
    arg=arg@entry=0x7fffa70a1370) at xf86drm.c:167
#2  0x00007fd38b80f514 in qxl_bo_update_area (surf=0x2575170, x1=<optimized out>, 
    y1=<optimized out>, x2=<optimized out>, y2=<optimized out>) at qxl_kms.c:543
#3  0x00007fd38b806fd6 in qxl_download_box (surface=surface@entry=0x2575170, x1=819, 
    y1=378, x2=<optimized out>, y2=<optimized out>) at qxl_surface.c:143
#4  0x00007fd38b807107 in qxl_surface_prepare_access (surface=0x2575170, 
    pixmap=0x25980c0, region=0x7fffa70a1420, access=<optimized out>)
    at qxl_surface.c:178
#5  0x00007fd38b812020 in uxa_prepare_access (pDrawable=pDrawable@entry=0x259b200, 
    region=region@entry=0x7fffa70a1560, access=access@entry=UXA_ACCESS_RO)
    at uxa.c:172
#6  0x00007fd38b814189 in uxa_copy_n_to_n (
    pSrcDrawable=pSrcDrawable@entry=0x259b200, pDstDrawable=0x29d96f0, 
    pGC=0x259ab30, pbox=pbox@entry=0x7fffa70a16d0, nbox=nbox@entry=1, 
    dx=dx@entry=819, dy=dy@entry=378, reverse=0, upsidedown=0, 
    bitplane=bitplane@entry=0, closure=0x0) at uxa-accel.c:614
#7  0x000000000057a58d in miCopyRegion (pSrcDrawable=0x259b200, 
    pDstDrawable=<optimized out>, pGC=<optimized out>, pDstRegion=<optimized out>, 
    dx=819, dy=378, copyProc=0x7fd38b813b70 <uxa_copy_n_to_n>, bitPlane=0, 
    closure=0x0) at micopy.c:121
#8  0x000000000057ab16 in miDoCopy (pSrcDrawable=0x259b200, pDstDrawable=0x29d96f0, 
    pGC=0x259ab30, xIn=819, yIn=378, widthSrc=229, heightSrc=heightSrc@entry=201, 
    xOut=xOut@entry=0, yOut=yOut@entry=0, 
    copyProc=copyProc@entry=0x7fd38b813b70 <uxa_copy_n_to_n>, 
    bitPlane=bitPlane@entry=0, closure=closure@entry=0x0) at micopy.c:297
#9  0x00007fd38b812f36 in uxa_copy_area (pSrcDrawable=<optimized out>, 
    pDstDrawable=<optimized out>, pGC=<optimized out>, srcx=<optimized out>, 
    srcy=<optimized out>, width=<optimized out>, height=201, dstx=0, dsty=0)
    at uxa-accel.c:642
#10 0x0000000000528868 in damageCopyArea (pSrc=0x259b200, pDst=0x29d96f0, 
    pGC=0x259ab30, srcx=819, srcy=<optimized out>, width=229, height=201, dstx=0, 
    dsty=0) at damage.c:765
#11 0x00000000004d6e38 in compNewPixmap (pWin=pWin@entry=0x29a4570, 
    x=<optimized out>, y=<optimized out>, w=229, h=201) at compalloc.c:554
#12 0x00000000004d7c65 in compAllocPixmap (pWin=pWin@entry=0x29a4570)
    at compalloc.c:605
#13 0x00000000004d64cc in compCheckRedirect (pWin=pWin@entry=0x29a4570)
    at compwindow.c:165
#14 0x00000000004d659d in compRealizeWindow (pWin=0x29a4570) at compwindow.c:265
#15 0x00000000004600c6 in RealizeTree (pWin=pWin@entry=0x29a4570) at window.c:2495
#16 0x0000000000462ea5 in MapWindow (pWin=0x29a4570, client=client@entry=0x28bd780)
#17 0x00000000004322f8 in ProcMapWindow (client=0x28bd780) at dispatch.c:802
#18 0x00000000004372bf in Dispatch () at dispatch.c:434
#19 0x000000000043b0da in dix_main (argc=12, argv=0x7fffa70a1b48, 
    envp=<optimized out>) at main.c:294
#20 0x00007fd38ee09af5 in __libc_start_main () from /lib64/libc.so.6
#21 0x0000000000426621 in _start ()
Comment 3 Søren Sandmann Pedersen 2014-01-10 19:41:42 UTC 
Is there anything in the kernel log when this happens?
Comment 4 Søren Sandmann Pedersen 2014-01-20 21:50:09 UTC 
Also, is this still reproducible?
Comment 5 Marian Krcmarik 2014-02-18 13:37:47 UTC 
(In reply to Søren Sandmann Pedersen from comment #4)
> Also, is this still reproducible?

Hi,
I am not able to reproduce on the latest bits so If you cannot see anything obviously wrong in backtrace, please close the bug as It's not reproducible for me in latest bits.
If I hit it again I will reopen.
Comment 6 Søren Sandmann Pedersen 2014-02-19 14:55:59 UTC 
Okay, closing. This bug *could* be a duplicate of 1050034, but it's hard to tell without a log.
Note You need to log in before you can comment on or make changes to this bug.