From owner-freebsd-current@FreeBSD.ORG Tue May 27 13:09:10 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA2F437B404 for ; Tue, 27 May 2003 13:09:10 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F2B443FA3 for ; Tue, 27 May 2003 13:09:09 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 537AA530E; Tue, 27 May 2003 22:09:07 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Roberto Nunnari References: <3ED32141.3080608@die.supsi.ch> <3ED36435.8090502@die.supsi.ch> From: Dag-Erling Smorgrav Date: Tue, 27 May 2003 22:09:06 +0200 In-Reply-To: <3ED36435.8090502@die.supsi.ch> (Roberto Nunnari's message of "Tue, 27 May 2003 15:12:21 +0200") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: current@freebsd.org Subject: Re: Timecounter "TSC" frequency 451024462 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2003 20:09:11 -0000 Roberto Nunnari writes: > What is interesting is that with 4.7-Stable the faulty timer was > handled correctly (or correctly ignored).. That's because 4.7 incorrectly fails to use ACPI to configure the system. As a result, 4.7 is unusable on newer laptops (which no longer support APM) and possibly also some high-end servers (where you need ACPI to figure out correct interrupt routing). > so I'd suggest to fix > in software the hardware bug in 5.1-Release, or at least in -current. There's no reliable way to do so. We *already* try to check that the clock we choose is correct. The best we can do is flag the chipset as known bad and never use the ACPI timer on that chipset, which will penalize motherboards which use this chipset but have correct ACPI tables. > I already had fixed it with sysctl, but I'll give a try to the > loader.conf solution as well. Using sysctl is an imperfect solution as the clock will run at double speed for a while before /etc/rc.d/sysctl is run. If you're running a lengthy fsck due to a power outage, that may be a long time. DES -- Dag-Erling Smorgrav - des@ofug.org