Comment # 5 on bug 943845 from Egbert Eich

(In reply to Robert Schweikert from comment #3)
> Nothing obvious from my perspective.
> 
> Curious:
> [    4.165924] efifb: framebuffer at 0xe0000000, mapped to
> 0xffffc90001000000, using 5628k, total 5625k
> 
> According to this message it appears that there is an overuse of 3k of memory

Might be a miscalculation. But for you it is irrelevant as efifb is replace by
inteldrmfb as soon as the native driver loads.

(In reply to Robert Schweikert from comment #4)
> This is the strace for X while the condition persists. While strace was
> running I switched to the virtual desktop to make the condition go away. The
> switch overpoint changes the pattern in the strace output.

Yeah, you're right. Darn, that I forgot to tell you to turn on time stamps in
strace, now it doesn't show how long it is sitting in a select().
It seems like before you do the switch the Xserver is talking to fd 41 a lot.

One can find out what this client wants so urgently: 
The client sends the request "GetInputFocus" and the server sends a reply.

Now, who is this client? One could try and find out what is on
/proc/<xserver_pid>/41. But this is most likely a socket from an X connection.
Then we still don't know who's on the other and as there is nothing to find out
the socket partner.

We need to use a different trick:
1. You will have to install the xorg-x11-server-debuginfo package.
2. When the condition occurs you need to attach a gdb to the Xserver:
   gdb --pid=<Xserver_PID> /usr/bin/Xorg
3. In gdb set a breakpoint on ProcGetInputFocus():
   (gdb) break ProcGetInputFocus
4. continue:
   (gdb) c
5. When the breakpoint hits, you need to inspect the argument passed 
   ('client'):
   (gdb) p *client->clientIds 
   it should now spit out this data structure. The 'cmdname' is the command 
   that is hammering on the Xserver.