Messages in this thread | | | Date | Wed, 15 Nov 2006 18:46:04 +0100 | From | Ingo Molnar <> | Subject | Re: [patch] genirq: do not mask interrupts by default |
| |
* 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/
| |