From owner-cvs-all  Sun Nov 29 12:47:09 1998
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id MAA02747
          for cvs-all-outgoing; Sun, 29 Nov 1998 12:47:09 -0800 (PST)
          (envelope-from owner-cvs-all@FreeBSD.ORG)
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA02742;
          Sun, 29 Nov 1998 12:47:06 -0800 (PST)
          (envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
	by critter.freebsd.dk (8.9.1/8.8.5) with ESMTP id VAA09483;
	Sun, 29 Nov 1998 21:46:45 +0100 (CET)
cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/kern kern_clock.c 
In-reply-to: Your message of "Sun, 29 Nov 1998 12:31:03 PST."
             <199811292031.MAA00945@freefall.freebsd.org> 
Date: Sun, 29 Nov 1998 21:46:45 +0100
Message-ID: <9481.912372405@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk


Here is the freshly submitted FAQ on this one:

Q:  My machine prints "calcru: negative time..."
Q:  My machine shoots processes down with "SIGXCPU exceeded cpu time limit"

A: (FreeBSD-3 from 1998/11/29 forward):  This can be caused by
various hardware and/or software ailments relating to interrupts.
It may be due to bugs but can also happen by nature of certain
devices.  Running TCP/IP over the parallel port using a large MTU
is one good way to provoke this problem.  Graphics accellerators
can also get you here, in which case you should check the interrupt
setting of the card first.

If the problem cannot be fixed otherwise the solution is to set
this sysctl variable:

	sysctl -w kern.timecounter.method=1

This means a performance impact, but considering the cause of this
problem, you probably will not notice.  If the problem persists,
keep the sysctl set to one and set the "NTIMECOUNTER" option in
your kernel to increasingly larger values.  If by the time you have
reached "NTIMECOUNTER=20" the problem isn't solved, interrupts are
too hosed on your machine for reliable timekeeping.

>phk         1998/11/29 12:31:03 PST
>
>  Modified files:
>    sys/kern             kern_clock.c 
>  Log:
>  Make the previous behaviour the default, add a sysctl which you
>  can set if your hw/sw produces the "calcru negative..." message.
>  
>  Setting the alternate method (sysctl -w kern.timecounter.method=1)
>  makes the the get{nano|micro}*() functions call the real thing at
>  resulting in a measurable but minor overhead.
>  
>  I decided to NOT have the "calcru" change the method automatically
>  because you should be aware of this problem if you have it.
>  
>  The problems currently seen, related to usleep and a few other corners
>  are fixed for both methods.
>  
>  Revision  Changes    Path
>  1.86      +42 -12    src/sys/kern/kern_clock.c
>

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
"ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message