Interrupt handling
Darshan Ghumare
darshan.ghumare at gmail.com
Wed Feb 16 23:49:01 EST 2011
Sir,
Thank you very much for the explanation.
On Wed, Feb 16, 2011 at 8:20 PM, Bruce Rowen <browen at aoc.nrao.edu> 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 at gmail.com> 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 at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110217/91f9fd24/attachment.html
More information about the Kernelnewbies
mailing list