1. Start X. I first thought this bug was tied to the awesome window manager, as
I wasn't able to produce it when just starting X with an xterm and no window
<http://awesome.naquadah.org/bugs/index.php?do=details&task_id=705>. But it's
now looking more like a bug with X or the synaptics driver.
2. Switch to a VT console. Wait a while. Sometimes seconds are enough,
sometimes it takes an hour. See the awesome bug report for details.
3. Switch back to X. If the bug is triggered, then the screen will initially
look as when you left it, all windows will then be repainted with their
background colors, and then no more graphics updates happen, no more
keyboard/mouse input is processed. Except: I can hit the keys to kill X, or the
keys to switch back to a VT console. Kernel hasn't frozen, I can continue to
work in the VT consoles, kill and restart X, and so on.
Nothing useful seems to be added to Xorg.0.log, nor to my .xsession.log, nor to /var/log/*
when the bug is triggered. Starting X under gdb makes the bug partially disappear.
See the awesome bug report linked above for details.
Versions: this has been happening for a few months with earlier versions of all
of the following. But it did not exist prior to that. Currently I'm using:
Arch Linux, kernel 220.127.116.11
X Server 18.104.22.1682 (I think bug was present back as far as 1.7.1, perhaps
synaptics input driver 1.2.1 (bug was definitely present when using 1.2.0 as
well, not sure about 1.1.3 or 1.1.2)
intel video driver 22.214.171.1242, bug existed in some earlier versions too
awesome window manager (not sure this is responsible) v. 3.4.2 and git
Speculative Diagnosis: turning off the SHMConfig setting for the synaptics driver
seems to have made the bug go away.
Now I gather this setting doesn't need to be on anymore, so says
But even if that's true, it will take some time for users to learn this,
and for GUI tools that now require SHMConfig to be true to be rewritten to use
the new communication channel.
Other bugs in this database with similar symptoms:
Bug 9349 - X hangs using 100% CPU during VT switch
However, I did not see 100% usage, and my experiences using gdb were different.
And that bug is from 2006, whereas mine only started in past few months.
Bug 5842 - Switching to text console and back hangs X server
However that was with the SiS driver, mine is with intel video and doesn't
seem related to the video driver. I don't get a white screen. Also that
bug is again from 2006.
Bug 8874 - xorg crashes when switching virtual console with mga g550
Bug 8191 - a running org crahses when swithing back from a fb console with dri
enabled on an amd64 with a mga g550 (2/3)
More bugs from 2006, so probably not the same. Also I'm not seeing anything
interesting in /var/log/*, but they are.
Bug 24172 - x11-driver-video-radeonhd-1.2.5-1mdv2010.0 hangs / freezes after switching to virtual console and back.
This bug is in the right timeframe (Sept 2009). We're using different
video drivers. He doesn't say enough about the symptoms he sees to settle
whether we're seeing the same behavior. He says Ctrl+Alt+Del doesn't work for him,
but it does work for me. (I have it remapped to different keys, but it works there.)
Bug just manifested after several hours even with SGMConfig off. It's proving very difficult to find a minimal basis for this bug; I'm no longer sure that the synaptics driver is involved. I am encountering this bug many times a day though, and can't trust switching between VT consoles and X while it's around.
when the server is frozen and you keep moving the input devices, do you see
errors in the log after a while?
does the pointer still move?
Pointer still moves. At times I noticed this behavior: it would update its shape appropriately as I passed over different windows. But after I clicked once in a window, the pointer's shape would be frozen. However, pointer would continue to move. I can't swear that this always what happens, but it's what tends to happen.
I haven't yet ever seen anything at all useful in logs. In a console I tail -f the likely logs when everything is working right, switch back to X and see the freezeup, switch back to the consoles and the logs haven't changed. Waiting a bit seems to make no difference.
sounds at least in part if a grab is getting stuck there. If you switch
virtual desktops using a keyboard shortcut, does that work?
Yes, in fact that's about all I can do. I can move the pointer around the screen, but no UI elements respond to clicks. No keypresses do anything, except for VT switching keys and the X server killing keys. These all continue to work. (I have them remapped away from their defaults, but that doesn't matter. They continue to work in their remapped positions.)
I've just switched to KMS and that may have made the bug disappear. (Hasn't shown up for about a day now.) KMS was on by default for Intel video with my distro's 2.6.32 kernel, however I had a vga=... argument in my kernel boot line and I think that disables KMS. At any rate, mode switching wasn't fast and smooth like it is now that I've removed the vga=... argument and rebooted.
So in summary:
This bug has afflicted me for a few kernel and video driver versions. Cleaning up my kernel boot line so that KMS actually gets used seems (for the moment at least...) to make the bug go away.
Please keep this bug open for another day or two, if it doesn't come back
with KMS in use, please close it. Or close it now and reopen if necessary,
as you prefer. Thanks for reporting though.
Yep, allowing KMS seems to make the problem go away entirely. Closing.