From owner-freebsd-current Thu Jul 16 02:01:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA12690 for freebsd-current-outgoing; Thu, 16 Jul 1998 02:01:46 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA12683 for ; Thu, 16 Jul 1998 02:01:40 -0700 (PDT) (envelope-from jak@cetlink.net) Received: from EXIT10 (i485-gw.cetlink.net [209.198.15.97]) by ns2.cetlink.net (8.9.1/8.9.1) with SMTP id FAA18163; Thu, 16 Jul 1998 05:01:20 -0400 (EDT) From: jak@cetlink.net (John Kelly) To: Bruce Evans Cc: current@FreeBSD.ORG Subject: Re: tickadj -t not changing tick Date: Thu, 16 Jul 1998 09:04:09 GMT Message-ID: <35afc126.212112276@mail.cetlink.net> References: <199807160853.SAA31913@godzilla.zeta.org.au> In-Reply-To: <199807160853.SAA31913@godzilla.zeta.org.au> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id CAA12684 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 16 Jul 1998 18:53:34 +1000, Bruce Evans wrote: >>>You want to fiddle kern.timecounter.frequency (units: Hz) or >>>kern.timecounter.adjustment (Units: PPM/2^16) >> >>Judging from what Bruce said, it seems that kern.timecounter.frequency >>is derived from the machdep.*_freq variables, so it would be better to >>change them and let the kernel propagate the changes. > >It would be nicest to change the machine-independent variables and let >the kernel propagate the changes to the machine-dependent variables and >hardware. However the kernel makes no attempt to propagate the changes. >OTOH, when you change the m-d variables, the kernel attempts to propagate >the changes, but it doesn't succeed (it sets the active frequency, >possibly causing a glitch due to the non-atomic update, and the change >gets blown away at the next clock interrupt). Argh! So should I change both kern.timecounter.frequency and the machine dependent variable? Will that work? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message