Date: Thu, 24 Jan 2008 00:12:47 +1030 From: Wayne Sierke <ws@au.dyndns.ws> To: Kris Kennaway <kris@freebsd.org> Cc: stable@freebsd.org Subject: Re: 7.0-PRERELEASE desktop system periodically freezes momentarily Message-ID: <1201095768.349.21.camel@predator-ii.buffyverse> In-Reply-To: <1200847317.64691.33.camel@predator-ii.buffyverse> References: <1199812249.96494.133.camel@predator-ii.buffyverse> <4783C8A8.2090705@raad.tartu.ee> <4783D41B.3000204@FreeBSD.org> <4783D748.1050401@raad.tartu.ee> <4783D824.1050502@FreeBSD.org> <4783DB72.6030605@raad.tartu.ee> <4783DCAA.1080108@FreeBSD.org> <47851247.1020306@raad.tartu.ee> <4785186E.4070609@FreeBSD.org> <47852EFF.8000103@raad.tartu.ee> <478530FC.8090701@FreeBSD.org> <478531C4.10909@raad.tartu.ee> <4785334F.205@FreeBSD.org> <47866B15.5070002@raad.tartu.ee> <47867FAD.9050701@FreeBSD.org> <1200156892.1196.34.camel@predator-ii.buffyverse> <1200197025.1225.17.camel@predator-ii.buffyverse> <4789F872.8000502@FreeBSD.org> <1200241867.1677.34.camel@predator-ii.buffyverse> <478A7014.4080804@FreeBSD.org> <1200323959.1971.27.camel@predator-ii.buffyverse> <478BC0AA.3080906@FreeBSD.org> <1200589144.7141.27.camel@predator-ii.buffyverse> <478FB18B.3090204@FreeBSD.org> <1200677810.57226.45.camel@predator-ii.buffyverse> <1200752559.48952.31.camel@predator-ii.buffyverse> <1200764776.48952.64.camel@predator-ii.buffyverse> <1200847317.64691.33.camel@predator-ii.buffyverse>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1201095768.349.21.camel>