Date: Sun, 13 Jan 2008 03:24:52 +1030 From: Wayne Sierke <ws@au.dyndns.ws> To: Kris Kennaway <kris@freebsd.org> Cc: Toomas Aas <toomas.aas@raad.tartu.ee>, freebsd-stable@freebsd.org Subject: Re: 6.3-PRERELEASE desktop system periodically freezes momentarily Message-ID: <1200156892.1196.34.camel@predator-ii.buffyverse> In-Reply-To: <47867FAD.9050701@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2008-01-10 at 21:27 +0100, Kris Kennaway wrote: > Toomas Aas wrote: > > Kris Kennaway wrote: > > > >> OK. Can you obtain a lock profiling dump? > > > > I'm trying, but not succeeding so far. I added the following to the > > kernel config: > > > > options MUTEX_PROFILING > > options MPROF_BUFFERS="1536" > > options MPROF_HASH_SIZE="1543" > > > > And set debug.mutex.prof.enable=1 > > > > However, kgmon says that profiling is not enabled in the kernel. Am I > > missing something essential or barking under completely wrong tree? > > > > > > > > > > Yes :) kgmon has nothing to do with mutex profiling, so remove the MPROF_*. > > sysctl debug.mutex.prof.enable=1 > ... trigger hang ... > sysctl debug.mutex.prof.enable=0 > > and send me the output of > > sysctl debug.mutex.prof.stats > > Kris I added options MUTEX_PROFILING and options HWPMC_HOOKS but the system hangs when going multi-user after printing: Entropy harvesting: interrupts ethernet point_to_point. ^t shows it stuck in dd, ^c brings out to sysctl [<null>] but I can't get past that and am forced to reset. I tried rebooting without loading modules which gets around that but then I can't get xorg to start even after loading nvidia.ko. I've seen the comment in the NOTES section in MUTEX_PROFILING re modules, does it mean that I won't be able to use nvidia.ko with this test kernel? If so perhaps someone could comment on how best to proceed re gathering test results? i.e. would it be better to just use 'nv' or 'vesa' driver for now and get mutex stats? Or forgo that and keep 'nvidia' and just use hwpmc, etc. I've found that the ~2Hz stuttering that I'm seeing in glxgears results from having the gnome 'Network Monitor' applet which updates at about 2Hz. Upon removing that applet from my desktop the stuttering ceases. I also have the 'System Monitor' applet loaded which updates at the same rate and creates a similar effect if I include 'Harddisk' as a monitored resource. Without 'Harddisk' even having all of 'Processor', "Memory', 'Network', 'Swap Space' and 'Load' enabled has no discernible effect. I still see a multitude of lengthy pauses at random intervals without these applets loaded, however, and this session hasn't touched any swap yet. Wayne
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1200156892.1196.34.camel>