This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: ARM Spurious Interrupts & Scheduler locking
- From: Andrew Lunn <andrew at lunn dot ch>
- To: cboling at hiwaay dot net
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Sun, 11 Apr 2004 13:38:23 +0200
- Subject: Re: [ECOS] ARM Spurious Interrupts & Scheduler locking
- References: <E1BC4Sl-0003YE-00@londo.lunn.ch>
On Fri, Apr 09, 2004 at 05:12:10PM -0500, ecos-dev@bcsw.net wrote:
> I have found what appears to be a bug in the handling of spurious interrupts
> on the ARM architecture with kernel support enabled.
>
> The problem is in vectors.s. The scheduler gets locked before running
> hal_IRQ_handler() (which deciphers the active interrupt) and gets unlocked
> in interrupt_end(). The problem is that the scheduler always gets locked,
> but interrupt_end() doesn't get called in the case of a spurious interrupt
> which leaves the scheduler locked forever. Perhaps that is the intended
> behavior, but there is no documentation to warn the user of this 'feature'.
I don't know if this is intended, sorry.
> This is particularly frustrating if you assert
> CYGIMP_HAL_COMMON_INTERRUPTS_IGNORE_SPURIOUS because you don't believe
> spurious interrupts are problem, then find that your system hangs whenever
> one occurs.
But is it hanging because of the code or because your spurious
interrupt? Maybe you are getting a storm of spurious interrupts?
Spurious interrupts should be investigated. It means either your
hardware is broken or there is a problem with your device drivers.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss