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

Benjamin Herrenschmidt benh at kernel.crashing.org
Tue Mar 14 08:32:09 EST 2006


> 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.

We can maybe send the EOI's to all processor block (EOI registers have
separate addresses for each CPU). I'm sure if we did something like
sending 128 EOI to all CPUs it would keep the mpic quiet :) But them, if
an MPIC reset works, then go for it... though it will not be enough in
the case of HT APICs as I said earlier (thus on js20/21 & quad g5)

EOI on MPIC doesn't carry the irq number, the MPIC will automatically
EOI whatever was pending on that CPU.

So a sequence of:

 - disable all irqs
 - go through all HT APICs and disable all irqs & EOI them
 - either reset the MPIC or send a bunch of EOIs to each processor block

Would probably work 

Ben.




More information about the Linuxppc64-dev mailing list