Sir, On Tue, Feb 15, 2011 at 4:16 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com>wrote:

Hi... :)

On Tue, Feb 15, 2011 at 16:08, Darshan Ghumare <darshan.ghumare@gmail.com> wrote:

...

Sir, On x86 UP (Single CPU), Can lower priority (say) IRQ5 preempt higher one (say) IRQ4 (Currently, CPU is executing interrupt handler of IRQ4)?

In Linux kernel, I never heard such irq prioritizing. Linux kernel does general preemption such that any code path could preempt other code path as long as preemption is allowed at that point and/or interrupt is enabled (which one affect the situation depends on type of code path).

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.

But, vaguely I read that Windows kernel does that.... that's why in certain BSOD you read message prefixed with "IRQL xxx xxx xxxx". That means lower interrupt handler somehow preempt higher one and that's not allowed.

It comes from my raw observation so things might be wrong somewhere...

-- regards,

Mulyadi Santosa Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com

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. 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@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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

On Feb 16, 2011, at 9:49 PM, Darshan Ghumare wrote:

Sir,

Thank you very much for the explanation.

On Wed, Feb 16, 2011 at 8:20 PM, Bruce Rowen <browen@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?

Depends on the interrupt controller. Common systems have interrupt controllers embedded into 'glue' chips such as a 'Southbridge' or 'Northbridge'. To find the exact device and functionality you will need to consult the hardware manuals for your system.

2) Can we configure hardware (say, I/O APIC) so that alway higher priority interrupt's handler runs first?

My experience with small form-factor (pc104) X86 is that much of the setup/assignments of priority is done in the BIOS. I found it to be complex to change the assignments after the kernel is running so your best chance is to use the features of your BIOS. Remember that the ISR typically exists as only a handful of lines of code. Its job is to determine that its hardware was the one interrupting (for when hardware shares interrupt lines), do whatever hardware changes are required (clear interrupt flags, acknowledge DMA, etc.), and then tell the kernel to schedule the rest of the handler (tasklet/bottom half, etc.). A truly prioritized interrupt would allow the higher level interrupt to preempt the running of a lower levels ISR and tasklet. A lower level interrupt would be held off until the higher level interrupts ISR has completed, but it then could preempt the running of the higher level interrupts tasklet. Once all interrupts are scheduled to run as tasklets, it is the order they are queued that determines their run order (last in, first run). For example, scheduling the tasklet for a higher level interrupt with tasklet_hi_schedule() will allow it to run before those scheduled with tasklet_schedule(). Thus there are two places to control interrupt servicing priorities. The hardware level which allows preemption during the microseconds long hardware ISR code, and the software (tasklet) level that has priorities assigned by scheduling methods and scheduling order. -Bruce