Correct. CPU 0's got to get out of the kernel first (which will cause
it to process the pending list anyway).

	Brian

On Wed, Aug 13, 2008 at 07:31:59PM -0400, Varaprasad Lingutla wrote:
> Thanks for your explanation Brian.
> 
> In my case, I am noticing CPU 0 handling a flood of interrupts from a 
> faulty device, while CPU 1 is running the idle thread.  IPI_CHECK_INTR 
> bit is set in ipicmds[0] and CPU 0 LAPIC's Interrupt Request Register 
> shows IPI is in the queue. First frame on CPU 0 stack is in function 
> kernel.S:enoerror(), right after setting the kernel lock & exit flags in 
> inkernel and enabled the interrupts. I think this is done 
while exiting 
> from interrupt processing. This indicates that kernel lock is held by 
> CPU 0 and it is busy handling interrupts.
> 
> I was trying to see if there is a way for CPU 1 to process the interrupt 
> event queue in such a situation. But from your explanation, looks like 
> thats not going to happen until  the lock is released by CPU 0.
> 
> Thanks again,
> Prasad
> 
> 
> -------- Original Message  --------
> Subject: Re: IPI_CHECK_INTR handling
> From: Brian Stecher <community-noreply@qnx.com>
> To: ostech-core_os <post11438@community.qnx.com>
> Date: 08/05/08 07:04
> > On Fri, Aug 01, 2008 at 04:39:29PM -0400, Varaprasad Lingutla wrote:
> >   
> >> From what I understand, looks like a CPU issues IPI_CHECK_INTR interrupt 
> >> to next CPU at the end of interrupt handling if INKERNEL_NOW and  
> >> INKERNEL_EXIT bits are set. Now, during the handling of IPI_CHECK_INTR, 
> >> next CPU is executing the same code path and bouncing this interrupt back 
> >> to the first one if value of inkernel hasn't changed. Is this the expected 
> >> behaviour?
> >>     
> >
> > The IPI_CHECK_INTR is only sent if this CPU was _not_ in the kernel
> > (it wasn't the one that set INKERNEL_NOW) _and_ the other one was (more
> > generally, some other CPU was). In that case the CPU exiting the interrupt
> > handling can not enter the kernel to process any pending interrupt
> > events, so it passes the job to the guy who's already in the kernel
> > and can. The other CPU will receive the IPI and on its way out of the
> > interrupt processing will notice if there are any high priority pending
> > events. If so, it'll preempt the kernel call in progress to deal with
> > them. If not, it'll complete the kernel call and deal with the pending
> > events when leaving the kernel. It won't bounce back the IPI since it's
> > in the kernel already.
> >
> >   
> 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post11763
> 

-- 
Brian Stecher (bstecher@qnx.com)        QNX Software Systems
phone: +1 (613) 591-0931 (voice)        175 Terence Matthews Cr.
       +1 (613) 591-3579 (fax)          Kanata, Ontario, Canada K2M 1W8