Date: Sat, 5 Jul 2008 12:12:09 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Nate Lawson <nate@root.org> Cc: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>, freebsd-acpi@FreeBSD.org Subject: Re: HP/Compaq nx6325 clock "jumping around" Message-ID: <20080705120027.G12725@delplex.bde.org> In-Reply-To: <486E4DE7.60807@root.org> References: <20080702191827.GK1469@uriah.heep.sax.de> <20080703145049.S6189@delplex.bde.org> <486E4DE7.60807@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 4 Jul 2008, Nate Lawson wrote: >> On Wed, 2 Jul 2008, Joerg Wunsch wrote: >> ... > Bruce Evans wrote: >> I know of the following bugs in time on nx6325: > ... > > This reminds me -- the algorithm for estimating the cpu frequency needs > improvement. You had a patch you sent me that reduced its error by a lot. > Would you commit it? I'm further than ever from committing this, since I'm not set up for svn. I never merged this to the kernel. Running it in userland on more SMP machines shows the expected problems from the CPU not being pinnable in userland. >> dev.cpu.0.freq: 1985 >> dev.cpu.0.freq_levels: 1985/-1 1736/-1 1488/-1 1240/-1 992/-1 744/-1 496/-1 >> 248/-1 >> >> Once I used some performance/power-reduction config and got a list like >> yours. >> >> 1985 actually gives 1995 MHz. > > Your freq estimation patch does better than this. Aren't the above frequencies just read from acpi read-only data? I forgot to mention another MI problem with cpu_ticker frequency recalibration: its sanity checks don't detect even the enormous transient garbage caused by stopping clocks. Apparently all the clocks used in the sanity checks are stopped too synchronously. Otherwise, the recalibration is very accurate. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080705120027.G12725>