lkml.org 
[lkml]   [1998]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [patch] io-apic-2.1.98-B
From
Date
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

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.199 / U:0.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site