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
_______________________________________________
[email protected]: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: [email protected]
_______________________________________________
[email protected]: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: [email protected]
_______________________________________________
[email protected]: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: [email protected]
_______________________________________________
[email protected]: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: [email protected]
_______________________________________________
[email protected]: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: [email protected]
