7.0-PRERELEASE desktop system periodically freezes momentarily

Wayne Sierke ws at au.dyndns.ws
Wed Jan 23 05:42:55 PST 2008

Doh! Now that I'm no longer using the 8 month old version of
schedgraph.py that was displaying interesting but useless graphs,
perhaps I won't continue to appear as though I'm raving like such a
lunatic about what is contained in my ktr captures.

Here follows a re-examination of the previously posted data with a
recent schedgraph.py. Note that lacking any particular knowledge I'm
only guessing at what might be significant.


(Stutter in glxgears with gnome metwork monitor) glxgears in runq for


Nothing significant is apparent.


(Dragging glxgears window which freezes - stops following mouse and
stops updating, desktop doesn't respond to keyboard/mouse-clicks for the
duration) glxgears in runq for 278ms and almost immediately again for
381ms. Note that this doesn't capture the entire period of interest
which can be 1-2 seconds, due to the high number of context switches
occurring with glxgears running and the difficulty of stopping the
logging quickly after the event. I'll need a much larger (than 128k)
buffer to catch an event in its entirety, unless someone can suggest a
way to reduce the number of context switches significantly?


Looks like this was probably just a mouse disconnect/reconnect - there
is approx 1s of inactivity in irq20/ohci0 towards the end. Unfortunately
these disconnects occur very frequently (typically multiple times per
hour) since running with the KTR-enabled kernel (afaict). Unfortunately
it looks as though that after gaining a false impression from this
capture with the old schedgraph.py, I subsequently mis-interpreted
numerous mouse disconnects as desktop freeze events.


Looks like just another mouse disconnect.



Nothing interesting is apparent.

So it seems the only thing of interest that I"ve managed to capture so
far pertains to glxgears - an instance of the "stutter" and a part of a
short freeze when dragging its window. Unfortunately these frequent
mouse disconnects make it difficult to recognise genuine freezes during
'normal' use, if indeed they are still occurring with RELENG_7. However
the glxgears behaviour remains (apparently) the same as it was on
RELENG_6. Whether that's a telling sign or not remains to be seen.


More information about the freebsd-stable mailing list