dead hvc_console with kdump kernel

[Michael Ellerman]

On Thu, 9 Mar 2006 12:12, Milton Miller wrote:
> 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.

Yeah I agree. Basically if we don't register the irq in the second kernel then 
we're better off just leaving it.

I can't think of a clean way to do this though, xics_enable_irq gets called 
multiple times and we don't want to end for each one, so we'd need to track 
that which gets ugly. It'd be nice to come up with a generic (non-xics) 
solution too. Still thinking.

cheers

-- 
Michael Ellerman
IBM OzLabs

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20060309/a9f5f19a/attachment.pgp