Re: [Fastboot] Re: [RFC/PATCH] Kdump: Disabling PCI interrupts in capture kernel

[Vivek Goyal <vgoyal@in.ibm.com>]

> > 
> > > > Shared interrupts are an interesting case.  The simplest solution I can
> > > > think of for a crash dump capture kernel is to periodically poll
> > > > the hardware, as if all interrupts are shared.  At that level
> > > > I think we could get away with ignoring all hardware interrupt sources.
> > > 
> > > Yes, that's perfectly ok. We are no longer in a multitasking env.
> > 
> > Well we are at least capable of multitasking but that is no longer the
> > primary focus.  Having polling as at least an option should make
> > debugging easier.  Last I looked Andrews kernel hand an irqpoll option
> > to do something very like this.
> > 
> 
> If I understand this right, the idea is that let all irqs be masked (except
> timer one) and invoke all the irq handlers whenever a timer interrupt occurs.
> This will automatcally be equivalent to drivers polling their devices for
> any interrupt.
> 
> As you mentioned that irqpoll option comes close. If enabled, it invokes
> all the irq handlers on every timer interrupt (IRQ0). The only difference is 
> that irqs are not masked (until and unless kernel masks these due to excessive
> unhandled interrupts). 
> 
> I tried booting kdump kernel with irqpoll option. It seems to be going 
> little bit ahead than previous point of failure (boot without irqpoll) but
> panics later. Following is the stack trace.
> 

Second kernel booted fine with MPT_DEBUG_IRQ enabled (with irqpoll option). 
There were few warning messages though spitted by the code under MPT_DEBUG_IRQ.

Looks like drivers need to be hardened on case to case basis to initialize 
properly even if underlying device is not in a reset state.

Thanks
Vivek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/