HP/Compaq nx6325 clock "jumping around"
brde at optusnet.com.au
Fri Jul 4 14:27:30 UTC 2008
On Wed, 2 Jul 2008, Joerg Wunsch wrote:
> On a nx6325 running 6-stable (because I couldn't get 7.x to work with
> ACPI at all so far), the main clock is frequently "jumping", up to a
> level where ntpd eventually gives up:
Try 7.x. 6.x never worked right for me on this machine, due to lapic
timer bugs which might be fixed now, while 7-CURRENT started working
right except for suspend and lid switch once the lapic timer bugs and
minor battery bugs were fixed, and 7-CURRENT and 8-CURRENT haven't
regressed in compatibility since then. I didn't try amd64 mode until
after the bugs were fixed, and it worked immediately with late
7-CURRENT after rcp'ing ~5.2 userland and updating the kernel.
> Jul 2 10:44:44 remi ntpd: time reset +11.885037 s
> Jul 2 10:44:44 remi ntpd: kernel time sync disabled 6041
> Jul 2 10:54:24 remi ntpd: kernel time sync disabled 2041
> Jul 2 11:07:13 remi ntpd: kernel time sync enabled 2001
> Jul 2 19:03:17 remi ntpd: time correction of 1785 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.
I know of the following bugs in time on nx6325:
- pressing the lid switch to turn the screen off makes the time jump by
almost precisely 1 second using any timecounter. The system appears
to spend the 1 second in something like SMM mode with all interrupts
and all timecounters stopped. More precisely, the jump is:
ACPI-fast and TSC: -1.000000 +- 10 uS
i8254: -1.043000 +- 1 mS
- pressing the lid switch to turn the screen on makes the time jump by
55 +- 1 mS with the i8254 timecounter. The magic 55 is 1 i8254 timer
maximum count (65536 / 1193182 = 0.054925. (65536 is with acpi_timer;
otherwise at least FreeBSD's max count would be ~11920 giving a magic
10). Apparently, SMM restarts and/or reloads all the timercounter's
hardware, but makes a larger mess of it for the i8254. Not making
a mess of it is harder than for the other timecounter hardware, since
the others have a granularity of 1 cycle while the i8254 has a
granularity of 65536 or 11920 cycles unless it is carefully synced
with the OS software which SMM can't do. The magic 43 for screen
off is presumably the magic 55 reduced a bit by other bugs.
- dynamic recalibration of cpu_tick_frequency has never worked. This
is a MI bug, and only affects process times. cpu_tick_frequency is
never adjusted downwards (except for a full recalibration). Thus
any glitches in the cpu_tick clock (TSC on nx6325), e.g., from the
SMM bug or entering ddb) cause cpu_tick_frequency to creep or jump
upwards and never come down.
Maybe you have a dynamic cause of events like the lid switch. I don't
see any problems except with time except the above.
> Notice the huge time resets of about 900 seconds between. Could this
> be related to CPU frequency changes caused by whomever might control
> that (ACPI BIOS? powerd is not running, should I?)? The CPU
> frequencies listed are:
> dev.cpu.0.freq: 1393
> dev.cpu.0.freq_levels: 1990/100000 1791/81822 1592/65808 1393/57582 1194/49356 995/41130 796/22152 696/19383 597/16614 497/13845 398/11076 298/8307 199/5538 99/2769
I don't use powerd and rarely use batteries. Suspsend stuff doesn't
work in FreeBSD, perhaps because I have no acpi support newer than
~5.2 in userland (powerd doesn't exist), and battery life at max CPU
is about 30 minutes. makeworld of ~5.2 over nfs takes 13 minutes 40
seconds. nx6325 doesn't run ~5.2 kernels (problems in video, ata and
acpi) or early (?) 6.x kernels with lapic timer.
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.
More information about the freebsd-acpi