7.0-PRERELEASE desktop system periodically freezes momentarily

[Wayne Sierke]

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