Re: [patch] genirq: do not mask interrupts by default

[Ingo Molnar <mingo@elte.hu>]

* Linus Torvalds <torvalds@osdl.org> wrote:

> On Wed, 15 Nov 2006, Ingo Molnar wrote:
> > 
> > problem is, we dont know /for a fact/ that something is "APIC-edge". 
> > We only know that the BIOS claims it that it's so.
> 
> This is incorrect. We will have _programmed_ the APIC with whatever 
> the BIOS said in the MP tables, so if we think it's level triggered, 
> it _is_ level triggered.

yeah. I was thinking about the low 16 irqs (those are really the problem 
spots most of the time, not the normal IO-APIC irqs) - which are routed 
all across the southbridge and might end up being handled by a 
i8259A-lookalike entity. Right now we default to level-triggered IRQ 
flow handling:

                if (i < 16) {
                        /*
                         * 16 old-style INTA-cycle interrupts:
                         */
                        set_irq_chip_and_handler_name(i, &i8259A_chip,
                                                      handle_level_irq, "XT");

because that's the best we can do (it's also what our i8259 code did 
historically). But it would be one step safer to also do the 
lazy-disable. Just in case things might get lost while masked. Or is 
that an absolutely horrible hardware breakage that i shouldnt worry 
about?

> So I really think that all the arguments for i8259 not wanting replay 
> weigh equally on level-triggered PCI irq's too.
> 
> Now, the one thing that makes me think your approach is the right one 
> is that it's potentially going to be better performance - if people 
> disable irq's and the normal case is that no irq will actually happen, 
> then optimistically not doing anything at all (except marking the irq 
> disabled, of course) is always good.
> 
> However, because it's a semantic change, I _really_ don't want to do 
> it right now. We're maybe a week away from 2.6.19, and the "ISA irq's 
> don't work" report is one of the things that is holding things up 
> right now.
>
> So that's why I'd much rather go with Eric's patch for now - because 
> it keeps the semantics that we've always had.

ok, i'm fine with Eric's patch too, if it solves Komuro's problem:

  Acked-by: Ingo Molnar <mingo@elte.hu>

and we dont have to worry about the present ugliness of the 
delayed-disabled flag either, as it would just go away in 2.6.20.

	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/