>  Is there considerable reason? compiler bug? hardware bug? race condition of
> kernel threads?

I've seen time jumping backwards on sparc64 too. Others blamed it on
missing clock interrupts and suggested we should avoid depending on accurate
hardclock interrupts and instead rely on CPU cycle counters where available.

Anyway, to miss a clock tick interrupts need to be blocked for more than
1/hz seconds - which is not good (TM).

>  It still occurs.

Yes, but only the (smaller) positive delays. This probably means your
pms input interrupt is delayed (i.e. blocked by something else) very long,
which fits into the picture painted above.

> [solved by increasing threshold]

If I understood you correctly this happens only under extreme load?
I think we are fighting symptoms here, not curing the desease.

We could either (a) make the threshold a config file option or (b) add a
config file option to completely disable the automatic resets. Maybe we
should do both.

Anyway, if your system blocks (most/all) interrupts for such a long time,
you are in trouble with or without working mouse driver.

Any ideas what would be blocking the interrupts?
Anyone have any ideas how to (easily) spot the culprit?

Martin