Date: Sat, 12 May 2007 04:32:11 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Tom Evans <tevans.uk@googlemail.com> Cc: freebsd-stable@freebsd.org, martin.dieringer@gmx.de Subject: Re: clock problem Message-ID: <Pine.BSF.3.96.1070512033726.21240C-100000@gaia.nimnet.asn.au> In-Reply-To: <1178900585.1231.63.camel@zoot.mintel.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 11 May 2007, Tom Evans wrote: > On Fri, 2007-05-11 at 08:53 -0600, M. Warner Losh wrote: > > In message: <20070511110759.L700@thinkpad.dieringer.dyndns.org> > > Martin Dieringer <martin.dieringer@gmx.de> writes: > > : This is NOT a hardware problem. 1. I have this on 2 machines, 2. the > > : problem is solved by switching to ACPI instead of APM > > > > It is a hardware problem. APM + powerd changes the frequency of the > > TSC. If the TSC is used as the time source, then you'll get bad > > timekeeping. ACPI uses its own frequency source that is much more > > stable and independent of the TSC, so switching to it fixes the > > problem because you are switching the hardware from using a really bad > > frequency source with ugly steps to using a good frequency source w/o > > steps. > > > > Warner Yes, but Martin already showed it was using the i8254, not TSC; would you expect the same effect using powerd with the i8254 clock? It seems so, unless it's some problem with est and/or p4tcc under APM (canoworms) Runnning APM, at least on my ol' Compaq 1500c 5.5-S running APM - really too ancient to expect ACPI to work properly - on verbose boot states: Calibrating clock(s) ... i8254 clock: 1193216 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 300011839 Hz [..] TSC timecounter disabled: APM enabled. <<<<<<<<<<<< Timecounter "TSC" frequency 300011839 Hz quality -1000 ie: kern.timecounter.hardware: i8254 kern.timecounter.choice: TSC(-1000) i8254(0) dummy(-1000000) > Surely that would imply that it is a software misconfiguration issue. If > the TSC is unreliable under fairly standard duties, and there exists an > alternate source that is reliable, surely that indicates the > manufacturer has identified a problem, and solved it with alternate > hardware. > > The failure then to use the correct hardware is a software > misconfiguration. If one considers disabling ACPI and enabling APM misconfiguration .. which in Martin's case it turned out to be, since his ACPI works, but est0: <Enhanced SpeedStep Frequency Control> on cpu0 p4tcc0: <CPU Frequency Thermal Control> on cpu0 apm0: <APM BIOS> on motherboard apm0: found APM BIOS v1.2, connected at v1.2 together with powerd appeared to heavily retard time on both laptops, beyond ntpd's ability to cope. Cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1070512033726.21240C-100000>