Bug 1098647 - Xorg process hangs after switching to vt and back
Summary: Xorg process hangs after switching to vt and back
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: xorg-x11-drv-qxl
Version: 6.5
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Default Assignee for SPICE Bugs
QA Contact: SPICE QE bug list
URL:
Whiteboard:
: 1140765 (view as bug list)
Depends On: 1140765
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-16 19:41 UTC by Marian Krcmarik
Modified: 2019-10-10 09:18 UTC (History)
9 users (show)

Fixed In Version: xorg-x11-drv-qxl-0.1.1-17.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-07-22 07:31:48 UTC


Attachments (Terms of Use)
Xorg log (71.32 KB, text/x-log)
2014-05-16 19:41 UTC, Marian Krcmarik
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1399 normal SHIPPED_LIVE xorg-x11-drv-qxl bug fix update 2015-07-20 18:07:22 UTC

Description Marian Krcmarik 2014-05-16 19:41:17 UTC
Created attachment 896507 [details]
Xorg log

Description of problem:
It seems that Xorg process hangs or nothing is rendered after switching to vt and back to gnome session with multimonitor session (4 monitors opened or two monitors with higher resolution - over 1920x1080).
I couldn't really reproduce on builds older than xorg-x11-drv-qxl-0.1.0-8.el6_5 but this build fixes problem with high resolution.

Bt from the process:
Thread 1 (Thread 0x7f143c4e1920 (LWP 1757)):
#0  0x0000003b8b8accd0 in __nanosleep_nocancel () from /lib64/libc.so.6
#1  0x0000003b8b8e1e74 in usleep () from /lib64/libc.so.6
#2  0x00007f143a92ba22 in qxl_wait_for_io_command (qxl=<value optimized out>)
    at qxl_driver.c:157
#3  0x00007f143a92bf54 in setup_slot (qxl=<value optimized out>) at qxl_driver.c:799
#4  qxl_reset_and_create_mem_slots (qxl=<value optimized out>) at qxl_driver.c:832
#5  0x00007f143a92e18d in qxl_enter_vt (arg=0x296f470) at qxl_driver.c:1934
#6  0x00000000004cf35e in xf86RandR12EnterVT (pScrn=0x296f470) at xf86RandR12.c:1759
#7  0x000000000048c081 in xf86VTSwitch (blockData=<value optimized out>, 
    err=<value optimized out>, pReadmask=<value optimized out>) at xf86Events.c:536
#8  xf86Wakeup (blockData=<value optimized out>, err=<value optimized out>, 
    pReadmask=<value optimized out>) at xf86Events.c:285
#9  0x000000000043b98b in WakeupHandler (result=-1, pReadmask=0x82d6c0)
    at dixutils.c:423
#10 0x000000000046a7ef in WaitForSomething (pClientsReady=0x2c1ab50) at WaitFor.c:224
#11 0x0000000000437ab2 in Dispatch () at dispatch.c:358
#12 0x000000000047d08a in main (argc=11, argv=<value optimized out>, 
    envp=<value optimized out>) at main.c:295

Version-Release number of selected component (if applicable):
xorg-x11-drv-qxl-0.1.0-8.el6_5

How reproducible:
Always (with enough high resolution)

Steps to Reproduce:
1. Switch to the VT with Ctrl+Alt+F2 in spice session with qxl driver in use (spice session should have multimonitors enabled - 4 monitors or 2 with high resolution)
2. Switch back to gnome-session

Actual results:
Xorg process seems to hang - only kill -9 solves the problem.

Expected results:


Additional info:

Comment 2 Søren Sandmann Pedersen 2014-05-22 15:49:45 UTC
Does this also happen with the latest 6.6 driver (ie., 0.1.1-12) and not with the 6.6 driver before the resolution fix (ie., 0.1.1-10)?

Comment 3 Marian Krcmarik 2014-06-06 16:00:11 UTC
(In reply to Søren Sandmann Pedersen from comment #2)
> Does this also happen with the latest 6.6 driver (ie., 0.1.1-12) and not
> with the 6.6 driver before the resolution fix (ie., 0.1.1-10)?

Yes, but I am not saying it is cause by the fix, The bug seems to happen with high resolutions and without the fix which is incluced in 0.1.1-12 I am not able to get such high resolutions. So maybe I just start to observe it once I am able to get such higher resolutions.

Comment 4 Søren Sandmann Pedersen 2014-06-10 18:41:21 UTC
Oh, so it only happens with higher resolutions? If so, maybe what's going on is that after switching back from the VT, only the ROM limit is allocated to the framebuffer.

Comment 5 Søren Sandmann Pedersen 2014-06-11 17:56:28 UTC
The backtrace when it is hanging is this:


0x0000003c61eaccc0 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:82
82	T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
(gdb) bt
#0  0x0000003c61eaccc0 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:82
#1  0x0000003c61ee1e54 in usleep (useconds=<value optimized out>) at ../sysdeps/unix/sysv/linux/usleep.c:33
#2  0x00007f4fb112fb76 in qxl_wait_for_io_command (qxl=0x20aed10) at qxl_io.c:47
#3  0x00007f4fb112fc39 in qxl_io_memslot_add (qxl=0x20aed10, id=1 '\001') at qxl_io.c:94
#4  0x00007f4fb1126bc2 in setup_slot (qxl=0x20aed10, slot_index_offset=0 '\000', start_phys_addr=1073741824, 
    end_phys_addr=1209606144, start_virt_addr=139980115648512, end_virt_addr=139980251512832)
    at qxl_mem.c:208
#5  0x00007f4fb1126de4 in qxl_reset_and_create_mem_slots (qxl=0x20aed10) at qxl_mem.c:241
#6  0x00007f4fb112118f in qxl_enter_vt (arg=0x20ae6f0) at qxl_driver.c:842
#7  0x00000000004f04e0 in xf86RandR12EnterVT (pScrn=0x20ae6f0) at xf86RandR12.c:1760
#8  0x000000000049870e in xf86VTSwitch () at xf86Events.c:545
#9  0x0000000000497f32 in xf86Wakeup (blockData=0x0, err=-1, pReadmask=0x8c9d40) at xf86Events.c:288
#10 0x0000000000445c94 in WakeupHandler (result=-1, pReadmask=0x8c9d40) at dixutils.c:423
#11 0x000000000061ce01 in WaitForSomething (pClientsReady=0x237e0a0) at WaitFor.c:229
#12 0x0000000000436759 in Dispatch () at dispatch.c:362
#13 0x0000000000444f39 in dix_main (argc=11, argv=0x7fff2eee12e8, envp=0x7fff2eee1348) at main.c:294
#14 0x0000000000426aec in main (argc=11, argv=0x7fff2eee12e8, envp=0x7fff2eee1348) at stubmain.c:34

Comment 7 Marc-Andre Lureau 2014-08-12 16:49:23 UTC
The qemu condition reached is in qxl_add_memslot: "finished loop without match"

Comment 8 Marc-Andre Lureau 2014-08-12 16:58:31 UTC
    qxl->main_mem_slot = setup_slot (qxl, 0,
                                     (unsigned long)qxl->ram_physical,
                                     (unsigned long)qxl->ram_physical + qxl->surface0_size +
                                     (unsigned long)qxl->rom->num_pages * getpagesize (),
                                     (uint64_t)(uintptr_t)qxl->ram,
                                     (uint64_t)(uintptr_t)qxl->ram + qxl->surface0_size +
                                     (unsigned long)qxl->rom->num_pages * getpagesize ()
        );

The main_mem_slot size doesn't match the qemu pci slot size. So it fails there and Xorg hangs.

Since qxl->surface0_size is updated it no longer matches qemu value, so qxl->rom-> num_pages needs to be recomputed too, so that slot ranges still matches qemu

Comment 9 Marc-Andre Lureau 2014-08-12 17:59:59 UTC
raising, assigning to myself

Comment 10 Marc-Andre Lureau 2014-08-14 18:05:16 UTC
patch from -12 removed, solving this issue

Comment 14 Marian Krcmarik 2014-09-11 11:23:37 UTC
I am not able to verify the bug since I am not able to match conditions which are needed for reproducing due to regression in #1076728 -> I am not able to set higher resolutions.

Comment 15 David Blechter 2014-09-11 21:11:11 UTC
moving to 6.7, not a blocker for 6.6

Comment 18 Marc-Andre Lureau 2014-12-15 10:44:59 UTC
discussed in bug 1140765

Comment 22 Marc-Andre Lureau 2015-03-19 11:24:05 UTC
There are now 2 acks (3 required) for the qemu patches to support higher resolutions. 

I did a scratch build of QXL driver without surface0-resize for testing:
https://brewweb.devel.redhat.com/taskinfo?taskID=8874192

Comment 23 Christophe Fergeau 2015-04-01 16:45:58 UTC
*** Bug 1140765 has been marked as a duplicate of this bug. ***

Comment 27 errata-xmlrpc 2015-07-22 07:31:48 UTC
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-1399.html


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