Messages in this thread | | | Date | Wed, 8 Jun 2005 16:53:46 +0530 | From | Vivek Goyal <> | Subject | Re: [Fastboot] Re: [RFC/PATCH] Kdump: Disabling PCI interrupts in capture kernel |
| |
> > > > > > 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/
| |