dead hvc_console with kdump kernel

Milton Miller miltonm at bga.com
Thu Mar 9 12:12:32 EST 2006


On Mar 8, 2006, at 3:31 PM, Benjamin Herrenschmidt wrote:

>
>> On real xics it is safe to do in the initial register irq.  Don't
>> do it every irq register though.
>>
>> Hypervisor will cover us for emulated xics if we do that.
>>
>> For real mpic?  I don't know.  Maybe we do an mpic reset and that
>> will cover us?  Ben?
>
> We should probably eoi all pending interrupts. That's especially true
> with machines with HT APICs like the js2x or the quad g5 since if we
> don't EOI on the APIC, the interrupt will remain blocked.

and later:
> To be more complete, what about a loop that iterates all irq_desc, and
> for each of them does
>
> disable_irq()
> if (desc->handler->end)
>     desc->handler->end()
>
> Or something like that... you could try to test the PENDING and
> INPROGRESS flags maybe though that wouldn't handle IPIs (but then, I
> think there should be no problem with those if we do an MPIC reset, not
> 100% clear there)

The problem is this is counter to the goal of kdump trusting anything
in the old kernel when going to the new kernel.  In fact this would be
walking dynamic data structures.

Also, does it cover us on interrupts that are sent against a cpu that
we choose not to online in the second kernel?  Or interrupts that are
sent after the loop (devices are not stopped at that point)

Hence the asked question, does the reset cover us?

This can now be tested expermentially with Michael's debugfs
patch harness.

milton




More information about the Linuxppc64-dev mailing list