https://bugzilla.novell.com/show_bug.cgi?id=473302
User matz@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=473302#c9
--- Comment #9 from Michael Matz 2009-02-09 03:41:52 MST ---
So that means your initial select timeout is 1 second (where it is about 870
for me)? That's fully possible, but still would hint at the same problem.
X has a list of timers (with an expire time). The select timeout is calculated
in such a way that it times out at or before the next timer has to fire.
The list of timers depend on the applications running on the display, so
slight changes there are expected. But the general theme is still the same.
My assumption is that this list of timers is not cleaned up in the bug case,
so that even already expired timers stay in the list. Due to compensation code
for negative offsets this would lead exactly to the picture of zero-timeout
selects.
(the other possibility for that to happen is with the SMART_SCHEDULE code
as mentioned above)
Btw. Ludwig: You can find out which application is connected to the socket
corresponding to FD 40 in Xorg in the following way:
# lsof -p $(pidof X) | grep '40u.*unix'
X 6191 root 40u unix 0xf7c94280 0t0 20618 /tmp/.X11-unix/X0
# lsof | grep 20617
kopete 6598 matz 4u unix 0xf7c94080 0t0 20617 socket
What you need to look out for is a socket filedescriptor with an inode of one
less than the inode number of the socket on the X11 side (above 20618 on X
side, 20617 on kopete side). This obviously depends on how the kernel invents
these inode numbers, but for my kernel (32bit kernel-pae-2.6.27.7-9.1) it uses
the above rules.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.