Bug#379480: X Key/Mouse Freeze might be time/clock based
On Sat, Sep 30, 2006 at 03:34:48PM -0600, Berg, Michael wrote:
> 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.
Mine freezes within minutes.
>
> 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?
>
> 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!
>
> 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.
Yes, this true for me, too, except that it's all so slow that ssh times
out during login. But if I'm alreaddy ssh'd in, I can do things --
slowly. Keystroke echo can take a minute!
>
> Can those of you who are also having this problem try the clock adjustment
> test above and see if you have the same results?
Will try and report results.
>
> How many of you who are experiencing the problem are running NTP
> synchronization software on your system?
Just chrony.
>
> 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).
running icewm.
>
> 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: