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@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: jerem...@freedesktop.org
_______________________________________________
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: x...@kayser.net
_______________________________________________
xorg@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.hutte...@who-t.net
_______________________________________________
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
