Created attachment 336650 [details] sosreport-jivenasisw8rhel.237319-138378-334cee.tar.bz2 Description of problem: Several users complain that their desktop HP DC5850 with RHEL4/SLC4 in 32bit, smp kernel regularly leaves the X11 mouse cursor stuck near the left edge of the X11 screen - it will move briefly right, then jump back to the edge. So far this has only been reported for horizontal movements. (see 216697 for details on the hardware) We have found that "xset m 5 100" inside the X11 session is a workaround, both preventive and applied after the mouse becomes stuck. So this appears as if the X coordinate delta overflows with acceleration, once some other (unknown) condition has been met. How reproducible: Difficult: mouse is fine after boot, issue takes several minutes to appear (or hours). Possibly linked to ongoing network activity.. Our "reproducer" involves twiddling the mouse horizontally while running "wget" in a loop. [I don't think this will be reproducible at Red Hat.]. Once the error condition has been met, it will stay (no further network traffic required). Additional info: The hardware had issues with the system clock running at double speed (workaround), this could be another timer issue (i.e. sample two mouse events too "closely" together in time, calculate delta that overflows, X11 goes bad whenever acceleration is used afterwards?), or could be linked to interrupt handling (c.f. "network" relationship, perhaps missing some interrupts leads to the mouse reporting enormous values?). We have run a simple gettimeofday() loop to see whether time would run backwards - apparently not the case. * workaround: We would like help with making the above "xset" setting permanent for all users on a machine (didn't find anything on how to configure this in xorg.conf), relying on individual users' .xinitrc/GNOME/KDE does not scale and is difficult to apply for users moving between machines. * We would also like some help in getting more data once the error condition has been triggered - what could/should we watch, are there X11 debugging tools that would allow to pinpoint where the error condition comes from (X11/kernel psmouse driver/IRQ handling)? Issue has been seen with PS2 and USB mice (different brands) - most likely not related to the exact model used. SEG Notes: As I understand it, this has been a long standing known problem in the X mouse code and it's been open for years. The cause for this has been because of floating point overflows. The patch I've found may or may not fix the problem. There's been some work done on this problem upstream over the last year because of an increasing number of complaints and it's required a revamping of the code. patch for this The report came in from the xorg mailing list. xf86Xinput.c.patch-accel has the reference: "I received an off-list email pointing me to NetBSD PR 30418 (fixed by NetBSD's pkgsrc/xorg-libs/patches/patch-bl). This NetBSD PR led me to xorg bug #3113 which says "the mouse pointer will reset itself to the left side of the screen. Unless I move the pointer very slowly, it will keep going back to the left edge of the screen." "
Created attachment 336651 [details] xorg-x11-server.1.1.1-mouseaccel-overflow2.patch
Created attachment 336652 [details] xf86Xinput.c.patch-accel
This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?".
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.