Date: Tue, 27 May 2003 22:09:06 +0200 From: Dag-Erling Smorgrav <des@ofug.org> To: Roberto Nunnari <nunnari@die.supsi.ch> Cc: current@freebsd.org Subject: Re: Timecounter "TSC" frequency 451024462 Message-ID: <xzpk7ccw3rx.fsf@flood.ping.uio.no> In-Reply-To: <3ED36435.8090502@die.supsi.ch> (Roberto Nunnari's message of "Tue, 27 May 2003 15:12:21 %2B0200") References: <3ED32141.3080608@die.supsi.ch> <xzpy90swq1i.fsf@flood.ping.uio.no> <3ED36435.8090502@die.supsi.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
Roberto Nunnari <nunnari@die.supsi.ch> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpk7ccw3rx.fsf>