From owner-freebsd-current Thu Sep 17 06:08:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA04014 for freebsd-current-outgoing; Thu, 17 Sep 1998 06:08:51 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA04006; Thu, 17 Sep 1998 06:08:41 -0700 (PDT) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.8.8) with SMTP id JAA17147; Thu, 17 Sep 1998 09:02:49 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Thu, 17 Sep 1998 09:02:49 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: Poul-Henning Kamp cc: Mike Smith , current@FreeBSD.ORG, bde@FreeBSD.ORG Subject: Re: Death by SIGXCPU (problems with our clock code) In-Reply-To: <8620.906017842@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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