Bug#647136: linux-image-2.6.32-5-amd64: psmouse.c bad data from KBD bad parity

[Jonathan Nieder <jrnieder@gmail.com>]

Arvind K wrote:

> -By modprobe psmouse I meant that, whenever the touchpad stops working, I
> have to run the following:
> $sudo modprobe -r psmouse
> $sudo modprobe psmouse

I see.

[...]
> [36521.371269] psmouse.c: bad data from KBC - bad parity
> [36521.373636] psmouse.c: bad data from KBC - bad parity
[... and so on, once every 2ms or so ...]

Yep, that sounds broken. :)

[...]
> [36552.047333] psmouse.c: bad data from KBC - bad parity
> [36556.015679] Synaptics Touchpad, model: 1, fw: 7.2, id: 0x1c0b1, caps: 0xd04731/0xa40000/0xa0000
> [36556.058547] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio4/input/input13

I assume this is when you unloaded and reloaded the driver.

It would also be interesting to see the initialization sequence (i.e.,
"dmesg" output from bootup) when nothing is going wrong.  The log you
sent is abridged at the beginning because the parity errors flooded
the log.

What version of gsynaptics are you using?  Based on [1], it seems that
gsynaptics does not work with a modern X server (though that is no
excuse to provoke parity errors like this).  Michal, any hints about
what gsynaptics could have been doing to provoke this (e.g., a simpler
command to simulate what it does)?

It would also still be interesting to see what a recent (3.x) kernel
does.  I have a vague suspicion that v2.6.34-rc7~22^2~8 (Input:
psmouse - ignore parity error for basic protocols, 2010-04-19) or some
similar fix could have changed the behavior here.