440GP system freezes with jiffies not incrementing?

David Adair dadair at ariodata.com
Tue Apr 5 06:40:20 EST 2005


I have a configuration where it appears that I have missed a decrementer
interrupt and the system gets frozen in the idle loop:

      Dec:  0           (interrupts on 1->0 transition)
      MSR[EE]: 1        (interrupt enabled)
      TSR[DIS]: 0       (no interrupt pending)

Since the decrementer interrupt occurs ONLY on the 1->0 transition
I'm not too sure how the system can get out of this state -- in my
particular case the answer is it gets a Watchdog timeout and reboots.

This occurs very rarely running a modified version of 2.4.28_pre3
on a custom board very similar to the Ebony.

I am very curious about the behavior of the code in arch/ppc/time.c
in the case where I manage to miss exactly 1 jiffy - IRQ service time:

int timer_interrupt(struct pt_regs * regs)
{
	int next_dec;
	unsigned long cpu = smp_processor_id();
	unsigned jiffy_stamp = last_jiffy_stamp(cpu);
	extern void do_IRQ(struct pt_regs *);

	if (atomic_read(&ppc_n_lost_interrupts) != 0)
		do_IRQ(regs);

	hardirq_enter(cpu);
	while ((next_dec = tb_ticks_per_jiffy - tb_delta(&jiffy_stamp))
< 0) {
		jiffy_stamp += tb_ticks_per_jiffy; 
<snip>
	}

	if ( !disarm_decr[smp_processor_id()] )
		set_dec(next_dec);
	last_jiffy_stamp(cpu) = jiffy_stamp;

}

Seems like the result is to go through the loop once and then program
the decrementer to 0, effectively disabling timer interrupts.

Also curious about exactly where disarm_decr() gets initialized.

I will be adjusting this and testing but it seems really strange
that I have the only setup that manages to hit just the right
timing -- is there someplace else where we would normally recover
from this situation?

Thanks
David







More information about the Linuxppc-embedded mailing list