Reload the timer when TimerControl is written, if the timer is to be enabled. Otherwise, if an earlier write to TimerLoad was done while periodic mode was not set, s->delta may incorrectly still have the value of the maximum limit instead of the value written to TimerLoad.
This problem is evident on versatileap on current linux-next, which enables TIMER_CTRL_32BIT before writing to TimerLoad and then enabling periodic mode and starting the timer. This causes the first periodic tick to be scheduled to occur after 0xffffffff periods, leading to a perceived hang while the kernel waits for the first timer tick. Signed-off-by: Rabin Vincent <ra...@rab.in> --- hw/arm_timer.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/arm_timer.c b/hw/arm_timer.c index 9fef191..5b6947a 100644 --- a/hw/arm_timer.c +++ b/hw/arm_timer.c @@ -113,7 +113,7 @@ static void arm_timer_write(void *opaque, target_phys_addr_t offset, case 1: freq >>= 4; break; case 2: freq >>= 8; break; } - arm_timer_recalibrate(s, 0); + arm_timer_recalibrate(s, s->control & TIMER_CTRL_ENABLE); ptimer_set_freq(s->timer, freq); if (s->control & TIMER_CTRL_ENABLE) { /* Restart the timer if still enabled. */ -- 1.7.0.4