Re: intel x86 instruction "cli"

From: Ed Skinner (Ed_at_REMOVETHIS.flat5.net)
Date: 03/19/04 

Date: Fri, 19 Mar 2004 07:46:55 -0800

On Fri, 19 Mar 2004 09:55:45 +0100, news wrote:

>> In linux the ISR will mask the corresponding interrupt bit in PIC and
>> will call sti so that processor can identify any new interrupt
>> generation ( as the interrupt
>> bit corresponding to the previous interrupt is cleared processor is not
>> notified
>> of the same interrupt again until ISR re enables that bit before
>> returning).
>
> I have a question on this. Why is the line masked, given that the hardware
> will not generate another int until it is serviced? Why not just only
> acknowledge the PIC?
>
>> The purpose of this is to service any higher priority interrupts arrival
>> during the execution of current interrupt's ISR.
>
> But if ints are enabled, lower priority interrupts could be triggered too,
> right?

     Yes, but...
     One of the problems over the years has been the idea that interrupts
from hardware devices should have fixed priorities. For workstation
systems that may be appropriate but out in the real world, in particular
with embedded devices, priorities may sometimes need to change. The reason
for a change varies but the essential idea is that circumstances change
and so the system should change how it reacts accordingly. With hard-wired
priorities, this isn't possible. Some hardware devices have a priority
scheme built in to them. The i8259a is an example. In that device, the
priority is associated with the INT# and, if that feature in the device is
used, the system has to kowtow to the device.
     A different solution would be to, for example, for the software to
read the state of all the INT lines into the PIC (which is possible in
some PICs) and, noting which INT#s are active, do a table lookup to
determine how important each of them is to the system at this moment. The
interrupts would then be handled in priority order and, during the life of
the system, interrupt priority could then be changed simply by replacing
the value in the lookup table. Hence, dynamic prioritization of hardware
interrupts.
     I don't know what specific systems, if any, use this technique now.
For many, it may not be possible due to hardware limitations. In others,
it may be overkill or simply not needed. But in a few cases, being able to
re-prioritize the importance of, for example, the network versus the local
keyboard interrupts, may be essential.

Relevant Pages

  • RE: Interrupt Priority
    ... Priority Among Simultaneous Exceptions and Interrupts ... Code Breakpoint Fault ... Faults from Fetching Next Instruction ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Interrupt Priority
    ... Priority Among Simultaneous Exceptions and Interrupts ... Code Breakpoint Fault ... Faults from Fetching Next Instruction ...
    (microsoft.public.win32.programmer.kernel)
  • Re: [RFC][PATCH] irq: remove IRQF_DISABLED
    ... The "irq's disabled fastpath" thing has been there since pretty much day ... allowing higher priority interrupts to "preempt" ... lower priority ones, which this would effectively render useless. ... The problems with enabling irqs in hardirq handlers are that you get ...
    (Linux-Kernel)
  • Re: Linux serial port dropping bytes
    ... Changing ISR priority isn't going to make any difference. ... It only determines which of two pending interrupts get ... preempt lower priority ones. ...
    (comp.arch.embedded)
  • Re: sio: lots of silo overflows on Asus K8V with Moxa Smartio C104H/PCI
    ... There must be bugs elsewhere for shared interrupts to cause lots of slo ... interrupt priority for the shared case (all tty interrupts get the low ... COM_MULTIPORT is only needed for old isa-ish multiport cards. ... shared with a device whose driver doesn't support fast interrupts. ...
    (freebsd-current)