From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1246 invoked by alias); 1 Nov 2005 12:29:13 -0000 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 Received: (qmail 1232 invoked by uid 22791); 1 Nov 2005 12:29:09 -0000 Received: from bonn.shuttle.de (HELO bonn.shuttle.de) (194.95.249.247) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 01 Nov 2005 12:29:09 +0000 Received: by bonn.shuttle.de (Postfix, from userid 10) id 9F9796C096; Tue, 1 Nov 2005 13:29:06 +0100 (CET) Received: from nullnullsix (nullnullsix.mikrom.local [192.168.0.32]) by mikrom.de (Postfix) with SMTP id 615DA8CC4E for ; Tue, 1 Nov 2005 13:28:35 +0100 (CET) Message-ID: <004001c5dedf$c84670a0$8262fea9@nullnullsix> From: "Stefan Sommerfeld" To: References: <001e01c5cff3$a4129150$8262fea9@nullnullsix> <20051013131422.GC6114@lunn.ch> Date: Tue, 01 Nov 2005 12:29:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Subject: Re: [ECOS] ISR to DSR delay? X-SW-Source: 2005-11/txt/msg00003.txt.bz2 Hi, Progress update: I'm still searching, but find a strange thing: In the irq_end routine (intr.cxx:323) there's a Cyg_Scheduler::unlock(), which should run pending dsr's. I think there're to possible things which this function could to: Decrease the scheduler lock and return and Decrease and call unlock_inner() to call pending dsr's. What i see is that this ::unlock() take sometimes more than 6ms, but the unlock_inner() is always fast (some microseconds). So what could be the cause? Maybe a context switch while unlocking? Any hints? Bye... ----- Original Message ----- From: "Andrew Lunn" To: "Stefan Sommerfeld" Cc: Sent: Donnerstag, 13. Oktober 2005 14:14 Subject: Re: [ECOS] ISR to DSR delay? > On Thu, Oct 13, 2005 at 02:42:58PM +0200, Stefan Sommerfeld wrote: >> Hi, >> >> I working with latest eCos on a XScale system and i noticed a very high >> delay between the ISR and the corresponding after some time. The system >> is >> not idle and does a lot of things (including multiple threads and >> irq's). I >> see a delay between ISR and DSR over 30 ms. >> >> I checked the system's DSR, to make sure there's no DSR which runs very >> long and i looked for possible cyg_scheduler_lock() calls. What i wonder >> about is, i see that sometimes a quick cyg_scheduler_lock() happen which >> between the long ISR/DSR delay. So it looks like scheduling is active >> and >> running but the DSR is not called. >> >> What could influence the ISR to DSR delay besides scheduler_lock and >> still >> active DSR? I thought a DSR will be called as soon as possible. Could >> this >> be a wrong eCos kernel setup? > > DSRs are only allowed to run with it is safe to run a DSR. This in > fact means that when the schedular is locked DSRs cannot run. Once the > schedular is unlocked the DSR will get to run. > > So the schedular is probably locked when the ISR happens and you see a > delay. When the ISR exits the DSR does not get to run. When you see a > cyg_scheduler_lock() this will actually be a nested lock inside > another lock. So the DSR will only get to run when both locks are > unlocked. This might actually be telling you something. A double lock > suggests something more complex is going on. It might be worth seeing > if a single lock gives you an acceptable delay but a double lock is > unacceptable. If so you can then just find the double lock case and > simply the code. Otherwise you need to investigate all locks and find > onces which are taking too long. > > Andrew > > -- > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss