From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23395 invoked by alias); 10 Apr 2006 09:36:15 -0000 Received: (qmail 23386 invoked by uid 22791); 10 Apr 2006 09:36:14 -0000 X-Spam-Check-By: sourceware.org Received: from anchor-post-32.mail.demon.net (HELO anchor-post-32.mail.demon.net) (194.217.242.90) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Apr 2006 09:36:12 +0000 Received: from calivar.demon.co.uk ([83.104.54.243] helo=xl5.calivar.com) by anchor-post-32.mail.demon.net with esmtp (Exim 4.42) id 1FSsob-000NVH-8M; Mon, 10 Apr 2006 09:36:09 +0000 Received: from xl5.calivar.com (localhost [127.0.0.1]) by xl5.calivar.com (Postfix) with ESMTP id EC3D31386A9; Mon, 10 Apr 2006 10:36:08 +0100 (BST) To: Sergei Organov Cc: ecos-discuss@sources.redhat.com References: <20060406211847.GH12221@lunn.ch> <20060409123238.GS12221@lunn.ch> From: Nick Garnett Original-Sender: nickg@ecoscentric.com Date: Mon, 10 Apr 2006 09:36: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. Bug found? X-SW-Source: 2006-04/txt/msg00108.txt.bz2 Sergei Organov writes: > Andrew Lunn writes: > > [...] > > > However, from what you are saying it sounds like there needs to be > > another comparison afterwards. Something like: > > > > and r0,r0,#2 // CYG_ISR_CALL_DSR > > beq 17f > > No, bit checking of the ISR return value is performed inside the > interrupt_end() routine: > > if( isr_ret & Cyg_Interrupt::CALL_DSR && intr != NULL ) intr->post_dsr() Exactly. And there are other housekeeping things that go on in interrupt_end() which cannot be skipped. The most important of these is decrementing the scheduler lock. I don't really see how the original poster's problem is fixed by trying to skip interrupt_end(), I would only expect doing that to aggravate the problem. The scheduler lock is acquired early in interrupt processing -- before the ISR is called and we know whether there is a DSR to call. interrupt_end() decrements the scheduler lock and as a side-effect may cause any DSRs to be called. As Andrew has suggested, I think Joe's best way of working out what is happening is to switch on instrumentation and see if he can track down the extra increments of the scheduler lock. -- 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