aboutsummaryrefslogtreecommitdiff
path: root/arch/i386/Kconfig
diff options
context:
space:
mode:
authorDimitri Sivanich <sivanich@sgi.com>2006-09-26 10:52:34 +0200
committerAndi Kleen <andi@basil.nowhere.org>2006-09-26 10:52:34 +0200
commitcbf9b4bb76c9ce53b7fdde0dffcd000951b5f0d4 (patch)
tree0942698b5aef01d2b89fe04111f7ba40b28865f0 /arch/i386/Kconfig
parentd28c4393a7bf558538e9def269c1caeab6ec056f (diff)
[PATCH] X86_64 monotonic_clock goes backwards
I've noticed some erratic behavior while testing the X86_64 version of monotonic_clock(). While spinning in a loop reading monotonic clock values (pinned to a single cpu) I noticed that the difference between subsequent values occasionally went negative (time going backwards). I found that in the following code: this_offset = get_cycles_sync(); /* FIXME: 1000 or 1000000? */ --> offset = (this_offset - last_offset)*1000 / cpu_khz; } return base + offset; the offset sometimes turns out to be 0, even though this_offset > last_offset. +Added fix From: Toyo Abe <toyoa@mvista.com> The x86_64-mm-monotonic-clock.patch in 2.6.18-rc4-mm2 made a change to the updating of monotonic_base. It now uses cycles_2_ns(). I suggest that a set_cyc2ns_scale() should be done prior to the setup_irq(). Because cycles_2_ns() can be called from the timer ISR right after the irq0 is enabled. Signed-off-by: Toyo Abe <toyoa@mvista.com> Signed-off-by: Dimitri Sivanich <sivanich@sgi.com> Signed-off-by: Andi Kleen <ak@suse.de>
Diffstat (limited to 'arch/i386/Kconfig')
0 files changed, 0 insertions, 0 deletions