> [...]
> various programs get killed by the kernel when gettimeofday
> gets a div by 0 fault about 7 hours later. They all die within seconds
> of each other, and any subsequent program trying to use gettimeofday
> also triggers the problem.
> [...]
> I've got a Cyrix 6x86MX with suspend on idle turned on, and I don't
> use APM.
That is a known problem of Cyrix with "suspend on idle" - but
the real microprocessor bug is still IMHO not clearly identified.
The gettimeofday uses the internal "cycle" counter, which happens
to give twice the same value, even if some assembly instructions
have been executed in between the "rdtsc" instruction, if one of
those middle instruction is "hlt".
I cannot test anything (lack of hardware/time) but I have maybe
an explanation: The TSC is only activated after the first use of it,
following a power-on or a suspend; i.e. it is only counting after
the first "rdtsc".
It is easy to show if I am stupid (and should not have written
this message) or not, apply this (hand-edited) one-line patch to
"arch/i386/kernel/process.c" on 2.1.122 (only for UP 586+, no SMP):
asmlinkage int sys_idle(void)
{
unsigned long start_idle = 0;
int ret = -EPERM;
lock_kernel();
if (current->pid != 0)
goto out;
/* endless idle loop with no priority at all */
current->priority = 0;
current->counter = 0;
for (;;) {
/*
* We are locked at this point. So we can safely call
* the APM bios knowing only one CPU at a time will do
* so.
*/
if (!start_idle) {
check_pgt_cache();
start_idle = jiffies;
}
if (jiffies - start_idle > HARD_IDLE_TIMEOUT)
hard_idle();
else {
if (boot_cpu_data.hlt_works_ok && !hlt_counter &&
!current->need_resched)
__asm__("hlt");
}
+ __asm__ __volatile__ ("rdtsc" : : : "eax", "edx");
run_task_queue(&tq_scheduler);
if (current->need_resched)
start_idle = 0;
schedule();
}
ret = 0;
out:
unlock_kernel();
return ret;
}
Etienne.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/