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.


http://au.dyndns.ws/public/ktr-sched_gnome-netmonitor.out.bz2

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


http://au.dyndns.ws/public/ktr-sched_move-glxgears_1.out.bz2
http://au.dyndns.ws/public/ktr-sched_move-glxgears_2.out.bz2

Nothing significant is apparent.


http://au.dyndns.ws/public/ktr-sched_move-glxgears_3.out.bz2

(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?


http://au.dyndns.ws/public/ktr-sched-200801192346.out.bz2

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.


http://au.dyndns.ws/public/ktr-sched-200801200336.out.bz2

Looks like just another mouse disconnect.


http://au.dyndns.ws/public/ktr-sched-200801200302.out.bz2

http://au.dyndns.ws/public/ktr-sched-200801210207.out.bz2

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.


Wayne



More information about the freebsd-stable mailing list