Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Sep 1998 09:02:49 -0500 (EST)
From:      Alfred Perlstein <bright@hotjobs.com>
To:        Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc:        Mike Smith <mike@smith.net.au>, current@FreeBSD.ORG, bde@FreeBSD.ORG
Subject:   Re: Death by SIGXCPU (problems with our clock code) 
Message-ID:  <Pine.BSF.3.96.980917090033.17139A-100000@bright.fx.genx.net>
In-Reply-To: <8620.906017842@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
if it means anything i don't ever recall being smacked by this bug,
although on a machine that i set to EST instead of EDT (i'm in New York
City) all kinds of probelsm happened when compiling stuff with file dates 
being messed up. didn't have a chance to look into it.  and it could be
perfectly normal result of user error.

Alfred Perlstein - Programmer, HotJobs Inc. - www.hotjobs.com
-- There are operating systems, and then there's FreeBSD.
-- http://www.freebsd.org/                        3.0-current

On Thu, 17 Sep 1998, Poul-Henning Kamp wrote:

> 
> Mike,
> 
> >Since nobody else has taken up my suggestion to instrument the code to 
> >find out what's going on, I've shouldered the cross.  
> 
> I have my version here instrumented far more than what you've done,
> and I have two and a half extra kinds of timecounting hardware
> running here in my lab but I have not been able to catch it in
> flagrante delico yet, leading me to conclude that some hardware is
> involved.
> 
> The check in microtime and nanotime are strictly not valid.  The
> reason is that both microtime and nanotime are reentrant now, so
> you might take an interrupt in the middle of it. 
> 
> The reentrancy could possibly be a problem if some spl*() are missing
> somewhere else, or if logic is flawed in the code.  You can test
> that hypothesis by splalot() around the [get]{micro|nano}[run]time()
> functions.
> 
> I am puzzeled about the negative fractions and I think they are the
> most important clue.
> 
> tco_forward() does not do any sanity checks on the timecounter, so
> if there is some trouble with the hardware (or our method of
> accessing it), that would shine straight through.
> 
> Can you please add a check to the i8254/tsc get_timecount functions
> (in isa/clock.c) which report if the count goes backwards or is
> bigger than (1/HZ + epsilon) seconds ?
> 
> What machine is this on ?  
> 
> What is your timecounter TSC/i8254 ?
> 
> BIOS settings ?
> 
> Bruce: You mentioned that some i8254 cloneoids didn't implement
> the latch correctly any references to that ?
> 
> Poul-Henning
> 
> --
> 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 freebsd-current" in the body of the message
> 


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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980917090033.17139A-100000>