Interrupt handling

[Darshan Ghumare <darshan.ghumare@xxxxxxxxx>]

---------- Forwarded message ----------
From: Darshan Ghumare <darshan.ghumare@xxxxxxxxx>
Date: Wed, Feb 16, 2011 at 10:14 AM
Subject: Re: Interrupt handling
To: Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx>

Sir,

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

Hi... :)

On Tue, Feb 15, 2011 at 16:08, Darshan Ghumare
<darshan.ghumare@xxxxxxxxx> 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

-- 
Darshan®
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies