From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28265 invoked by alias); 11 Apr 2006 04:15:10 -0000 Received: (qmail 28255 invoked by uid 22791); 11 Apr 2006 04:15:08 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 11 Apr 2006 04:15:06 +0000 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1FTAHO-0000fL-EP for ecos-discuss@sources.redhat.com; Tue, 11 Apr 2006 06:15:02 +0200 Received: from 87.236.81.130 ([87.236.81.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 11 Apr 2006 06:15:02 +0200 Received: from osv by 87.236.81.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 11 Apr 2006 06:15:02 +0200 To: ecos-discuss@sources.redhat.com From: Sergei Organov Date: Tue, 11 Apr 2006 04:15:00 -0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.18 (linux) 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: [ECOS] Re: DSR stops running after heavy interrupts. Spurious Interrupt! X-SW-Source: 2006-04/txt/msg00133.txt.bz2 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? -- Sergei. -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss