7.0-PRERELEASE desktop system periodically freezes momentarily

Wayne Sierke ws at au.dyndns.ws
Sat Jan 19 09:46:21 PST 2008


Another one, this time xorg for 2 seconds, approximately in the middle.

I'm feeling inclined to doubt the validity of this and the previous data
set, however. Looking at the tail end of each of the events in question,
there is clearly activity on other processes before the supposedly long
exclusive cpu event terminates. Unless this is some limitation of the
schedgraph.py script, or the ktr logging mechanism, etc., then this must
surely indicate that they are not valid captures?

I am all the more inclined to question them because the very next
capture/dump I did after the previous set was captured looked so similar
to it that I felt prompted to do a diff between the files and found that
they contained identical lines for the most part, with only approx every
nth line being different (for n=about 4 or so - I don't recall exactly
and unfortunately didn't keep that particular one).

Is it sufficient to just set debug.ktr.mask to resume capturing, or is
it necessary to set debug.ktr.clear? (Note that so far there has always
a substantial time interval between setting the mask and clearing it
again, at least some minutes and usually much more, so I've assumed that
there's plenty of logging occurring to over-write the previous

I should also have mentioned that I'm getting these messages

ums0: at uhub0 port 2 (addr 2) disconnected
ums0: detached
ums0: <B16_b_02 USB-PS/2 Optical Mouse, class 0/0, rev 2.00/98.02, addr 2> on uhub0
ums0: 8 buttons and Z dir.

which for the moment I'm assuming are related to running the KTR-enabled
kernel as I can't recall seeing these previously.



More information about the freebsd-stable mailing list