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

[Jeremy Huddleston]

Hey Tiago,

What ever happened to your work to create a separate thread for input enqueue?  I seem to recall you came across this issue during that work and had something working.


On May 18, 2011, at 08:24, 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
>>> 
>> 
>