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