X server instability... is it mouse event overrun?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

X server instability... is it mouse event overrun?

asmith-4
Hi,

 

I have been getting an issue, typically when memory starts to get low and my
Zaurus starts to page with the X server bombing out.

 

Typically in the Xorg.0.log I see.

 

ioctl FBIOGETCMAP: Invalid argument

ioctl FBIOPUTCMAP: Invalid argument

(WW) TouchScreen0: bad wsmouse event type=-117440512

(WW) TouchScreen0: bas wsmouse event type=-16777216

.

 

Sometimes about 300 of these wsmouse events before the X server finally
dies.

 

Anyone experiencing similar problems? Anyone got a fix for this
(workaround)?

 

I'm torn between the belief that either the X session is going over a stack
limit.. possibly, login.conf default is 4M, may try upping that. or the
mouse event queue is overflowing and the duff events are being read from
'out of bounds' locations until finally it hits a location that's unreadable
and the X server is killed.

 

Any other suggestions?

 

BTW: this is OpenBSD 3.9 beta (-current) from the latest snapshots but the
problem with in 3.8 -release and -current too.

 

- Andy

Reply | Threaded
Open this post in threaded view
|

Re: X server instability... is it mouse event overrun?

Ray Lai
On Tue, Jan 31, 2006 at 06:47:59PM -0000, Andrew Smith wrote:

> I have been getting an issue, typically when memory starts to get low and my
> Zaurus starts to page with the X server bombing out.
>
> Typically in the Xorg.0.log I see.
>
> ioctl FBIOGETCMAP: Invalid argument
>
> ioctl FBIOPUTCMAP: Invalid argument
>
> (WW) TouchScreen0: bad wsmouse event type=-117440512
>
> (WW) TouchScreen0: bas wsmouse event type=-16777216

I've gotten ``bad wsmouse event''s when I put my Thinkpad X40 under
heavy load (to the point where the screen freezes for a couple of
seconds) and try to move the mouse while it's frozen.  After the
freeze is over the mouse jumps to the far left if I try to quickly
move the mouse right.  I can still gradually move the mouse right
if I lightly nudge the trackpoint, but push too hard and it pops
all the way to the left.  The Y axis remains fine.

I'm not sure if this is the same problem (I'm on i386 and the X40
never pages), but if it is it's more of an X issue and should be
posted to x11@.

-Ray-

Reply | Threaded
Open this post in threaded view
|

Re: X server instability... is it mouse event overrun?

Matthieu Herrb
In reply to this post by asmith-4
Andrew Smith wrote:

> Hi,
>
>  
>
> I have been getting an issue, typically when memory starts to get low and my
> Zaurus starts to page with the X server bombing out.
>
>  
>
> Typically in the Xorg.0.log I see.
>
>  
>
> ioctl FBIOGETCMAP: Invalid argument
>
> ioctl FBIOPUTCMAP: Invalid argument
>
> (WW) TouchScreen0: bad wsmouse event type=-117440512
>
> (WW) TouchScreen0: bas wsmouse event type=-16777216
>
> .
>
>  
>
> Sometimes about 300 of these wsmouse events before the X server finally
> dies.
>
>  
>
> Anyone experiencing similar problems? Anyone got a fix for this
> (workaround)?
>
>  
Dale Rahn found the probable cause of the problem.
Try this patch (sorry if my mailer trashes it):

Index: xc/programs/Xserver/hw/xfree86/input/ws/ws.c
===================================================================
RCS file: /cvs/OpenBSD/XF4/xc/programs/Xserver/hw/xfree86/input/ws/ws.c,v
retrieving revision 1.10
diff -u -r1.10 ws.c
--- xc/programs/Xserver/hw/xfree86/input/ws/ws.c 22 Jun 2005 06:22:06
-0000 1.10
+++ xc/programs/Xserver/hw/xfree86/input/ws/ws.c 2 Feb 2006 23:04:52 -0000
@@ -418,7 +418,7 @@
  XisbBlockDuration(priv->buffer, -1);
  pBuf = (unsigned char *)eventList;
  n = 0;
- while ((c = XisbRead(priv->buffer)) >= 0 && n < sizeof(eventList)) {
+ while (n < sizeof(eventList) && (c = XisbRead(priv->buffer)) >= 0) {
  pBuf[n++] = (unsigned char)c;
  }
 

--
Matthieu Herrb

Reply | Threaded
Open this post in threaded view
|

Re: X server instability... is it mouse event overrun?

asmith-4
Matthieu,

Initial results look good, I will keep monitoring it for now. My Zaurus is
on the major task of compiling kdelibs (just to try out building a more
recent konqueror-embedded) and has peaked at 80Mb paged out without the X
server running so if anything is going to stress the machine for the test
this is.

I can see that the while statement originally dropped a read if the buffer
was full and that the new ordering ensures that the buffer length test
completes before trying the buffer read (logical since the while conditional
will continue once the first part of the ANDed logic has failed before
trying the second op.. neat).

My initial reaction was... you couldn't get this type of problem from
dropping a single event but am I right in suspecting that the events are
actually multi-byte data and that by dropping one character we are actually
getting misaligned event data in the previous version once we have a buffer
full condition? - hence all the bad mouse event messages?

- Andy

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of
Matthieu Herrb
Sent: 02 February 2006 23:08
To: Andrew Smith
Cc: 'OpenBSD Arm Mailing List'
Subject: Re: X server instability... is it mouse event overrun?

Andrew Smith wrote:
> Hi,
>
>  
>
> I have been getting an issue, typically when memory starts to get low and
my

> Zaurus starts to page with the X server bombing out.
>
>  
>
> Typically in the Xorg.0.log I see.
>
>  
>
> ioctl FBIOGETCMAP: Invalid argument
>
> ioctl FBIOPUTCMAP: Invalid argument
>
> (WW) TouchScreen0: bad wsmouse event type=-117440512
>
> (WW) TouchScreen0: bas wsmouse event type=-16777216
>
> .
>
>  
>
> Sometimes about 300 of these wsmouse events before the X server finally
> dies.
>
>  
>
> Anyone experiencing similar problems? Anyone got a fix for this
> (workaround)?
>
>  
Dale Rahn found the probable cause of the problem.
Try this patch (sorry if my mailer trashes it):

Index: xc/programs/Xserver/hw/xfree86/input/ws/ws.c
===================================================================
RCS file: /cvs/OpenBSD/XF4/xc/programs/Xserver/hw/xfree86/input/ws/ws.c,v
retrieving revision 1.10
diff -u -r1.10 ws.c
--- xc/programs/Xserver/hw/xfree86/input/ws/ws.c 22 Jun 2005 06:22:06

-0000 1.10
+++ xc/programs/Xserver/hw/xfree86/input/ws/ws.c 2 Feb 2006 23:04:52
-0000
@@ -418,7 +418,7 @@
  XisbBlockDuration(priv->buffer, -1);
  pBuf = (unsigned char *)eventList;
  n = 0;
- while ((c = XisbRead(priv->buffer)) >= 0 && n < sizeof(eventList)) {
+ while (n < sizeof(eventList) && (c = XisbRead(priv->buffer)) >= 0) {
  pBuf[n++] = (unsigned char)c;
  }
 

--
Matthieu Herrb

Reply | Threaded
Open this post in threaded view
|

Re: X server instability... is it mouse event overrun?

Otto Moerbeek
On Fri, 3 Feb 2006, Andrew Smith wrote:

> My initial reaction was... you couldn't get this type of problem from
> dropping a single event but am I right in suspecting that the events are
> actually multi-byte data and that by dropping one character we are actually
> getting misaligned event data in the previous version once we have a buffer
> full condition? - hence all the bad mouse event messages?

Yes, you're right. On a side note: tot only zaurus was seeing this,
but other arches as well. A similar fix was put in for the other
arches (zaurus uses mouse input handling a bit different from the
other arches). They should all be fixed now.

        -Otto

Reply | Threaded
Open this post in threaded view
|

Re: X server instability... is it mouse event overrun?

asmith-4
Awesome,

Once again the decision to port to other architectures benefits the whole
project :)

- ANdy

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Otto
Moerbeek
Sent: 03 February 2006 11:39
To: Andrew Smith
Cc: 'Matthieu Herrb'; 'OpenBSD Arm Mailing List'
Subject: Re: X server instability... is it mouse event overrun?

On Fri, 3 Feb 2006, Andrew Smith wrote:

> My initial reaction was... you couldn't get this type of problem from
> dropping a single event but am I right in suspecting that the events are
> actually multi-byte data and that by dropping one character we are
actually
> getting misaligned event data in the previous version once we have a
buffer
> full condition? - hence all the bad mouse event messages?

Yes, you're right. On a side note: tot only zaurus was seeing this,
but other arches as well. A similar fix was put in for the other
arches (zaurus uses mouse input handling a bit different from the
other arches). They should all be fixed now.

        -Otto

Reply | Threaded
Open this post in threaded view
|

Re: X server instability... is it mouse event overrun?

asmith-4
Matthieu,

I have been putting this patch through testing over the last couple of days
with my Zaurus in constant saturation and have to say I consider it at this
point pretty 'bullet proof'.

Slight activity on the page file with the Zaurus is enough to cause the
buffer fill condition that previously caused the X server to fail 99% of the
time in a quite ugly fashion.

Over the last day or two I have had a large compilation running in the
background whilst running full xfce4, with AbiWord open, xscreensaver
periodically kicking off xmatrix and all I get when I move the mouse are a
few lost events and the cursor hopping (this is with about 85Mb of page
partition in use) - this is just what I would expect to see on a saturated
machine and gives me confidence that the buffer is now filling and we are
dropping events normally without the previous terminal results.

So I think this patch has nailed the issue and I with my understanding of
what the issue was I can highly recommend that anyone using a Zaurus with X
should put the patch through its paces and assure themselves that they find
the situation better.

I am presuming that you want more feedback from others before you commit
this to the -current CVS since I see that ws.c is still showing 7 months
without an update :P - this also means of course that the patch didn't make
it into the build snapshot of the X components on the 3rd February
distribution (present on the ftp.openbsd.org site).

Since building XF4 from cvs takes a while I was wondering about the
practicality of you releasing a binary patch for testing as I'm sure that
this will assist with getting feedback. I thank you for the module that you
sent me as I had a large build going on when you asked for testing and it
worked like a charm.

I'm not sure if there are any back dependencies in other updated headers
that may cause this to be incompatible in binary form with a -release
version, perhaps you could clarify.

In the meantime I have posted the binary driver and an md5sum for it on the
following thread..

http://www.oesf.org/forums/index.php?showtopic=17259

If folk wish to take my word for it that it is unmodified then please feel
free to download and test (note I have only tested with -current and not
with -release).

If you haven't modified the driver since you sent it to me and if you don't
want to host a binary anywhere else Matthieu could you possibly at least
confirm the md5sum so that people of a 'suspicious nature' can take a little
confidence that I didn't modify it :) - hopefully we can get some more
stability feedback then.

- Andy

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of
Andrew Smith
Sent: 03 February 2006 11:43
To: 'Otto Moerbeek'
Cc: 'Matthieu Herrb'; 'OpenBSD Arm Mailing List'
Subject: Re: X server instability... is it mouse event overrun?

Awesome,

Once again the decision to port to other architectures benefits the whole
project :)

- ANdy

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Otto
Moerbeek
Sent: 03 February 2006 11:39
To: Andrew Smith
Cc: 'Matthieu Herrb'; 'OpenBSD Arm Mailing List'
Subject: Re: X server instability... is it mouse event overrun?

On Fri, 3 Feb 2006, Andrew Smith wrote:

> My initial reaction was... you couldn't get this type of problem from
> dropping a single event but am I right in suspecting that the events are
> actually multi-byte data and that by dropping one character we are
actually
> getting misaligned event data in the previous version once we have a
buffer
> full condition? - hence all the bad mouse event messages?

Yes, you're right. On a side note: tot only zaurus was seeing this,
but other arches as well. A similar fix was put in for the other
arches (zaurus uses mouse input handling a bit different from the
other arches). They should all be fixed now.

        -Otto