Bug#364288: Randomly loses input since X11R7 upgrade
Hello Tore, I see the same problem on my mac mini using a self compiled X using usb keyboard and usb mouse. My solution so far for it is pulling the usb keyboard out and putting it after a second or so back in. After that my usb keyboard starts working again. I know that my pointer works to, but I didn't check the buttons. If you find anything further usefull please let me know. Next time it hangs, I try if magic sysrq works for me, too. (Nice trick with unrar and giving the kernel back the vt switching). Btw. when I do this on a working Xserver I simply can switch back to vt 5 (this is where my Xserver runs) and it seems to switch keyboard back to raw modus. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364288: Randomly loses input since X11R7 upgrade
Hello Michel, * Michel Dänzer Some semi-random ideas to try and narrow down the problem: * Kill the running X apps one at a time and see if the problem goes away after killing any of them. Didn't help. After Openbox were the last client remaining I restarted it too using SIGUSR1, no go. * Add Option AllowClosedownGrabs to xorg.conf Section ServerFlags and press Ctrl+Alt+Keypad-Multiply when the problem occurs. No effect. (I tested that it worked correctly before the hang, too.) * Do not load the type1 and/or freetype X server modules. If you actually need their functionality, an X font server such as xfs should serve as a replacement. I have no idea what functionality they provide, they've just been in my config file in my years. :-) Anyway I removed them (without noticing any difference in how the fonts looked), but it did not prevent a hang. You can only attach to the X server with gdb remotely from another machine (or at the very least from console), as otherwise you end up in a dead lock where gdb stops execution of the X server, which is what provides interaction with gdb... Ehh... *blushes* Anyway, I attached GDB to the X server from the console, put it in a screen and attached to it from within X. When the hang occurred there were no signals or anything else showing up. So that didn't make me any wiser either. :-( Regards -- Tore Anderson
Bug#364288: Randomly loses input since X11R7 upgrade
On Wed, 2006-05-10 at 20:38 +0200, Tore Anderson wrote: Do you think there's any hope of getting nearer any solution to this bug in forseeable future? I'm sorry, but this is making my workstation so useless that I'll soon downgrade to etch or change to some other distribution in the hope that this bug only appears in the Debian builds. Some semi-random ideas to try and narrow down the problem: * Kill the running X apps one at a time and see if the problem goes away after killing any of them. * Add Option AllowClosedownGrabs to xorg.conf Section ServerFlags and press Ctrl+Alt+Keypad-Multiply when the problem occurs. * Do not load the type1 and/or freetype X server modules. If you actually need their functionality, an X font server such as xfs should serve as a replacement. I tried to attach GDB to the X server but then it just froze solid, both with the binary NVidia driver, and with the included one. You can only attach to the X server with gdb remotely from another machine (or at the very least from console), as otherwise you end up in a dead lock where gdb stops execution of the X server, which is what provides interaction with gdb... -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Bug#364288: Randomly loses input since X11R7 upgrade
* Tore Anderson Yep, it did, using 2.6.15-1-k7. I ran that kernel for a long time with X11R6 on top and didn't have any problems at all, so it seems very unlikely that the kernel is to blame. Hi David, Do you think there's any hope of getting nearer any solution to this bug in forseeable future? I'm sorry, but this is making my workstation so useless that I'll soon downgrade to etch or change to some other distribution in the hope that this bug only appears in the Debian builds. I tried to attach GDB to the X server but then it just froze solid, both with the binary NVidia driver, and with the included one. I don't know if there is any other debugging possibilities at all? Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364288: Randomly loses input since X11R7 upgrade
* Tore Anderson I will try downgrading my kernel now and see if it still happens. Yep, it did, using 2.6.15-1-k7. I ran that kernel for a long time with X11R6 on top and didn't have any problems at all, so it seems very unlikely that the kernel is to blame. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364288: Randomly loses input since X11R7 upgrade
* David Martínez Moreno I think that you could use xev in order to know if X.Org is receiving input: I am supposing you are capable of making the failure happen quickly (more or less). First launch a terminal and a browser in the same desktop. Then use xwininfo in order to obtain the ID of the browser. Then launch xev -id WINDOW_ID in the terminal and feel free to surf. As you will see, xev intercepts *every* event belonging to the window (key presses, mouse movements, etc.). When it happens, you can tell us if you start to lack output in the xev terminal. If so, I would guess for a kernel problem. If not...well, we could try another thing. :-) I thought of this a few minutes after writing my original report, but obviously forgot to follow up with my results. I'm at work now, so this is from memory, but what I did was something like this (when the breakage happened): 1) Change to another VT (with the help of Alt+SysRq+R). 2) From there start DISPLAY=:0 xev 3) Change back to the VT with X, where xev now is visible and has input focus according to my window manager And then batter the keyboard, move the pointer around, hit mouse buttons, and so on, and change back to the VT where xev was started to inspect the output. The result: No MotionNotify, KeyPress/Release, or ButtonPress/Release events at all. The only ones were some Expose and Visibility*-events (can't quite remember the order of them, though). I'm using focus-follows-pointer, but the focus do not change from the xev window when I move the pointer to some other window, so the window manager appears to be oblivious to the MotionNotify-events too. It seems as if the X server simply stops sending those events. It might of course be a kernel bug - I did indeed upgrade to 2.6.16 recently. I can try downgrading to 2.6.15 and see if I experience the bug then. The X server is my prime suspect though - the keyboard works perfectly on the console, and I need only restart X to fix the problem. I will install GPM to see if the mouse continues working fine on the console when X has problems. One thing that really makes me think the kernel is unlikely, is the fact that the pointer actually moves around the screen when I move the mouse, so the X server has to receive the events from the kernel orelse the pointer would appear to be stuck/frozen, no? Yet there's no MotionNotify-events - I assume the kernel doesn't have anything to do with generating those? I will attach an xev to my browser like you suggested and see if I get the same results. However I'm unable to reproduce it at will, it just happens once in a while - and I can't guarantee that I will be browsing when it happens. I'll try (from the console) to attach xev to whatever window had focus if that happens, though. I guess I can use xwininfo -name to get the window ID without having to rely on the mouse working, so that should be no problem. Another thing I just thought of and I'll try is to remove all the USB- related modules and re-insert them again, to see if that will fix the problem without requiring a restart. Both my keyboard and my mouse are USB devices. I did try hotplugging them though, without any success. Kind regards -- Tore Anderson
Bug#364288: Randomly loses input since X11R7 upgrade
El miércoles, 26 de abril de 2006 11:47, Tore Anderson escribió: * David Martínez Moreno [...] It might of course be a kernel bug - I did indeed upgrade to 2.6.16 recently. I can try downgrading to 2.6.15 and see if I experience the bug then. The X server is my prime suspect though - the keyboard works perfectly on the console, and I need only restart X to fix the problem. I will install GPM to see if the mouse continues working fine on the console when X has problems. One thing that really makes me think the kernel is unlikely, is the fact that the pointer actually moves around the screen when I move the mouse, so the X server has to receive the events from the kernel orelse the pointer would appear to be stuck/frozen, no? Yet there's no MotionNotify-events - I assume the kernel doesn't have anything to do with generating those? Well, it seems that the problem is not in the kernel input layer, then. Anyway, if VT switching is working...we can discard a kernel input problem, I think. Anyway it will be nice if you could switch kernels. I will attach an xev to my browser like you suggested and see if I get the same results. However I'm unable to reproduce it at will, it just happens once in a while - and I can't guarantee that I will be browsing when it happens. I'll try (from the console) to attach xev to whatever window had focus if that happens, though. I guess I can use xwininfo -name to get the window ID without having to rely on the mouse working, so that should be no problem. All right, we will wait, then. Another thing I just thought of and I'll try is to remove all the USB- related modules and re-insert them again, to see if that will fix the problem without requiring a restart. Both my keyboard and my mouse are USB devices. I did try hotplugging them though, without any success. It seems right as well. Although you could not find anything useful in Xorg.0.log, you should send it to us (preferably from a problematic session) and your xorg.conf, along with the output of lsmod and dmesg. Best regards, Ender. -- Network engineer Debian Developer pgpGAJm58zF53.pgp Description: PGP signature
Bug#364288: Randomly loses input since X11R7 upgrade
El sábado, 22 de abril de 2006 15:17, Tore Anderson escribió: Package: xserver-xorg Version: 1:7.0.14 Severity: important First off, apologies for the lack of detail in this bug report. I simply do not know what's going on nor how to debug it. :-/ I think that you could use xev in order to know if X.Org is receiving input: I am supposing you are capable of making the failure happen quickly (more or less). First launch a terminal and a browser in the same desktop. Then use xwininfo in order to obtain the ID of the browser. Then launch xev -id WINDOW_ID in the terminal and feel free to surf. As you will see, xev intercepts *every* event belonging to the window (key presses, mouse movements, etc.). When it happens, you can tell us if you start to lack output in the xev terminal. If so, I would guess for a kernel problem. If not...well, we could try another thing. :-) Does it seem feasible to you? Best regards, Ender. -- Hey, Mom, I saw a bunch of products on TV that I didn't know existed, but I desperately need! -- Calvin (Calvin Hobbes comic strip). -- Desarrollador de Debian Debian developer pgpkhkrZevhJN.pgp Description: PGP signature
Bug#364288: Randomly loses input since X11R7 upgrade
Package: xserver-xorg Version: 1:7.0.14 Severity: important First off, apologies for the lack of detail in this bug report. I simply do not know what's going on nor how to debug it. :-/ After my latest dist-upgrade, which pulled in X.Org 7, the X server has started randomly losing input. When it ends up in this state, no input is accepted whatsoever, all keypresses and mouse button clicks does not appear to be processed at all (even the keyboard LEDs won't change if I hit e.g. Num Lock). The only thing that keeps working is the mouse pointer, which moves normally when I move the mouse. I believe every time the server has entered this state I've been using the mouse for something. It doesn't seem to happen unprovoked - I've never woken up to the server having entered the defunct state during night, for instance, while when actively using the computer it usually happens within a few hours. I don't use the mouse for much, though, so I suspect it might happen more frequently if I used it more. I've experienced the problem both using the nv and nvidia drivers, and also both when using the evdev and mouse drivers for my mouse device. There's nothing relevant in /var/log/Xorg.0.log, nor in ~/.xsession-errors. The X server itself is completely unuseable when it occurs, and I have found no way of reviving it. It doesn't seem to be another way out than to change to another VT (after having set the keyboard to raw mode using Alt+SysRq+R), and from there do a full restart of X. I have no idea how to debug this further, so any suggestions on how to get to the bottom of this would be much appreciated. Kind regards Tore Anderson -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages xserver-xorg depends on: ii debconf 1.5.0 Debian configuration management sy ii nvidia-glx [xserver-xorg-vid 1.0.8756-4 NVIDIA binary XFree86 4.x driver ii x11-common 1:7.0.14X Window System (X.Org) infrastruc ii xbase-clients1:7.0.0-4 miscellaneous X clients ii xkb-data 0.8-5 X Keyboard Extension (XKB) configu ii xserver-xorg-core1:1.0.2-5 X.Org X server -- core server ii xserver-xorg-input-kbd [xser 1:1.0.1.3-2 X.Org X server -- keyboard input d ii xserver-xorg-input-mouse [xs 1:1.0.4-2 X.Org X server -- mouse input 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: true * xserver-xorg/config/inputdevice/mouse/port: /dev/input/mice * xserver-xorg/config/monitor/lcd: true * 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/autodetect_monitor: true * xserver-xorg/config/inputdevice/mouse/protocol: ImPS/2 * shared/no_known_x-server: * xserver-xorg/config/display/default_depth: 16 * xserver-xorg/config/display/modes: 1600x1200, 1280x1024, 1280x960, 1152x864, 1024x768, 800x600, 640x480 * xserver-xorg/config/device/bus_id_error: * xserver-xorg/config/inputdevice/keyboard/internal: * xserver-xorg/config/monitor/vert-refresh: 50-75 * xserver-xorg/config/inputdevice/keyboard/options: * xserver-xorg/autodetect_keyboard: false * xserver-xorg/config/inputdevice/mouse/zaxismapping: true * xserver-xorg/config/device/use_fbdev: * xserver-xorg/config/inputdevice/keyboard/variant: * xserver-xorg/config/nonnumeric_string_error: xserver-xorg/config/fontpath/fontserver: * xserver-xorg/config/inputdevice/keyboard/layout: no * xserver-xorg/config/modules: GLcore, bitmap, dbe, ddc, dri, extmod, freetype, glx, int10, record, speedo, type1, vbe * xserver-xorg/config/monitor/identifier: Generic Monitor * xserver-xorg/config/inputdevice/mouse/emulate3buttons: true * xserver-xorg/autodetect_mouse: true * xserver-xorg/config/monitor/horiz-sync: 30-94 * xserver-xorg/config/device/video_ram: * 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: nvidia * xserver-xorg/config/device/identifier: NVIDIA Corporation NV18 [GeForce4 MX - nForce GPU] * xserver-xorg/config/monitor/selection-method: Medium * xserver-xorg/config/null_string_error: * shared/multiple_possible_x-servers: * xserver-xorg/config/device/bus_id: *
