From owner-svn-src-all@FreeBSD.ORG Fri Apr 8 22:29:25 2011 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40401106564A; Fri, 8 Apr 2011 22:29:25 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id B7C3D8FC19; Fri, 8 Apr 2011 22:29:24 +0000 (UTC) Received: from c122-106-155-58.carlnfd1.nsw.optusnet.com.au (c122-106-155-58.carlnfd1.nsw.optusnet.com.au [122.106.155.58]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p38MTLwu016611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Apr 2011 08:29:22 +1000 Date: Sat, 9 Apr 2011 08:29:21 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Jung-uk Kim In-Reply-To: <201104081954.p38JsTED090284@svn.freebsd.org> Message-ID: <20110409075110.L834@besplex.bde.org> References: <201104081954.p38JsTED090284@svn.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r220459 - head/sys/x86/isa X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 22:29:25 -0000 On Fri, 8 Apr 2011, Jung-uk Kim wrote: > Log: > Refactor DELAYDEBUG as it is only useful for correcting i8254 frequency. Er, DELAYDEBUG has nothing to do with the i8254 except that the non-i8254 case was broken (mostly in unreachable code, and missing instrumentation corresponding to the getit_calls counter). Now it is more broken -- e.g., configuring DELAYDEBUG now prevents the non-i8254 timers from even being compiled. The core of DELAYDEBUG was essentially just: for (n1 = 1; n1 <= 10000000; n1 *= 10) { printf("DELAY(%d)...", n1); DELAY(n1); printf("done\n"); } This could be in an extern function, and works for any implementation of DELAY(). You observe the resulting delays and fix them if they are too short or too long (the observation can only be done fairly accurately for the 2 or 3 final delays of 1/10, 1 and 10 seconds, unless these are very inaccurate). But it is implemented as a special state in DELAY() itself, with the printfs separate from the loop, for convenience and to allow the printfs to print implementation-specific details. Perhaps the complications for the state are not useful for debugging the i8254 case now, since the i8254 has a fixed frequency and is well understood and debugged. The delay_timecounter() case doesn't even need to be debugged at this level, since if the timecounter is broken then this will be obvious from userland. But the complications are useful for the delay_tsc() case, since the TSC doesn't have a fixed frequency and is often miscalibrated. Bruce