enigmatic 'Other Interrupt' message

WinCE PB4.20, XScale CPU, custom board, kernel derived from XSCBD1 BSP

The WinCE kernel intermittently prints out "Other Interrupt" when
there is a lot of USB activity on my system. When I see this message,
I see it a lot - other times it is not a problem. The message is
associated with starving all user threads for a substantial fraction
of a second.

I located the code generating this message in the OEMInterruptHandler
routine (kernel\HAL\ARM\intxsc1.c) and added to it to determine which
interrupts were pending. The answer was none! The host controller is
using GPIO1 as an interrupt signal in our system.

Has anyone seen this before or have any idea what could be causing it?

Thanks,
Steve Schumacher
Embed, Inc

K
Sat Apr 03 09:25:15 CST 2004

I have the same experience with the "other interrupt", and not only for the
PXA but also the IXP series have the same thing!
I guess if there is some noise (glitch) on GPIO lines will let the Interrupt
detect controller of the SoC working wrong...

"Will Cunningham" <tapar11@spammhotmail.com>
???????:893p601gaid598cff5usa6frspjdgf561k@4ax.com...
> WinCE PB4.20, XScale CPU, custom board, kernel derived from XSCBD1 BSP
>
> The WinCE kernel intermittently prints out "Other Interrupt" when
> there is a lot of USB activity on my system. When I see this message,
> I see it a lot - other times it is not a problem. The message is
> associated with starving all user threads for a substantial fraction
> of a second.
>
> I located the code generating this message in the OEMInterruptHandler
> routine (kernel\HAL\ARM\intxsc1.c) and added to it to determine which
> interrupts were pending. The answer was none! The host controller is
> using GPIO1 as an interrupt signal in our system.
>
> Has anyone seen this before or have any idea what could be causing it?
>
> Thanks,
> Steve Schumacher
> Embed, Inc
>

steve
Mon Apr 05 18:07:38 CDT 2004

Well, something's loose alright - but what I see is not consistent
with glitchy GPIO lines.

Here's some more info on the problem:
- "Other Interrupt" message is issued when OEMInterruptHandler
cannot find a supported bit set in the IRQ pending regisister (ICIP)
- trace message reveals that the ICIP is indeed all 0s at this point
- the interrupt mask register (ICMR) is also all 0s. Since I
normally unmask the GPIO1 interrupt, this indicates that the spurious
interrupt always occurs between servicing a valid interrupt (which
clears bit 9 for GPIO1) and my IST calling InterruptDone
- the GPIO_X edge detect bits are also zero, consistent with the
ICMR observation (I use falling edge detection for an active low
interrupt and ISR clears GEDR).

Steve
(now posting himself)

"K. S. Huang" <ks_huang@dlink.com.tw.remove.this> wrote in message news:<eeXUr#YGEHA.3576@tk2msftngp13.phx.gbl>...
> I have the same experience with the "other interrupt", and not only for the
> PXA but also the IXP series have the same thing!
> I guess if there is some noise (glitch) on GPIO lines will let the Interrupt
> detect controller of the SoC working wrong...
>
> "Will Cunningham" <tapar11@spammhotmail.com>
> ???????:893p601gaid598cff5usa6frspjdgf561k@4ax.com...
> > WinCE PB4.20, XScale CPU, custom board, kernel derived from XSCBD1 BSP
> >
> > The WinCE kernel intermittently prints out "Other Interrupt" when
> > there is a lot of USB activity on my system. When I see this message,
> > I see it a lot - other times it is not a problem. The message is
> > associated with starving all user threads for a substantial fraction
> > of a second.
> >
> > I located the code generating this message in the OEMInterruptHandler
> > routine (kernel\HAL\ARM\intxsc1.c) and added to it to determine which
> > interrupts were pending. The answer was none! The host controller is
> > using GPIO1 as an interrupt signal in our system.
> >
> > Has anyone seen this before or have any idea what could be causing it?
> >
> > Thanks,
> > Steve Schumacher
> > Embed, Inc
> >

Steve
Mon Apr 05 22:40:15 CDT 2004

There is a bug in the silicon whereby an interrupt can sometimes occur and
ICIP is all 0, which of course should NEVER happen. AFAIK it has not been
fully isolated but can be caught on occasion with special test tools.
Simplest thing to do is just test for it up front and return SYSINTR_NOP if
it occurs.

--
Steve Maillet (eMVP)
EmbeddedFusion
smaillet_AT_EmbeddedFusion_DOT_com

steve
Tue Apr 06 11:15:02 CDT 2004

Steve, how did you hear about this bug? I'd like to know more.

The code (from XSC1BD BSP) does return SYSINTR_NOP. I can't leave it
as is, though, because it (or something it triggers) hogs the CPU. It
can happen several hundred times per second and prevent all other
threads from running!
(Or it can happen not at all for several boots - life is good then.)

(I was wrong about "the ICMR is also all 0s" - I fixed my trace and my
GPIO interrupt and a few others are enabled, indicating that I am not
between ISR and IST processing as I thought. The ICPR is all 0s 99% of
the time it happens.)

"Steve Maillet \(eMVP\)" <nospam1@EntelechyConsulting.com> wrote in message news:<#T9ljj4GEHA.1720@tk2msftngp13.phx.gbl>...
> There is a bug in the silicon whereby an interrupt can sometimes occur and
> ICIP is all 0, which of course should NEVER happen. AFAIK it has not been
> fully isolated but can be caught on occasion with special test tools.
> Simplest thing to do is just test for it up front and return SYSINTR_NOP if
> it occurs.