Brian Stecher
|
Re: IPI_CHECK_INTR handling
|
Brian Stecher
08/14/2008 9:00 AM
post11788
|
Re: IPI_CHECK_INTR handling
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
|
|
|