From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4F0C5C00.3060508@domain.hid> Date: Tue, 10 Jan 2012 10:40:48 -0500 From: Makarand Pradhan MIME-Version: 1.0 References: <4F0B530A.80905@domain.hid> <4F0C5524.9020501@domain.hid> <4F0C58B7.1080602@domain.hid> In-Reply-To: <4F0C58B7.1080602@domain.hid> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Issue with Auto relax and nested mutexes List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: xenomai@xenomai.org Another point: "These are fast mutexes, the thread does not have to jump to kernel space unless the released mutex was actually contented." When the first task is started with prio 0, I always see that rt_mutex_release is invoked in the kernel. even when there is no contention. I have an instrumented kernel. The kernel trace is given below. In this trace only task1 is running at prio 0. It should be easy to follow: Jan 10 10:36:59 ruggedcom kernel: lo: rescnt: 0, switched: 0 Jan 10 10:36:59 ruggedcom kernel: hi: rescnt: 0, switched: 0 Jan 10 10:36:59 ruggedcom kernel: lo: rescnt: 1, switched: 1 Jan 10 10:36:59 ruggedcom kernel: hi: rescnt: 2, switched: 0 Jan 10 10:36:59 ruggedcom kernel: hi: rescnt: 3, switched: 0 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 3, switched: 0 Jan 10 10:37:01 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:01 ruggedcom kernel: RML Jan 10 10:37:01 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:01 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 2, switched: 0 Jan 10 10:37:01 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:01 ruggedcom kernel: RML Jan 10 10:37:01 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:01 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 1, switched: 0 Jan 10 10:37:01 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:01 ruggedcom kernel: RML Jan 10 10:37:01 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:01 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 0, switched: 0 Jan 10 10:37:01 ruggedcom kernel: lo: rescnt: 1, switched: 1 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 2, switched: 0 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 3, switched: 0 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 3, switched: 0 Jan 10 10:37:03 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:03 ruggedcom kernel: RML Jan 10 10:37:03 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:03 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 2, switched: 0 Jan 10 10:37:03 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:03 ruggedcom kernel: RML Jan 10 10:37:03 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:03 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 1, switched: 0 Jan 10 10:37:03 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:03 ruggedcom kernel: RML Jan 10 10:37:03 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:03 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 0, switched: 0 Jan 10 10:37:03 ruggedcom kernel: lo: rescnt: 1, switched: 1 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 2, switched: 0 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 3, switched: 0 Jan 10 10:37:04 ruggedcom kernel: hi: rescnt: 3, switched: 0 root@domain.hid:~# ./a.out 0 1 Spawning: tasks bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete ^C Rgds, Mak. On 10/01/12 10:26 AM, Makarand Pradhan wrote: > Hi Phillippe, > > You are right. Task 1 requires to be started with prio 0. I start seeing > the problem after task2 grabs the mutex and releases them. The first > task never jumps back to seconodary. Here is my output. The mode never > goes back to 0 after "Grabbing mux in HP" and the rescnt stays stuck at > 1 in the kernel. > > root@domain.hid:~# ./relax 0 1 > Spawning: tasks > bP: 0, cp: 0, mode: 0 > Acquire complete > Release complete > bP: 0, cp: 0, mode: 0 > Acquire complete > Release complete > bP: 0, cp: 0, mode: 0 > Acquire complete > Release complete > bP: 0, cp: 0, mode: 0 > Acquire complete > Grabbing mux in HP > Mux held by Task2 > Release complete > bP: 0, cp: 0, mode: 1 > Acquire complete > Release complete > bP: 0, cp: 0, mode: 1 > Acquire complete > > Rgds, > Mak. > > > On 10/01/12 10:11 AM, Philippe Gerum wrote: >> On 01/09/2012 09:50 PM, Makarand Pradhan wrote: >>> Hi, >>> >>> I am running kernel 3.0.0, xenomai: 2.6, powerpc 8360. >>> >>> I am noticing an issue while using the auto relax feature related to >>> mutexes. I am using nested mutexes. The code is attached to this email. >>> >>> The problem is that I am not relaxing after a RT thread grabs and >>> releases a mutex. On further investigation, it was noted that the rescnt >>> is not going down to 0. >> From your code, task1 would auto-relax only if started with priority 0, >> which is what I get here: >> >> -bash-3.2# ./relax 0 1 >> Spawning: tasks >> bP: 0, cp: 0, mode: 0 >> Acquire complete >> Release complete >> bP: 0, cp: 0, mode: 0 >> Acquire complete >> Release complete >> bP: 0, cp: 0, mode: 0 >> Acquire complete >> Release complete >> ... >> >> Conversely, I get the right behavior if setting a non-zero priority to >> task1: >> >> -bash-3.2# ./relax 1 0 >> Spawning: tasks >> bP: 1, cp: 1, mode: 1 >> Acquire complete >> Release complete >> bP: 1, cp: 1, mode: 1 >> Acquire complete >> Release complete >> bP: 1, cp: 1, mode: 1 >> Acquire complete >> ... >> >> In any case, the priority of task2 should have no impact on the result. >> >> I'm running current 2.6 HEAD commit (168da46de), kernel 3.1.5/powerpc32 >> (52xx), pipeline 2.13-06. >> >> Which priority arguments are you passing to your test program? >> >>> Another observation is that I do not hit >>> rt_mutex_release in the kernel in the problem scenario, I believe when >>> the thread undergoes a priority inversion.This may be a problem as the >>> rescnt would not get decremented. Not sure how the mutex is releasing >>> wiithout hitting rt_mutex_relase or am I missing anything? >>> >> These are fast mutexes, the thread does not have to jump to kernel space >> unless the released mutex was actually contented. >> >>> If I have both the tasks running at priority 0, I stay in the secondary >>> domain, rt_mutex_release is invoked as expected, the rescnt goes down to >>> 0 when all the mutexes are released. >>> >>> Has anyone faced this problem? >>> >> I'm unsure there is any yet. Auto-relax applies to non -rt Xenomai >> threads only (i.e. prio == 0). >> >>> Rgds, >>> Makarand >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Xenomai-help mailing list >>> Xenomai-help@domain.hid >>> https://mail.gna.org/listinfo/xenomai-help > -- ___________________________________________________________________________ NOTICE OF CONFIDENTIALITY: This e-mail and any attachments may contain confidential and privileged information. If you are not the intended recipient, please notify the sender immediately by return e-mail and delete this e-mail and any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal. _____________________________________________________________________