From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6412 invoked by alias); 10 Apr 2006 17:20:12 -0000 Received: (qmail 6402 invoked by uid 22791); 10 Apr 2006 17:20:11 -0000 X-Spam-Check-By: sourceware.org Received: from anchor-post-34.mail.demon.net (HELO anchor-post-34.mail.demon.net) (194.217.242.92) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Apr 2006 17:20:09 +0000 Received: from calivar.demon.co.uk ([83.104.54.243] helo=xl5.calivar.com) by anchor-post-34.mail.demon.net with esmtp (Exim 4.42) id 1FT03V-0006GO-Ep; Mon, 10 Apr 2006 17:20:01 +0000 Received: from xl5.calivar.com (localhost [127.0.0.1]) by xl5.calivar.com (Postfix) with ESMTP id 1E9691386A9; Mon, 10 Apr 2006 18:20:01 +0100 (BST) To: Cc: References: From: Nick Garnett Original-Sender: nickg@ecoscentric.com Date: Mon, 10 Apr 2006 17:20:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00123.txt.bz2 "Joe Porthouse" writes: > Nick, > Thanks for you reply. > > Your right. Not calling the interrupt_end() routine would cause the lock > not to be released. After your comment I started looking closer at my > modification. > > My original modification of: > /hal/arm/arch/current/src/vectors.S file at line 951. > cmp v1,#CYGNUM_HAL_INTERRUPT_NONE <-- from this > cmp r0,#CYGNUM_HAL_INTERRUPT_NONE <-- to this > > v1 originally contained the interrupt vector. But I mistakenly believed > this was the check of the return value from the ISR. I modified it to look > at r0, the return value from the isr. The return value from the isr will be > 0-3 (really 1 or 3). The CYGNUM_HAL_INTERRUPT_NONE is -1! (for some reason > I thought it was +1 looking at the assembly listing) > > Bottom line, my modification made sure that interrupt_end() would always be > called, even when v1 == CYGNUM_HAL_INTERRUPT_NONE (spurious interrupt). > > I just did a quick test with the original code and verified that when a > spurious interrupt occurs, the interrupt_end() routine is not called and the > lock is not released and my problem occurs. > > Calling the interrupt_end() routine with a spurious interrupt did not seem > to break anything. This all makes sense. > Was there a reason why interrupt_end() should not be > called on spurious interrupts? I guess it was an attempt to avoid doing more than the absolute minimum on spurious interrupts. It looks like there is a bug in there, since the scheduler lock doesn't get decremented. In general, spurious interrupts shouldn't happen, which is why it has managed to lurk here for so long. > > Now to figure out why I am getting a spurious interrupt with the simple UART > code listed below? > > 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, enable assertions, it might tell you something. -- Nick Garnett eCos Kernel Architect http://www.ecoscentric.com The eCos and RedBoot experts -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss