From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4332 invoked by alias); 11 Apr 2006 08:43:00 -0000 Received: (qmail 4323 invoked by uid 22791); 11 Apr 2006 08:43:00 -0000 X-Spam-Check-By: sourceware.org Received: from anchor-post-35.mail.demon.net (HELO anchor-post-35.mail.demon.net) (194.217.242.85) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 11 Apr 2006 08:42:58 +0000 Received: from calivar.demon.co.uk ([83.104.54.243] helo=xl5.calivar.com) by anchor-post-35.mail.demon.net with esmtp (Exim 4.42) id 1FTESc-000OnB-Ix; Tue, 11 Apr 2006 08:42:55 +0000 Received: from xl5.calivar.com (localhost [127.0.0.1]) by xl5.calivar.com (Postfix) with ESMTP id 62A9A1386A9; Tue, 11 Apr 2006 09:42:54 +0100 (BST) To: Sergei Organov Cc: ecos-discuss@sources.redhat.com References: From: Nick Garnett Original-Sender: nickg@ecoscentric.com Date: Tue, 11 Apr 2006 08:43: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/msg00139.txt.bz2 Sergei Organov writes: > Nick Garnett writes: > > "Joe Porthouse" writes: > [...] > > >> 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. > > Well, I think the right question here is why scheduler lock is > incremented at all? I mean if SMP implementations happen to increment it > inside the interrupt_end(), then it should be safe for ARM HAL to > increment it just before calling interrupt_end(), isn't it? This way > spurious interrupt handling code will avoid both scheduler lock > increment and interrupt_end() call. Makes sense? The scheduler lock has several duties. As well as disabling thread suspension and controlling when DSRs are called, it also does duty as an interrupt nesting counter. We only want DSRs to be called when all nested interrupts have been unwound and we are about to return from the first one. The scheduler lock count does this implicitly. But for this to work properly, the scheduler lock must be incremented in the VSR before interrupts are re-enabled and the ISR is called. In the SMP case I decided, at least initially, that nested interrupts would not be supported. It was hard enough keeping track of interrupts going off on different CPUs. This allowed me to move the lock operation into interrupt_end(), and avoided having to write any asm code to go into the VSR. SMP is really still in its development phase, there are a number of things that a little experimental in there. Moving the scheduler locking to interrupt_end() was one of them. I certainly would not want to do that for any other configuration. -- 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