From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19118 invoked by alias); 10 Apr 2006 17:44:06 -0000 Received: (qmail 19110 invoked by uid 22791); 10 Apr 2006 17:44:05 -0000 X-Spam-Check-By: sourceware.org Received: from londo.lunn.ch (HELO londo.lunn.ch) (80.238.139.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Apr 2006 17:44:02 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1FT0QI-00025g-00; Mon, 10 Apr 2006 19:43:34 +0200 Date: Mon, 10 Apr 2006 17:44:00 -0000 To: Nick Garnett Cc: jporthouse@toptech.com, ecos-discuss@sources.redhat.com Message-ID: <20060410174334.GA8017@lunn.ch> Mail-Followup-To: Nick Garnett , jporthouse@toptech.com, ecos-discuss@sources.redhat.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060403 From: Andrew Lunn X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Re: DSR stops running after heavy interrupts. Spurious Interrupt! X-SW-Source: 2006-04/txt/msg00125.txt.bz2 > > What should I look for in attempting to eliminate spurious interrupts? Can > > they be eliminated? > > The CYGNUM_HAL_INTERRUPT_NONE return from hal_IRQ_handler() only > happens when an interrupt occurs but the interrupt controller denies > all knowledge of it. One possibility is that hal_IRQ_handler() is > decoding a real interrupt wrongly and generating -1 by mistake. > > What you need to do is find out why hal_IRQ_handler() is returning > this value. If you can put a breakpoint in hal_IRQ_handler() > where CYGNUM_HAL_INTERRUPT_NONE is returned, then you should be able > to look at all the relevant device and interrupt controller registers > and find out what is going on. Also check that you have level vs edge trigger correct for your hardware. It could be a hardware error, eg a pulse is too short, a floating interrupt signal, some device which does not get reset when the process does etc. 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