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

From: Vivek Goyal
Date: Wed Jun 08 2005 - 06:26:53 EST


> >
> > > > 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/