Bug 3113

Does this patch fixes the issue for you?

http://www.in-nomine.org/~asmodai/pkgsrc/patch-bl

(It is from a PR in pkgsrc's GNATS regarding DragonFly support.)

I've witnessed the issue on my NetBSD/Xen station, though it would only happen
when under very high load.  Suddenly the pointer would start sticking to the
left side (one time it stuck on the upper side).  I believe this is the same
issue you're experiencing.

This is a regression from 6.8.1 to 6.8.2, the patch named on my URL is reverting
the code back to its 6.8.1 state and all the problems disappear.  Of all people
who had this problem on DragonFly this patch fixed their issue.

I call it a showstopper for 6.8.3 or 6.9 depending on which is first.

Given how annoying this problem is I've bumped it from normal to blocker.
X is simply unworkable without the patch mentioned in comment #1 on NetBSD and
DragonFly.

The same problem exists in OpenBSD-3.7. It has been fixed by making the kernel
correctly save/restore the FPU context during signal handlers. 
There is now a regression test for that in OpenBSD:
<http://www.openbsd.org/cgi-bin/cvsweb.cgi/src/regress/sys/kern/signal/fpsig/>

moving to mouse component, but pretty sure at this point that it's a kernel issue.

I'm experiencing the same issue on linux 2.6.11 patched for XEN 2.0.7, xorg 
6.8.2. 

I had same problem. I restarted X and now my mouse works fine.

I compiled and ran that OpenBSD fpsig.c (with no changes) on NetBSD/i386 2.0.2.
My results:

rainier:~/tmp$ gcc -o fpsig fpsig.c 
rainier:~/tmp$ ./fpsig 
rainier:~/tmp$ time ./fpsig
fpsig: 5700.000000 5146.000000

real    0m8.154s
user    0m6.066s
sys     0m0.007s
rainier:~/tmp$ ./fpsig 
rainier:~/tmp$ time ./fpsig
fpsig: 5700.000000 5392.000000

real    0m6.063s
user    0m6.049s
sys     0m0.005s
ainier:~/tmp$ /usr/bin/time ./fpsig 
        9.09 real         9.03 user         0.00 sys
rainier:~/tmp$ /usr/bin/time ./fpsig
fpsig: 5700.000000 2260.000000
        7.07 real         7.06 user         0.00 sys
rainier:~/tmp$ ./fpsig
rainier:~/tmp$ ./fpsig
rainier:~/tmp$ time ./fpsig

real    0m9.093s
user    0m9.076s
sys     0m0.012s
rainier:~/tmp$ time ./fpsig

real    0m9.091s
user    0m9.058s
sys     0m0.003s
rainier:~/tmp$ 

What am I looking for? As you can see above sometimes it gives output and
sometimes it does not. Nine times I tested without using time and it never had
output.

The fact that you get an output from time to time shows that there is a problem.
The program also exits with a non-zero status to show the failure. 

This test program computes the same floating point value, using variables on the
stack both in the main code path and in a signal handler. 
If signal handlers do correctly save/restore the FPU registers, the results are
unpredictable and will probably not be the same (and are printed). When no
corruption of the FPU, the 2 results are the same and nothing is printed (and
the exit status is 0). 
You can replace 'while (count < 10)' with 'while (count < 1000)' (or bigger) to
run the test for a longer period to make it more "reliable".
In X I found out that running an (unaccelerated) glxgear while moving the mouse
around was a real efficient  way to trigger the bug in 10-20 seconds. Glxgears
gets the X server to do lots of floating point computations (in Mesa). 
Otherwise I could use X for whole days without seeing the bug. 

Since the the FPU context save/restore has been fixed on OpenBSD/i386 no one
reported this bug again.
 

(In reply to comment #7)

> If signal handlers do correctly save/restore the FPU registers, the results are

oops: If signal handlers do *not* correctly ......

I had the problem again today. glxgears could be used within five seconds to
repeat it.

I am now using patch from
http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/x11/xorg-libs/patches/patch-bl?rev=1.1&content-type=text/plain
And now running glxgears with a lot of mouse movement for a few minutes doesn't
trigger the problem.

This was discussed some on the NetBSD' port-i386 list. I was told that NetBSD
3.0 (to be released soon) has changes so the fpsig test works fine there. (I am
using NetBSD 2.0.2 on this system.)

The problem in programs/Xserver/hw/xfree86/common/xf86Xinput.c seems to exist on
four different platforms (as shown in this bug report, but now fixed on newer
OpenBSD and newer NetBSD). Can this be redone to be portable? (No floating point
in signal handler?)

Thanks

Created attachment 4548 [details] [review]
Proposed patch

Dale Rahn found one additional cause that can trigger a similar problem. 
When the input buffer gets full because the machine is too buzy, one byte in
the last event in the buffer is lost, causing corrupted events to be processed.

The attached patch fixes this additional case. 
Note that hurd/hurd_mouse.c has the same bug.

I was having this issue under Gentoo Linux with Xorg 6.8.2, 6.9.0 and 7.0.
I took the changes in comment #9 and applied them successfully to the
xorg-server-1.0.1-r4 gentoo ebuild for 7.0. Recompiled and haven't had the
issue crop up in about 3 hours of use.

This is Linux 2.6.14 with Grsec and PaX patches on an x86. The issue hasn't
occured on the non-grsec/pax Gentoo builds I have with otherwise
same configurations (2.6.14 and Xorg 6.9/7.0) and hardware. Could this be
related to the similar protections grsec/pax provides that are also present in
OpenBSD? Just an uneducated guess based on circumstance.

Thanks for the patch.

*** Bug 5769 has been marked as a duplicate of this bug. ***

So, any ETA of merging this one into HEAD

I have this problem again with xorg-server MAIN on NetBSD/i386 3.99.20.

For NetBSD the patch in attachement  4548 is probably relevant. It was never
commited though. I've done it now. 

Is there another way to cause this problem without glxgears?

This week my mouse has been stuck to left side twice -- but I can't
reproduce on my own -- even with glxgears on this system.

I am not using the latest xserver with latest fix (just used git to retrieve this).

I want to be able to test this before and after. Any ideas on how I can
reproduce the bug?

For the bug fixed by attachment 4548 [details] [review], getting the machine to swap heavily and
then moviing the mouse for a few seconds was enough to trigger the buffer full
condition. 

On NetBSD -current, I am able to cause the cursor to be stuck on left side by
attempting to start up 100 firefox processes while using some Xorg built in April.

Using the Xorg with latest bsd_mouse.c fix (git and built on June 10), I can not
repeat the problem. It appears to be fixed for me. Thanks!

The problem happened to me again last night. First time since June 12.

(In reply to comment #19)
> The problem happened to me again last night. First time since June 12.

Not that i'm too deep into it, so just some blahblah: A fix (attachment 4548 [details] [review])
depending on just changing evalution order (or am I missing something?) is a big
fat sign there is something more subtle going on. The patch might be solely an
improvement, so proper synchronization might be the cure here. Assuming the
patch actually is an improvement.

Occurs in FC6 with xorg-x11-* packages updated to latest 
NVidia drivers installed on AMD dual core with MS Wireless Natural KB and
Intellimouse 2.0

Created attachment 11245 [details] [review]
proposed patch 2

From Otto Moerbeeck <otto@openbsd.org>:

A high resolution device that's moving fast can potentially generate
an int overflow, making dx*dx+dy*dy negative. Now pow(negative,
non-integer) yields NaN, so you loose.  Use fp math to avoid that.

Committed to master: 12d27cf33c6d963eae77795c0d247175907162a5

Cherry-picked to server-1.4.

*** Bug 13010 has been marked as a duplicate of this bug. ***

*** Bug 13107 has been marked as a duplicate of this bug. ***

I have confirmed that on NetBSD current, IBM X31 thinkpad laptop, with NetBSD kernel of:

$ uname -a
NetBSD garlique.algebras.org 4.99.37 NetBSD 4.99.37 (GGM_ACPI) #0: Mon Nov 26 11:28:19 EST 2007  ggm@garlique.algebras.org:/data/Build/obj/usr/src/sys/arch/i386/compile/GGM_ACPI i386
$

and with modular xorg server 1.4, and xf86-input-mouse of 1.2.2 I *still* have this problem. Both of the patches above are demonstrably in the Xorg code, so, I think the comment that they are (at best) remediation, and some underlying problem still exists is true.

I have also confirmed the problem exists with openbsd-input-ws in this config.

I re-opened. But, I would acknowledge its arguably a corner-case, and may be confined to my situation. If somebody else says they see this, especially on another BSD, I'd tend to ask the bug be considered still open.

cheers

-George

The fix was pushed in August as 12d27c.