Bug#379480: X Key/Mouse Freeze might be time/clock based
Package: xserver-xorg Version: 1:7.1.0-1 Hello, I don't use NTP, but I can reproduce the time skew problem with xorg 7.1.0. I have to MOVE or CLICK the mouse during the skew period, if I only type, nothing happens. But I only experienced this freeze two times till now, so maybe there was something else that changes the clock. The symptoms are identical. Regards Jiri Palecek -- System Information: Debian Release: testing/unstable Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17.3 Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2) (ignored: LC_ALL set to cs_CZ) Versions of packages xserver-xorg depends on: ii debconf 1.5.4 Debian configuration management sy ii x11-common1:7.1.0-1 X Window System (X.Org) infrastruc ii xbase-clients 1:7.1.ds-3 miscellaneous X clients ii xkb-data 0.8-12 X Keyboard Extension (XKB) configu ii xserver-xorg-core 2:1.1.1-6 X.Org X server -- core server ii xserver-xorg-input-evdev [xse 1:1.1.2-1 X.Org X server -- evdev input driv ii xserver-xorg-input-kbd [xserv 1:1.1.0-1 X.Org X server -- keyboard input d ii xserver-xorg-input-mouse [xse 1:1.1.1-2 X.Org X server -- mouse input driv ii xserver-xorg-video-ati [xserv 1:6.6.2-2 X.Org X server -- ATI display driv Versions of packages xserver-xorg recommends: pn discover1 | discover none (no description available) pn laptop-detect none (no description available) pn mdetect none (no description available) pn xresprobe none (no description available) -- debconf information: xserver-xorg/multiple_possible_x-drivers: * xserver-xorg/config/monitor/use_sync_ranges: false * xserver-xorg/config/inputdevice/mouse/port: /dev/input/mice xserver-xorg/config/monitor/lcd: false xserver-xorg/config/device/default-identifier: xserver-xorg/autodetect_monitor: true * xserver-xorg/config/display/default_depth: 24 * xserver-xorg/config/display/modes: 1280x1024, 1024x768, 800x600, 640x480 xserver-xorg/config/inputdevice/keyboard/internal: * xserver-xorg/config/inputdevice/keyboard/options: * xserver-xorg/config/device/use_fbdev: false * xserver-xorg/config/inputdevice/keyboard/variant: xserver-xorg/config/nonnumeric_string_error: * xserver-xorg/config/inputdevice/keyboard/layout: cz * xserver-xorg/config/monitor/identifier: Generic Monitor * xserver-xorg/config/inputdevice/mouse/emulate3buttons: false * xserver-xorg/autodetect_mouse: true * xserver-xorg/config/monitor/horiz-sync: 30-65 xserver-xorg/config/monitor/range_input_error: * xserver-xorg/config/write_dri_section: true * xserver-xorg/config/inputdevice/keyboard/model: pc105 * xserver-xorg/config/device/driver: ati * xserver-xorg/config/monitor/selection-method: Medium * xserver-xorg/config/write_files_section: true * xserver-xorg/config/monitor/mode-list: 1280x1024 @ 60Hz xserver-xorg/config/doublequote_in_string_error: xserver-xorg/config/monitor/screen-size: 17 inches (430 mm) * shared/default-x-server: xserver-xorg * xserver-xorg/config/inputdevice/mouse/protocol: ImPS/2 shared/no_known_x-server: xserver-xorg/config/device/bus_id_error: * xserver-xorg/config/monitor/vert-refresh: 50-75 * xserver-xorg/autodetect_keyboard: false xserver-xorg/config/fontpath/fontserver: * xserver-xorg/config/modules: bitmap, dbe, ddc, dri, extmod, freetype, glx, int10, record, type1, v4l, vbe * xserver-xorg/config/device/video_ram: * xserver-xorg/config/device/identifier: Generic Video Card xserver-xorg/config/null_string_error: shared/multiple_possible_x-servers: * xserver-xorg/config/device/bus_id: PCI:1:0:0 xserver-xorg/autodetect_video_card: true * xserver-xorg/config/inputdevice/keyboard/rules: xorg xserver-xorg/config/monitor/default-identifier:
Bug#379480: X Key/Mouse Freeze might be time/clock based
On Sat, Sep 30, 2006 at 11:23:47PM -0400, [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
