> It' s not. I catched very big problems in the do_fast_gettimeoffset() at
> least. In such function the jiffies static initialization change cause
> problems (just fixed also in other arch).
>
> Seems that such function cause a div_by_zero fault if run when jiffies ==
> 0 if I understand well this:
>
> (divl %2) == (dx:ax / %2)
>
> Unfortunately I had not time to understand what do_fast_gettimeoffset()
> does, I was going to work on it now.
Unfortunately I had time and reason to figure out what it does ;-<
It tries to do the following: assume that we last time we got a timer
interrupt we were at J jiffies from the boot and N TSC ticks from the same
event. We are called between two timer interrupts and want to figure out
how many time passed since the last one. Fine, just read the current TSC
value (say it, N1) and try the following:
((N1-N)*J/N)*(time_units_per_jiffie)
Since J/N ratio changes only on timer interrupts we can try to push
division out of the main branch. The problem occurs when J/N (actually
J*2^32/N; trivial scaling) goes too high. It _can_ happen on braindead
processors that don't increase TSC when they are halted (in theory TSC
should be increased on each CLOCK signal). Kernel doesn't like the idea of
being run on sub-MHz processor ;-/ You can fix it by checking for too
low values of N (and assuming that in this case we should return
1/100sec), but actually we shouldn't use do_fast_gettimeofday() on such
processors.
It's pretty spectacular: write a trivial program that reads
/dev/kmem and computes the ratio. You'll see how it drops when system is
inactive. Usually you start with something around the actual clock rate of
your processor (scaled) due to the activity on the boottime. After a while
it decreases. When it reaches 1000 (IIRC) programs doing gettimeofday()
begin to oops. wc </dev/hda "fixes" the situation...
-
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/