[RFC/PATCH] powerpc: Fix kdump EOI bug (often exhibits as dead console)

Milton Miller miltonm at bga.com
Tue Mar 14 02:59:15 EST 2006

On Mar 13, 2006, at 2:44 AM, Benjamin Herrenschmidt wrote:

> On Mon, 2006-03-13 at 19:16 +1100, Michael Ellerman wrote:
>> If we take an interrupt, and while processing it, decide to kdump we 
>> never
>> EOI that interrupt. This can happen for any interrupt, but most 
>> commonly it's
>> the console interrupt from a user hitting 'sysrq-c', which prevents 
>> the
>> console from working in the second kernel.
>> We're panicking so we don't want to do any more than we need to in 
>> the first
>> kernel, so leave things alone there. When we come back up iff we 
>> reenable the
>> interrupt in question, do an EOI then. This fixes the bug for me, and 
>> appears
>> to cause no issue for other interrupts.
> You may want to do the same for mpic.c ...
> Ben.

Is that possible?   My memory says that, at least for the distributed 
pic in Power3 boxes, part of the information to do the EOI was 
remembered in a stack in the interrupt controller.  This means (1) the 
EOI must be issued from the processor server that took the interrupt, 
(2) there are a limited number of interrupts that can be presented 
before they are EOId (3) they must be EOId in reverse order.  (4) I 
don't know what happens if we issue and EOI with no hardware.  However, 
a write to the reset register sent a packet to all pics to reset them.

What we are doing here is a possibly extranious, third party EOI 
(device X interrupted cpu Y, and cpu Z is issuing the EOI to allow the 
device to reissue the interrupt).  For real XICS I know that is both 
possible and safe as long as the interrupt X exists; I am familiar with 
the hardware implementation.


More information about the Linuxppc64-dev mailing list