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

[Donald Kayser]

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
>>
>