generic one-shot bug (was Re: sparc generic time / clockevents)

David Miller
2007-02-25T05:13:56Z

As I suspected, the one-shot code wasn't very well tested and I'd be
the one to debug this thing on sparc64 :-)

When a timer exceeds the timer period, the one-shot handling code does
the following loop:

for (;;) {
ktime_t next = ktime_add(dev->next_event, tick_period);

if (!clockevents_program_event(dev, next, ktime_get()))
return;
tick_periodic(cpu);
}

So it just keeps running tick_periodic() until we "catch up".

Problem is, if clockevents_program_event() gets a "next" time in the
past, the very case where we'll loop, it DOES NOT update
dev->next_event. It returns the error before doing so.

As a result of this, we'll loop forever here, the softlockup watchdog
will trigger, and the system will wedge completely.

I was getting a softlockup and immediate system hang, so to debug this
I kept a history of the last 8 TSC values when tick_periodic() was
invoked. At softlockup trigger, I'd dump the log. And what I saw
were TSC deltas that we so tiny as to be just enough to indicate
tick_periodic() was running in a tight loop :-)

I propose the following fix, which I'm about to test.

Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 4500e34..0986a2b 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -77,6 +77,7 @@ static void tick_periodic(int cpu)
void tick_handle_periodic(struct clock_event_device *dev)
{
int cpu = smp_processor_id();
+ ktime_t next;

tick_periodic(cpu);

@@ -86,12 +87,12 @@ void tick_handle_periodic(struct clock_event_device *dev)
* Setup the next period for devices, which do not have
* periodic mode:
*/
+ next = ktime_add(dev->next_event, tick_period);
for (;;) {
- ktime_t next = ktime_add(dev->next_event, tick_period);
-
if (!clockevents_program_event(dev, next, ktime_get()))
return;
tick_periodic(cpu);
+ next = ktime_add(next, tick_period);
}
}