Bug 25870 - Switching from VT console back to X tends to freeze X when synaptics/SHMConfig is on
Summary: Switching from VT console back to X tends to freeze X when synaptics/SHMConfi...
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/synaptics (show other bugs)
Version: 7.5 (2009.10)
Hardware: x86-64 (AMD64) Linux (All)
: medium critical
Assignee: Peter Hutterer
QA Contact:
Depends on:
Reported: 2010-01-03 04:37 UTC by profjim
Modified: 2010-01-11 17:41 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Description profjim 2010-01-03 04:37:50 UTC
To reproduce:

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
manager. See
<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
	X Server (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, 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.)
Comment 1 profjim 2010-01-03 05:00:10 UTC
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.
Comment 2 Peter Hutterer 2010-01-03 17:24:00 UTC
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?
Comment 3 profjim 2010-01-03 17:43:40 UTC
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.
Comment 4 Peter Hutterer 2010-01-03 18:24:53 UTC
sounds at least in part if a grab is getting stuck there. If you switch
virtual desktops using a keyboard shortcut, does that work?
Comment 5 profjim 2010-01-03 19:02:03 UTC
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.)
Comment 6 profjim 2010-01-04 15:13:23 UTC
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.
Comment 7 Peter Hutterer 2010-01-04 22:41:33 UTC
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.
Comment 8 profjim 2010-01-11 17:41:25 UTC
Yep, allowing KMS seems to make the problem go away entirely. Closing.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.