(*** This bug was imported into bugs.kde.org ***) Package: kwin Version: unknown (using KDE 2.2.1 -0.rh71.1.cups) Severity: normal Installed from: Red Hat Linux 7.1 Compiler: gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85) OS: Linux (i686) release 2.4.3-12 OS/Compiler notes: KWin sometimes semi-freezes the keyboard when I use keyboard combinations to switch windows. For example if I ALT-TAB rapidly twice in succession sometimes the keyboard locks up (keystrokes are not passed to underlying applications like Konsole nor to KWin itself). The only way to unlock the system is to click the mouse somewhere in a way that causes the window manager to do something e.g. by clicking on an inactive title bar. Notes: + I can also sometimes induce the bug by using the keyboard to bring up the window ops menu (ALT-F3 by default). + If I wait for about 3 seconds between keyboard window switches the lockup happens more rarely. + After a keyboard hang the mouse behaves normally most of the time but some mouse clicks are swallowed without a trace. + The bug manifests itself nondeterministically. I can go weeks without experiencing this bug and then I will boot my laptop and suddenly KWin starts freezing again. I know this is exactly the kind of bug report developers hate to get because it's quite mysterious and not reproducible. However I have inspected my system from all the angles I can think of up to and including inspecting /var/log/messages etc. for possible non-KDE reasons for the lockup. I can find none. Non-KWin window managers do not freeze on ALT-TAB. Perhaps there is some kind of race condition or deadlock in one of KWin's event handling routines. However I was under the impression that KWin is non-multithreaded and I am using non-multithreaded Qt so that doesn't really make sense. Or perhaps my X server is sending events in an order that is not expected by KWin? I notice that Workspace::keyPress() and Workspace::keyRelease() use timing-dependent code and do grab/ungrab the X input devices based on timing. Anyway I am currently building KDE 3 so perhaps someday in the future I will be able to give you better debug information although I'm quite busy these days so that may be a long time in the future. Thanks. ~k.lee (Submitted via bugs.kde.org) (Called from KBugReport dialog)
I've got the exact same setup as above cept I'm using kernel 2.4.2-12. With the default setup as is all you have to do is: ALT-F1 ;; Pulls up K menu CTRL-Tab ;; Should switch desktops with menu still up However once you hit the second key stroke. Your keyboard is a goner. My situation is worse than k.lee's. When it locks it locks. No coming back without nuking the X server. Mouse still works though! So I guess I can click on the logout selection in the menu. Hope this helps. __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com
Hi. Each of you posted a kwin bug similar to the same kwin bug that I reported. I am emailing you to see if we can put together a plausible explanation for the hangs; perhaps there is a common pattern. I am noticing for one that the hangs only occur when I boot my laptop on battery power then switch to outlet power or vice versa. Since Linux uses a test at boot time to set the length of its delay loop (or used to) and plugging in the laptop changes the CPU speed (via Intel's SpeedStep) I have a theory that my X server gets confused by dynamic CPU speed changes and sends events with oddly ordered timestamps. Right now this is a crackpot theory since I haven't tried to capture the X events during lockup or pointed my debugger at the kwin code responsible for key handling. I'm trying to build KDE 3 so that I can do so. In any case the bug seems to be timing-dependent on my machine. Have any of you noticed external circumstances or patterns common to your kwin hang incidents? Perhaps something that might affect your X server's event timing? ~k.lee CC:'ed to 33548@bugs.kde.org because I thought our discussion could go in the bug database.
My setup does happen to be on a Toshiba Tecra 8100 running the latest crap from rh-roswell and kde. And it locks up whether on battery or not. The magic combination kills everytime: 1) ALT-F1 [pull up K menu] 2) CTRL-Tab [switch desktop] I have not been able to extract any messages from the X server that have to do with my particular hanging condition. Debugging it would be very appropriate. Too bad I'm working on too much other stuff... Let me know if the above key combo kills it for you too. That way I won't feel so alone. :-) Maybe it's a QT problem. That's what half the bugs blame it on anyway. So QT3/KDE3 probably fixes it. All I have to do is remember not to type certain key combinations and wait for KDE3. later. --- Keunwoo Lee <klee@cs.washington.edu> wrote: > Hi. Each of you posted a kwin bug similar to the > same kwin bug that I > reported. I am emailing you to see if we can put > together a plausible > explanation for the hangs; perhaps there is a common > pattern. > > I am noticing for one that the hangs only occur > when I boot my laptop on > battery power then switch to outlet power or vice > versa. Since Linux > uses a test at boot time to set the length of its > delay loop (or used to) > and plugging in the laptop changes the CPU speed > (via Intel's SpeedStep) > I have a theory that my X server gets confused by > dynamic CPU speed > changes and sends events with oddly ordered > timestamps. > > Right now this is a crackpot theory since I haven't > tried to capture the > X events during lockup or pointed my debugger at the > kwin code responsible > for key handling. I'm trying to build KDE 3 so that > I can do so. In any > case the bug seems to be timing-dependent on my > machine. > > Have any of you noticed external circumstances or > patterns common to your > kwin hang incidents? Perhaps something that might > affect your X server's > event timing? > > ~k.lee > > CC:'ed to 33548@bugs.kde.org because I thought our > discussion could go in > the bug database. > > __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com
HOW I AVOID THIS PROBLEM: I have experienced keyboard freeze on all KDE versions since 2.0beta an all used distributions (SuSE 6.1 until 7.2 Redhat 7.0J) using IBM Thinkpad models 240 570 and 570e. Most frequent occurence was at switching between active windows (alt tab) virtual desktop and during build of konqueror window. I assume it is a problem with the graphics card and driver. Instead of using the default driver I treated the card as <non supported> using framebuffer driving mode selecting vga=791 (16bit colour XGA). Screen build is a little slower but no more freezes at all and no more mouseklicks are being ignored!!! Note: While the freeze problem was most severe in KDE and especially konqueror there was also hanging or ignoring of some mouseklicks in gnome and fvwm2 but those could mostly be cured by [esc] if the application under which it occurred was not konqueror. Conclusion: this problem which seems to be fairly common in many laptop PCs does not seem to be a kde one but in kde it turns out to be most severe. BR Thomas Piekenbrock
I'm having the same problem. Random lockups when I put the window manager (especially the alt-f3 window) into weird states. kwin starts using 100% CPU and calls gettimeofday() like crazy until I ssh into the machine and kill -9 it. alt-f1 ctrl-tab does *not* immediately hang the machine but makes it start randomly locking the mouse and keyboard after a while. One time the keyboard died and then I logged out using the mouse but after kdm came up the keyboard still didn't work. I had to restart the X server for it to start responding to the keyboard again. I'm running Debian 2.2 testing with kernel 2.4.16 on a Toshiba Satellite 3005-S303 with the NVidia Geforce2Go chip. Using the offical NVidia drivers v1.0.2313. Libraries are: thalakan@thom:~$ ldd /usr/bin/kwin kwin.so => /usr/lib/kwin.so (0x4001f000) libkdeui.so.3 => /usr/lib/libkdeui.so.3 (0x40076000) libkdecore.so.3 => /usr/lib/libkdecore.so.3 (0x40269000) libdl.so.2 => /lib/libdl.so.2 (0x403df000) libDCOP.so.1 => /usr/lib/libDCOP.so.1 (0x403e3000) libqt.so.2 => /usr/lib/libqt.so.2 (0x40417000) libpng.so.2 => /usr/lib/libpng.so.2 (0x408c5000) libz.so.1 => /usr/lib/libz.so.1 (0x408f1000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40900000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4091f000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4092d000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40a08000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40a12000) libresolv.so.2 => /lib/libresolv.so.2 (0x40a28000) libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x40a39000) libm.so.6 => /lib/libm.so.6 (0x40a84000) libc.so.6 => /lib/libc.so.6 (0x40aa6000) libXft.so.1 => /usr/X11R6/lib/libXft.so.1 (0x40bc9000) libmng.so.1 => /usr/lib/libmng.so.1 (0x40bf2000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x40c36000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x40c3b000) liblcms.so.1 => /usr/lib/liblcms.so.1 (0x40c79000) They're all from the standard Debian packages. -- - Jason "They make a desert and call it peace." -- Tacitus (55?-120?)
On Monday 18 February 2002 20:50 Jason Spence wrote: > I'm having the same problem. [cut off reports of strange behavior apparently on laptops with intel speedstep tech] Did you try to use some other window manager than KDE? Does that happen inthere? This is really very very difficult to get a hand of especially as I don't own a laptop at all (lest a specific model that would exhibit this weird behavior). I'm sorry about this. -- Cristian Tibirna .. tibirna@sympatico.ca PhD Student .. ctibirna@giref.ulaval.ca .. www.giref.ulaval.ca/~ctibirna KDE contact - Canada .. tibirna@kde.org .. www.kde.org
On Mon Feb 18 2002 at 10:08:46PM -0500 Cristian Tibirna developed a new theory of relativity and: > On Monday 18 February 2002 20:50 Jason Spence wrote: > > I'm having the same problem. > > [cut off reports of strange behavior apparently on laptops with intel > speedstep tech] > > Did you try to use some other window manager than KDE? Does that happen > inthere? Nope but I don't think it's necessary: the problem is definately with kwin. When I kill it and restart it everything is fine. > This is really very very difficult to get a hand of especially as I > don't own a laptop at all (lest a specific model that would exhibit > this weird behavior). I'm sorry about this. I just had the freeze with one of my desktop machines. It has almost the same configuration as the laptop: GeForce2 latest drivers etc. It's an Athlon though which throws the Intel theory out the window. -- - Jason All I can think of is a platter of organic PRUNE CRISPS being trampled by an army of swarthy Italian LOUNGE SINGERS ...
This problem is likely specific to laptops. One my system cat'ing the /proc/acpi/battery/* files generates this lockup under other window managers using ACPI and the stock 2.4.18 kernel. Using the 20020829 ACPI version from http://sf.net/projects/acpi and the 2.4.20pre5 kernel the problem disappears. Removing all ACPI clients form KDE also works so I suspect the problem is in klaptopdaemon and it's access of the ACPI subsystem under buggy ACPI implementations. If you need more information an working and broken configs drop me a line. Patrick. -- The only way to discover the limits of the possible is to go beyond them to the impossible. -Arthur C Clarke ... Patrick Audley paudley@compbio.dundee.ac.uk Computational Biology http://www.compbio.dundee.ac.uk University of Dundee http://blackcat.ca Dundee Scotland +44 1382 348721
can you reproduce this problem with KDE 3.x? I had this problem with 2.x too, but never again with 3.x.
Subject: Re: kwin locks keyboard on keyboard-activated window change events On 30 Sep 2002, Stephan Kulow wrote: > ------- Additional Comments From coolo@kde.org 2002-09-30 10:56 ------- > can you reproduce this problem with KDE 3.x? I had this problem with 2.x too, > but never again with 3.x. Yes, I have reproduced this problem with KDE 3.0.3, Qt 3.0.5, on Red Hat (kernel 2.4.9-34, XFree 4.0.3). For me, the best way to trigger it is to hit alt-tab a few times rapidly to switch windows. And it only happens when I boot from battery power (if I boot from AC and switch to battery power afterwards, it's fine), so I believe it's some weird interaction between KDE and X or the kernel. Maybe you upgraded your X server or kernel (or both) around the same time you went to KDE 3? ~k
Please try upgrading your XFree86 and try again. I vaguely remember there used to be a notebook related bug in older versions that could be causing this bug.
Hi, I'm experiencing a similar problem as mentioned above. I'm running a Gateway E4200 *desktop* with an Intel P3 - 600MHz, ATi Rage 128, and PS2 keyboard and mouse. I am running the stock XFree86 for my configuration from Mandrake 9.0, using the KDE 3.1 Beta2 (updated via Mandrake Cooker) My Problem: When I try to resize or move a window, using the Alt + Mouse combination (not the drag bars on the window), the keyboard locks out. This has happened so far only when the K menu is active, and has been activated using the Windows key (the one between Left Ctrl and Left Alt). Reproducible: Erratic behaviour, but I can usually get it withing 4-5 tries. Tried this with Konsole and GVIM so far. Other hardware and software: responsive (I can save all my open files, close any windows of gvim/mozilla/konqueror/etc, log out of GAIM, close XMMS and logout) Keyboard is reset when I logout, and is functional in the next KDE session (as same user) Irritation level: high. though I can save and cleanly exit from KDE, i *need* to end the KDE session to get the keyboard working again. I have seen this only with KDE so far. Please let me know if you need any more info. Regards, Hrishikesh
I have the same issue with kde 3.1 with qt 3.1.1. I'm not alt-tabbing or anything though. Just navigating with the mouse. Mouse continues to work but the keyboard stops responding - numlock, capslock, none of them work. Have to logout, restart X and then the keyboard comes back. Works fine with IceWM,Fluxbox, and XFCE though. No issues like this with any of the other WM's I use, just KDE 3.1. Will try disabling ACPI in the bios to see if it makes a difference. Regards, Tony Brijeski Vector Linux Chief Architect of the SOHO branch.
Can anybody reproduce this problem with KDE3.2?
Waiting for response.
I am unable to reproduce on KDE 3.2, Qt 3.2.3, XFree 4.0.3, kernel 2.4.22. However, it was always a subtle intermittent bug even back when it was appearing. I suppose we can close it for good and reopen if anyone can ever reproduce it.
I have seen this problem on KDE 3.2, Qt 3.2.3, XFree 4.3, kernel 2.4. Last time the keyboard lock occured, I because curious, and left xev open. During the keyboard freeze, xev shows no X keyboard events occuring on key presses. I have the CDE style windows-switch functionality bound to Win-Tab, and the "drag window to move" mousebinding bound to Win-Mouse1. When the freeze occurs, the cursor changes to a move cursor over windows, almost as if kwin thinks the move modifier is still depressed (of course not being familiar with kwin/qt, this is speculation). This is on a laptop, but I have not experienced this behavior with other window managers. Hope this Helps, Dan
I have the exact same bug with KDE 3.5.2 / Qt 3.3.4 on my Dell laptop running Gentoo. But I never had this bug before upgrading to Xorg v7 (modular). Note that I never run on battery... Complete bug filled at: https://bugs.gentoo.org/show_bug.cgi?id=129793
http://bbs.archlinux.org/viewtopic.php?id=30430 Please reopen this bug. I'm experiencing random keyboard lockups on my Acer TravelMate 240. I can't reproduce them, but they happen about 2 times a day. Here is the link to the ArchLinux forum, when more people are admiting to experience them: http://bbs.archlinux.org/viewtopic.php?id=30430
Sorry I will continue here: http://bugs.kde.org/show_bug.cgi?id=109322