[Xquartz-dev] Time Machine Backup Alert
selkovjr at gmail.com
Wed Jan 7 16:30:36 PST 2009
Please pardon my ignorance, but if it is waiting patiently, why is the
CPU time counted and the fan is blowing at full speed? I would
understand if it were wating in its own loop, but this is a unix.
Maybe we have found a bug in darwin?
> have you seen this with other apps?
No, I haven't seen this with other apps, but I don't run too many.
Other than firefox and emacs-app, I hardly use anything on this mac;
occasionally I run Apple utilities, such as (now very useful) Activity
Monitor. I mostly use this machine as a terminal and a drawing pad. I
use it as a computer, too, but my computation does not involve GUI, so
I cannot tell. Negative, based on whatever little I have seen.
> Does it happen only when using your stylus?
No, it happens without the stylus attached. Gimp skips mouse events
just as well.
On the account of the lost events, I have just tried the stylus with
Ink, and it works smoothly, even if I write extremely quickly. So I
don't think the events are lost in the kernel space.
I've made a couple more experiments since my last message.
First, I tried to attach gdb to it, in the hope that I could stop it
inside one of those crazy idle loops and get a meaningful backtrace.
Guess what. It didn't do that with gdb attached. Almost as soon as I
detached gdb, the same X11.bin went crazy again. While in gdb, I could
work normally without any perceptible impediment, except gimp was
missing the pointer events (from the stylus, as well as the mouse).
Then I randomly fooled around with it, hoping to find a trigger for
this behavior. 4 times in a row, it started at the same moment the
screen timed out and turned off. I could hear the fan kick into high
speed seconds later, and found that X11.bin was at 100% by logging in
from another machine (without touching the keys). I had almost
finished typing the announcement of this finding, when I noticed that
the 5th screen time-out experiment turned out negative, and so did the
6th and the 7th. So seemed to be the 8th, but then I left for 30
minutes without touching it, and when I came back, X11.bin was again
spinning the fan. So I am still not sure whether there is a reliable
way to reproduce it, but statistically, this has been a likely
1. Start X11
2. Start gimp and do something in it.
3. Switch to another app for a while. Even transferring focus to
Activity Monitor may be enough. Sometims it takes only 10-15 seconds
to activate the fan; sometimes multiple minutes, and almost as often
as not, nothing will happen during a very long time.
4. But if it does happen, any activity in gimp or any other X11
client brings it back to normal. Until it loses focus or until the
screen turns off, in which case the high idle is likely to occur
Returning to normal seems to be new in 22.214.171.124. In rc3 and rc4, I had
to restart the machine (another fact suggestive of a kernel-space
By the way, when it does this, ps shows it as running (as does
35884 ?? R 20:49.98
35897 ?? S 0:00.05 /usr/X11/bin/xterm
35898 ?? S 0:00.02 /bin/sh /usr/X11/bin/startx
35964 ?? S 0:00.01 /usr/X11/bin/xinit
/usr/X11/lib/X11/xinit/xinitrc -- /usr/X11/bin/X :0 -nolisten tcp
35968 ?? S 0:00.00 /usr/X11/bin/X :0 -nolisten tcp -auth
Attaching gdb as an anchor to lull it could be a fine hack, but it
doesn't solve the event-skipping problem in gimp, which makes it
useless as a drawing tool. That may very well be a bug in gimp, and I
was going to set off in that direction, but Tom's observation of
missing keystrokes made me think again. Is it possible that something
is broken where all events are handled? Also, the same version of gimp
and the same tablet work fine with the recent Xorg in linux. How much
code does that isolate as suspect?
More information about the Xquartz-dev