From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8247 invoked by alias); 27 Jun 2008 18:25:24 -0000 Received: (qmail 8230 invoked by uid 22791); 27 Jun 2008 18:25:22 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS 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; Fri, 27 Jun 2008 18:25:01 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1KCIcy-0003Fp-00; Fri, 27 Jun 2008 20:24:56 +0200 Date: Fri, 27 Jun 2008 18:25:00 -0000 From: Andrew Lunn To: Davy Wouters Cc: ecos-devel@ecos.sourceware.org Subject: Re: New hal port + interrupts + rescheduling + call_pending_dsrs problem Message-ID: <20080627182456.GH696@lunn.ch> References: <111ced750806270740k430d9ca9we3f3f1bd84d65ab7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <111ced750806270740k430d9ca9we3f3f1bd84d65ab7@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2008-06/txt/msg00040.txt.bz2 > I assume a return from interrupt should be executed somewhere between > the execution of the isr/post_dsr and the call_pending_dsrs? Nope. If the scheduler is not locked, the DSR is called in the interrupt handler context. If the scheduler is locked, the DSR will be called when the scheduler is unlocked. > Is it correct that call_pending_dsrs should be executed only when > other interrupts are allowed again, in other words after return from > the interrupt? After returning from the interrupt handler which has been registered with eCos, but before the actual reti instruction, or what ever is used to return the processor from interrupt context back into normal context. > Sorry if my questions are a bit confusing, but i don't quite > understand the problems i'm having at this point (Crashes when having > a lot of communication > on my uart rx resulting in ASSERT_FAIL: <6>mutex.cxx[249]cyg_bool > Cyg_Mutex::lock() Locking mutex I already own) Is this crash in thread code? You are not allowed to use mutex, or any other blocking call in ISR or DSR context. Andrew