Re: X ignores keyboard and mouse input, but shows cursor movement (etch)
On 09/14/2007 03:19 PM, Kelly Clowers wrote:
> On 9/14/07, Ralph Katz <firstname.lastname@example.org> wrote:
>> A curious and rare (2 times since Etch became stable) X freeze or hang
>> has me wondering what to do.
>> Problem: X ignores keyboard and mouse input, but shows cursor movement
>> and running apps update normally on-screen in visible windows (gkrellm,
>> gaim, etc).
>> What happened: Viewing email message in icedove, right-click to save
>> image from the email, no response to mouse clicks, mouse wheel or
>> keyboard input, but mouse cursor movement appears normal. icedove
>> continues to fetch new mail on schedule. The identical symptoms
>> happened once before while composing in icedove.
>> Ssh from another box to examine: Nothing unusual in /var/log. Kill the
>> icedove processes. Screen shows icedove closing, then switches to VT1
>> apparently from a queued earlier attempt. Keyboard now accepts
>> ctrl-alt-F7 back to X, but again is frozen to all input in X! Just as
>> it was before killing icedove.
>> >From ssh: Restarted gdm. All is normal. This last line in
>> /var/log/Xorg.0.log.old is the only thing I could find that looked
>> FreeFontPath: FPE "/usr/share/fonts/X11/misc" refcount is 2, should be
>> 1; fixing.
>> Window manager is openbox.
>> Has anyone experienced this behavior? Any ideas? (Next time I'll
>> remember to check .xsession-errors.)
>> Ralph Katz
> I have experienced somewhat similar freezes in Unstable. The
> differences are that I am using SeaMonkey 2.0a1pre (Nightlies)
> for web browsing, I have never managed even a VT switch and
> I am using Fluxbox. Oh, and I don't use a session manager
> (GDM, etc). This has happened at least six times.
> I know the Font refcount thing is not related because it always
> says that when I exit X.
> With such a hard freeze, that happens so sporadically, I feel
> (as a non-programmer) helpless to try to figure it out.
> Sorry I can't help.
Kelly, thanks for responding. Looking further back in my notes, in
April of 2004, I had the same problem running sid. In that case, ssh'd
in to kill off processes one at a time to isolate the culprit, which was
gaim. Problem never re-occurred until what I described above.
And let me clarify that the VT switch was /after/ killing icedove. So
during the freeze, the box was inaccessible locally.
Ralph (also a non-programmer)