From owner-freebsd-stable@FreeBSD.ORG Fri Jan 18 17:36:56 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CFAE16A46D; Fri, 18 Jan 2008 17:36:56 +0000 (UTC) (envelope-from ws@au.dyndns.ws) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by mx1.freebsd.org (Postfix) with ESMTP id 97C6A13C465; Fri, 18 Jan 2008 17:36:55 +0000 (UTC) (envelope-from ws@au.dyndns.ws) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAAtwkEeWZWdv/2dsb2JhbAAIrgM X-IronPort-AV: E=Sophos;i="4.25,217,1199626200"; d="scan'208";a="38343704" Received: from ppp103-111.static.internode.on.net (HELO [192.168.1.131]) ([150.101.103.111]) by ipmail05.adl2.internode.on.net with ESMTP; 19 Jan 2008 04:06:53 +1030 From: Wayne Sierke To: Kris Kennaway In-Reply-To: <478FB18B.3090204@FreeBSD.org> 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> Content-Type: text/plain Date: Sat, 19 Jan 2008 04:06:50 +1030 Message-Id: <1200677810.57226.45.camel@predator-ii.buffyverse> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: 7.0-PRERELEASE desktop system periodically freezes momentarily X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2008 17:36:56 -0000 On Thu, 2008-01-17 at 20:50 +0100, Kris Kennaway wrote: > Wayne Sierke wrote: > > On Mon, 2008-01-14 at 21:06 +0100, Kris Kennaway wrote: > >> Same deal as before then. It cannot be the same problem as in the > >> previous 6.x trace (unless you are using a non-mpsafe filesystem, i.e. > >> not UFS). > >> > >> Kris > > > > In fact I have some MSDOSFS auto-mounting from /etc/fstab, but normally > > not in active use (by me - as for what gnome-* are doing in the > > background?). > > > > Without those mounts the stuttering in glxgears when 'Harddisk' is > > enabled in System Monitor is barely perceptible. The stuttering with > > Network Monitor remains as do the other freezes. > > > > I didn't have the same luck getting nvidia-driver working with > > LOCK_PROFILING in RELENG_7 as I did with MUTEX_PROFILING in RELENG_6. > > Looks like I'll have to test with nv or vesa driver instead, now. > > > > I've also prepared a KTR testing kernel but in the process realise I > > don't know which trace classes to include? > > KTR_SCHED > > Kris Ah, yes. Thanks. I've finally latched on to the whole schedgraph concept. Links to logs below. ktr-sched_gnome-netmonitor.out is just the 2Hz stutter in glxgears with the gnome Network Monitor applet active. I believe I've caught an instance of one stutter. ktr-sched_move-glxgears_1.out is a first attempt to catch the freeze that occurs when moving the glxgears window. Because of the freeze it's difficult to stop the recording promptly. It appears that all keyboard and mouse input (other than movement) is either ignored or discarded during the freeze[1]. Consequently, I have to wait until the system unfreezes before clicking over the terminal window to activate it and then pressing enter to run the waiting 'debug.ktr.mask=0' command. ktr-sched_move-glxgears_2.out is a second attempt. ktr-sched_move-glxgears_3.out was conducted by running the command: sleep 2; sysctl debug.ktr.mask=0 then waiting about 1.5 seconds, then dragging the glxgears window in an attempt to have the freeze active at the end of recording. What's a sensible upper limit for KTR_ENTRIES? Wayne [1] With the very curious exception that when the freeze occurs due to an alt-tab window-switching action, mouse and keyboard *do* get buffered - if I continue hitting alt-tab after the system freezes, those alt-tabs get played out when the system unfreezes. Similarly if I click over a window while the system is frozen during alt-tab, that mouse click gets played as normal when the system unfreezes. Odd. http://au.dyndns.ws/public/ktr-sched_gnome-netmonitor.out.bz2 http://au.dyndns.ws/public/ktr-sched_move-glxgears_1.out.bz2 http://au.dyndns.ws/public/ktr-sched_move-glxgears_2.out.bz2 http://au.dyndns.ws/public/ktr-sched_move-glxgears_3.out.bz2