Date: Sun, 12 Feb 2006 21:59:01 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Yuriy Tsibizov <Yuriy.Tsibizov@gfk.ru> Cc: freebsd-current@freebsd.org Subject: Re: calcru: runtime went backwards Message-ID: <30864.1139781541@critter.freebsd.dk> In-Reply-To: Your message of "Sun, 12 Feb 2006 23:34:38 %2B0300." <20060212225911.M598@free.home.local>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20060212225911.M598@free.home.local>, Yuriy Tsibizov writes: >> The other side of this is that I've been looking at having the >> ACPI power management code announce the maximum speed of the TSC >> to the cputick code, that would make such machines "fixed frequency" >> cpu_tick machines from the start and even if enabled, this warning >> should not issue in that case. >I have CPU (AMD K6) with TSC, but my motherboard (ASUS TX97) does not >support ACPI. This combination can also be treated as a "fixed frequency" >machine. The trouble really is that there is no way to tell if the TSC is fixed frequency. Some of the machines where it is variable can tell us that it is variable (ie: ACPI is enabled) and some subset of those may be able to tell what the max is and this effectively make it fixed. For a fixed machine which is treated as variable, what will happen is that the 16 second calibration will keep finding close to the same number. Every so often however, a slightly higher number will be found and then this message may occur... As I said: I may simply hide the message for for machines with variable cpu_tick (even if it is in reality fixed). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?30864.1139781541>