<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Context:<br>
Host is running qemu-kvm 1.1.2 and spice 0.12.2.<br>
Fedora 16 VMs ran rock solid on these same virtualization hosts.<br>
The Fedora 19 and 20(testing) VMs are running xf86-video-qxl
compiled from the master branch of the git repo.</p>
<p>We've been seeing a lot of X server crashes in Fedora 19 and 20,
generally after the VM has been running for at least 2-3 days.<br>
The last gasp in the Xorg logs from these crashes generally look
something like:<br>
</p>
<p>[1024592.839] Out of memory allocating 261140 bytes<br>
[1024592.839] Out of mem - stats<br>
<br>
[1024592.850] max system bytes = 243257344<br>
[1024592.850] system bytes = 243257344<br>
[1024592.850] in use bytes = 133245384<br>
</p>
<p>Someone here managed to get a stack trace out of one such crash:<br>
</p>
<p>(EE) <span class="error">[mi]</span> EQ overflowing. Additional
events will be discarded until existing events are processed.<br>
(EE)<br>
(EE) Backtrace:<br>
(EE) 0: /usr/bin/X (mieqEnqueue+0x22b) <span class="error">[0x57691b]</span><br>
(EE) 1: /usr/bin/X (QueuePointerEvents+0x52) <span class="error">[0x44d862]</span><br>
(EE) 2: /usr/lib64/xorg/modules/input/evdev_drv.so (_init+0x2913)
<span class="error">[0x7ff0faeb17e3]</span><br>
(EE) 3: /usr/bin/X (DPMSSupported+0xe8) <span class="error">[0x4861f8]</span><br>
(EE) 4: /usr/bin/X (xf86SerialModemClearBits+0x230) <span
class="error">[0x4ae7b0]</span><br>
(EE) 5: /lib64/libpthread.so.0 (__restore_rt+0x0) <span
class="error">[0x3b7de0ef9f]</span><br>
(EE) 6: /lib64/libpthread.so.0 (__nanosleep_nocancel+0x24) <span
class="error">[0x3b7de0e804]</span><br>
(EE) 7: /usr/lib64/xorg/modules/drivers/qxl_drv.so
(qxl_handle_oom+0x69) <span class="error">[0x7ff10fceccb9]</span><br>
(EE) 8: /usr/lib64/xorg/modules/drivers/qxl_drv.so
(qxl_allocnf+0x48) <span class="error">[0x7ff10fcecd08]</span><br>
(EE) 9: /usr/lib64/xorg/modules/drivers/qxl_drv.so
(qxl_bo_alloc_internal+0x76) <span class="error">[0x7ff10fcece06]</span><br>
(EE) 10: /usr/lib64/xorg/modules/drivers/qxl_drv.so
(qxl_image_create+0xf2) <span class="error">[0x7ff10fce9782]</span><br>
(EE) 11: /usr/lib64/xorg/modules/drivers/qxl_drv.so
(qxl_surface_put_image+0xf5) <span class="error">[0x7ff10fceb045]</span><br>
(EE) 12: /usr/lib64/xorg/modules/drivers/qxl_drv.so
(uxa_copy_n_to_n+0x5e7) <span class="error">[0x7ff10fcf7127]</span><br>
(EE) 13: /usr/bin/X (miCopyRegion+0x1ad) <span class="error">[0x574d2d]</span><br>
(EE) 14: /usr/bin/X (miDoCopy+0x456) <span class="error">[0x5752b6]</span><br>
(EE) 15: /usr/lib64/xorg/modules/drivers/qxl_drv.so
(uxa_copy_area+0xae) <span class="error">[0x7ff10fcf5efe]</span><br>
(EE) 16: /usr/bin/X (dixDestroyPixmap+0x711) <span class="error">[0x433a31]</span><br>
(EE) 17: /usr/bin/X (SendErrorToClient+0x3f7) <span class="error">[0x436fa7]</span><br>
(EE) 18: /usr/bin/X (_init+0x3aaa) <span class="error">[0x429b4a]</span><br>
(EE) 19: /lib64/libc.so.6 (__libc_start_main+0xf5) <span
class="error">[0x3b7d221b75]</span><br>
(EE) 20: /usr/bin/X (_start+0x29) <span class="error">[0x4267b1]</span><br>
(EE) 21: ? (?+0x29) <span class="error">[0x29]</span><br>
(EE)<br>
(EE) <span class="error">[mi]</span> These backtraces from
mieqEnqueue may point to a culprit higher up the stack.<br>
(EE) <span class="error">[mi]</span> mieq is <b>NOT</b> the
cause. It is a victim.<br>
(EE) <span class="error">[mi]</span> EQ overflow continuing. 100
events have been dropped.</p>
His comment was:<br>
<br>
Examining the stack trace more closely, the functions identified are
misleading. The offsets are sometimes larger than the named
functions, and point to different functions not listed in the
stripped symbol table. Looking at the source, it seems that:
<div class="action-body flooded">
<p>(EE) 16: /usr/bin/X (dixDestroyPixmap+0x711) <span
class="error">[0x433a31]</span></p>
<ul class="alternate" type="square">
<li>This is probably ProcCreatePixmap()</li>
</ul>
<p>(EE) 17: /usr/bin/X (SendErrorToClient+0x3f7) <span
class="error">[0x436fa7]</span></p>
<ul class="alternate" type="square">
<li>This is possibly init_screen() or AddScreen()</li>
</ul>
<p>So, it appears the memory allocation fails while setting up a
new screen structure. This makes more sense, but still leaves
open the question why it's trying to create new screens long
after startup.<br>
</p>
<p>It's hard to recreate the crashes other than by simply booting
and using a VM for a few days. One theory we're tossing around
is that the memory buffer xf86-video-qxl has to work with is
getting fragmented and when the fragmentation gets bad enough an
allocation can fail.<br>
Our best guess is that this is a bug in the xf86-video-qxl
driver. Has anyone else seen similar Xorg crashes?<br>
</p>
<p>Guidance on how to fix or at least troubleshoot this further
would be greatly appreciated.<br>
</p>
<p>Thanks!<br>
-Nahum<br>
</p>
</div>
</body>
</html>