From owner-freebsd-stable@FreeBSD.ORG Thu Jan 24 11:36:24 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BA4216A421 for ; Thu, 24 Jan 2008 11:36:24 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 1C5FA13C43E for ; Thu, 24 Jan 2008 11:36:24 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m0OBMvCI023657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jan 2008 03:23:00 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <47987511.6070201@errno.com> Date: Thu, 24 Jan 2008 03:22:57 -0800 From: Sam Leffler User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Joe Peterson References: <1199812249.96494.133.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> <1201095768.349.21.camel@predator-ii.buffyverse> <47975CFE.4070000@skyrush.com> <20080123135705.3ff903e4@linwhf.opal.com> <479794E3.5060307@skyrush.com> <20080123161128.01040b96@linwhf.opal.com> <4797B041.2020700@skyrush.com> <20080123174820.08ba33ad@linwhf.opal.com> <4797DE22.6020508@skyrush.com> <4797F0D7.8020702@skyrush.com> <47981DC7.2030706@skyrush.com> In-Reply-To: <47981DC7.2030706@skyrush.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: freebsd-stable@freebsd.org Subject: Re: New KTR trace for mouse freezing/stuttering in 7.0-RC1 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: Thu, 24 Jan 2008 11:36:24 -0000 Joe Peterson wrote: > In an attempt to track down this mouse freezing/stuttering (i.e. "jerky > mouse movement) behavior in FreeBSD 7.0-RC1, I have come up with a > reliable way to cause it to happen, and I have created a longer trace > showing the results. Note that I am using the ULE scheduler. > > In general, it becomes easier to see the effect if there is CPU > activity. I have noticed it during kernel compiles, while at the same > time loading web pages in firefox that contain images (and moving the > mouse while this is happening). But a more controlled way to see it is > to run something that uses some CPU and then generating lots of X events. > > In my case, I start "xtrs" (TRS-80 emulator) in Model IV mode, which > happens to poll for input, using the CPU. Then I move the mouse back > and forth quickly between windows in "focus under mouse" mode (in my > case, a KDE focus mode), which causes many focus events quickly. In > about 15 or 20 seconds, the mouse reliably starts to show erratic > movement, not moving smoothly. > > I really hope this can shed more light on what might be going on. Here > is the trace: > > http://www.skyrush.com/downloads/ktr_ule_4.out > > This is an interesting trace. It appears that something is blocking threads in the runq from running for 2 seconds! I don't see what it is from the trace data. It sort of looks like the last thing that ran is the swi4 which is likely a callout (need to check the log file contents to be certain). If the callback function does something it wouldn't necessarily be visible in the schedgraph plot. If you could stick a dmesg from booting out in the same spot it might be worthwhile. Also if you rebuild the kernel the kernel with DIAGNOSTIC then softclock() will complain about callouts that take longer than 2ms to run. This might generate too much noise in which case you can adjust the threshold by editing the code in sys/kern/kern_timeout.c. Sam