From owner-freebsd-current Fri Oct 6 15:17:11 2000 Delivered-To: freebsd-current@freebsd.org Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by hub.freebsd.org (Postfix) with ESMTP id 6A6F837B503; Fri, 6 Oct 2000 15:17:06 -0700 (PDT) Received: from netch@localhost by burka.carrier.kiev.ua id BGO31522; Sat, 7 Oct 2000 01:17:03 +0300 (EEST) (envelope-from netch) Date: Sat, 7 Oct 2000 01:17:03 +0300 (EEST) Message-Id: <200010062217.BGO31522@burka.carrier.kiev.ua> From: netch@carrier.kiev.ua (Valentin Nechayev) To: John Baldwin , freebsd-current@FreeBSD.ORG Subject: Re: microuptime() went backwards User-Agent: tin/1.4.1-19991201 ("Polish") (UNIX) (FreeBSD/3.5-STABLE (i386)) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At Fri, 6 Oct 2000 22:00:23 +0000 (UTC), jhb wrote: JB> The problem was that the interrupt threads for the clk interrupt introduced JB> enough latency that occasionally (mostly during a heavy load of interrupts) JB> tc_windup() wasn't called soon enough to update the timecounter. Making On my system _each_ boot causes hundreds of these messages. And as described, long offsets without updating are caused by some code in drivers, i.e. DELAY(1000000) in isa/fd.c. Is it nesessary to call tc_windup() between iterations in isa_configure? ;| JB> clock interrupts not be threaded fixes this problem. Oh, well, I understand now that scheduling is nesessary to be run early because interrupts are implemented as kernel threads even when kernel is in phase of hardware detection.;( /netch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message