From owner-cvs-all Mon Nov 30 06:32:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA02800 for cvs-all-outgoing; Mon, 30 Nov 1998 06:32:49 -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 GAA02791; Mon, 30 Nov 1998 06:32:45 -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 PAA12217; Mon, 30 Nov 1998 15:31:46 +0100 (CET) To: Mike Smith 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 "Mon, 30 Nov 1998 06:10:29 PST." <199811301410.GAA03905@dingo.cdrom.com> Date: Mon, 30 Nov 1998 15:31:46 +0100 Message-ID: <12215.912436306@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk In message <199811301410.GAA03905@dingo.cdrom.com>, Mike Smith writes: >> In message <199811301338.FAA03590@dingo.cdrom.com>, Mike Smith writes: >> >> 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. >> > >> >The sysctl should be automatically set by the "calcru negative ..." >> >detection code. >> >> No, because at that time you clock has already been warped out of >> shape. People need to know and be aware that their sw/hw has a problem. > >Since we can't do this except by screwing up, and for that one time you >can fudge things so that they're not fatal, I think this is a better >approach. No. I have no way from the kernel to make the change persistent, so it would have to mess up once per boot. >If you're suggesting that the only workaround for this so-called >"broken" hardware is to degrade all of our timekeeping resolution to >+/- 1 second, then I think that "botch" is being far too kind. No, precision is actually better for some operations which don't need it, on the downside they take longer time than they would on non-broken hardware. >I hope I'm misreading you here; you are. >I can't see where you get off >suggesting that the calcru problems are "rare"; I've seen them on every >Alpha I've used, for example, and I simply don't buy that they're >something that can't be dealt with correctly in software. Everyone >else seems to get it right; we should too. What is our HZ on alpha ? How high a NTIMECOUNTER do you need to solve it for alpha with method=0 ? Does method=1 solve the problem for alpha ? -- 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