Messages in this thread | | | Subject | Re: [patch] io-apic-2.1.98-B | From | Claus-Justus Heine <> | Date | 27 Apr 1998 02:32:02 +0200 |
| |
MOLNAR Ingo <mingo@chiara.csoma.elte.hu> writes:
> On 27 Apr 1998, Claus-Justus Heine wrote: > > > > I've attached a patch against vanilla-2.1.98 that works even on insane > > > hardware like NE2000 cards and shared PCI devices, survives 30 minutes > > > > If I understand your code right, then in order to enable a previously > > disabled interrupt one has to call enable_irq() as many times as > > disable_irq() previously has been called. Is this the intended > > behavior? I thought enable_irq() should re-enable the interrupt > > unconditionally? <-- question, I'm just unsure about it. > > yes you are right, it should enable them unconditionally. There was a > warning in earlier ioapic code, and only floppy.c used them in an > 'unbalanced' way. (floppy.c enabled IRQ6 twice, i reported this) > > but most drivers use dis/enable_irq() in a 'balanced' way, thus there > should be no difference in behavior. Personally i liked that nested > dis/enable_irq() version as it _did_ show us a floppy.c bug, but maybe it > can be abused in drivers, so it should probably be changed back to the > original behavior. (yes i think it should be changed back, there is no > good reason to change the driver-API)
I really think that it should be changed back for the same reason. Thinking e.g. of loadable kernel modules the nested enable/disable_irq() approach would make the kernel remember the enable/disable_irq() balance history accross loading of possibly different modules that happen to use the same resources. Maybe floppy driver versus ftape driver. Actually, enable_irq() used to enable the interrupt unconditionally on UP machines.
Looking at your new irq.c code, I think it would suffice to change the meaning of the counter "disabled_irq[irq]" to be a mere flag.
I still wonder why it should be necessary to call the interrupt handler chain more often than once in case more than a single interrupt has accumulated while an IRQ was disabled? Would this be the case for the 8259A in the non-IO-APIC case? I don't think so.
Of course, if any number of interrupts of a given IRQ line has accumulated while that IRQ was disabled one needs to resend the IPI. I need this for ftape, too. But I don't see the point in counting the number of accumulated interrupts.
> > view said video again, and all is well. Even the floppy driver works again.
> here it breaks the NE2000 driver. (flood pinging causes interface hang, > this is because IRQs are lost with the counter-less approach)
BTW, Linus had the send_IPI() still disabled in his patch, did you enable it before testing with your NE2000?
Good night
Claus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |