mieqProcessDeviceEvent make calls to mieqEnque with signals enabled - freezes Xorg server - multi-screen

Donald Kayser xorg at kayser.net
Wed May 18 12:22:43 PDT 2011


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:

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
On May 18, 2011, at 2:13 PM, Donald Kayser wrote:

> 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:
>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> Regards,
>> Donald
>>
>>
>> On May 17, 2011, at 5:46 PM, Peter Hutterer wrote:
>>
>>> On Tue, May 17, 2011 at 05:13:37PM -0500, Donald Kayser wrote:
>>>> Thanks for the quick response Jeremy. I was aware that I would miss
>>>> events during this test, but that was better than freezing. I have
>>>> not tried 1.10.x, but I will. We are trying to release a product
>>>> soon and changing to a new server and distribution is not
>>>> straightforward or the best move on our part. I might have to
>>>> consider any other solution for the short term. I am glad to hear
>>>> that we are not the only ones to have this problem and that it  
>>>> might
>>>> already be solved. I will look further at 1.10.x and go from there.
>>>
>>> I think this bug may still be there (possibly in a different  
>>> incarnation) in
>>> 1.10. I haven't had any success reproducing it yet though.
>>> I know at least one of these got fixed in the last couple of server
>>> versions, but I can't seem to find the commit for it now.
>>>
>>> I suppose the quickest fix is to put OsBlockSignals() and  
>>> OsReleaseSignals()
>>> around the part that must not be interrupted and rewrite it to be  
>>> as short
>>> as possible. If you have a good description of the bug I'd love to  
>>> hear it
>>> so we can look at a proper fix.
>>>
>>> Cheers,
>>> Peter
>>>
>>>> On May 17, 2011, at 4:49 PM, Jeremy Huddleston wrote:
>>>>
>>>>> Ignoring SIGIO will just result in dropped events.  I seem to
>>>>> vaguely recall that this issue was addressed at some point in the
>>>>> past year or two since 1.7.x was active.  Have you tried 1.10.x or
>>>>> master?
>>>>>
>>>>> On May 17, 2011, at 13:34, Donald Kayser wrote:
>>>>>
>>>>>> I am developing a system that include's the debian/squeeze
>>>>>> distribution of xorg-server, version 1.7.7. I have come across a
>>>>>> scenario where mouse movements on one screen and a touch on
>>>>>> another screen will cause the Xorg process to freeze in an
>>>>>> infinite loop in the function mieqProcessInputEvents(). I have
>>>>>> traced the problem down to a small window during which a call to
>>>>>> mieqProcessDeviceEvent can be interrupted by a signal and mess
>>>>>> up the miEventQueue.head and tail. It appears that in some place
>>>>>> in this stack a new event is being enqueued while the screen is
>>>>>> changing and device messages get swapped to the wrong screen and
>>>>>> back and forth.
>>>>>>
>>>>>> I put a global variable in mieqProcessDeviceEvent to indicate to
>>>>>> mieqEnqueue to ignore data until finished. This has solved the
>>>>>> problem as a test. I am now writing the code to ignore the SIGIO
>>>>>> signal during mieqProcessDeviceEvent and test this approach
>>>>>> also.
>>>>>>
>>>>>> Does anyone have a similar problem or advice?
>>>>>>
>>>>>> Thanks
>>>>>> Donald Kayser
>>>>>> xorg at kayser dot net
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> xorg at lists.freedesktop.org: X.Org support
>>>>>> Archives: http://lists.freedesktop.org/archives/xorg
>>>>>> Info: http://lists.freedesktop.org/mailman/listinfo/xorg
>>>>>> Your subscription address: jeremyhu at freedesktop.org
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> xorg at lists.freedesktop.org: X.Org support
>>>>> Archives: http://lists.freedesktop.org/archives/xorg
>>>>> Info: http://lists.freedesktop.org/mailman/listinfo/xorg
>>>>> Your subscription address: xorg at kayser.net
>>>>>
>>>>
>>>> _______________________________________________
>>>> xorg at lists.freedesktop.org: X.Org support
>>>> Archives: http://lists.freedesktop.org/archives/xorg
>>>> Info: http://lists.freedesktop.org/mailman/listinfo/xorg
>>>> Your subscription address: peter.hutterer at who-t.net
>>>>
>>>
>>
>> _______________________________________________
>> xorg at lists.freedesktop.org: X.Org support
>> Archives: http://lists.freedesktop.org/archives/xorg
>> Info: http://lists.freedesktop.org/mailman/listinfo/xorg
>> Your subscription address: xorg at kayser.net
>>
>
> _______________________________________________
> xorg at lists.freedesktop.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.freedesktop.org/mailman/listinfo/xorg
> Your subscription address: xorg at kayser.net
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20110518/7de1e5c1/attachment.html>


More information about the xorg mailing list