Good morning (morning being that time after I wake up, without regard to the
wall clock, which, at the moment, reads 12:45 PDT).

We have an issue in the way that the microtime_func function pointer is set.
This function pointer is macroized into the microtime(9) call used all over
the kernel. I'm sending this to port-i386 because I'm dealing with this issue
on this platform, but NetBSD may have this "order of operations" issue in
other ports as well.

At compile time, it's set to i8254_microtime (which means, I guess, that all
i386 systems have an i8254 timer chip or core because there's no one driver
for it as such).

At boot time, in identifycpu(), various features of the system CPU(s) are
discovered, and for the WinChip C6 (and shortly for the Cyrix MediaGX (geode)
and its follow-ons when I commit that change) the CPUID_TSC bit is shut off
again in the NetBSD kernel's copy of the CPU features bitfield, because it's
known to be broken.

Unfortunately, the CPU specific cpu_setup() routine that turns off CPUID_TSC
is called in cpuinit() from i386/i386/cpu.c and by this time, microtime_func
is *already* set to cc_microtime (the generic CPU cycle clock register read
routine) at the bottom of identifycpu(), if TSC function is present in the
CPU features. The only way to prevent this is to also compile the kernel with

options         NO_TSC_TIME

which defeats the purpose of having cpuidentify turn off various known-broken
features.

I suggest that setting microtime_func = cc_microtime be done in cpu_init() in
i386/i386/cpu.c AFTER the call to the CPU-specific cpu_setup function that
gets initialized in identifycpu().

The main thing I want discussed here is whether that's "too late" in the system
initialization process, or would have some other "bad" effects.

Comments, please?

	Erik <fair@netbsd.org>