Re: [going OFF TOPIC] Re: do_fast_gettimeoffset oops explained (6x86MX Bug)

=?ISO-8859-1?Q?Andr=E9?= Derrick Balsa (
Fri, 15 May 1998 11:53:57 -0100

Hi Molnar,

MOLNAR Ingo wrote:
> On Fri, 15 May 1998, [ISO-8859-1] André Derrick Balsa wrote:
> > Unfortunately, nobody has come up with an APM-compatible
> > do_fast_gettimeoffset(). Yet. I am working on it.
> *cough*. What about the suggestion i made a few days ago, to put the
> following workaround into apm.c:APM_BIOS_CALL():

Sorry, I had discarded it because it was a hack of the apm driver code,
which I don't believe needs fixing. It also assumes the x86 CPU has a
TSC, which is not always true.

I would prefer to do everything inside /arch/i386/kernel/time.c,
dynamically switching between do_fast_gettimeoffset() and
do_slow_gettimeoffset(), based on the value of kernel-wide variables
called cpu_clock_stoppable and apm_enabled.

These variables could be set/reset by:

a) the CPU detection code in setup.c (where the K5 model 0 hack should
be moved, BTW) if a 6x86MX or a Centaur C6 are detected (for

b) the APM driver (which already has a local variable apm_enabled).

This would considerably simplify function time_init, and would allow
removing all the #ifndef APM_CONFIG in time.c.

It also means Pentium users with APM (e.g. portables) will still get the
faster, higher precision do_fast_gettimeoffset, as long as APM is
disabled i.e. one keeps the cake and eats it too, for once. :)

Do you think this is the correct approach, or otherwise how would you do

André Balsa

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to