Bug 294011 (xen-mouse-stuck-left)

Just to be sure, attach please to this bug report /etc/X11/xorg.conf and
/var/log/Xorg.0.log as separate uncompressed attachments.

However, I am afraid this is more vnc problem.

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

After consultation with RH people, it seems to be more libvirt problem. Guys, do
you have any ideas, what's going on here (and in bug 242737, which is from vnc
maintainer)?

Got the problem reproduce under gdb. Added a breakpoint on the mouse 
acceleration code where movement is above the configured threshold:

(gdb) c
Continuing.

Breakpoint 6, xf86PostMotionEvent (device=0x84daec8, is_absolute=0, 
first_valuator=0, num_valuators=2) at xf86Xinput.c:941
941                                 local->dxremaind = ((float)dx * (float)
(device->ptrfeed->ctrl.num)) /
(gdb) list
936                      */
937                     if (device->ptrfeed && device->ptrfeed->ctrl.num) {
938                         /* modeled from xf86Events.c */
939                         if (device->ptrfeed->ctrl.threshold) {
940                             if ((abs(dx) + abs(dy)) >= 
device->ptrfeed->ctrl.threshold) {
941                                 local->dxremaind = ((float)dx * (float)
(device->ptrfeed->ctrl.num)) /
942                                     (float)(device->ptrfeed->ctrl.den) + 
local->dxremaind;
943                                 valuator[0] = (int)local->dxremaind;
944                                 local->dxremaind = local->dxremaind - 
(float)valuator[0];
945
(gdb) p local->dxremaind
$10 = -nan(0x400000)
(gdb) p local->dyremaind
$11 = 0


Somehow local->dxremaind becomes -NaN.


I have added a watch on local->dxremaind, and I got when the NaN value was 
set:

(gdb) c
Continuing.
Hardware watchpoint 3: ((struct _LocalDeviceRec *) 137218624)->dxremaind

Old value = 0
New value = -nan(0x400000)
Hardware watchpoint 6: ((struct _LocalDeviceRec *) 137218624)->dxremaind

Old value = 0
New value = -nan(0x400000)
xf86PostMotionEvent (device=0x82dcec8, is_absolute=0, first_valuator=0, 
num_valuators=2) at xf86Xinput.c:946
946                                 local->dyremaind = ((float)dy * (float)
(device->ptrfeed->ctrl.num)) /
4: ((struct _LocalDeviceRec *) device->public.devicePrivate)->dxremaind 
= -nan(0x400000)
2: device = (DeviceIntPtr) 0x82dcec8
1: device->public.devicePrivate = (pointer) 0x82dca40
(gdb) list
941                                 local->dxremaind = ((float)dx * (float)
(device->ptrfeed->ctrl.num)) /
942                                     (float)(device->ptrfeed->ctrl.den) + 
local->dxremaind;
943                                 valuator[0] = (int)local->dxremaind;
944                                 local->dxremaind = local->dxremaind - 
(float)valuator[0];
945
946                                 local->dyremaind = ((float)dy * (float)
(device->ptrfeed->ctrl.num)) /
947                                     (float)(device->ptrfeed->ctrl.den) + 
local->dyremaind;
948                                 valuator[1] = (int)local->dyremaind;
949                                 local->dyremaind = local->dyremaind - 
(float)valuator[1];
950                             }
(gdb) bt
#0  xf86PostMotionEvent (device=0x82dcec8, is_absolute=0, first_valuator=0, 
num_valuators=2) at xf86Xinput.c:946
#1  0x00129570 in ?? () from /usr/lib/xorg/modules/input//mouse_drv.so
#2  0x00129c0a in ?? () from /usr/lib/xorg/modules/input//mouse_drv.so
#3  0x0012a10b in ?? () from /usr/lib/xorg/modules/input//mouse_drv.so
#4  0x080d499a in xf86SigioReadInput (fd=7, closure=0x82dca40) at 
xf86Events.c:1212
#5  0x080b3821 in xf86SIGIO (sig=29) at ../shared/sigio.c:113
#6  <signal handler called>

The bug is getting interesting: I have added a breakpoint on xf86Xinput.c:941 
with condition 'dx<-1000||dx>1000', and the condition was never met while I 
was reproducing the bug.

While reproducing the bug, a watchpoint on local->dxremaind was never hit, 
until local->dxremaind became -nan(0x400000). Before that, local->dxremaind 
was 0.

Here is the relevant code:

 local->dxremaind = ((float)dx * (float)(device->ptrfeed->ctrl.num)) /
     (float)(device->ptrfeed->ctrl.den) + local->dxremaind;
 valuator[0] = (int)local->dxremaind;
 local->dxremaind = local->dxremaind - (float)valuator[0];

device->ptrfeed->ctrl.num is always 2, device->ptrfeed->ctrl.den is always 1.

dx is an int.

If dxremaind is 0, it doesn't seem to be mathematically possible to get NaN if 
dx is never larger than 1000 or smaller than -1000. So I believe this is a bug 
on either compiler, kernel, or processor. I bet on kernel-xen.

Created attachment 198581 [details]
Test program to reproduce the bug

I have managed to reproduce the floating-point bug outside the X server.

Run the test program attached, and create a new full-virt guest (as in the
description of this bug). Approximatedly half of the time the test program
begin to spit "nan" right after the guest is initialized. No need to move the
mouse while testing, anymore.

It is really not a Xorg bug.

Changing component to kernel-xen, as it is likely a kernel-xen bug when 
restoring floating point state.

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

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

I have noticed the i386 sleazy-fpu patch that was introduced on 2.6.20 
introduces the problem.

I thought the problem was that math_state_restore() doesn't call clts() under 
Xen (that is expected when handling the device_not_available trap, under Xen). 
However, the problem persistedwith clts() on math_state_restore() (when called 
from switch_to()).

When using the xen-3.1.1-rc1 hypervisor, however, the problem was solved.

We have two problems that need to be fixed:

a) Hypervisor FPU restoring bug under HVM (fixed on xen-3.1.1). The problem 
that this bug is about.
b) sleazy-fpu needs clts() to be called on math_state_restore() (it doesn't 
cause visible problems, but it causes the kernel to trap itself when trying to 
restore math state on switch_to())

Found fix on xen-3.1.1-rc1:
http://xenbits.xensource.com/xen-3.1-testing.hg?rev/8c24767501ff

kernel-xen-2.6.21-2942.fc8 looks fine. I don't see any mouse problems

kernel-xen-2.6-2.6.20-2936.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.

kernel-xen-2.6-2.6.20-2936.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.