Bug#379480: X Key/Mouse Freeze might be time/clock based
Several of my friends and I have been having similar problems - X
keyboard/mouse input occasionally freezing.
The problem has been encountered on both i386 and AMD64 systems, with both
nvidia and ati video cards, with both free and proprietary drivers.
The interesting thing is that most of our systems would "freeze" at almost
the exact same time each time it happened (once every few months). It
happened again today, and three of our systems (in various locations around
the city and state) all froze up during the same 1-2 minute period.
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).
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.
ssh'ing in from another computer and then stopping gdm and/or X would allow
me to recover, restart X and run other test scenarios.
Can those of you who are also having this problem try the clock adjustment
test above and see if you have the same results?
How many of you who are experiencing the problem are running NTP
synchronization software on your system?
I should also note that I could adjust the clock forward as much as I
wanted with no adverse effects (I had test cases of moving forward a few
seconds, a few minutes, a few hours, and almost an entire day), but any
adjustment of the clock backward from its current setting triggered the
problem.
I'm running openbox, and my friends were both running GNOME (one on top of
openbox and one on top of metacity).
I had the same results in my tests whether the X session was started
through GDM or from startx on the command line, and the same results
whether xscreensaver was running or not.
My theory on the three computers having having the problem at the same time
is that a small backward re-adjustment may have propagated through the NTP
servers we're using - which triggered the problem.
For those of you who are experiencing this problem more frequently, if you
have worse than average clock drift and are running NTP software, your
system would probably be having to "skip" the clock back more often than
most on most systems. Or you may be using a very "jittery" NTP server.
People who aren't running NTP probably wouldn't encounter the problem.
But please respond to this if you are experiencing this and don't use NTP
(every data point can help track down a bug).
Anyway, hopefully this helps track down the problem.
Michael
Reply to: