Created attachment 896507 [details]
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>)
#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)
#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):
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
Xorg process seems to hang - only kill -9 solves the problem.
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)?
(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.
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.
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)
#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)
#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
The qemu condition reached is in qxl_add_memslot: "finished loop without match"
qxl->main_mem_slot = setup_slot (qxl, 0,
(unsigned long)qxl->ram_physical + qxl->surface0_size +
(unsigned long)qxl->rom->num_pages * getpagesize (),
(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
raising, assigning to myself
patch from -12 removed, solving this issue
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.
moving to 6.7, not a blocker for 6.6
discussed in bug 1140765
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:
*** Bug 1140765 has been marked as a duplicate of this bug. ***
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.