Thank you very much for the explanation.
On Wed, Feb 16, 2011 at 8:20 PM, Bruce Rowen <browen@xxxxxxxxxxxx> wrote:
When the interrupt line is asserted by the hardware device (could be
a peripheral, whatever) the interrupt controller decides how to pass
this signal onto the processor. Some controllers will prioritize the
interrupt based on the interrupt line number. For example, assume line
#3 has interrupted. If line #4 then interrupts and #4 has higher
priority, the service routine for interrupt line #3 will itself be
interrupted. If a lower priority interrupt (say #2) occurs, then #3
will continue until completion at which point #2 will be serviced.
Note that this hardware prioritization is highly dependent on hardware
and hardware setup. It could be such that an incoming interrupt with a
lower priority than a currently servicing interrupt is simply ignored.
If that is the case,
1) What happens in the case of x86?
2) Can we configure hardware (say, I/O APIC) so that alway higher priority interrupt's handler runs first?
Mulyadi is correct in that once this hardware interrupt has been
acknowledged at the controller and the (usually very short) interrupt
service routine has been run, the prioritization of the rest of the
interrupt handler is left to the Kernel. Typically in most systems the
NMI has the highest priority and of course given its name, can never
be ignored (masked).
-Bruce
> _______________________________________________
On Feb 16, 2011, at 1:54 AM, Mulyadi Santosa wrote:
> Hi :)
>
> On Tue, Feb 15, 2011 at 19:20, Darshan Ghumare
> <darshan.ghumare@xxxxxxxxx> wrote:
>> IMHO, When the Processor is executing interrupt handler of IRQ4 then
>> Processor is the one which pushes SS, SP, EFLAGS, CS & EIP on
>> stack (in
>> this case this will all corresponds to interrupt handler of IRQ4) &
>> loads CS
>> & EIP corresponding to IRQ5.
>> So, how come its depends on OS (kernel)? Please correct me if I am
>> wrong.
>
> OK, to make it clear, I was talking about bottom half prioritizing
> .... the upper half is reacting whenever interrupt is coming (and it
> is not currently masked/disabled) AFAIK. Bottom half is the part where
> OS could do prioritizing if it indeed does so.
>
> The only "prioritizing" (if you take it as prioritizing) in interrupt
> is when it is fall into NMI (Non Maskable Interrupt). AFAIK, they
> could just kick others in queue, just like real time task kick regular
> process :) Uhm, maybe watchdog timer does same kind of interrupt
> too...
>
> Guys, CMIIW here...
>
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
>
> Kernelnewbies mailing list
> Kernelnewbies@xxxxxxxxxxxxxxxxx
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
