I do get the lockups from time to time (mostly in the version, that mouse can still move and CPU usage not very high). My observations are :

in a great majority of cases, it happens, while just browsing (I mostly use opera)

the suggestions with kernel options (i/o scheduler especially) and vm settings do help

one strange thing I've noticed lately, that it did NOT happen, when for quite some time I had no access to the Internet (even though I ran Opera, browsing local files)

almost always, the acpid is left as the only thing that CAN respond to events, so I created a helpful script, which:
- is activated by the power-button
- uses /usr/bin/chvt 1 to switch the active terminal - this is often enough to keep working without reboot
- kills X and dm
- if X cannot get killed in some number of tries, it goes into a try-hard-to-shutdown loop
- if the button is pressed while no X nor *dm is running, then just shutdown

Has anyone had any experiences with a computer that was offline? I don't much believe in that being an important reason, but it won't hurt to check...

Forgive me if this one has already been mentioned, I did try searching for it beforehand.

After using X for a few hours, the keyboard suddenly develops a ~1 second lag between keypress and result. That is, if I type something at normal typing speed, nothing happens. A keypress has to be held for a second or so before X responds to it. Weird, no? This is ~amd64, so it's xorg-server-1.5.2. Not sure if it happened with 1.5.1 since I didn't use it for long, but it's been happening somewhat regularly now.

This is the relevant section from my xorg.conf:

Code:

Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
EndSection

Should I be using a different driver, like evdev or something? I switched my mouse over to evdev when I upgraded to 1.5, but otherwise my config file is pretty much as it was when I was running 1.3. Thanks, cheers.

Forgive me if this one has already been mentioned, I did try searching for it beforehand.

After using X for a few hours, the keyboard suddenly develops a ~1 second lag between keypress and result. That is, if I type something at normal typing speed, nothing happens. A keypress has to be held for a second or so before X responds to it. Weird, no? This is ~amd64, so it's xorg-server-1.5.2. Not sure if it happened with 1.5.1 since I didn't use it for long, but it's been happening somewhat regularly now.

This is the relevant section from my xorg.conf:

Code:

Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
EndSection

Should I be using a different driver, like evdev or something? I switched my mouse over to evdev when I upgraded to 1.5, but otherwise my config file is pretty much as it was when I was running 1.3. Thanks, cheers.

Reintroducing an old version to the tree for testing purposes would be pointless considering that everything necessary to install that version of that package is available to anyone interested. All that is required is downloading a few files and placing them in a local overlay, at which point the package would be available to that system just as it would be using an old snapshot of the tree or if the old version of the package was reintroduced to the tree.

Reintroducing an old version to the tree for testing purposes would be pointless considering that everything necessary to install that version of that package is available to anyone interested. All that is required is downloading a few files and placing them in a local overlay, at which point the package would be available to that system just as it would be using an old snapshot of the tree or if the old version of the package was reintroduced to the tree.

Right, thanks. (I've not used an overlay before, so it's unfamiliar terrain for me.) So why, out of curiosity, are the old minor versions of xorg-server removed immediately like that? Compared with, say, dhcpcd or util-linux or even gentoo-sources?

Forgive me if this one has already been mentioned, I did try searching for it beforehand.

After using X for a few hours, the keyboard suddenly develops a ~1 second lag between keypress and result. That is, if I type something at normal typing speed, nothing happens. A keypress has to be held for a second or so before X responds to it. Weird, no? This is ~amd64, so it's xorg-server-1.5.2. Not sure if it happened with 1.5.1 since I didn't use it for long, but it's been happening somewhat regularly now.

This is the relevant section from my xorg.conf:

Code:

Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
EndSection

Should I be using a different driver, like evdev or something? I switched my mouse over to evdev when I upgraded to 1.5, but otherwise my config file is pretty much as it was when I was running 1.3. Thanks, cheers.

I have this same problem but as yet no solution?

What version of xorg-server and xf86-input-keyboard are you using? I just realised that I upgraded xf86-input-keyboard from 1.1 to 1.3 around the same that I upgraded xorg-server from 1.3 to 1.5. I'm going to try downgrading xorg-server to see if it fixes the problem; do you want to try downgrading your xf86-input-keyboard?

Hello. I've been using ati hd 2006 pro with two monitors not configuring dual-head/xinerama and it was working fine.
But once I configured dual-head mode (using aticonfig + manually editing xorg.conf) I'm getting X locked when I try to stop it using C-M-BkSp (no mouse moving, keyboard leds don't react on pressing the corresponding keys and, consequently, I can't switch to terminals) It doesn't even matter whether I run startx and use fluxbox, or just the standalone X. Only Magic SysRq S(ync) U(mount) re(B)oot helps me out.

But! That's not all. I do can switch to a terminal and terminate X from there. But when I then try to start X again, it hangs and I'm unable to do SysRq re(B)oot and have to do a hardreset.

It definitely has something to do with that moment when the video driver switches between "mirroring"/"stripping" modes.

My X Server locks up whenever I try to log out of Xfce 4.4.3 (the only Desktop Environment I have installed) I have components of KDE and GNOME which I run as services. This never happened before installing Compiz-Fusion. But even with it turned off/unloaded and using Xfwm4 (compiled with XComposite) I get the logout lockups and have to do a HARD REBOOT.

If I get it right, there is still no real solution for the X.org lockups?

After updating to KDE 4.2 / xorg-server 1.5 following the official guide I occasionally run into a xorg-lockup. I can move the mousepointer but nothing else happens. Logging in via ssh from a notebook I can see X consuming 100% of one of my two (hyperthreading) cpus (P4 3GHz). This is annoying as it is not able to work reliable on my system.

Is there any proved solution for this problem? Which is the standard information I shall provide?

Why didn't this happen with old xorg-server 1.3 (this was a rocking solid solution with KDE 3.5)?

BTW, sorry for not using a url, and I'm sure I'll find a way to get the GLX extension working at a later date. For now, I just want my keyboard and mouse to work.
DELL 5150, 3.2HT 1G Ram 64Mb nVidia GeForce FX Go5200 Synaptics touchpad._________________Typically I'd do all the work, but for now I'll let you do it.

@kacox: It's not really clear, what's your problem? Does your screen lock, i.e. your not able to click on things any more but e.g. are able to move your cursor around or is instead everything working fine but you just cannot use keyboard and mouse/touchpad? For the latter case I suppose you have to search for HAL, evdev and X related problems (I am sure, you'll find enough). This seems to be the case if you've updated from an old Xorg 1.3 due to several changes in Xorg 1.5_________________Gentoo forums back to Google! http://www.google.com/search?q=site%3Aforums.gentoo.org

into serverflags and I can now access my X. Although I have a working X complete with nVidia GLX, my fresh install of KDE 4.2.1 (On a fresh system install and update) is giving me problems now. I attribute my woes to evdev bypassing some of my modules. I just don't know why that option is enabled by default.

Thanks!_________________Typically I'd do all the work, but for now I'll let you do it.

I was having lockups too. Not the KDE or the recoverable variations, the ones where it really stops working whatever the Window Manager, generally (but not necessarily) associated with high CPU load (such as during compilations).

There were two ways to make it stop:

Using maxcpus=1 as a kernel argument or

Using the nv driver instead of nvidia.

Both would cease the problem completely.

Now, the How-I-Fixed-It part you might be waiting for:

Updating to nvidia-drivers 180.60 did. Simple as that. I also updated glibc, but I am guessing this had nothing to do with it.

FWIW, i had some serious lockups in xorg 1.5 with compiz and various effects, even to the point i had to reemerge a few times. I solved it by removing the .kde/ and .kde3.5/ folders and re installing the profile AND I setup to use hald and dbus and evdev for mouse and keyboard. Runs smooth now._________________Drinking from the fountain of knowldege.
Sometimes sipping.
Sometimes gulping.
Always thirsting.