[PATCH] mi: if we fail to process 100 input events due to a stuck EQ, terminate.
Peter Hutterer
peter.hutterer at who-t.net
Sun Apr 19 21:19:19 PDT 2009
On Sun, Apr 19, 2009 at 09:07:29PM -0700, Aaron Plattner wrote:
> Please don't. Or at the very least, make this optional. There are a
> number of reasons why the graphics driver would get stuck for long
> periods of time including ridiculous client requests (e.g. huge
> convolution filters), graphics cards hitting thermal slowdown
> thresholds, graphics "hardware" that's actually a simluation library,
> the server being stopped in a debugger, etc.
Fair enough. Is there any way to "reliably" detect the difference?
I don't think making this optional is particularly useful, so dropping it is
probably better.
Cheers,
Peter
> On Sun, Apr 19, 2009 at 08:10:18PM -0700, Peter Hutterer wrote:
> > After > 100 stuck input events, the server is unlikely to recover. So print a
> > message to the log and terminate the server instead of requiring users to kill
> > the server themselves.
> >
> > Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
> > ---
> > mi/mieq.c | 8 +++++++-
> > 1 files changed, 7 insertions(+), 1 deletions(-)
> >
> > diff --git a/mi/mieq.c b/mi/mieq.c
> > index 0dedbee..c263114 100644
> > --- a/mi/mieq.c
> > +++ b/mi/mieq.c
> > @@ -182,11 +182,17 @@ mieqEnqueue(DeviceIntPtr pDev, InternalEvent *e)
> > ErrorF("[mi] EQ overflowing. The server is probably stuck "
> > "in an infinite loop.\n");
> > xorg_backtrace();
> > - stuck = 1;
> > + stuck++;
> > }
> > #ifdef XQUARTZ
> > pthread_mutex_unlock(&miEventQueueMutex);
> > #endif
> > +
> > + if (stuck >= 100)
> > + FatalError("[mi] The last 100 input events could not be "
> > + "processed. This is a bug.\n"
> > + "Terminating server now. Please submit this log"
> > + "file to http://bugs.freedesktop.org");
> > return;
> > }
> > stuck = 0;
> > --
> > 1.6.2.2.447.g4afa7
More information about the xorg-devel
mailing list