Re: the ppc_n_lost_interrupts thing...

Benjamin Herrenschmidt wrote:

quoted

However,
what I don't understand is - how could this possibly detect an
interrupt that happens while the CPU is blocking external
interrupt?
In this case, ppc_n_lost_interrupts won't be incremented and when
the external interrupt is re-enabled, we won't be able to get
into interrupt mode.

The interrupt will be lost only when it's masked in the controller while
beeing issued by the device. It's a PIC bug.

Hmm, I assume that not every power pc board would have this problem.
Which PIC is having this problem?  The one used in Mac?

If this is the case, it would be nice that the workaround code can be
put in the #ifdef scope.  Just a thought.

So, we need to check it out only when unmasking the interrupt -in the
controller-. That's what we do in pmac-pic.c. If interrupts are masked on
the CPU but not on the controller, they are not lost. If they are masked
in both, it's not a problem neither, at least until someone tries to
umask one in the controller.

Note that our implementation if restore_flags() will check
lost_interrupts since the unmask call can be done while MSR_EE is 0.

Thanks a lot.  I got it.

Jun

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/