From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7287 invoked by alias); 7 Jul 2005 05:33:15 -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 6874 invoked by uid 22791); 7 Jul 2005 05:32:59 -0000 Received: from micran.ru (HELO micran.ru) (217.29.80.82) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 07 Jul 2005 05:32:59 +0000 Received: from localhost (localhost [127.0.0.1]) by micran.ru (Postfix) with ESMTP id EEE734ACADF for ; Thu, 7 Jul 2005 12:32:55 +0700 (NOVST) Received: from micran.ru ([127.0.0.1]) by localhost (micran.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25000-03 for ; Thu, 7 Jul 2005 12:32:55 +0700 (NOVST) Received: from Viola.home (Viola.home [192.168.1.157]) by micran.ru (Postfix) with ESMTP id DDDBF4ACADD for ; Thu, 7 Jul 2005 12:32:55 +0700 (NOVST) Date: Thu, 07 Jul 2005 05:33:00 -0000 From: Yuriy Coureelo Reply-To: Yuriy Coureelo Message-ID: <1393963667.20050707123254@micran.ru> To: ecos-discuss@sources.redhat.com In-Reply-To: <20050705072355.GB30398@lunn.ch> References: <526561229.20050701155934@micran.ru> <20050701105246.GJ5563@lunn.ch> <665984288.20050704172147@micran.ru> <20050704111330.GA30398@lunn.ch> <1626342822.20050705105105@micran.ru> <20050705072355.GB30398@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [ECOS] Task switching problem X-SW-Source: 2005-07/txt/msg00067.txt.bz2 Dear Sir! AL> Do you have assertions enabled? That might also give a clue as to what AL> is happening. CYGPKG_INFRA_DEBUG is what you need. >> >> Num Thread Time Arg1 Arg2 >> 149 06 0x1d90 SCHED_LOCK 0x00000001 0x020053d4 radiorx_data() >> 150 06 0x1d96 MUTEX_UNLOCK 0x0211dfc0 0x00000000 radio_mutex >> 151 06 0x1d9f SCHED_UNLOCK 0x00000001 0x020053d4 radiorx_data() >> 152 06 0x1db4 SCHED_LOCK 0x00000001 0x020054c4 radioErx_proc() >> 153 06 0x1dbc SCHED_LOCK 0x00000002 0x0201adbc _flagwait >> 154 06 0x1dc3 SCHED_UNLOCK 0x00000002 0x0201adbc _flagwait >> 155 06 0x1dcf THREAD_SLEEP 0x0211dfe0 0x00000000 radioErx_thread >> 156 06 0x1dd6 SCHED_LOCK 0x00000002 0x0201ae3c _flagwait >> 157 06 0x1de0 SCHED_UNLOCK 0x00000002 0x0201ae3c _flagwait >> 158 06 0x1dea SCHED_RESCHEDULE 0x00000001 0x00000000 >> 159 06 0x1df2 SCHED_RESCHEDULE 0x00000000 0x00000000 >> 160 06 0x1e0f THREAD_SWITCH 0x0211dfe0 0x0208cfe4 radioErx_thread => idle_thread AL> What is happening at 152? Is your code locking the schedular before AL> calling the flag_wait function? It's ok. Flagwait piece of code works that way. In file packages/hal/arm/arch/current/src/vectors.s line something about 780 contains: #ifdef CYGFUN_HAL_COMMON_KERNEL_SUPPORT .extern cyg_scheduler_sched_lock ldr r3,.cyg_scheduler_sched_lock ldr r4,[r3] add r4,r4,#1 str r4,[r3] #endif I inserted before this construction checkpoint, which just puts a byte 0xCC (into my check buffer) each time. Finally, buffer shows following info: correct situation: 0xCC 0xAA - this was put by interrupt_end(), beginning 0x01 - scheduler lock at the beginning of interrupt_end() 0x00 - scheduler lock at the end of interrupt_end() 0xBB - this was put by interrupt_end(), end incorrect and nothing more after that: 0xCC 0xCC 0xAA - this was put by interrupt_end(), beginning 0x02 - scheduler lock at the beginning of interrupt_end() 0x01 - scheduler lock at the end of interrupt_end() 0xBB - this was put by interrupt_end(), end 0xCC was put twice! How is it possible? Interrupts are disabled at this stage. Am I right? Sincerely yours Yuriy Coureelo ------------------------ Engineer Telecommunication Equipment Division Micran Company Tomsk, Russia -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss