On Sun, 12 Mar 2000 yodaiken@fsmlabs.com wrote:
>
> So what happens on a uniprocessor when
> level triggered arrives
> no-ack dispatch of level trigger
> higher priority level arrives
> dispatch second driver
> ack.
>
> Acks are not vector specific, so does the unacked level irq assert again?
Acks _are_ vector specific. It's just that you don't need to specify the
vector, because the local APIC knows which one it must be (very simple: it
must always be the highest-priority in-service irq).
> BTW: Is it correct to say that
> ack after a level causes a operation on both local and io-apic
> ack after an edge is purely local.
>
> If so, what happens with
> level triggered arrives
> no-ack dispatch of level trigger
> higher priority EDGE arrives
> ack (intended to ack edge)
The nesting is always ok, because the local APIC knows which interrupts
are in service, and thus also knows which one is "active" (the highest
priority in-service one).
I personally think it's a stupid design (it would be so easy for software
to just explicitly say _which_ IRQ to ACK, and I don't see the point of
not requireing that and make it explicit), but it's straightforward.
> Is it now an error to do __sti in interrupt mode?
No, why would it be?
Doing an __sti in interrupts will let higher-priority interrupts in. As it
always has.
I think it's probably stupid most of the time, and shows that something is
wrong (an interrupt should not take long enough for it to matter that we
do an __sti), but sometimes that kind of stupidity is a result of horrible
hardware latencies (eg the time it takes to read a sector from the IDE
disk using programmed IO).
> What happens on
> level triggered arrives
> no-ack dispatch of level trigger
> timer irq arives
> ack (intended to ack edge)
> process switch from timer code.
That would be a horrible bug, and would ALWAYS have been a horrible bug.
Quite regardless of how you do interrupts: it doesn't matter where youput
the ACK's, you always need to make sure that irq masking etc is correct,
and you must NOT allow a context switch while an interrupt handler is
still running.
The kernel _only_ does a process switch on return to user level. That very
much includes the case above; the timer interrupt obviously is not
returnign to user level.
You're making these problems up.
> I really dislike hardware interrupt priorities since they have nothing
> to do with the OS' ideas of importance and are complex to work with.
I agree. I think interrupt controllers should be simple masks, nothing
more, nothing less.
However, I'm not designing the hardware.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:21 EST