From owner-cvs-all  Wed Jul 28 13:23:12 1999
Delivered-To: cvs-all@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id B51861544B; Wed, 28 Jul 1999 13:23:10 -0700 (PDT)
	(envelope-from msmith@FreeBSD.org)
Received: (from msmith@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) id NAA25414;
	Wed, 28 Jul 1999 13:22:31 -0700 (PDT)
	(envelope-from msmith@FreeBSD.org)
Message-Id: <199907282022.NAA25414@freefall.freebsd.org>
From: Mike Smith <msmith@FreeBSD.org>
Date: Wed, 28 Jul 1999 13:22:31 -0700 (PDT)
To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: cvs commit: src/sys/i386/apm apm.c apm_setup.s apm_setup.h
         src/sys/i386/isa clock.c
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

msmith      1999/07/28 13:22:31 PDT

  Modified files:
    sys/i386/apm         apm.c apm_setup.s 
  Removed files:
    sys/i386/apm         apm_setup.h 
  Log:
  Remove unused real-mode APM setup support.  We've been using the vm86
  mode initialiser for a while now, and it's looking happy.
  
  Revision  Changes    Path
  1.93      +14 -3     src/sys/i386/apm/apm.c
  1.14      +3 -159    src/sys/i386/apm/apm_setup.s


  Modified files:
    sys/i386/isa         clock.c 
  Log:
  We're called too early to have any idea whether APM is going to be
  active or not.  The only sane thing we can do here is assume that if
  APM is supported it might be active at some point, and bail.
  
  In reality, even this isn't good enough; regardless of whether we support
  APM or not, the system may well futz with the CPU's clock speed and throw
  the TSC off.  We need to stop using it for timekeeping except under
  controlled circumstances.  Curse the lack of a dependable high-resolution
  timer.
  
  Revision  Changes    Path
  1.141     +7 -11     src/sys/i386/isa/clock.c



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