mouse problems in 2.4.2

mouse problems in 2.4.2

[linas]

Hi,

I am experiencing debilitating intermittent mouse problems & was about 
to dive into the kernel to see if I could debug it.  But first, I thought
a quick note to the mailing list may help.

Symptoms:
After a long time of flawless operation (ranging from nearly a week to 
as little as five minutes), the X11 pointer flies up to top-right corner, 
and mostly wants to stay there.  Moving the mouse causes a cascade of 
spurious button-press events get generated.

This did not occur with 2.4.0test2 or 2.2.16 (to the best of my
recollection) and first showed up in 2.4.0test7 or 2.4.1 (not sure).
With 2.4.2, the symptoms seem slightly different (almost all pointer
movement events seem to be lost; although spurious button-press events
still happen).

Mouse is a logitech trackman marble, with USB connector to
logitech-supplied USB to ps/2 DIN plug.  Configured as a PS/2 mouse.
Motherboard is a Athalon/VIA Apollo KA7.

Unplugging mouse for 10 seconds sometimes fixes the problem on the sixth
try, sometimes. 

Switching to virtual terminal running gpm, and back to X11 used to fix
the problem, sometimes, after some magic incantations, unplugging,
starting gpm, moving mouse, etc.  This no longer does the trick w/
2.4.2.

Rebooting X11 frequently, but not always, fixed the problem.

The *only* sure-fire fix is to reboot the system. 

Sometimes, the mouse seemed usable with gpm even as it wasn't with X11;
sometimes it had the same bad behaviour (scooting to the corner,
spurious button-press) even under gpm.

Changing mouse protocols to imps2 from ps2 in gpm/X11 seems to make no
difference.

Disabling power management in kernel and bios to various degrees (including 
disabling *all* power management) doesn't seem to fix anything.  (It
was suggested to me that this was an APM bug; indeed, an early
manifestation of the bug seemed to be that it triggered if/when I moved
the mouse just as the video-powersave triggered. )

Sometimes, the problem seems to be associated with moving the mouse
during CPU-intensive or disk-i/o intensive operations (e.g. a large 
file copy, compile; or system activity during mp3 playing) Lost
interrupt?

On rare ocasions, its associated with system lockup.  (specifically,
some keyboard buffer seems to fill up, and everything seems hung,  
not even ctrl-alt-del works).  (I haven't checked to see if I can 
still telnet in). 

I've been living with this problem for 6+ months, and it is getting to
be infuriating.  As you can see above, all sorts of different attempts
above make subtle variations in the symptoms, but no fixes.  

I conclude that this is probably a hardware (motherboard chipset)
bug, that its rare (google/deja  searches are unfruitful) and that 
the only place to hunt is in the kernel. 

---------------
So: any advice, comments, suggestions before I embark on a long and
possibly fruitless hunt?  Any recommendations for best tools/proceedures
to catch it 'in the act'?  

--linas

p.s. direct replies to linas@linas.org appreciated.

Re: mouse problems in 2.4.2

[Stephen Satchell]

I'm experiencing the same thing with an ASUS P5A-B running a K6-2/266 with 
Linux 2.2.17, and Windows 98.   Central problem appears to be the KVM 
switch I'm using. Save yourself the problem.

I had to reboot all the systems to get regular mouse operation back with 
the Logitech.

Satch


At 04:33 PM 3/25/01 -0600, you wrote:
>I am experiencing debilitating intermittent mouse problems & was about
>to dive into the kernel to see if I could debug it.  But first, I thought
>a quick note to the mailing list may help.
>
>Symptoms:
>After a long time of flawless operation (ranging from nearly a week to
>as little as five minutes), the X11 pointer flies up to top-right corner,
>and mostly wants to stay there.  Moving the mouse causes a cascade of
>spurious button-press events get generated.
>
>This did not occur with 2.4.0test2 or 2.2.16 (to the best of my
>recollection) and first showed up in 2.4.0test7 or 2.4.1 (not sure).
>With 2.4.2, the symptoms seem slightly different (almost all pointer
>movement events seem to be lost; although spurious button-press events
>still happen).
>
>Mouse is a logitech trackman marble, with USB connector to
>logitech-supplied USB to ps/2 DIN plug.  Configured as a PS/2 mouse.
>Motherboard is a Athalon/VIA Apollo KA7.

Re: mouse problems in 2.4.2

[Keith Owens]

On Sun, 25 Mar 2001 16:27:37 -0800, 
Stephen Satchell <satch@fluent-access.com> wrote:
>I'm experiencing the same thing with an ASUS P5A-B running a K6-2/266 with 
>Linux 2.2.17, and Windows 98.   Central problem appears to be the KVM 
>switch I'm using. Save yourself the problem.
>
>I had to reboot all the systems to get regular mouse operation back with 
>the Logitech.

I sometimes have keyboard and mouse problems after changing machines
using a mechanical KVM, on a Logitech mouse.  This script fixes it for
me.

/usr/local/bin/switched

#!/bin/sh
/etc/rc.d/init.d/gpm restart
/sbin/kbdrate -r 30

I run gpm in redirect -R mode as
  daemon gpm -t $MOUSETYPE -R -m /dev/ttyS0
and tell X11 to read from /dev/gpmdata as
   Protocol        "MouseSystems"
   Device          "/dev/gpmdata"
not directly from the mouse; the redirect protocol is always
MouseSystems, no matter what the underlying mouse type is.  Restarting
gpm after KVM switch then fixes everything else.

Re: mouse problems in 2.4.2

[linas]

It's been rumoured that Stephen Satchell said:
> 
> I'm experiencing the same thing 
[...]
>  Central problem appears to be the KVM 
> switch I'm using. Save yourself the problem.

Am not using a KVM switch, or any cable extenders, etc.  The USB-to-PS2
connecter came with the mouse, so I assume its OK ... Besides, the
symptoms don't point at the connector.

--linas

Re: mouse problems in 2.4.2 -> lost byte

[Gunther Mayer]

[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]

linas@linas.org wrote:

> 
> I am experiencing debilitating intermittent mouse problems & was about
...
> Symptoms:
> After a long time of flawless operation (ranging from nearly a week to
> as little as five minutes), the X11 pointer flies up to top-right corner,
                                                          ^^^^^^^^^^^^^^^^
> and mostly wants to stay there.  Moving the mouse causes a cascade of
> spurious button-press events get generated.

This is easily explained: some byte of the mouse protocol was lost.
(Some mouse protocols are even designed to allow
 easy resync/recovery by fixed bit patterns!)

Write an intelligent mouse driver for XFree86 to compensate for
lost bytes. 

Regards, Gunther

APPENDIX
========

Output ot litte test program:
> a.out
Simulating 1 lost byte
    1 -- ff 00 08 ---   -256 : -248   Buttons=MRL Overflow/errors:XY 
    2 -- 00 04 08 ---      4 :    8   Buttons=    Overflow/errors:  T
    3 -- 00 04 08 ---      4 :    8   Buttons=    Overflow/errors:  T
    4 -- 00 03 08 ---      3 :    8   Buttons=    Overflow/errors:  T
    5 -- 00 03 18 ---      3 :   24   Buttons=    Overflow/errors:  T
    6 -- ff 02 08 ---   -254 : -248   Buttons=MRL Overflow/errors:XY 
    7 -- 00 02 08 ---      2 :    8   Buttons=    Overflow/errors:  T
    8 -- 00 03 18 ---      3 :   24   Buttons=    Overflow/errors:  T
    9 -- ff 03 18 ---   -253 : -232   Buttons=MRL Overflow/errors:XY 
   10 -- ff 03 08 ---   -253 : -248   Buttons=MRL Overflow/errors:XY 
...

Probably XFree ignores data packets with XY overflow set. All other
packets move you to top-right corner.

Moving your mouse will quickly show button mania, as described by your post.

[-- Attachment #2: gm_psauxprint.c --]
[-- Type: application/octet-stream, Size: 771 bytes --]

// show effects of lost bytes on ps/2 mouse protocol 
#include <stdio.h>
#include <errno.h>
int main(void)
{ 
	FILE *f;
	int i=0,x,a,y, xo,yo,xs,ys,r,m,l,t,dx,dy;

	f=fopen("/dev/psaux","r");
	if(f==NULL) strerror(errno);

 //printf("Simulating 2 lost bytes\n");
 //a=fgetc(f); a=fgetc(f);

 printf("Simulating 1 lost byte\n");
 a=fgetc(f);
	while (1) {
		a=fgetc(f);
		x=fgetc(f);
		y=fgetc(f);
		i++;
		printf("%5d -- %02x %02x %02x",i,a,x,y);

		yo=a&0x80;
		xo=a&0x40;
		ys=a&0x20;
		xs=a&0x10;
		t=a&0x08;
		m=a&0x04;
		r=a&0x02;
		l=a&0x01;

		dx=x;
		dy=y;
		if(xs) dx=x-256;
		if(ys) dy=y-256;
		printf(" ---   %4d : %4d   Buttons=%s%s%s Overflow/errors:%s%s%s\n",
			dx,dy,m?"M":" ", r?"R":" ", l?"L":" ",
			xo?"X":" ", yo?"Y":" ", t?" ":"T");
	}
	return 0;
}	

Re: mouse problems in 2.4.2 -> lost byte

[linas]

It's been rumoured that Gunther Mayer said:
> 
> > I am experiencing debilitating intermittent mouse problems & was about
> ...
> > Symptoms:
> > After a long time of flawless operation (ranging from nearly a week to
> > as little as five minutes), the X11 pointer flies up to top-right corner,
>                                                           ^^^^^^^^^^^^^^^^
> > and mostly wants to stay there.  Moving the mouse causes a cascade of
> > spurious button-press events get generated.
> 
> This is easily explained: some byte of the mouse protocol was lost.

Bing!

That's it! This would also explain why gpm seems to work i.e. correctly
process the events, even when X11 can't.  I will take this up on the
Xf86 lists ...

> (Some mouse protocols are even designed to allow
>  easy resync/recovery by fixed bit patterns!)

This mouse seems to set every fourth byte to zero, which should allow
syncing ...  
I'm still investigating to see if the kernel buffer is overflowing ...


--linas

Re: mouse problems in 2.4.2 -> lost byte

[Gunther Mayer]

linas@linas.org wrote:
> 
> It's been rumoured that Gunther Mayer said:
> >
> > > I am experiencing debilitating intermittent mouse problems & was about
> > ...
> > > Symptoms:
> > > After a long time of flawless operation (ranging from nearly a week to
> > > as little as five minutes), the X11 pointer flies up to top-right corner,
> >                                                           ^^^^^^^^^^^^^^^^
> > > and mostly wants to stay there.  Moving the mouse causes a cascade of
> > > spurious button-press events get generated.
> >
> > This is easily explained: some byte of the mouse protocol was lost.
> 
> Bing!
> 
> That's it! This would also explain why gpm seems to work i.e. correctly
> process the events, even when X11 can't.  I will take this up on the
> Xf86 lists ...
> 
> > (Some mouse protocols are even designed to allow
> >  easy resync/recovery by fixed bit patterns!)
> 
> This mouse seems to set every fourth byte to zero, which should allow
> syncing ...

The fourth byte is propably the wheel or 5 button support, see
http://www.microsoft.com/hwdev/input/5b_wheel.htm
to get a hint about mouse protocol variations.

Getting resync right is not as easy as detecting zero bytes. You
should account for wild protocol variations in the world wide mouse
population, too.

Re: mouse problems in 2.4.2 -> lost byte

[Vojtech Pavlik]

On Wed, Mar 28, 2001 at 08:31:52PM +0200, Gunther Mayer wrote:
> linas@linas.org wrote:
> > 
> > It's been rumoured that Gunther Mayer said:
> > >
> > > > I am experiencing debilitating intermittent mouse problems & was about
> > > ...
> > > > Symptoms:
> > > > After a long time of flawless operation (ranging from nearly a week to
> > > > as little as five minutes), the X11 pointer flies up to top-right corner,
> > >                                                           ^^^^^^^^^^^^^^^^
> > > > and mostly wants to stay there.  Moving the mouse causes a cascade of
> > > > spurious button-press events get generated.
> > >
> > > This is easily explained: some byte of the mouse protocol was lost.
> > 
> > Bing!
> > 
> > That's it! This would also explain why gpm seems to work i.e. correctly
> > process the events, even when X11 can't.  I will take this up on the
> > Xf86 lists ...
> > 
> > > (Some mouse protocols are even designed to allow
> > >  easy resync/recovery by fixed bit patterns!)
> > 
> > This mouse seems to set every fourth byte to zero, which should allow
> > syncing ...
> 
> The fourth byte is propably the wheel or 5 button support, see
> http://www.microsoft.com/hwdev/input/5b_wheel.htm
> to get a hint about mouse protocol variations.
> 
> Getting resync right is not as easy as detecting zero bytes. You
> should account for wild protocol variations in the world wide mouse
> population, too.

The new input psmouse driver can resync when bytes are lost and also
shouldn't lose any bytes if there are not transmission problems on the
wire. But this is 2.5 stuff.

-- 
Vojtech Pavlik
SuSE Labs

Re: mouse problems in 2.4.2 -> lost byte

[linas]

It's been rumoured that Vojtech Pavlik said:
> On Wed, Mar 28, 2001 at 08:31:52PM +0200, Gunther Mayer wrote:
> > linas@linas.org wrote:
> > > It's been rumoured that Gunther Mayer said:
> > > > linas@linas.org wrote:
> > > > > 
> > > > > I am experiencing debilitating intermittent mouse problems & was about
> > > >
> > > > This is easily explained: some byte of the mouse protocol was lost.
> > > 
> > Getting resync right is not as easy as detecting zero bytes. You
> > should account for wild protocol variations in the world wide mouse
> > population, too.
> 
> The new input psmouse driver can resync when bytes are lost and also
> shouldn't lose any bytes if there are not transmission problems on the
> wire. But this is 2.5 stuff.

umm linux kernel 2.5? Umm, given that a stable linux 2.6/3.0 might be
years away ... and this seems 'minor', wouldn't it be better to 
submit this as a teeny-weeny new kind of mouse device driver as a 2.4.x
patch?  e.g. CONFIG_MOUSE_PSAUX_SUPERSYNC or something?   I mean this
cant be more than a few hundred lines of code? Requireing no other
changes to the kernel?

--linas

Re: mouse problems in 2.4.2 -> lost byte

[Vojtech Pavlik]

On Wed, Mar 28, 2001 at 05:19:33PM -0600, linas@linas.org wrote:
> It's been rumoured that Vojtech Pavlik said:
> > On Wed, Mar 28, 2001 at 08:31:52PM +0200, Gunther Mayer wrote:
> > > linas@linas.org wrote:
> > > > It's been rumoured that Gunther Mayer said:
> > > > > linas@linas.org wrote:
> > > > > > 
> > > > > > I am experiencing debilitating intermittent mouse problems & was about
> > > > >
> > > > > This is easily explained: some byte of the mouse protocol was lost.
> > > > 
> > > Getting resync right is not as easy as detecting zero bytes. You
> > > should account for wild protocol variations in the world wide mouse
> > > population, too.
> > 
> > The new input psmouse driver can resync when bytes are lost and also
> > shouldn't lose any bytes if there are not transmission problems on the
> > wire. But this is 2.5 stuff.
> 
> umm linux kernel 2.5? Umm, given that a stable linux 2.6/3.0 might be
> years away ... and this seems 'minor', wouldn't it be better to 
> submit this as a teeny-weeny new kind of mouse device driver as a 2.4.x
> patch?  e.g. CONFIG_MOUSE_PSAUX_SUPERSYNC or something?   I mean this
> cant be more than a few hundred lines of code? Requireing no other
> changes to the kernel?

To work correctly, this requires to kill the current psaux and keyboard
driver, and those two are one file, and are very very builtin into the
console system.

Thus it's a patch of almost thousand lines to pc_keyb.c and keyboard.c
and can't easily added as a CONFIG_ option.

Plus, it's very likely the new PS/2 code will break on some systems that
have not-so-compatible i8042 chips, so it is really something that can't
go in 2.4. And I would love to have it in 2.4, really.

-- 
Vojtech Pavlik
SuSE Labs

Re: mouse problems in 2.4.2 -> lost byte -> Patch(2.4.3)!

[Gunther Mayer]

[-- Attachment #1: Type: text/plain, Size: 3102 bytes --]


Original Problem: PS/2 mouse pointer goes upper right corner and stays there.
Diagnosis: one byte was lost and this is fatal for the mouse driver.

Various people wrote:
> 
> On Wed, Mar 28, 2001 at 05:19:33PM -0600, linas@linas.org wrote:
..
> > > > > > > I am experiencing debilitating intermittent mouse problems & was about
> > > > > >
> > > > > > This is easily explained: some byte of the mouse protocol was lost.
> 
> Plus, it's very likely the new PS/2 code will break on some systems that
> have not-so-compatible i8042 chips, so it is really something that can't


Losing bytes on psaux is a bug!

We must first understand, how bytes can be lost (most probable first):
- transmission error on the line can easily happen in noisy environments
   and is _not_ handled correctly by linux (i.e. should do RESEND)
- 0xAA is always handled as reconnect, if the mouse generates this byte,
   Linux will de-sync the mouse driver
- Mouse is defective or keyboard controller defective
- An error in the linux kbd/mouse driver (e.g. triggered by X11<->console switching)

This patch printk's necessary information on the first 2 cases and
should be applied to the stable kernel, as this will help to resolve a severe bug !

Regards, Gunther

P.S.
These messages can be generated:
Apr  8 21:49:23 linux kernel: psaux: reconnect 0xAA detected
Apr  8 21:49:42 linux kernel: pc_keyb: mouse error (0x75), byte ignored(ff).
Apr  8 21:49:43 linux kernel: psaux: reconnect 0xAA detected


--- linux-2.4.3-orig/drivers/char/pc_keyb.c     Wed Apr  4 19:46:42 2001
+++ linux/drivers/char/pc_keyb.c        Sun Apr  8 21:45:37 2001
@@ -404,6 +404,11 @@
                mouse_reply_expected = 0;
        }
        else if(scancode == AUX_RECONNECT){
+               // Under normal operation most mice don't generate 0xAA.
+               // But, Other devices might be unusable with this policy.
+               //  (My mouse easily generates 0xAAs on rapid movements,
+               //   when set to 10 samples/sec.)
+               printk("psaux: reconnect detected(0xaa), sending AUX_ENABLE.\n");
                queue->head = queue->tail = 0;  /* Flush input queue */
                __aux_write_ack(AUX_ENABLE_DEV);  /* ping the mouse :) */
                return;
@@ -420,6 +425,9 @@
                        kill_fasync(&queue->fasync, SIGIO, POLL_IN);
                        wake_up_interruptible(&queue->proc_list);
                }
+               else
+                       // 2K buffer is enough for about 10 sec under normal operations, here.
+                       printk("psaux: buffer overflow, byte dropped.\n");
        }
 #endif
 }
@@ -465,6 +473,11 @@
                        else
                                handle_keyboard_event(scancode);
                }
+               else
+                       // Fixme: Ignoring bytes will de-sync mouse protocol.
+                       printk("pc_keyb: %s error (0x%02x), byte ignored(%02x).\n",
+                       (status & KBD_STAT_MOUSE_OBF)?"mouse":"kbd",status,scancode);
+
 
                status = kbd_read_status();
        }

[-- Attachment #2: gmdiff-lx243-psaux-error-reporting --]
[-- Type: application/octet-stream, Size: 1218 bytes --]

--- linux-2.4.3-orig/drivers/char/pc_keyb.c	Wed Apr  4 19:46:42 2001
+++ linux/drivers/char/pc_keyb.c	Sun Apr  8 21:45:37 2001
@@ -404,6 +404,11 @@
 		mouse_reply_expected = 0;
 	}
 	else if(scancode == AUX_RECONNECT){
+		// Under normal operation most mice don't generate 0xAA.
+		// But, Other devices might be unusable with this policy.
+		//  (My mouse easily generates 0xAAs on rapid movements,
+		//   when set to 10 samples/sec.)
+		printk("psaux: reconnect detected(0xaa), sending AUX_ENABLE.\n");
 		queue->head = queue->tail = 0;  /* Flush input queue */
 		__aux_write_ack(AUX_ENABLE_DEV);  /* ping the mouse :) */
 		return;
@@ -420,6 +425,9 @@
 			kill_fasync(&queue->fasync, SIGIO, POLL_IN);
 			wake_up_interruptible(&queue->proc_list);
 		}
+		else
+			// 2K buffer is enough for about 10 sec under normal operations, here.
+			printk("psaux: buffer overflow, byte dropped.\n");
 	}
 #endif
 }
@@ -465,6 +473,11 @@
 			else
 				handle_keyboard_event(scancode);
 		}
+		else
+			// Fixme: Ignoring bytes will de-sync mouse protocol.
+			printk("pc_keyb: %s error (0x%02x), byte ignored(%02x).\n",
+			(status & KBD_STAT_MOUSE_OBF)?"mouse":"kbd",status,scancode);
+
 
 		status = kbd_read_status();
 	}