Bug#379480: X Key/Mouse Freeze might be time/clock based

[hendrik@topoi.pooq.com]

On Sat, Sep 30, 2006 at 11:23:47PM -0400, hendrik@topoi.pooq.com wrote:
> On Sat, Sep 30, 2006 at 03:34:48PM -0600, Berg, Michael wrote:
> > 
> > So I started really looking into time-based triggers.  During my
> > troubleshooting experiments, I found that if the system clock is adjusted
> > even a few seconds backward, X input will freeze up a few seconds later.
> > 
> > For example:
> > 1. Make sure any NTP software is turned off (since we want to know what
> > changes are being made to the clock).
> 
> It's chrony I'm using, which, I believe, doesn't set the clock backward, 
> but adjusts the speed of the clock instead.  Maybe that has the same 
> effect as adusting it more often, hence minutes instead of months?

I uninstalled chrony, and do not have ntp installed, and I rebooted 
before the test just to make sure it was really gone.

> > 2. Execute the date command and then adjust the time back slightly (about 2
> > minutes backward is used in this example).
> > 
> >   # date
> >   Sat Sep 30 15:02:22 MDT 2006
> > 
> >   # date -s 'Sat Sep 30 15:00:00 MDT 2006'
> > 
> > Every time I tried this, X keyboard and mouse input would freeze up a few
> > seconds later.  Desktop applets like the system clock, CPU monitor, network
> > activity, etc would all still be actively displaying (so the screen is
> > still updating), but I would be unable to mouse between windows, hot-key
> > between windows, type into the currently focused xterm, Ctrl-Alt-backspace
> > to kill X, or Ctrl-Alt-F2 to a terminal window.
> 
> Regulas ASCII keyboard characters still work oafter a freeze -- if I 
> happen to be in a shell at the time the mouse freezes, I can still go on
> merrily entering commands.  But I'd better not try to start any commands 
> that create windows!

I tried this test, set the time back about two minutes.

It did indeed freeze after minute or so.  The system clock froze too, 
which is different from your experience.

The test is not conclusive, though.  I performed it on the second 
reboot.  On the first reboot, the system froze within a second of 
starting icewm, without any clock setting (and ssh'ing in did not work 
at all -- no route to host any more).  So the clock-set freeze may 
just be coincidence.

-- hendrik