<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Here is a stack trace of an event that is now being ignored and I suspect is revealing why the signal approach didn't work and maybe will give you insight:<div> </div><div>0 mieqEnqueue (pDev=0x10462d80, e=0x101f78e8) at ../../mi/mieq.c:162 #1 0x100715dc in xf86PostMotionEventP (device=0x10462d80, is_absolute=<value optimized out>, first_valuator=<value optimized out>, num_valuators=<value optimized out>, valuators=<value optimized out>) at ../../../../hw/xfree86/common/xf86Xinput.c:982 #2 0x0f6b50f0 in ?? () from /usr/lib/xorg/modules/input/evdev_drv.so #3 0x0f6b54c4 in ?? () from /usr/lib/xorg/modules/input/evdev_drv.so #4 0x1006db08 in xf86SigioReadInput (fd=<value optimized out>, closure=<value optimized out>) at ../../../../hw/xfree86/common/xf86Events.c:313 #5 0x10135f28 in xf86SIGIO (sig=<value optimized out>) at ../../../../../hw/xfree86/os-support/linux/../shared/sigio.c:118 #6 <signal handler called> #7 0x0fb02ba0 in sigprocmask () from /lib/libc.so.6 #8 0x10135834 in xf86UnblockSIGIO (wasset=<value optimized out>) at ../../../../../hw/xfree86/os-support/linux/../shared/sigio.c:297 #9 0x1006fd78 in xf86WarpCursor (pDev=0x10462d80, pScreen=0x10249b48, x=<value optimized out>, y=<value optimized out>) at ../../../../hw/xfree86/common/xf86Cursor.c:476 #10 0x1005cec8 in miPointerSetCursorPosition (pDev=0x10462d80, pScreen=0x10249b48, x=<value optimized out>, y=<value optimized out>, generateEvent=1) at ../../mi/mipointer.c:239 #11 0x100ecdac in AnimCurSetCursorPosition (pDev=0x10462d80, pScreen=0x10249b48, x=<value optimized out>, y=<value optimized out>, generateEvent=<value optimized out>) at ../../render/animcur.c:266 #12 0x1001f738 in CheckPhysLimits (pDev=0x10462d80, cursor=<value optimized out>, generateEvents=1, confineToScreen=0, pScreen=0x10249b48) at ../../dix/events.c:756 #13 0x100acf60 in mieqProcessDeviceEvent (dev=0x10462d80, event=0x105091c0, screen=0x10249b48) at ../../mi/mieq.c:402 #14 0x100ad020 in mieqProcessInputEvents () at ../../mi/mieq.c:489 #15 0x1006dd54 in ProcessInputEvents () at ../../../../hw/xfree86/common/xf86Events.c:165 #16 0x10050d1c in Dispatch () at ../../dix/dispatch.c:371 #17 0x1001d0d4 in main (argc=5, argv=0xbffffdc4, envp=<value optimized out>) at ../../dix/main.c:283 <div><div>On May 18, 2011, at 2:13 PM, Donald Kayser wrote:</div> <blockquote type="cite"><div>More notes of interest. The use of OsBlockSignals() and OsReleaseSignals() does not solve the problem. I also attempted using sigaction() to set the handler of SIGIO to SIG_IGN and this does not solve the problem. The only kludge, hack that works is setting a static variable in mieq.c that I added to indicate that mieqProcessDeviceEvent is being called, and in mieqEnqueue I check the value of the static variable and toss events if true. I have narrowed the "protected" code to the part surrounding the call to NewCurrentScreen() in mieqProcessDeviceEvent() in the top half of the function. I have not yet tried the newer version of Xorg; this is the more painful step in terms of time to solve this problem. I would have to repeat an entire product test regression if this becomes the solution. Any more ideas are very welcome. Thanks, Donald On May 18, 2011, at 10:24 AM, Donald Kayser wrote: <blockquote type="cite">I'm glad to know I'm not alone on this one. I can reproduce it at will with this embedded application and target. FYI, I will give you some details of the system. It is an embedded controller with PPC processor. We are running Linux 2.6.26 PREEMPT, debian squeeze distribution, Xorg 1.7.7. I ported the 2.6.26 kernel to load on this target. The video is two embedded C&T69030 graphics chips; I re-wrote the xf86-video-chips driver to support 4 screens. We do not use Xinerama. Our application is QT based and we use fluxbox as a window manager. </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">To reproduce the problem here involves running the embedded application. On one screen supported by one of the embedded chips is a window that is being dragged upon and is consuming large amounts of cpu time. Overlaying another screen on the second embedded video chip is a touchscreen. As our application gets to the state where it is consuming most of the cpu by dragging on the first screen and one touches the second screen, this bug re-appears 100% of the time, or nearly enough. I have not had the time or platform ready to test on non PPC platform, but that is not out of my realm since we do have target systems running Intel. I have downloaded the source for the Xorg server, built it, and have been debugging it to get to this point. I will provide detailed stack traces and will narrow it down as much as I can. </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">As mentioned before, I have been able to work around it, but would like a better solution. I will use the OsxxxxSignals() calls to narrow down the exact time, but I suspect it is in the call of NewCurrentScreen within the mieqProcessDeviceEvent() function. </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">Regards, </blockquote><blockquote type="cite">Donald </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">On May 17, 2011, at 5:46 PM, Peter Hutterer wrote: </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite"><blockquote type="cite">On Tue, May 17, 2011 at 05:13:37PM -0500, Donald Kayser wrote: </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Thanks for the quick response Jeremy. I was aware that I would miss </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">events during this test, but that was better than freezing. I have </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">not tried 1.10.x, but I will. We are trying to release a product </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">soon and changing to a new server and distribution is not </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">straightforward or the best move on our part. I might have to </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">consider any other solution for the short term. I am glad to hear </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">that we are not the only ones to have this problem and that it might </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">already be solved. I will look further at 1.10.x and go from there. </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I think this bug may still be there (possibly in a different incarnation) in </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">1.10. I haven't had any success reproducing it yet though. </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I know at least one of these got fixed in the last couple of server </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">versions, but I can't seem to find the commit for it now. </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I suppose the quickest fix is to put OsBlockSignals() and OsReleaseSignals() </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">around the part that must not be interrupted and rewrite it to be as short </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">as possible. If you have a good description of the bug I'd love to hear it </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">so we can look at a proper fix. </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Cheers, </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Peter </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On May 17, 2011, at 4:49 PM, Jeremy Huddleston wrote: </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Ignoring SIGIO will just result in dropped events. I seem to </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">vaguely recall that this issue was addressed at some point in the </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">past year or two since 1.7.x was active. Have you tried 1.10.x or </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">master? </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On May 17, 2011, at 13:34, Donald Kayser wrote: </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I am developing a system that include's the debian/squeeze </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">distribution of xorg-server, version 1.7.7. I have come across a </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">scenario where mouse movements on one screen and a touch on </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">another screen will cause the Xorg process to freeze in an </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">infinite loop in the function mieqProcessInputEvents(). I have </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">traced the problem down to a small window during which a call to </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">mieqProcessDeviceEvent can be interrupted by a signal and mess </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">up the miEventQueue.head and tail. It appears that in some place </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">in this stack a new event is being enqueued while the screen is </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">changing and device messages get swapped to the wrong screen and </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">back and forth. </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I put a global variable in mieqProcessDeviceEvent to indicate to </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">mieqEnqueue to ignore data until finished. This has solved the </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">problem as a test. I am now writing the code to ignore the SIGIO </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">signal during mieqProcessDeviceEvent and test this approach </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">also. </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Does anyone have a similar problem or advice? </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Thanks </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Donald Kayser </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">xorg at kayser dot net </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">_______________________________________________ </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="mailto:xorg@lists.freedesktop.org">xorg@lists.freedesktop.org</a>: X.Org support </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Archives: <a href="http://lists.freedesktop.org/archives/xorg">http://lists.freedesktop.org/archives/xorg</a> </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Info: <a href="http://lists.freedesktop.org/mailman/listinfo/xorg">http://lists.freedesktop.org/mailman/listinfo/xorg</a> </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Your subscription address: <a href="mailto:jeremyhu@freedesktop.org">jeremyhu@freedesktop.org</a> </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">_______________________________________________ </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="mailto:xorg@lists.freedesktop.org">xorg@lists.freedesktop.org</a>: X.Org support </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Archives: <a href="http://lists.freedesktop.org/archives/xorg">http://lists.freedesktop.org/archives/xorg</a> </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Info: <a href="http://lists.freedesktop.org/mailman/listinfo/xorg">http://lists.freedesktop.org/mailman/listinfo/xorg</a> </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Your subscription address: <a href="mailto:xorg@kayser.net">xorg@kayser.net</a> </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">_______________________________________________ </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="mailto:xorg@lists.freedesktop.org">xorg@lists.freedesktop.org</a>: X.Org support </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Archives: <a href="http://lists.freedesktop.org/archives/xorg">http://lists.freedesktop.org/archives/xorg</a> </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Info: <a href="http://lists.freedesktop.org/mailman/listinfo/xorg">http://lists.freedesktop.org/mailman/listinfo/xorg</a> </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Your subscription address: <a href="mailto:peter.hutterer@who-t.net">peter.hutterer@who-t.net</a> </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">_______________________________________________ </blockquote><blockquote type="cite"><a href="mailto:xorg@lists.freedesktop.org">xorg@lists.freedesktop.org</a>: X.Org support </blockquote><blockquote type="cite">Archives: <a href="http://lists.freedesktop.org/archives/xorg">http://lists.freedesktop.org/archives/xorg</a> </blockquote><blockquote type="cite">Info: <a href="http://lists.freedesktop.org/mailman/listinfo/xorg">http://lists.freedesktop.org/mailman/listinfo/xorg</a> </blockquote><blockquote type="cite">Your subscription address: <a href="mailto:xorg@kayser.net">xorg@kayser.net</a> </blockquote><blockquote type="cite"> </blockquote> _______________________________________________ <a href="mailto:xorg@lists.freedesktop.org">xorg@lists.freedesktop.org</a>: X.Org support Archives: <a href="http://lists.freedesktop.org/archives/xorg">http://lists.freedesktop.org/archives/xorg</a> Info: <a href="http://lists.freedesktop.org/mailman/listinfo/xorg">http://lists.freedesktop.org/mailman/listinfo/xorg</a> Your subscription address: <a href="mailto:xorg@kayser.net">xorg@kayser.net</a> </div></blockquote></div> </div></body></html>