Messages in this thread | | | Date | Fri, 10 Aug 2007 10:56:11 +0200 | From | Ingo Molnar <> | Subject | Re: 2.6.23-rc2: WARNING: at kernel/irq/resend.c:70 check_irq_resend() |
| |
* Jarek Poplawski <jarkao2@o2.pl> wrote:
> > > [...] Well, there are probably (but need more testing) two other > > > solutions: _SW_RESEND and disabling without delay for levels > > > only... > > > > IIRC Marcin tested software-resend and it didnt fix the hang. That > > strongly points in the direction of a driver bug (or a genirq bug) > > being made more prominent by the genirq change - not any hardware > > detail such as the APIC vector-retrigger sequence. > > > > While we'd like to see the suspected driver bug (or any higher level > > genirq bug) fixed, we'll undo the effect of the genirq change > > (because it is causing a regression). We'll also add a separate, > > optional irq-debugging feature that generates high-rate interrupts > > on any shared irq line. (and thus artificially stresses the > > robustness of the driver and the genirq layer against spurious > > interrupts.) > > Not exactly so... I've send modified version of your software-resend > patch, and it seems to work OK.
ah, i completely missed that! Thanks :-)
this changes the picture completely and makes the IO-APIC/local-APIC hw retrigger code/logic the main suspect. I think you right that it's quite bogus to hw-retrigger level irqs, and that could be confusing the IO-APIC (or the local APIC, or both).
and i think i see why my first sw-resend patch didnt do the trick:
> > - if (!desc->chip || !desc->chip->retrigger || > > - !desc->chip->retrigger(irq)) { > > + if (desc->handle_irq == handle_edge_irq) { > > + if (desc->chip->retrigger) > > + desc->chip->retrigger(irq); > > + return; > > + } > > #ifdef CONFIG_HARDIRQS_SW_RESEND
we used the hw-resend method unconditionally, right?
Ingo - 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/
| |