Recent Problems with RELENG_7 i386

Jeremy Chadwick koitsu at
Wed Oct 8 22:12:16 PDT 2008

On Wed, Oct 08, 2008 at 10:00:32PM -0700, bf wrote:
> --- On Wed, 10/8/08, Jeremy Chadwick <koitsu at> wrote:
> > From: Jeremy Chadwick <koitsu at>
> > Subject: Re: Recent Problems with RELENG_7 i386
> > To: "bf" <bf2006a at>
> > Cc: freebsd-stable at
> > Date: Wednesday, October 8, 2008, 2:36 PM
> > On Wed, Oct 08, 2008 at 10:19:47AM -0700, bf wrote:
> > > After updating to RELENG_7 i386 of this weekend, I
> > have been having problems
> > > with my machine.  When booting normally, the system
> > slows or hangs at the
> > > login prompt.  If I am able to continue past the
> > prompt, I sometimes experience 
> > > erratic mouse behavior, and a subsequent hang, after
> > varying lengths of time,
> > > even under light workloads.  The same problem does not
> > seem to occur in 
> > > single-user mode, and did not occur with the RELENG_7
> > i386 of just over a
> > > week ago.  I have been unable to obtain crashdumps so
> > far, and the only
> > > log messages I can find that weren't present
> > before are notices like those
> > > recorded below:
> > > 
> > > Oct  8 11:00:40 myhost kernel: t_delta
> > 15.fd80bdcb75b60200 too short
> > 
> > This comes from src/sys/kern/kern_tc.c, around line 908. 
> > I'm not
> > familiar with the kernel, but two ideas come to mind:
> > 
> > 1) If you have Intel SpeedStep (EIST) or AMD
> > Cool'n'Quiet enabled in
> > your BIOS, try disabling it,
> > 
> > 2) If you're using powerd, disable it (I don't see
> > it enabled),
> > 
> > 3) Try keeping HZ at 1000 (the default).
> > 
> Thanks, Jeremy, for taking the time to consider my question and reply.
> My CPU is pre-Cool'n'Quiet, and as far as I can tell I had disabled
> all forms of power management that may affect the clock speeds.  I have
> found that by raising kern.hz to 250, or by using the default, I no
> longer receive the t_delta is too short messages, and the other problems
> are no longer apparent.  My question is: why did this occur now?

I don't know.  We can't rewind time and find out system parameters and
kernel details from 6 months ago.  :-)

I'm thinking it might have something to do with the timecounter selected
by the kernel, but as I said, we can't rewind time to find out what
things were in the past.

The kernel environment variables I'm talking about are kern.timecounter.
"sysctl kern.timecounter" could help shed some light here, maybe.  It
would at least allow us to see what timecounters are available on your
system, and if a bad/unreliable one is being selected automatically.

> I have been using a similar configuration for months now without any
> apparent problems. My original goal in using a lower kern.hz was to
> avoid burdening my machine with excessive context switching.

This is over my head, technically.  I would need to pull John Baldwin
into this, since he knows a bit about both (timecounters and context
switching).  I'm just a simple caveman..... :-)

> I saw the relevant section of kern_tc.c before I wrote my first
> message, but when skimming through the changes in RELENG_7 over the
> past week or two, I couldn't see any commit that may have directly
> affected kernel timekeeping.  Has some new workload been imposed on
> the system by recent changes, that may have made a kern.hz of 100
> insufficient?  Is this tuneable setting properly implemented, so that
> all parts of the base system are using it's current value rather than
> the default?  Could some of my hardware, such as my RTC, be
> malfunctioning?

Well, I believe HZ was increased from 100 to 1000 long ago (RELENG_6?)
as a default.  I'm really not sure of the implications of decreasing it,
besides having less granularity for some things (the only things I know
of would be something pertaining to firewalls, I just can't remember
what.  My brain is full.  :-) )

| Jeremy Chadwick                                jdc at |
| Parodius Networking              |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |

More information about the freebsd-stable mailing list