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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
