RE: [ECOS] spurious interrupt occuring for no apparent reason

RE: [ECOS] spurious interrupt occuring for no apparent reason

[Dan Conti]

> -----Original Message-----
> From: Trenton D. Adams [ mailto:tadams@theone.dnsalias.com ]
> Subject: RE: [ECOS] spurious interrupt occuring for no apparent reason
> 
> I have in fact checked to make sure that it is registering it 
> correctly.
> It is, that's why it occurs so rarely.  If it wasn't registering
> properly, it would occur all the time would it not?

If it was actually registering an interrupt handler for that vector,
then you wouldn't be seeing a message from hal_arch_default_isr() on
that vector. In terms of occurring rarely, it's not like the proper
handler is sometimes registered and sometimes not, so that it occurs
rarely just means you're rarely getting interrupts.
 
> This won't actually affect my end program anyhow will it?  After all,
> once Assertions are disabled, my program should run normally as
> predicted, no?  If so, maybe this should be changed to a CYG_TRACEX
> instead of a CYG_ASSERT?

No, it really should be an assertion. A hardware interrupt is unmasked
but there is no software handler installed for it (hence it hits the
default). Normally if you hit this condition it means you're unmasking
the wrong interrupt, in which case your program probably wont do
anything useful in any case. Additionally, unmasking the wrong interrupt
is generally naughty, hence the assertion. Traceing is useful for
following the path of execution in kernel code, not for checking error
conditions or misconfiguration.

-Dan
 
> -----Original Message-----
> From: ecos-discuss-owner@sources.redhat.com
> [ mailto:ecos-discuss-owner@sources.redhat.com ] On Behalf Of Dan Conti
> Sent: Monday, August 27, 2001 2:19 PM
> To: eCos Discussion
> Subject: RE: [ECOS] spurious interrupt occuring for no apparent reason
> 
> 
> When you get a spurious interrupt, it's because the interrupt is
> unmasked on the processor, but you haven't registered a 
> handler for the
> interrupt in eCos. If the cs8900 driver is unmasking that 
> interrupt you
> might want to make sure that it is properly registering an interrupt
> handler first.
> 
> Yes, theoretically that should never occur, hence the assertion.
> 
> -Dan
> 
> > -----Original Message-----
> > From: Trenton D. Adams [ mailto:tadams@theone.dnsalias.com ]
> > Sent: Monday, August 27, 2001 11:44 AM
> > To: 'eCos Discussion'
> > Subject: [ECOS] spurious interrupt occuring for no apparent reason
> > 
> > 
> > I'm running on and edb7111-2 rev b board.  Every once in 
> > awhile (once in
> > a blue moon), I get a spurious interrupt occuring.
> > 
> > TRACE: <5>[202]hal_arch_default_isr() Interrupt: 8
> > ASSERT FAIL: <5>[204]hal_arch_default_isr() Spurious Interrupt!!!
> > 
> > My program does not enabled EINT3 (int 8) in any way shape or 
> > form.  The
> > edb7111-2 ethernet driver for the CS-8900 does enable this interrupt
> > though.  But all it appears to do is IGNORE it.  By this I 
> mean simply
> > ack it and then re-enable it.  So, this EINT3 problem should
> > theoretically never occur, should it?
> > 
> > Trenton D. Adams
> > Extreme Engineering
> > #17, 6025 - 12 St. SE
> > Calgary, Alberta, Canada
> > T2H 2K1
> > 
> > Phone: 403 640 9494 ext-208
> > Fax: 403 640 9599
> > 
> > http://www.extremeeng.com
> > 
> > 
> 
> 

RE: [ECOS] spurious interrupt occuring for no apparent reason

[Trenton D. Adams]

Something very odd is happening then.  From what I understand, EINT3 has
to occur all the time because I'm sending/receiving data all the time.
So, the fact that I would be receiving an interrupt only rarely is
EXTREMELY unlikely because my program seems to work fine.

This spurious interrupt has only occurred twice in the entire time I've
been using this board.  It seems that it might be a synchronization
problem somewhere within eCos.  Possibility, considering what I've said
so far?

-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[ mailto:ecos-discuss-owner@sources.redhat.com ] On Behalf Of Dan Conti
Sent: Monday, August 27, 2001 2:46 PM
To: eCos Discussion
Subject: RE: [ECOS] spurious interrupt occuring for no apparent reason


> -----Original Message-----
> From: Trenton D. Adams [ mailto:tadams@theone.dnsalias.com ]
> Subject: RE: [ECOS] spurious interrupt occuring for no apparent reason
> 
> I have in fact checked to make sure that it is registering it 
> correctly.
> It is, that's why it occurs so rarely.  If it wasn't registering
> properly, it would occur all the time would it not?

If it was actually registering an interrupt handler for that vector,
then you wouldn't be seeing a message from hal_arch_default_isr() on
that vector. In terms of occurring rarely, it's not like the proper
handler is sometimes registered and sometimes not, so that it occurs
rarely just means you're rarely getting interrupts.
 
> This won't actually affect my end program anyhow will it?  After all,
> once Assertions are disabled, my program should run normally as
> predicted, no?  If so, maybe this should be changed to a CYG_TRACEX
> instead of a CYG_ASSERT?

No, it really should be an assertion. A hardware interrupt is unmasked
but there is no software handler installed for it (hence it hits the
default). Normally if you hit this condition it means you're unmasking
the wrong interrupt, in which case your program probably wont do
anything useful in any case. Additionally, unmasking the wrong interrupt
is generally naughty, hence the assertion. Traceing is useful for
following the path of execution in kernel code, not for checking error
conditions or misconfiguration.

-Dan
 
> -----Original Message-----
> From: ecos-discuss-owner@sources.redhat.com
> [ mailto:ecos-discuss-owner@sources.redhat.com ] On Behalf Of Dan Conti
> Sent: Monday, August 27, 2001 2:19 PM
> To: eCos Discussion
> Subject: RE: [ECOS] spurious interrupt occuring for no apparent reason
> 
> 
> When you get a spurious interrupt, it's because the interrupt is
> unmasked on the processor, but you haven't registered a 
> handler for the
> interrupt in eCos. If the cs8900 driver is unmasking that 
> interrupt you
> might want to make sure that it is properly registering an interrupt
> handler first.
> 
> Yes, theoretically that should never occur, hence the assertion.
> 
> -Dan
> 
> > -----Original Message-----
> > From: Trenton D. Adams [ mailto:tadams@theone.dnsalias.com ]
> > Sent: Monday, August 27, 2001 11:44 AM
> > To: 'eCos Discussion'
> > Subject: [ECOS] spurious interrupt occuring for no apparent reason
> > 
> > 
> > I'm running on and edb7111-2 rev b board.  Every once in 
> > awhile (once in
> > a blue moon), I get a spurious interrupt occuring.
> > 
> > TRACE: <5>[202]hal_arch_default_isr() Interrupt: 8
> > ASSERT FAIL: <5>[204]hal_arch_default_isr() Spurious Interrupt!!!
> > 
> > My program does not enabled EINT3 (int 8) in any way shape or 
> > form.  The
> > edb7111-2 ethernet driver for the CS-8900 does enable this interrupt
> > though.  But all it appears to do is IGNORE it.  By this I 
> mean simply
> > ack it and then re-enable it.  So, this EINT3 problem should
> > theoretically never occur, should it?
> > 
> > Trenton D. Adams
> > Extreme Engineering
> > #17, 6025 - 12 St. SE
> > Calgary, Alberta, Canada
> > T2H 2K1
> > 
> > Phone: 403 640 9494 ext-208
> > Fax: 403 640 9599
> > 
> > http://www.extremeeng.com
> > 
> > 
> 
> 

Re: [ECOS] spurious interrupt occuring for no apparent reason

[Jonathan Larmour]

"Trenton D. Adams" wrote:
> 
> Something very odd is happening then.  From what I understand, EINT3 has
> to occur all the time because I'm sending/receiving data all the time.
> So, the fact that I would be receiving an interrupt only rarely is
> EXTREMELY unlikely because my program seems to work fine.
> 
> This spurious interrupt has only occurred twice in the entire time I've
> been using this board.  It seems that it might be a synchronization
> problem somewhere within eCos.  Possibility, considering what I've said
> so far?

Not really: the interrupt handler is set up at startup time, with no real
scope for sync problems.

Perhaps the ISR table is getting scribbled on with NULLs? If you can set a
breakpoint on cyg_assert_fail and reproduce the problem you can then debug
your app to see what the state of the system is at the time.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

RE: [ECOS] spurious interrupt occuring for no apparent reason

[Trenton D. Adams]

Apparently I never replied to this! :(

The main problem is that I never know when one of these is going to
happen because it's only happened twice since I've been using eCos.  So,
it's a very rare problem which is extremely hard to reproduce.

-----Original Message-----
From: jlarmour@cambridge.redhat.com
[ mailto:jlarmour@cambridge.redhat.com ] On Behalf Of Jonathan Larmour
Sent: Thursday, September 06, 2001 2:20 PM
To: Trenton D. Adams
Cc: 'eCos Discussion'
Subject: Re: [ECOS] spurious interrupt occuring for no apparent reason


"Trenton D. Adams" wrote:
> 
> Something very odd is happening then.  From what I understand, EINT3
has
> to occur all the time because I'm sending/receiving data all the time.
> So, the fact that I would be receiving an interrupt only rarely is
> EXTREMELY unlikely because my program seems to work fine.
> 
> This spurious interrupt has only occurred twice in the entire time
I've
> been using this board.  It seems that it might be a synchronization
> problem somewhere within eCos.  Possibility, considering what I've
said
> so far?

Not really: the interrupt handler is set up at startup time, with no
real
scope for sync problems.

Perhaps the ISR table is getting scribbled on with NULLs? If you can set
a
breakpoint on cyg_assert_fail and reproduce the problem you can then
debug
your app to see what the state of the system is at the time.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223)
271062
Maybe this world is another planet's Hell -Aldous Huxley ||
Opinions==mine

RE: [ECOS] spurious interrupt occuring for no apparent reason

[Trenton D. Adams]

I have in fact checked to make sure that it is registering it correctly.
It is, that's why it occurs so rarely.  If it wasn't registering
properly, it would occur all the time would it not?

This won't actually affect my end program anyhow will it?  After all,
once Assertions are disabled, my program should run normally as
predicted, no?  If so, maybe this should be changed to a CYG_TRACEX
instead of a CYG_ASSERT?

-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[ mailto:ecos-discuss-owner@sources.redhat.com ] On Behalf Of Dan Conti
Sent: Monday, August 27, 2001 2:19 PM
To: eCos Discussion
Subject: RE: [ECOS] spurious interrupt occuring for no apparent reason


When you get a spurious interrupt, it's because the interrupt is
unmasked on the processor, but you haven't registered a handler for the
interrupt in eCos. If the cs8900 driver is unmasking that interrupt you
might want to make sure that it is properly registering an interrupt
handler first.

Yes, theoretically that should never occur, hence the assertion.

-Dan

> -----Original Message-----
> From: Trenton D. Adams [ mailto:tadams@theone.dnsalias.com ]
> Sent: Monday, August 27, 2001 11:44 AM
> To: 'eCos Discussion'
> Subject: [ECOS] spurious interrupt occuring for no apparent reason
> 
> 
> I'm running on and edb7111-2 rev b board.  Every once in 
> awhile (once in
> a blue moon), I get a spurious interrupt occuring.
> 
> TRACE: <5>[202]hal_arch_default_isr() Interrupt: 8
> ASSERT FAIL: <5>[204]hal_arch_default_isr() Spurious Interrupt!!!
> 
> My program does not enabled EINT3 (int 8) in any way shape or 
> form.  The
> edb7111-2 ethernet driver for the CS-8900 does enable this interrupt
> though.  But all it appears to do is IGNORE it.  By this I mean simply
> ack it and then re-enable it.  So, this EINT3 problem should
> theoretically never occur, should it?
> 
> Trenton D. Adams
> Extreme Engineering
> #17, 6025 - 12 St. SE
> Calgary, Alberta, Canada
> T2H 2K1
> 
> Phone: 403 640 9494 ext-208
> Fax: 403 640 9599
> 
> http://www.extremeeng.com
> 
> 

RE: [ECOS] spurious interrupt occuring for no apparent reason

[Dan Conti]

When you get a spurious interrupt, it's because the interrupt is
unmasked on the processor, but you haven't registered a handler for the
interrupt in eCos. If the cs8900 driver is unmasking that interrupt you
might want to make sure that it is properly registering an interrupt
handler first.

Yes, theoretically that should never occur, hence the assertion.

-Dan

> -----Original Message-----
> From: Trenton D. Adams [ mailto:tadams@theone.dnsalias.com ]
> Sent: Monday, August 27, 2001 11:44 AM
> To: 'eCos Discussion'
> Subject: [ECOS] spurious interrupt occuring for no apparent reason
> 
> 
> I'm running on and edb7111-2 rev b board.  Every once in 
> awhile (once in
> a blue moon), I get a spurious interrupt occuring.
> 
> TRACE: <5>[202]hal_arch_default_isr() Interrupt: 8
> ASSERT FAIL: <5>[204]hal_arch_default_isr() Spurious Interrupt!!!
> 
> My program does not enabled EINT3 (int 8) in any way shape or 
> form.  The
> edb7111-2 ethernet driver for the CS-8900 does enable this interrupt
> though.  But all it appears to do is IGNORE it.  By this I mean simply
> ack it and then re-enable it.  So, this EINT3 problem should
> theoretically never occur, should it?
> 
> Trenton D. Adams
> Extreme Engineering
> #17, 6025 - 12 St. SE
> Calgary, Alberta, Canada
> T2H 2K1
> 
> Phone: 403 640 9494 ext-208
> Fax: 403 640 9599
> 
> http://www.extremeeng.com
> 
> 

[ECOS] spurious interrupt occuring for no apparent reason

[Trenton D. Adams]

I'm running on and edb7111-2 rev b board.  Every once in awhile (once in
a blue moon), I get a spurious interrupt occuring.

TRACE: <5>[202]hal_arch_default_isr() Interrupt: 8
ASSERT FAIL: <5>[204]hal_arch_default_isr() Spurious Interrupt!!!

My program does not enabled EINT3 (int 8) in any way shape or form.  The
edb7111-2 ethernet driver for the CS-8900 does enable this interrupt
though.  But all it appears to do is IGNORE it.  By this I mean simply
ack it and then re-enable it.  So, this EINT3 problem should
theoretically never occur, should it?

Trenton D. Adams
Extreme Engineering
#17, 6025 - 12 St. SE
Calgary, Alberta, Canada
T2H 2K1

Phone: 403 640 9494 ext-208
Fax: 403 640 9599

http://www.extremeeng.com