New KTR trace for mouse freezing/stuttering in 7.0-RC1

Sam Leffler sam at
Fri Jan 25 12:46:27 PST 2008

John Baldwin wrote:
> On Thursday 24 January 2008 06:22:57 am Sam Leffler wrote:
>> 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:
>> 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.
> Hmm, when I look at that graph using schedgraphy from HEAD it just looks
> like xtrs is using up all the CPU.  I didn't see the 2 second window where
> nothing was running.

Sigh, you are correct.  I backrev'd the machine where I ran schedgraph 
to RELENG_7 and didn't notice the old version mis-parses the ktr file.  
The graph is totally different w/ schedgraph from HEAD.

Sorry Joe for misleading you.


More information about the freebsd-stable mailing list