mieqProcessDeviceEvent make calls to mieqEnque with signals enabled - freezes Xorg server - multi-screen
Donald Kayser
xorg at kayser.net
Wed May 18 12:13:30 PDT 2011
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
>
More information about the xorg
mailing list