From owner-freebsd-current  Sun Nov 29 06:51:15 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id GAA06364
          for freebsd-current-outgoing; Sun, 29 Nov 1998 06:51:15 -0800 (PST)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA06354;
          Sun, 29 Nov 1998 06:51:03 -0800 (PST)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id BAA24073;
	Mon, 30 Nov 1998 01:50:51 +1100
Date: Mon, 30 Nov 1998 01:50:51 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199811291450.BAA24073@godzilla.zeta.org.au>
To: elias@cnetworks.net, seggers@semyam.dinoco.de
Subject: Re: kern_clock.c (was: video mode switching has gone south)
Cc: current@FreeBSD.ORG, green@unixhelp.org, phk@FreeBSD.ORG
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>> I'm another one who can report somewhat new behaviour :
>> 
>> 1. X now starts up more slowly, with flicker.
>
>I think for me that's the case, too but is hard to judge.
>
>> 2. usleep(s), where s=1, 10, 100, 10000 sleeps for about 1 second,
>> regardless of argument.

It actually sleeps for an average of about half a second.

Everything that uses get{micro,nano}{,up}time (mainly timeouts) is broken
because the time reported by these functions now lags the actual time
by up to about 1 second.

Ignore the `force' flag to go back to the previous brokenness which
affects relatively few systems.

Bruce

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