6.3-PRERELEASE desktop system periodically freezes momentarily

Wayne Sierke ws at au.dyndns.ws
Sat Jan 12 08:55:02 PST 2008

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


More information about the freebsd-stable mailing list