xtime is not properly incremented when main timer ticks are lost.
Whatever the number of ticks elapsed is, only one tick worth of time
is added to xtime. This patch fixes that.
Signed-off-by: Jiri Bohac <[email protected]>
Index: linux-2.6.19-rc5/kernel/timer.c
===================================================================
--- linux-2.6.19-rc5.orig/kernel/timer.c
+++ linux-2.6.19-rc5/kernel/timer.c
@@ -904,7 +904,7 @@ static void clocksource_adjust(struct cl
*
* Called from the timer interrupt, must hold a write on xtime_lock.
*/
-static void update_wall_time(void)
+static void update_wall_time(unsigned long ticks)
{
cycle_t offset;
@@ -915,7 +915,7 @@ static void update_wall_time(void)
#ifdef CONFIG_GENERIC_TIME
offset = (clocksource_read(clock) - clock->cycle_last) & clock->mask;
#else
- offset = clock->cycle_interval;
+ offset = ticks * clock->cycle_interval;
#endif
clock->xtime_nsec += (s64)xtime.tv_nsec << clock->shift;
@@ -1053,7 +1053,7 @@ void run_local_timers(void)
*/
static inline void update_times(unsigned long ticks)
{
- update_wall_time();
+ update_wall_time(ticks);
calc_load(ticks);
}
--
Jiri Bohac <[email protected]>
SUSE Labs, SUSE CR
On Thursday 16 November 2006 17:52, Jiri Bohac wrote:
> xtime is not properly incremented when main timer ticks are lost.
> Whatever the number of ticks elapsed is, only one tick worth of time
> is added to xtime. This patch fixes that.
Normally it is supposed to be called as often as there are missing
ticks (e.g. see s390 implementation of noidletick). This is also
true for non no idle tick - the hardware is not supposed to lose
interrupts.
You would need to change at least the existing noidletick implementations
in tree too.
Anyways, i'm sure it could be improved, but in .20 with dyntick
everything will be different anyways. I don't think it makes sense
to change now.
-Andi