From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32399 invoked by alias); 2 Mar 2014 20:19:37 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 32373 invoked by uid 89); 2 Mar 2014 20:19:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.3.2 X-HELO: p02c12o147.mxlogic.net Received: from p02c12o147.mxlogic.net (HELO p02c12o147.mxlogic.net) (208.65.145.80) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sun, 02 Mar 2014 20:19:34 +0000 Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c12o147.mxlogic.net(mxl_mta-7.2.4-1) with ESMTP id 15293135.0.42187.00-361.90574.p02c12o147.mxlogic.net (envelope-from ); Sun, 02 Mar 2014 13:19:34 -0700 (MST) X-MXL-Hash: 531392561473f0b7-f4b2aab0393489f769ed07267c3d5aa0eaf6105b Received: from [192.168.0.225] (174-24-4-43.clsp.qwest.net [174.24.4.43]) by smtpauth1.linear.com (Postfix) with ESMTPSA id 4FDB474009; Sun, 2 Mar 2014 12:19:28 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Jones In-Reply-To: Date: Sun, 02 Mar 2014 20:19:00 -0000 Cc: ecos discuss Content-Transfer-Encoding: quoted-printable Message-Id: <496B24D9-62B6-48F2-BD53-1F6B9ABE2083@linear.com> References: To: =?iso-8859-1?Q?Lambrecht_J=FCrgen?= X-AnalysisOut: [v=2.0 cv=GK2/5JxK c=1 sm=1 a=glloKNylpeYNumXQcclYyA==:17 a] X-AnalysisOut: [=CFl6StMSI_gA:10 a=D2_GN2MmYMYA:10 a=BLceEmwcHowA:10 a=8nJ] X-AnalysisOut: [EP1OIZ-IA:10 a=MqDINYqSAAAA:8 a=FP58Ms26AAAA:8 a=prgfXTrUA] X-AnalysisOut: [AAA:8 a=CCpqsmhAAAAA:8 a=AYTndh7z4E2l-cbheMQA:9 a=wPNLvfGT] X-AnalysisOut: [eEIA:10 a=ntesgRjRzHUA:10 a=xLpt9-x9cSEA:10 a=4t78-hnhQh4A] X-AnalysisOut: [:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014030208); S=0.200(2010122901)] X-MAIL-FROM: X-IsSubscribed: yes Subject: Re: [ECOS] Scheduler startup question X-SW-Source: 2014-03/txt/msg00000.txt.bz2 Jurgen, I think I fully understand how the scheduler locking works during interrupt= now. Vectors.S takes the lock, and interrupt_end clears it. However, the n= ormal technique of incrementing the lock count does not work with SMP. The = problem is that another CPU may have the lock. Incrementing anyway leads to= assertions. Attempting to take the lock with the spinlock can lead to dead= locks or an unresponsive network application. So I changed things so that in Vectors.S, during an interrupt, an attempt a= t locking is made. This means trying to take a spinlock that might fail. If= the lock is taken, interrupt_end is called. If the lock fails, interrupt_e= nd is not called. This means that a DSR may not be posted on that interrupt. This can cause s= ome latency based on the real time clock interrupt rate, or time until a th= read switch. However, it is stable and assertion free. Also, a HAL could im= plement a timeout on the try spinlock which might reduce latency. To support the try and testing if the lock was taken, I had to add some fun= ctions to the kernel. The following wiki page has been updated to reflect t= he kernel changes. https://sourceforge.net/p/ecosfreescale/wiki/SMP%20Kernel/ Anyone with SMP knowledge might want to take a look. There may be better so= lutions to some of these problems. But at least for now, the IMX6 SMP HAL s= eems stable and I can run IO intensive Lua scripts over telnet reliably, ev= en when the client aborts. The client abort means telnet has to kill a thread. This was quite a challe= nge. Telnet is creating a separate heap for Lua so it can kill the thread a= nd reclaim memory. The remaining problem is closing file handles. I still g= et some assertions when a handle is sometimes killed by a thread that does = not own it. I don't think that can be solved without adding some new functi= ons dedicated to clean up of file handles by an outside thread. Mike On Feb 26, 2014, at 11:40 PM, Lambrecht J=FCrgen = wrote: > As far as I know the scheduler is started after cyg_user_start(), used by= your application to initialize everything. Do you use cyg_user_start? >=20 >=20 > Verzonden vanaf Samsung Mobile >=20 >=20 >=20 > -------- Oorspronkelijk bericht -------- > Van: Michael Jones > Datum: > Aan: ecos discuss > Onderwerp: [ECOS] Scheduler startup question >=20 >=20 > I have a question about proper scheduler locking startup behavior. >=20 > The context is I am cleaning up my iMX6 HAL and attempting to make things= work without a couple of kernel hacks I added to make it work. >=20 > The question has to do with sched_lock. By default this has a value of 1,= so during startup the scheduler is locked. >=20 > When there is an interrupt, sched_lock is incremented in Vectors.S, and d= ecremented in interrupt_end. >=20 > However, I am getting an assert in sync.h which is part of the BSD stack.= The assert is because it expects the lock to be zero. >=20 > The question is, during the startup process, how does the lock get set to= zero after initialization? Is it supposed to stay 1 while hardware is init= ialized and through all the constructors, etc? Is it cleared by the schedul= er somehow? Is the HAL supposed to zero it at some point during startup? >=20 > My HAL is part of the ARM hal, so if this is device specific, it is the A= RM HAL I am working with. >=20 > Mike > -- > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss >=20 >=20 > -- > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss >=20 -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss