freebsd stable - Dec 2004 - Timecounter problems on 5.3 - things take twice as long

Hi,

I have a weird problem on a dual Xeon 550MHz system running
5.3-RELEASE. Everything takes twice as long as it should.

Example:
winston% time sleep 2
sleep 2  0.00s user 0.00s system 0% cpu 4.006 total

The same for pings, the scsi delay when booting, etc. The time of the
system itself doesn't seem to be affected (but maybe ntpd takes care
of that). I tried changing the kern.timecounter.hardware sysctl from
ACPI-safe to TSC and i8254, but that didn't help.

Any other suggestions on how to fix this? Do I have to provide more information?

Arjan

On Thu, 2 Dec 2004, Arjan Van Leeuwen wrote:
> Hi,
>
> I have a weird problem on a dual Xeon 550MHz system running
> 5.3-RELEASE. Everything takes twice as long as it should.
>
> Example:
> winston% time sleep 2
> sleep 2  0.00s user 0.00s system 0% cpu 4.006 total
>
> The same for pings, the scsi delay when booting, etc. The time of the
> system itself doesn't seem to be affected (but maybe ntpd takes care
> of that). I tried changing the kern.timecounter.hardware sysctl from
> ACPI-safe to TSC and i8254, but that didn't help.
TSC isn't available on SMP systems.  Its possible one of the CPUs is
damaged, though.
> Any other suggestions on how to fix this? Do I have to provide more
> information?
'vmstat -i' output would be handy.

-- 
Doug White                    |  FreeBSD: The Power to Serve
dwhite@gumbysoft.com          |  www.FreeBSD.org

Hey Doug,

On Tue, 7 Dec 2004 12:57:01 -0800 (PST), Doug White
<dwhite@gumbysoft.com> wrote:
> On Tue, 7 Dec 2004, Arjan Van Leeuwen wrote:
> 
> > > > In other words, exactly the same thing. I should also note
that
> > > > earlier versions of 5-CURRENT worked correctly (-CURRENT
from june 7).
> > > > Is there anything else I could try?
> > >
> > > Replace the motherboard?  :) The i8254 hasn't changed in
years, so I doubt
> > > we're programming it wrong.  Something along the way is
applying a /2
> > > divisor.  Maybe its been broken forever and you only recnetly
noticed due
> > > to the HZ change?
> >
> > Heh :).
> >
> > No, this is on 5.3-RELEASE and I've been running with HZ=1000 for
a
> > long time, because I use DUMMYNET.
> 
> Good to know. Can you try booting an old kernel, or booting 5.2.1-R and
> see if it shows up there too?  If it works with 5.2.1, then I'd start
> playing the binary-search game to find the commit(s) that broke you.
Sorry for the late reply, I needed some time to try out older kernels.

Looks like it's a hardware fault. Kernels that worked correctly in the
past have the same problems if I boot them now. It probably had
nothing to do with me upgrading to 5.3-RELEASE at all.

Thanks for the help,

Arjan