From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Charlton, John" Date: Thu, 25 Feb 2010 16:12:44 -0500 Message-ID: Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_CF7FB0793253794F9F45991443E5FE2006483DE98Cus194mx002tyc_" MIME-Version: 1.0 Subject: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "xenomai@xenomai.org" --_000_CF7FB0793253794F9F45991443E5FE2006483DE98Cus194mx002tyc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a xenomai application that runs without problems with xenomai-2.4.6.= 1/linux-2.6.27.7. When run under xenomai-2.5.1/linux-2.6.32.7 it fails with= the warning: Xenomai: process memory not locked (missing mlockall?). I ve= rified that mlockall() is being called before any xenomai calls are made as= follows with out error: // lock process in memory for xenomai int err =3D mlockall(MCL_CURRENT | MCL_FUTURE); if (err) { fprintf(stderr, "TimerInit: mlockall failed to lock process into memory= : %d\n", err); exit(1); } fprintf(stdout, "TimerInit: Locked process memory\n"); The relevant message in dmesg output is: Xenomai: watchdog triggered -- signaling runaway thread 'timerloop-2166' This occurs when creating a native xenomai task (created by CanFestival lib= rary) with the following code with no errors: void StartTimerLoop(TimerCallback_t _init_callback) { int ret =3D 0; stop_timer =3D 0; init_callback =3D _init_callback; char taskname[32]; snprintf(taskname, sizeof(taskname), "timerloop-%d", getpid()); printf("Starting timerloop task %s\n", taskname); /* create timerloop_task */ ret =3D rt_task_create(&timerloop_task, taskname, 0, 50, T_JOINABLE); if (ret) { printf("Failed to create timerloop_task, code %d\n",errno); return; } /* start timerloop_task */ ret =3D rt_task_start(&timerloop_task,&timerloop_task_proc,NULL); if (ret) { printf("Failed to start timerloop_task, code %u\n",errno); goto error; } return; error: cleanup_all(); } Debug output is displayed from the timerloop_task indicating that the task = starts, but the mlockall warning is displayed before those outputs and the = application already begins to shut down. xeno-test runs without errors. The trivial_periodic application also compi= les and runs without error --John --_000_CF7FB0793253794F9F45991443E5FE2006483DE98Cus194mx002tyc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have a xenomai application that runs without problems with xenomai-2= .4.6.1/linux-2.6.27.7. When run under xenomai-2.5.1/linux-2.6.32.7 it fails= with the warning: Xenomai: process memory not locked (missing mlockall?).&= nbsp; I verified that mlockall() is being called before any xenomai calls are made as follows with out error:
 
  // lock process in memory for xenomai
  int err =3D mlockall(MCL_CURRENT | MCL_FUTURE);
  if (err)
  {
    fprintf(stderr, "TimerInit: mlockall failed to= lock process into memory: %d\n", err);
    exit(1);
  }
  fprintf(stdout, "TimerInit: Locked process memory\n")= ;
 
The relevant message in dmesg output is:
Xenomai: watchdog triggered -- signaling runaway thread 'timerloop-216= 6'
 
This occurs when creating a native xenomai task (created by CanFestiva= l library) with the following code with no errors:
 
void StartTimerLoop(TimerCallback_t _init_callback)
{
  int ret =3D 0;
  stop_timer =3D 0;      
  init_callback =3D _init_callback;
       
  char taskname[32];
  snprintf(taskname, sizeof(taskname), "timerloop-%d", = getpid());
 
  printf("Starting timerloop task %s\n", taskname);
  /* create timerloop_task */
  ret =3D rt_task_create(&timerloop_task, taskname, 0, 50, T_= JOINABLE);
  if (ret) {
    printf("Failed to create timerloop_task, code = %d\n",errno);
    return;
  }
        
  /* start timerloop_task */
  ret =3D rt_task_start(&timerloop_task,&timerloop_task_p= roc,NULL);
  if (ret) {
    printf("Failed to start timerloop_task, code %= u\n",errno);
    goto error;
  }
       
  return;
       
error:
  cleanup_all();
}
 
Debug output is displayed from the timerloop_task indicating that the = task starts, but the mlockall warning is displayed before those outputs and= the application already begins to shut down.
 
xeno-test runs without errors.  The trivial_periodic application = also compiles and runs without error
 
 
--John
 
 
 --_000_CF7FB0793253794F9F45991443E5FE2006483DE98Cus194mx002tyc_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B86EADA.6080001@domain.hid> Date: Thu, 25 Feb 2010 22:25:46 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Charlton, John" Cc: "xenomai@xenomai.org" Charlton, John wrote: > I have a xenomai application that runs without problems with > xenomai-2.4.6.1/linux-2.6.27.7. When run under > xenomai-2.5.1/linux-2.6.32.7 it fails with the warning: Xenomai: > process memory not locked (missing mlockall?). I verified that > mlockall() is being called before any xenomai calls are made as > follows with out error: > > // lock process in memory for xenomai int err = mlockall(MCL_CURRENT > | MCL_FUTURE); if (err) { fprintf(stderr, "TimerInit: mlockall failed > to lock process into memory: %d\n", err); exit(1); } fprintf(stdout, > "TimerInit: Locked process memory\n"); > > The relevant message in dmesg output is: Xenomai: watchdog triggered > -- signaling runaway thread 'timerloop-2166' > > This occurs when creating a native xenomai task (created by > CanFestival library) with the following code with no errors: > > void StartTimerLoop(TimerCallback_t _init_callback) { int ret = 0; > stop_timer = 0; init_callback = _init_callback; > > char taskname[32]; snprintf(taskname, sizeof(taskname), > "timerloop-%d", getpid()); > > printf("Starting timerloop task %s\n", taskname); /* create > timerloop_task */ ret = rt_task_create(&timerloop_task, taskname, 0, > 50, T_JOINABLE); if (ret) { printf("Failed to create timerloop_task, > code %d\n",errno); return; } > > /* start timerloop_task */ ret = > rt_task_start(&timerloop_task,&timerloop_task_proc,NULL); if (ret) { > printf("Failed to start timerloop_task, code %u\n",errno); goto > error; } > > return; > > error: cleanup_all(); } > > Debug output is displayed from the timerloop_task indicating that the > task starts, but the mlockall warning is displayed before those > outputs and the application already begins to shut down. > > xeno-test runs without errors. The trivial_periodic application also > compiles and runs without error Please post a preferably simple, self-contained, compiling test case which we can compile and run to reproduce the issue you are meeting. The flags you pass to xenomai configure script and the command lines you use when compiling the program also matter. At first sight, your real problem is that your program has an infinite loop in primary mode which causes the watchdog to trigger. Then, the message printed gets it wrong. You can try and revert the commit 803ff2e093a4260054e1e9e59114bc4e656c84bd to see if you get a more meaningful message. -- Gilles. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B86EDC2.7010905@domain.hid> Date: Thu, 25 Feb 2010 22:38:10 +0100 From: Jan Kiszka MIME-Version: 1.0 References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig459948B2FD06ACE47F53D5C2" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Charlton, John" Cc: "xenomai@xenomai.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig459948B2FD06ACE47F53D5C2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Charlton, John wrote: > I have a xenomai application that runs without problems with xenomai-2.= 4.6.1/linux-2.6.27.7. When run under xenomai-2.5.1/linux-2.6.32.7 it fail= s with the warning: Xenomai: process memory not locked (missing mlockall?= ). I verified that mlockall() is being called before any xenomai calls a= re made as follows with out error: >=20 I'm afraid that warning is misleading. > // lock process in memory for xenomai > int err =3D mlockall(MCL_CURRENT | MCL_FUTURE); > if (err) > { > fprintf(stderr, "TimerInit: mlockall failed to lock process into me= mory: %d\n", err); > exit(1); > } > fprintf(stdout, "TimerInit: Locked process memory\n"); >=20 > The relevant message in dmesg output is: > Xenomai: watchdog triggered -- signaling runaway thread 'timerloop-2166= ' That is the actual error message, likely pointing to an application bug. Try to attach gdb to your application, it will catch the signal and allow to dump a stack trace that should give some hint what loops endlessly here. >=20 > This occurs when creating a native xenomai task (created by CanFestival= library) with the following code with no errors: >=20 > void StartTimerLoop(TimerCallback_t _init_callback) > { > int ret =3D 0; > stop_timer =3D 0; > init_callback =3D _init_callback; >=20 > char taskname[32]; > snprintf(taskname, sizeof(taskname), "timerloop-%d", getpid()); >=20 > printf("Starting timerloop task %s\n", taskname); > /* create timerloop_task */ > ret =3D rt_task_create(&timerloop_task, taskname, 0, 50, T_JOINABLE);= > if (ret) { > printf("Failed to create timerloop_task, code %d\n",errno); > return; > } >=20 > /* start timerloop_task */ > ret =3D rt_task_start(&timerloop_task,&timerloop_task_proc,NULL); > if (ret) { > printf("Failed to start timerloop_task, code %u\n",errno); > goto error; > } >=20 > return; >=20 > error: > cleanup_all(); > } >=20 > Debug output is displayed from the timerloop_task indicating that the t= ask starts, but the mlockall warning is displayed before those outputs an= d the application already begins to shut down. Way more interesting is how timerloop_task_proc looks like. Can you post a complete test case? Besides that this would allow us to help you with the runaway timerloop, I would like to understand why this wrong warning is dumped in user space. Jan --------------enig459948B2FD06ACE47F53D5C2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkuG7cYACgkQitSsb3rl5xRHcACcD8mtCCaO4f9LaFMWrG0W9zEl G6AAn0lqHzC94LvB8qsrA5Prj6nuQRo8 =rBHx -----END PGP SIGNATURE----- --------------enig459948B2FD06ACE47F53D5C2-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B86FCBB.10203@domain.hid> Date: Thu, 25 Feb 2010 23:42:03 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> In-Reply-To: <4B86EDC2.7010905@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig72A66244F388DD99C86225F9" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Charlton, John" Cc: "xenomai@xenomai.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig72A66244F388DD99C86225F9 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Jan Kiszka wrote: > Charlton, John wrote: >> I have a xenomai application that runs without problems with xenomai-2= =2E4.6.1/linux-2.6.27.7. When run under xenomai-2.5.1/linux-2.6.32.7 it f= ails with the warning: Xenomai: process memory not locked (missing mlocka= ll?). I verified that mlockall() is being called before any xenomai call= s are made as follows with out error: >> >=20 > I'm afraid that warning is misleading. And this should fix the error reporting (without any signal handler installed, your application will still terminate, though): ------> From: Jan Kiszka Avoid false error reports of xeno_handle_mlock_alert We already propagate the SIGDEBUG reason to user space. Use it to tell SIGDEBUG_NOMLOCK apart from other triggers of this signal, e.g. the watchdog. This also allows to drop xeno_sigxcpu_no_mlock. Signed-off-by: Jan Kiszka --- include/asm-generic/bits/bind.h | 6 +++--- include/asm-generic/bits/mlock_alert.h | 7 ++----- src/skins/native/task.c | 15 --------------- src/skins/posix/thread.c | 9 --------- 4 files changed, 5 insertions(+), 32 deletions(-) diff --git a/include/asm-generic/bits/bind.h b/include/asm-generic/bits/b= ind.h index 7267e0d..1aeffb5 100644 --- a/include/asm-generic/bits/bind.h +++ b/include/asm-generic/bits/bind.h @@ -9,7 +9,7 @@ union xnsiginfo; =20 typedef void xnsighandler(union xnsiginfo *si); =20 -void xeno_handle_mlock_alert(int sig); +void xeno_handle_mlock_alert(int sig, siginfo_t *si, void *context); =20 int=20 xeno_bind_skin_opt(unsigned skin_magic, const char *skin,=20 @@ -29,9 +29,9 @@ xeno_bind_skin(unsigned skin_magic, const char *skin, exit(EXIT_FAILURE); } =20 - sa.sa_handler =3D &xeno_handle_mlock_alert; + sa.sa_sigaction =3D xeno_handle_mlock_alert; sigemptyset(&sa.sa_mask); - sa.sa_flags =3D 0; + sa.sa_flags =3D SA_SIGINFO; sigaction(SIGXCPU, &sa, NULL); =20 return muxid; diff --git a/include/asm-generic/bits/mlock_alert.h b/include/asm-generic= /bits/mlock_alert.h index 6c7217d..eded3c1 100644 --- a/include/asm-generic/bits/mlock_alert.h +++ b/include/asm-generic/bits/mlock_alert.h @@ -6,15 +6,12 @@ #include #include =20 -__attribute__ ((weak)) -int xeno_sigxcpu_no_mlock =3D 1; - __attribute__ ((weak, visibility ("internal"))) -void xeno_handle_mlock_alert(int sig) +void xeno_handle_mlock_alert(int sig, siginfo_t *si, void *context) { struct sigaction sa; =20 - if (xeno_sigxcpu_no_mlock) { + if (si->si_value.sival_int =3D=3D SIGDEBUG_NOMLOCK) { fprintf(stderr, "Xenomai: process memory not locked " "(missing mlockall?)\n"); fflush(stderr); diff --git a/src/skins/native/task.c b/src/skins/native/task.c index ba04a27..6312f2f 100644 --- a/src/skins/native/task.c +++ b/src/skins/native/task.c @@ -41,7 +41,6 @@ extern pthread_key_t __native_tskey; #endif /* !HAVE___THREAD */ =20 extern int __native_muxid; -extern int xeno_sigxcpu_no_mlock; =20 /* Public Xenomai interface. */ =20 @@ -97,9 +96,6 @@ static void *rt_task_trampoline(void *cookie) =20 xeno_set_current(); =20 - if (iargs->mode & T_WARNSW) - xeno_sigxcpu_no_mlock =3D 0; - /* Wait on the barrier for the task to be started. The barrier could be released in order to process Linux signals while the Xenomai shadow is still dormant; in such a case, resume wait. */ @@ -231,9 +227,6 @@ int rt_task_shadow(RT_TASK *task, const char *name, i= nt prio, int mode) =20 xeno_set_current(); =20 - if (mode & T_WARNSW) - xeno_sigxcpu_no_mlock =3D 0; - return 0; =20 fail: @@ -347,14 +340,6 @@ int rt_task_set_mode(int clrmask, int setmask, int *= oldmode) __native_task_set_mode, clrmask, setmask, oldmode); =20 - /* Silently deactivate our internal handler for SIGXCPU. At that - point, we know that the process memory has been properly - locked, otherwise we would have caught the latter signal upon - thread creation. */ - - if (!err && xeno_sigxcpu_no_mlock) - xeno_sigxcpu_no_mlock =3D !(setmask & T_WARNSW); - return err; } =20 diff --git a/src/skins/posix/thread.c b/src/skins/posix/thread.c index d565d52..8084a20 100644 --- a/src/skins/posix/thread.c +++ b/src/skins/posix/thread.c @@ -330,20 +330,11 @@ int pthread_wait_np(unsigned long *overruns_r) =20 int pthread_set_mode_np(int clrmask, int setmask) { - extern int xeno_sigxcpu_no_mlock; int err; =20 err =3D -XENOMAI_SKINCALL2(__pse51_muxid, __pse51_thread_set_mode, clrmask, setmask); =20 - /* Silently deactivate our internal handler for SIGXCPU. At that - point, we know that the process memory has been properly - locked, otherwise we would have caught the latter signal upon - thread creation. */ - - if (!err && xeno_sigxcpu_no_mlock) - xeno_sigxcpu_no_mlock =3D !(setmask & PTHREAD_WARNSW); - return err; } =20 --=20 1.6.0.2 --------------enig72A66244F388DD99C86225F9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkuG/L8ACgkQitSsb3rl5xRygwCg5He0Bb67q2GdBAkn/V+E4a6g Z1gAn33mQR6rwJ1NiqfPQVxgsROYrQKW =zRF7 -----END PGP SIGNATURE----- --------------enig72A66244F388DD99C86225F9-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B86FFA0.3000403@domain.hid> Date: Thu, 25 Feb 2010 23:54:24 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> In-Reply-To: <4B86FCBB.10203@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: "xenomai@xenomai.org" Jan Kiszka wrote: > Jan Kiszka wrote: >> Charlton, John wrote: >>> I have a xenomai application that runs without problems with xenomai-2.4.6.1/linux-2.6.27.7. When run under xenomai-2.5.1/linux-2.6.32.7 it fails with the warning: Xenomai: process memory not locked (missing mlockall?). I verified that mlockall() is being called before any xenomai calls are made as follows with out error: >>> >> I'm afraid that warning is misleading. > > And this should fix the error reporting (without any signal handler > installed, your application will still terminate, though): Arg, it will conflict with the libxenomai thing. I am punished for not having pushed my work earlier. Did you test it? Or should I wait for John to test it before merging it? -- Gilles. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B870134.2040802@domain.hid> Date: Fri, 26 Feb 2010 00:01:08 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> In-Reply-To: <4B86FFA0.3000403@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC2590698227BED3EC50479F4" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: "xenomai@xenomai.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC2590698227BED3EC50479F4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Jan Kiszka wrote: >>> Charlton, John wrote: >>>> I have a xenomai application that runs without problems with xenomai= -2.4.6.1/linux-2.6.27.7. When run under xenomai-2.5.1/linux-2.6.32.7 it f= ails with the warning: Xenomai: process memory not locked (missing mlocka= ll?). I verified that mlockall() is being called before any xenomai call= s are made as follows with out error: >>>> >>> I'm afraid that warning is misleading. >> And this should fix the error reporting (without any signal handler >> installed, your application will still terminate, though): >=20 > Arg, it will conflict with the libxenomai thing. I am punished for not > having pushed my work earlier. >=20 > Did you test it? Or should I wait for John to test it before merging it= ? >=20 Of course it's untested. :) Yes, I forgot to state explicitly that it would be nice of John to check this with his application. I've no problem rebasing this later on over your work, the changes are trivial enough. Jan --------------enigC2590698227BED3EC50479F4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkuHATgACgkQitSsb3rl5xRcLwCgqr1ClCJRCqakuqZiyQq4ew8o ET4AoK0d+ePo4KG7JpcGQwvYS53hjlr+ =1FgT -----END PGP SIGNATURE----- --------------enigC2590698227BED3EC50479F4-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Charlton, John" Date: Fri, 26 Feb 2010 11:47:03 -0500 Message-ID: References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> In-Reply-To: <4B870134.2040802@domain.hid> Content-Language: en-US Content-Type: multipart/mixed; boundary="_002_CF7FB0793253794F9F45991443E5FE2006483DE98Dus194mx002tyc_" MIME-Version: 1.0 Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "'jan.kiszka@domain.hid'" , Gilles Chanteperdrix Cc: "xenomai@xenomai.org" --_002_CF7FB0793253794F9F45991443E5FE2006483DE98Dus194mx002tyc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am attaching a simpler portion of the timer loop that demonstrates the pr= oblem. As I said before the problem does not occur with xenomai-2.4.6.1/li= nux-2.6.27.7 but does occur with xenomai-2.5.1/linux-2.6.32.7. I had some problems applying your patch so I will let you know if I am able= to do that. Thanks, --John=20 -----Original Message----- From: jan.kiszka@domain.hid [mailto:jan.kiszka@domain.hid Sent: Thursday, February 25, 2010 6:01 PM To: Gilles Chanteperdrix Cc: Charlton, John; xenomai@xenomai.org Subject: Re: [Xenomai-help] mlockall error after calling mlockall() Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Jan Kiszka wrote: >>> Charlton, John wrote: >>>> I have a xenomai application that runs without problems with xenomai-2= .4.6.1/linux-2.6.27.7. When run under xenomai-2.5.1/linux-2.6.32.7 it fails= with the warning: Xenomai: process memory not locked (missing mlockall?). = I verified that mlockall() is being called before any xenomai calls are ma= de as follows with out error: >>>> >>> I'm afraid that warning is misleading. >> And this should fix the error reporting (without any signal handler=20 >> installed, your application will still terminate, though): >=20 > Arg, it will conflict with the libxenomai thing. I am punished for not=20 > having pushed my work earlier. >=20 > Did you test it? Or should I wait for John to test it before merging it? >=20 Of course it's untested. :) Yes, I forgot to state explicitly that it would be nice of John to check th= is with his application. I've no problem rebasing this later on over your work, the changes are triv= ial enough. Jan --_002_CF7FB0793253794F9F45991443E5FE2006483DE98Dus194mx002tyc_ Content-Type: application/x-compressed; name="timers_xeno.tgz" Content-Description: timers_xeno.tgz Content-Disposition: attachment; filename="timers_xeno.tgz"; size=12849; creation-date="Fri, 26 Feb 2010 11:35:26 GMT"; modification-date="Fri, 26 Feb 2010 11:35:26 GMT" Content-Transfer-Encoding: base64 H4sIADv5h0sAA+xaC3BUVZq+3emQ0J1IHMEXUY8QNIGkk0464e0SQgLBADEPDKPYXLpvcq/0y3tv RyI4gpFZ25BdRnF2ytqdlcHZ0XlsOaszC6hrpkKNyLozyLoW66MGZ7GqI9ld1h0RAc3+37nndncC uDVVjFVbOxdOn/s/z///5z/PG1OLKLoR2KxEY5XSH+ipomdubS1q39zaquzafiSfr8bvmzvXTz9S la/aX1cjsdo/lEHZT8IwZZ0xqsnG+dXzL8335fT/o4+Z1f9Z7964HrtsbaCD6/z+S/Z/XXWd6P86 n89fTf1fW1vjl1jVZbPgS57/5/3v7mhc1dpS39HIFjM5Hnc3rFnd1LycVSxmkVjQ7W7vqF/evHp5 YFlzGzGUlJRmIcrcmtEYiZt945Bsi5sxNl6uMmHoleFYUA5XxpSKkNJbaUbilRT4Hi3a436QmlnT 2dbQ2M7mLGbZSUgGdDWuXhMQRnEDshBl7mAsaspa1MjGljPvbEhXELFb6/HOtkzSosFwIqSwUq+3 kv6DIyJrXkKXETWiGIbco5TO6DTIJNZlUZkS7dX0WDSiRM0ZZWSoEjYUrk3R9ZheOqND1QxGQ6VH lyNMV+5LaLpiMFNVLqnBbbfUbnnPQpq+gPwaF1f3V9f/F47/YHePV72sbfwv47+6tspvj//a6mqM f3+dr/qP4/+reCpnu3kSd2thhSGZZd1ksW7WIEebFMPUeuVwOZNZWNuoy3of0yLxsIJkRuoSz5q4 EmWUysFNXuZ2N8TifbrWo5qstKFsAWsMxRKyHmIdze3tjW31qzuYHA2xJl2OBqmlZZ2tzatp6CsK a1jTuo6S3zKiO6azoK3IYCGFRnjY8LotO9OGkMk6iRqxbvN+WVcWsr5YggXlKA3DkGaYurYxYZJH JtqsjOnuSCykdfcBkYiGFJ0PUlPRIwa8BbB8dSdrocFJtOVKVNHlMGtNbAxrQXeLFlSiNPBlCg8w hqqE2MY+LtUEI9qFEawpRsplU4tFFzJFI7ru7qUhRTCr9vrsloS+ckaelsomLNdZLA6xMjK3j4Vl sowJyYt4nnEwRPMa16nG4uSPStrIw/u1cJhtVFjCULoT4XI3cbI7mztWrOnsYPWr17E769vQHesW Eqepxoiq9CqWHnSwRmrJHeons49sdq9qbGtYQfz1S5tbmjvWweym5o7Vje3trGlNG6tnrfVtHc0N nS31bay1s611TXujl5YARbHj6r5oXO048B6PxCh8mb5eR51pkGXhEFPlXoU6NahovWSXzHPj9+iz cIwyFW6SQCaKC5nWzaIxs5zdr2uUJ2bswt50Z3qznDVHg95yVjufdSgYAqw1LAepB9sTkK6pqSpn S2OGCc5V9YxVVft8vgpfTdVcxjrb692zK93umVo3JV43CwQ6mimi7Q1NywMrAgH3TEJqUeUCPAmI JWtRlIzoVSpN2djkVW+7CAET90UpEcqRzRel0OoYuijBUCIXxcthWecUd2Ul66AWaSBRri1gUSON odUvFk4gYoSv828keuk3auf5WZ8i60ZZ2ld4ura+hbXhZSI2sKq+i32jlNPKqtLUVe2BjjUBwVMa McoY080Adz0QNapNLbjJKBVSEWO2z1pcMm12jpNPfKl8wpKnlThtW3377QEaBMtaGsnqAEAiKlGa VL7C1fryP5fY/1/WNr78/Of319TVpc9/Nb5arP9za+f+cf3/Kp6HGluaHA5HGnZKORKgop2ufD/V x8UhnI5jUp5UKs2SZkiTOExlG/FQOQ4+KrlUXFRyqEwlJVO3u/JRriL4KkFziMIfkkUpvkaSUCAv FVl0jvsB0ai8RYhWp8TbBZ1epSqiVxENhREdZZJoA6WU4FJqG4URzLJod3xohi4WC1u+khaJynCo IqxFE5u9RsxbbeGLhO206ohYWTLAz6JSLvRMo3L1BN0zstq4Trx7RHt4bqYyncoVVG6F/VTmCNqV E3TlU7k+C55N5WtUZgr4FioUHukmyYr7lz3wAXHPmYB3XIQXE91k8Z5HpVC8w/+p4v3aCTJTqBRI VvxvoHJjFq1Y1IhdCZWyS9hYI+ofSZafDwvjrhPwLU4LXiTgFwR9voDPCfkPBFyUpRt23TQBPkjl jd0uhJn4C6U5Qt9cIf8rAS9xWPArAo4Ieruw55eC/qzQ/aagPybg3wp4dIJ/hY4JMOkbJXuQK1dS hjwo+IeE/qcE/JLg96P952z+ayR7Nrfbb5jA3ybgPU4L/rlo3y/oS4U/djzlCfYuFPRXhT23C3im oB8W/HZ/uSb4lyD+U89a8S6S/mvse4J/UNizVfAHBH+xgDeJ9rYTX/i5jHwFwSzL/5uFPacF/7tC /6jQ93MB/1TA0Qn2KEJ+nt2+gHOFvrepfiZp5wuNEpo/rE0TJo8aKRDoicSiASw0ZiAgBVb2BtqU HtrDK3pDWKbdqyERgW/VAiElrJgKYGzQAkFdkS0Qm78skHZpWbycyPWnJe+XNTOjdoIeI6wocVtN Fo1vhggMSQHa9WgZeTnI7zYyCJ3alo2MoYbWE5XDtsq07t40wwRjJ4D3xrQowqaboQiC5gMQCluT L8ensT1UKqq9VUBUARE3VZhswXGZDj0UcUXXo7EA7pywG81iC2SpotY2WWJkR1zXomZ3+i0QJAej iXgGQQExIWWYoeCcOZCrAxhJv/UEgwEjrTxo4QPNa6hnQlo0QIaFJGUzKYknTEPqUcy4FpKIRgcw VGSy1M2PI1KEDN8kh8NSt7AqEIBGkUIRmYJlRG2SQmcUmTg2GobIgQDtS6XlLc1LGwIUKJ6rzqwZ 3p7bJ2Jy0vic9C9oOXyVcIzDYJeAfzlOaz5lGCuaVgi5bzptrQ4p7MjMtxbdmaa30hibhAWRxmru VGvM5tJCsIHweSQXQk28KmpqOoyaBnUcNS1aJmqS34yaFqatqGn4bUNNi+sjqGnxeRQ1tbwTNS2w u1DTwrQbNRn3HdQ0kP8SNS2YT6OmRfwZ1LSQP4uaFtQfo6YF7nnUNJm9iJoW4n2oafF+GTUtakOo abE7iJoWvEOoKUBvoKaF/ghq2hC8hZoWv2OoadF+DzUt/sdR02J4AjUt7p3JD9v7R10pxOyu7cPP kMqBJ86PjY3tOGrmpqKETf2YwpR6j3zvuuv14bHaLpIcm3W3mMPGZiGi/E5v5DiJjc1CZFXQRo5w GBFW0U0jQxxGpFUs5SPPcxgRV9HFI09zGJFXsUUZ2cVh9ICKRBvZxmH0hIrpciTOYfSIugTwBg6j Z9QVgFs5jB5SWwEv4TB6Su0CXMVh9Ji6ATDjMHpOhUMjRRxGD6pxwBKH0ZPqZsCnvgCMHlW3cf85 jJ5VH+X+cxg9rO7i/nMYPa1+h/vPYfS4+jT3n8PoefVZ7j+HkQHq89x/DiMT1H3cfw4jI9Qh7j+H kRnqIe4/h5Eh6hHuP4eRKeox7j+HkTHqce4/h5E5aor7z2FkkHqK+89hZJJ6hvv/OeDjvP8d8J/D J3j/Az5CsJT1+P79nuQH/SdOtXa0qVW70Wv0c8dadcO3XPmpBlL+u127RD5uW1yCRTdRua+UNuEV JfTzizPOwa6xk4VL9pYSaWzqDiD34H3+Mf2jX+ZCwNF11/phUtE/mt+/uJzoknk1QiXtGDIL+0cL VODGjvQfLHp9mNryHU1+6BvqH7022VHiSq4/k0ycTy4ryX/NVTKPlKXQHykP+SQQyeHk23Nu6MLb tBb6nV57N/3uXQHet4g3eWyAdHw8QFpG1w93k/7XYcq1pHlgfb5viNQPJAqSLSX51IrLbmUBJG+o gtZaP/3a+IcJT/pea8zvINBSOrKKQpo8PfgytvFS5z7MrdxbEgLX3nJIlhLT62jfJqnA/pZjB/mG ZPBVLk8mcfvIGnq1POe83efBO15+4+fpQKQmnefvaDJ12HpvxfttFs8GvC8lPIW9gOBT1M+p72XR vvn5OP0c97UJ/HoW/1qLH/ZSdvi5m4Pr30t99xyFo7iETC/YN/qkC3HN34e5BC6lNiBYd/NIf0bE 1DZqwXd0H85F+6stpiLqjQLq/XzBx1tbwS1JbLBism/J4y67wzh5smVoWaqIWh+QCL3EatqVupFI qVmUMf0H/ZSJgy/iuCQJ3WHYcP6cTezelfr1WaFgqq3g/TR5sFfMzX6iY21MvXkO7U7ZgSPrHqxn +3GwO8BzgHKK4oE0Ju5DlraC1KskkXrgbCZG0749MUaLEJMhTnRYODsUvNNfOWu1WU/EVBUB+5nV nMtW6RUqUx+fQ3RJVwdFNKOG50WvUPMO/Bj5LGOQ/wKDfnQu3Wk81W4Xog9B9G8/u4gFC2wL4hlR nplxLmpevwebgAPTwXY32YWx7ipJ/R1ReRjRgZaKgn1XiRjYwXCltpy1e2TXvukWm4sr5LpIz73E MLKR+vwS9JWg512aPht0TDVol1Ne2vkkJ3MzPWf5MIA9qb+m90HzFkmM/0EKAk2nY/ed9w1RrtzR PzpV5KnE8+UMd7/402Pco45xjZPmn37GNUcJn8olzamd1ojDDip10CI+DGKK3lMPIbX/wcLuBvYo sH3IsLd40k71Da1bPyifH87MT/b4/j74nWeQaTDug09yeWifP8O1vQzqiU/57GQNGFse4/3OtTQG irP9+uxTKyP+imJCuKMQ/z7hUuVn0cIAn5v3YkL1De3FjLpnhdXLI4jAND5nd/H8IKERHJhFs6mb yKUBPhXn3ACZAT4hX1ULhcnGVPLYHPrpHE1+PJ1+rOkSiYaMPzDPenGlDpPW/jOPJ1+b8siAxC3k efwCemPMvLJ/7LxZ0D/2OI3vKTsOEMMeTGbw5ydYIofGTcZc8jqS3AOjBhbDnJvPLJmy4w7Kp/2g +k773k2afLRhZUnn/rJPM8vWa6k6UnFye9Jau/iqZSsvPiPG/4QVIHSaArrwC66EI/aSQtvURzqp +e5dya28vXPogJLTyIHiu+4JrB9RT1tpeqnEm4e4LyXdu8Y/wycLx8Gd1Pepeygq24c9tIWn9Xsg XFKaav6E1PcfIvnBJ/BbdiT52i/GnGal7/T4/BlYVlKSDFurLb0zants9wsQaZr/hf5B/8ECmDs8 UFwyzPcdL+FCkDYfJ3Npi3DSNZDTf2Ys8TtsKdL7EnufvJUmilQr+bGO9sQ5/DzilJpkLayE8L0H R07rwxA+XejhWCzOcBaVsniso7H1Nwlg4IfVchaMhRQ2K4T7sAwvP3pdgjXBvxG0KHIvvpu2g5M3 2mI3ymYZbomjmumUuYDZB0DWndYPDP7WIKgYBqOTX4xFlEhM71vALcmSbSFGErFZLS4YkLatYlZI 4kbAGnOc99yQdh84GvE3DlYIwMcJ1SCs4uQG/pvVbthyzz3+xCw8sKwEQpPD2gPphr1SVtwYzAAG xmQhGqOmokMErS3TjLhsBlV3Op7jsRP6gXvlvQBNGNirXOB+yJv+noOjRHYtSZn7a5R5DqtuFHWr qO8SdVjUT4j6b0T9nqhPivoTUeMsjbtS3CXhbvUNcee3Yjudi6nu2EHnZap3P+zKh5G7nNYdMg5u 04R9yPMO2t1jgShyWPeyuD/GffDuR135eN9KNe6tcMDDYoqDIA242CLCk6sxyJ6i+sSfWufH3/fB nbz9/hH5cpaK+zFX/vVUZlNZQGUlla9TuZfKA1Qeo/IUlR9SOUDlMJV3qHxE5SwV9wDJU5lNZQGV lVS+TuVeKg9QeYzKU1R+SOUAlcNU3qHyEZWzA1l+LG9oWMBKl6/uLGN+b4235qvF8Htu6/rDuvlH X88QfZ19V1/M+X6T5nt6pyt/e16Gbun57zybfiRp5coJkTP2g7tTS89U4i0jUo9iNobluKGEMG6k tYQyFGs6kh4ioJ1GX3pykp5wWfOWsgrXftIzBPLRaIE/I5DzNojLssOEEBdnAdxf/YYrzJ7uJJYr ZWYNqZsgfp/1gkDbA1k6lJs1Y1m3hJjSpPtoCOBGUcPFnnUbKfUTLusvVgT2SYvT1GNhLi/9YJJQ GSCPpf2TJjYg/SOhwrJh3YRaF6Hv26hYMJjQlVCAfweX/jObM5YwuUYHhRiTl3WRyuP/bqa/059U LvhzuIr7TL+3jv9R3P0xfVOlVjevrkKO9hhkesT6DFWJa89gRbV3foVeU+utrtyY0MKhiotxBo1E ZZDmdm/75WkpDUMzPn6x+nb8Ocs8ybGtKA/uWZf6SFkH5rgvRL7eTLn4Hvzfip+3cT+U48p70Ikq FycklyuXlgkpJz/31wTluvJynHkraQbLcUzCN5QcR/5Kzpy3mUOTWlA5cxHZnPw8gyAnhkTOvEY0 8OeQHMRHGucOvP7ZNnqd5MpzraU6Hz/7qUxukfDFx42PJLtzK/owhwYoS11FjtsgOlPyfEA41zTH Xg66PC8AvFqA+Z53SbfrGgEWeK4C9VoBFnl+hlBcJ8CpHnxndF0vwGs97wOcLsBiz39AtliAzIO7 TdeNAizx/AQN3STAUs+dkGUCLPc0IX4zHH+PIMys8vwFmEscr3DQ76kB9Rbh0TzPP4E6W4CLPFgw XOWOAQ4u8XwK5irHGg4u83wMZp9jEwebPM/ByGrHMNe83PM+mOsc/8zBFdjzSa4/cXybM7d4boDs CsceDnZ4cCh2NQuwy9MFVSsFeLenB+DtAtzgWQzmFscsDoY8/wJwtbBZ9fgBtjr+lbcblgq2IFgv ur+LNdN1AGEoXAaWl6yISIW3QvvLVkBchVcAGrKU5Ut5rm0E57n225kBd3hmAIuc4NgRG3urdIVr 0lIsroUBfIheGrJSRXIuQI4tBaMTk2veIk5ZR6/5C/vo1T0Nr5OXIq3599LJDZ4cy0CN6snLLE0u yfkYGmu8GUQnKG9CxO2GT+45W2xxd7kQl5yPUE+4KzYAxBcvdwxMbtwqFni8h2wBT5Xd3n1Ue2oO 5VgBOYvEr80EBM45n4bAvG/h9d9Iu2fLr6DyRXR5wcwxW2XBrLQNfvKu4NYTAHFbU6CCaYoDOxnH Fge9jWJv0++gvchR4M47rs6xJocvdlqLMtafK3XF+B/2rj04ruq837t3116tZWNbxg9s7LuSTVZm tbJk2TCWbSxLK1tEr+phbAO9rPYhbSztLvswEgZPqHn0jwQwdob2jySktAOk0GmnpUkwdAi0GZq2 YWgZQmc6TdIE4nRgSiFT2mbS9Pudx73n3l0/wIK0M76j1TnfOd/9zvv1ne/7rqb/ElHsDn25/jPy 6u/p2hf9wZvo10OBWJsahkDu34AIbq+2Qp+hUP3wbYRznH5forArN1DQ5wk4Tb9vIwBN8BgBL9Lv XQpYqZ/AVDWtI8B80B9coyPwVqSZ0BEwTD/s6lbpX0Hg9wDvesgfvB2SBgGWYZrtX0Xt4YS7+lpg /f1TqMyTY2t05OmnP6B3qCQ4eejX6nvo7fGT/uBrhJ6xKURB4Zc2hRZBYRmugvQtiLwVi8dV+svI 8EKdjQawYj+k3zGKeoZIrcV9pb6Axa1t5H6Er2NUgiz8L3ysZz/OSr8LOGFde8QfbKffP+GaVf9X pPBFHYw0zNtBys+NtMZdnShOavoX2Bg9KXL9IChiPPJ8PgRwhMD1N4LGl1nrALwTZfoKwHvptwHN 8OQpagb66d/YgGb6K/K+BvBbmvkC4QROYrzqupmhyMAjAngFi8MpDoTBpdev/EeQDhg4HodfRMTK +3kIzsHhcfSSVSIEzK0w7ir01SE/C8HhOzwBnDXjHAc8w/CjCFm7koeAtRBGc+vrRAjO5eH9oHC1 CMF5P9wJnA2oAgrB2Vu7hy35Pkw4+h1+fjXGVtxkMj04lZnIx0qf/MKsL9OWLhhfYATXBjcFG3B6 0Jfpm5Y0LDKWrF2yTF+uL6XG9a3UjCU7FnUu6qOtp7FRW7RoN8VjIeFeGqAB7qVJ7gryUB+CA/Sg rvc16OSpC2t9Da0UFWrQjSWLFoEewhct5sQDfQ3X02mlXqZFk8hiO1nELGnQnbeuiGk31PPYz9Sb hLw0pjsBfQ3I+p4FwFzWQZsATsVHZVmu4jlYVHSZFrBWOOQ5Dk0PMa2tQQIr1eRl4CqHtEN4dYdD mAqxJqRJDBqv9gsBd57XBuw6ofEpChDgWbs64JSHCK7vcGV8w9UilwcXHaJaMZ3YG+p30qExrAbg fa26B7zJOiaGsq7/Ysli+q+Lo6z+yW9JtVistTRXSqULpdZJyOpmk7Q759tUygE4AxA5iCX5djng w8nIWKKHW8O7DocnJ1tbfQHKsd9HUTgsGe9oIo6qR9ex//Fps76PWLZkMV8qscIxoa/JZLJmSdnp rVVIxJ538AqllppU8Jqg0TqRLZ9/FrhIQpdEQyjB2JlKlGZk2LzSzVXoTFi5tPJW0WQCNi4BVuo7 Gg5gqVQ6E2PXneW5QrpEXh+TycnmyWswDOlNlPMz2ST5/Q5ywPHihMiEruFjgtHwCKFqTRxEuQ9d Fvsa4xe63hjdEt29f+qDw8XPpifThw8bM++HW55p2bkruOvM852VtPH28TcaD9xcOnTI2HTj5Bnj 6BvhlkPBQ0Y+NnmGng+eP2NMxybhnNVijdGpm33XrPi5L9IwHPzqZ4O5Qy9/aBR+y1gazBgvHX94 7swDwdbO4C5fU0Pw+w/g/zP4/wH71x98xPeZBuNo2ZgL/oT9ZoNvBE8a/6AHM19tqVD8H5059MKZ w4fPHL7ZuPd4cOfkmWAYqb7fGL33gweeP9SaPmMZc+U/NZYElx8KlnYf2O1rXHl9+8wLRsbXqAcr wd3BD/NbjbryGaP3OWNnsGz0HzR2PPfWf9NLxsjDvjANxGE27VxTc9qhlqdKdNZFnVckuBnGBj0c Dvt0wqcQ8DWMFicERxjw5Qi4K1jv9/+27sgTohnAku5aErzP17M4MHS/cQI8ERnPdpVKfO8J/35s FqQMI3aT62X8vsUBGY5N5QoZvtcJx97SVOjJcGwvb6uBjx3mFiVcykxil/muQqfnhGHLU2L/eKXP eQdxG2V+aTP4KLk99bpW59d7qTq6BVrXvUq52IZPSVfWB/Z8P9LV+gjc73/A0PKFxO0VCFPdXkmk rLJm5adTVj6TAasDu41uwdVyWCojY1DC69Fmc4licsrio4veTFaKxXSOM0u4RFTiaJpJKQFgMk8M Kk3li2Uwt7VS9s40vehiLnm5PpTawPhY/KA13N/VHd8/1N8TH1EIFspFzlqyhdYKUNqYolKkiwxv opKxJiDFVovP1DqVn0m3SrHvVgr7XDpZLrUOdI+2dhUKvcXETJotjarYvAUVJnIVLpA1kygeIQTt aGKaatPFkPKwn2rwmaiMo/EBVwk9DCr3BCjF7dSiCtkypgnD/qGCIRt3xK5ClcdnUfpEZLoyk1N5 fVYhX1Jql9UbHQ6OalaJ6lFklCH09vXH3by8Sg7ygemUmZxKUI1YhURqK9VEBdQ52AFaSSWP9ivI rNC4qGpoXrWUA/Qb5AKBTMoPvamaI+jhfdrY6CqyQ+BN1E3SSdcWa1T7D3Ldxp12tkrkEiBZyUHO r51HbNOsXHq2LPq1q0gql5QPtHYtQy3LmoUyNS06gIURt70Dww8+uFSJ1Ks9bFWW/UTyCJFkTcNk DhVGq5WZTkyWKF8z+ZRSco4r+b/W0XJiYjotBznTcnXG64QQ+ORjRKmL2dxUIpeaxoAVM0DtDiv5 pEzJRuRICkC62c5IEzVBFDW+VtASUmYs1AD3sxuR32T+is3d76UfZPMXaKOn/AdO2YxwzMIJQQNu WtCA+w0PDeAeZWEnmYv4haBXqXcIvki/bwuCcF8RBOH+s4fgDzUueg5cuD8WuHB/7sFlq6IuCqtz EWNWWJ2rOKi4gMMCF26TwIX7eQ8u4HsELtwTAhfuH3twAf+JwIX7rMCF+2WfG3c9wYzloA2Dq9DD vQlyZrn3ODn3ca985zEfFzUHfbiPc38QLi4UVPrNBuc00OtgKRzj3j8k58+5921y3uVeH/hvfuZt JWcb9w6RM869eXIqfldenqU0X+TZe4hifscd+yKBf+nnOYX7XRb9G3D+TgTDfZX7g3BvCrgL8BaF vc+pGhR1RcCVwG0EJgKiX5Kb5P4g3Ec8lB4j+GsCF+4fCFy49yx0495KG1JrAUvqZ+QcWAjvTTL2 BXrjVZ6RWyjmyEJXnurohVs4vSk17DsLnHH1HvnHFlaPM+euFKe379APR7UfnHbu32Q8dniv0w/7 urNKvBYrzc3QJERuucjdKenLYrkoaLFcvpyOde3ta6EjgxabSpSmtFhqLkcvcpcm89hkrhITCrQu wKK4YnoaeNxTmC6DMs2QsTKm6hgTfI8V80yqOpaesjJY6bVYspynRTyW4s7nkkWWWII2OJRAvsz+ cWr8zYkSoSXzM9CWprD0RGXSShTpZJMuSbBQmcCiYcPZXCZvo05MFNNHJUTnoLT0i/xwgBVW4NCm RXhFMh/hge4Rn2WF3pbu1h2Sl1fQ6Vgo8Jh+lc4ZXPKRXaFNkzM1v7/eT3j9uhMvdbFwXbNI4OFe +7QYkAGRptS7ukHjd9vAwz34WIDff3vzt4/3MXaHjfvrn1BmDyr58kkaGr/zhh/33jupB+5R8izx caSsE2G4N78ryO/N1XKg804reLhnPx3k9+9+zdHzAl5F5BUnRoyR36eXVD1HSbeg4GGcvA48nxsP v2MKHnT2ltZr2vPKrb2Uvb9HwcOY/NsVynlISfcBzekHGJdnCa/FV433kIK3+lF/cPUqJ07F+12B h7Zj+nyreD148R5T8CA0vPEceE8oeBAUjp4j3adFWYHH9ARX8QUzoOCB/rMKPegjDK+upoffcwoe 5CvGCO90DbyXFbyzhHd2de1y/LVIn2lUPOUPvrea9yH5mML9nubWxQPecQWWcd/34BXWiCsS8cg8 vO3B++Eavjnw0vsPD95tNEHMBqvxfLob702aIFbUGJdLPXjvbNK0v/FX463z4H1zs6allAD5SrPA k2NnXVTT7vfQw6/DQ+/36IWnDTcenhs8eMMdfD6Qjyw65GdUXcmHCW+gRv3JsSGfJzupDoJcbuN6 zZnX6jz0vtmtabsDDqzmyftgntbY+xwrYsM85f02zFPA/MphXlGYRznME5TyPgbnZ7F5kcNc8OQu G+a1cdqGuVao1IEzNC5C9boNL2Lw0i9IuJ7BUsfSEJqkZ214CYMxr3D4Cgave0LCfFbbaMNcQzZq w8sZvMWG+Uo2/KSEOUdkzIa59NRZGxbau09JeJWr3g2Plqtha/RK+CoPvNYDr/PAV3vg9R54gwc2 PXDY1U/82r//KuiBGzwwUpD1CW4a7l032vAyDffaURteztbVDtF+Pmq/W4EPbQ4Wv4rNXRGhcwn4 TnLvUPC96d9Prqmkf0pz2lun9v6aJ30I3j592qHnLd/LHvg1Dww5FNneuu9K7X2l/JpvqWbobnil 7vQf3degbRAVLHVWW3Wnv5jUX3aIeKnjegDvU30AATqokyJe6ijPCVjq1OIgBn0bncH1TGYQt5v1 4v3HdWf8IP7rBO9X6H9L0PuRoPeS0iFM+r3mgd/S+XiTOsW4px9WdGb/S3frQP9KvC91oOvF5CZ1 oK8SsNSBvtajA71fwFIH+YCA/0XAGZ+7fise+F6fWwf6FMFjSn5xMJXtQa2nfZ3gg0r94PZY8j9R f9/1OXxewG+K9KRO9Vs+h6+L+PdEvNSZ/h/ASvpLDXf51hsO/xfv435f8n0BX2e46fUS/I7I/zLf Sm1UxEud7AmCb1PKA2GOyBMSf5l2nGCoak0K+g+K96UO92MClv3tzwx3/b4kYKnD/bqAm0T8TwUs +/d/et6HzIOqM73Y7/DLkZ/VBE8p9bVZrNVSx7sTsODLA79HxEud73EBS53vlN+t8531OzxyvF/y u3XA7xPvSx3wL/kdvjfwnxLxUif8OQFLnfBXPOV7VcRLnfAf+x3+Pei9L+Kljrgv4NxLIH4ZwU/I 8eWr1yIBh4+P+JaAW6d8K8FRpTzswjSWVO9Nk8VyqVzJZMhrWd1jQyNWf9/oGBTOrR4XdGO3AqTy 1uR0fiIxbbGTrZWozGp0ai1APTsV27Z1S7uGCCubmgXUobHjp5WqzMzMyXTigz2MVu9I10DchpCM 9DupJO1U3Izr9HSmRZTJ2tc/tLer3xrq7R2NgwO7tz8OIoi2YJdqjl8dqAFC8bnn0GDXQF93lT49 juQSx6MbvmePoyldxankStoqiqMpLnSyk6UKV5b3Xk+I9DzseltD/iKsAliZgjV1h/vKwFbMd/Tm 3RrqVQrsVbrjnuK4bQB47QV4tPtVXX6PartzDUTt7dR3jUsN192Am/HrMl+g3D64LRfwGw1PORQj CO5rI4XT7rGrQBkt5S3OvPYaWfDczYhBJDu03fSsznmPUPMjFThq1LWoPa7qr8ZnqsnUMsDA7Sqo +v7K5U31nQerMZWmze1nthJqVaJsX4wy5waBM+pVfNgxUOFa12i1LEaodia49QJpzUCl5rnggOUE Ndp7l2NBciBGoVYhaZWnKrkjsYlZfgHIG8kjmX35waPa/xpIHEnj/jI2z4bALmD/s2NLR7u0/7Vl awfsf23v2HbZ/uen8jSFzckZavdQqCnUZLoMeJrt1Gxmf6KCq3tzL+zWFlOERH81TYYmE7nMhUyG wsgi4eUL6RyRKcFwqELxYxv3bDIvwbxnk3lJBj6bzHkw8VmzDj6qmc8m8xINfTaZl27qs6l2LZ/H 2Ccr+yUb/FRa8RJMfjaZ82f0swkWcbul+euJbK41mUwkUfXVIm4tk8mk2TIDqZldBYyVygytnmZL tjRHG8KZeRAUNFuG2kNDw2NWd29/175RyhYCbGBjxIlrDg2PDO1zEM2WnvHRuAUb22ZL3zwK8RFh i1rU4ua/AY3E44NjzFRwy01Qf20pZAsMjaVuWeTtie8d32dRz4agwegQHQ2GBu3g+EjN4IHRfa7g ydDQqEUnBVg970fuQl3U72XI7PXbqQbivX0Ha9kuv/jihkLcoqvVM9J3IA5D6MrCGgr1DXb3j/fE WVP0xUKhob038pZwvdUcI9TRkW4mVVMzPhkK0aaIkemfj8ah8XKJlBiFm6aje+YpO62FfCk7G7uj mCgUqP7ms5zTXI6UPDA9Rk5qmvnpnzQ0Rl5hO8zxWQwD9sNokFNH3VHVLKGQN2SHiVFGjdwcqtsY 6e9pJrCfDzizJV9FQCIDi5qXCG7K7zA3JfFydzeCxWglnzJeCTwGsIf6L83bd1Os7Gg8mT1mS9Lc uDMUYueiHaG6IhU7Y2ctNFOkmYeqeYfJEP5fW7e9/FzoqbL/O8+2//FceP+/zbb/D8P/W9q2Xrft 8vc/PpXnsv3/y/b/L9v//3Tt/3P215TL9r8TpljeVz7Iohrkp10QFZGHuoznj0gL9X2DY/F98ZG2 7TDWb7/YCFZbbKqRAjebLfIxmbILG5rJfI5mwxwbdRlmq4UCFEwqhju5Xtqvm1s8gV0jA/Ees80T OjbSt89srxFoDcdH+oZ6zK3esgwODdKZoA1FQBZRd0fz2ZQZ2czZu7TtgsCzVW6OdA9ZPVS2zWYq ao4Pjm5tN7Op5k72pQIaKZVkWThWSVQ0zWA0lI4BoY5euB6siHK6k8EOMQ57UqNJhns7TarGMcbQ 4AFmpkK9BLUkyLJ8XABNfgqBJtpOVwCTdkQo3h9OF7M0gSWzNCL5i3fz4smaOV8xXVCnp/VhJ6ic 533A1dKtm2VzjKbLXeDbR6h2s/STBYmaTKUhahZY7ppNzsONNG4qRc1NhGi/yAJcv+Zbco1Rix1q LCtKA6CfdqvwNdF7TUilyUmmSaTTJBLqNK2LzROrLNfYsN+s1Wmi5rlaO2oqLYUEJCjz5E2nJz3N 03GF8rsGwmZdWb0IiSCkuap5aGaaSPPxyGf7CmY7mgIcJCojoyYZ+xFXTomkhN0scztB/hkLdLMa 8xG6wq97k3L5+cSec33/LzmPaZx//9+2dfs2m//f0b59K77/13Zd2+X9/6fxOLuKUjlFmyP3TqOS o52m5zNBpblS68xMIsd3H/PwjaJzfXDoY3y7yP5GkRPDbLzzrxY5GyFnB9XoCqfzg5UqEqUiYpxw kflGzxalf2homCumdY/Eu8Zo1yMetmnxriS4wCSIJlypdWd6RAY6Q1yLzqy6xbVjVFmATjMk1K1M ++69sy4klNY8pgg7Q8CmXJtugYRONdR1Td/pxRdCEVQAWuZN5zrV3GVuOeeCFsLnEm2hiUhjTVt+ tBmghYh/kMm+5Y+0yQ+EyjhJo5bhP07ibiyfm0PmZhNX1ia7E8c+ZCZRmMoXxTa3W9Y6LZDFLBTe QqZcQ+3rbiX3KG0xXebFNJkOoykV/m7e2n4rVYhp0l7MY6FRWF5kxxvBcxTE0kXUmRQRiAx091vd 4yMjcToh32UC6h0fGx+Js2LTwhwhfHykkn1Z0xRSAhEuAxE1Gz++2UjswZAZlpDJOmikjQF3h1wJ Ucu7E6ppY1K2orzMj8hKippQ5807Ac1EjRmZpPS5iE2kmTcyq2aXUErkmqrREDUdym3UvLSN7B2y a4tonKe2qqxaskqwM8YLf/GFaL/YQqgDV83/lk8i/6ZZR38XXYqB8zaFKhHEyqFOWZ6k5y//F535 7vNmXpH2iVxjz5KfVK7PN2SEeVTvPAXxJz7rmGNEDkF7Cgl8TxbDEUdFVLYzQbnEpSKYoGjmkWsL lVl9iw1GdZpuExOpItSl1ArPF0tFkZlSJ0LUkyJ5Jt6115hmM0xzZDOvQzlZX9jirpw37lZWAC6C VJWAWnNMvstEqZ35PWqKXpmsmuPZ1A9xIJamZ8YXsmLuJcsR1qoxB8k1SRUzrBodzWp9u4ok6rsq HXWacPrm/5k6H0scoYqkk6aocKcaHVm96kos1JzDxwasvsHevsG+sbh7RLB+iWFWMyFH2K06oaO1 Gwq0cS1YziarzvdMhtRm6TgFVUekSLmGeBvLgrk5UZysuVVwFnuXjGaEJv3B8f7+i1zgz2VPmc1B LXL9Rku6t0k1LSHzhidEDzOA0fBu9WQ5qjeHFOPdR2LKbt1slovZyUmqu0y2WCqbHJmzrBzWCwrP lj5X7bMQvtnjO0/VbIgT6hhHYOU4d4FjspPzhzyp/LFQXR0L8UpW1ljZ3B0UL2Uzkeoq2qV+uLSZ 4R0TibqXIci0RuzsKKuRE+bNgx2j5MUOa+6sq+O8xZzJdsxmJVfOTpswOSG/aE41L7LikcOsPVdR N8I3zmX+1QbgBXFENyN21ToNUtUrzGtrHB/OWTfoPlUFSREZqD+bdlE+at1FlAy2uMpEmwWkyT7r zuPBAs/+b3tX29PGEYQ/279iqwrLRgTOd+ezBZEqB2xESw06TBWpiU5ueiGoYCJsCFLJf+/Mvty+ njFtg/JhniiE7NzO7sy+zOzu3B6eD5UPn6FXwNjeEV1HNv+taPFXI2zzg5PzaefvqpzgKDF7q3pw 3bZAGPOqkWqts4x0Y3KsUkWLsn9R+tem+vn1yyc8m2sr+SP2+MgqXRxNprmVUCmHtVrsB+2CuAu5 uivY+cx2qy2kFdCOkjXEigsaRHo+vBlwjvEUxhPlU2LiiXS6qy/cWDddDHn//6cy7KIV1vxlOmlm 6HI7aBuc9XODyxRYW67rB5u3+9vucFM7BvW3/vsOLQyM4PcPxECshq8RM++6Ds46pwd/p8XPJ0cT fKPD8rxZnf+y+gsMWGn+NofsssDq7nYuraG0R6HvMoRE4M95ErQCRn/Lst0rq7/yoxBu7S9uIAe/ c8ew5+6eR/jjEX7rKVU0mpzjLnYuw6m3Pa5SfYAB9yqwt/OZ9ws4e3efje7OzxN0L685b1AO2XPN a8D54AwtR3vlnPXEykZKe4jSgoyl8H645DCg5h/EQMdqCGPAJRd6BFeUPwbO9Hw2v1mUWM6Cq2LV 4QpXhfJaFnv/US/CogbNMG5tebb3VXBTb21lCsF5vUF5fM8Pl09t/AUv69oSs9Umer/3eop7SX9X DY7Ad0WU76c39MTeFN9ZjDtqz+7M+PqICO0z2HqfJlFM3fldzLH4Ok3bnm/dT5loBtYqnuexFqIi SbZBhC3wbfb/zfMfvSv+/5bxRPxXP0r7VfxX0k3x++9p3KPzn5cAxX9R/BfFf71s/Nfw9PT4aH98 iDEv52+tMDCPZGT7ZZRPRsf4uHFmi0dpzvmsuN3YPbKVVxpDMi4HDaIIjDfIGAzCo1DYgagWagbf TAFRP4A9KtkuqHG5vOJ3tl7CkIP2++PyQv6vqQNTnoMmaBYcL/BTRSzOPa6KHrpxkg7f7B+AzRTO BoawAaV1j/YxLxd3V0vef2ZOlez6Nhnm+z16z5lydjyhKxKGb1RCLBKSVCUk72U9vPK0xCsLw5xW YZp37JaeGPXDLrODx5jL8gLfeTBi72R03wDdrUGxdNO7GRK6mU+JU6QksU/B4KcwJY2QgheQepRB HaWX1VGytKKgdOfGjaiemDwujzF8xdoSE9JBRJFuSSk6jiBYogABRA8TQD5BsKqLhEENoZfVELLU JKB8eTm7smTKR8PjJG58vLqZLa1EyAvWEo+icad0H7ySm2ulFRmhiWv+RZVJ7AAUumWTGhII2Ksj DVhWQwIh+02XJvXolSTV6BUjteiVIZXY57JOwDhyQXH2rvoBrEiU5bye4S39Zk+K0yIukrg964D9 ZK9xzPTHCPYTDMxdNnuMHsZjGTtgZkwjyJilZkbpg44VLBaIqILNahBkpRl5rKKohlUvC7AyGQUF 06xMXtC94Y/k1UJGgoFVYIb6SyPjIYQuLfDwwHrYrJr/cC/zitcP47A4qKKL0ZDz/QnuGoLVnaNj KVpcBKGuaU34ILv86FrKhqzar2eH7e3tbRmi+hdrF8Vvw2KYH54VRQdNIrgDKsYS33XMp8OjQO6d TbU2dVhg6R4TfGURmAQss8dYroFZtQh264cmey1OipHDoDLqtu7xxchRnq9StaHZ0DuWzR9xDa9r geT2/O56C2OReTRuhxl419S/Y50xVnjjT+ja0duNB7axEP/WBAfbbPeUXp6swGr5wRt+lvz2q6de 8UCulf8FpPeLr6Q3o+g32f5wIoOS90Kk05N8WsUGUwQwgUAgEAgEAoFAIBAIBAKBQCAQCAQCgUAg EAgEAoFAIBAIBAKB8D3gH2cUpgwAyAAA --_002_CF7FB0793253794F9F45991443E5FE2006483DE98Dus194mx002tyc_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B87FC70.90903@domain.hid> Date: Fri, 26 Feb 2010 17:53:04 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Charlton, John" Cc: "xenomai@xenomai.org" , "'jan.kiszka@domain.hid'" Charlton, John wrote: > I am attaching a simpler portion of the timer loop that demonstrates > the problem. As I said before the problem does not occur with > xenomai-2.4.6.1/linux-2.6.27.7 but does occur with > xenomai-2.5.1/linux-2.6.32.7. > > I had some problems applying your patch so I will let you know if I > am able to do that. But did you have the watchdog enabled with 2.4.6.1 ? -- Gilles. From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Charlton, John" Date: Fri, 26 Feb 2010 12:15:22 -0500 Message-ID: References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> In-Reply-To: <4B87FC70.90903@domain.hid> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Gilles Chanteperdrix' Cc: "xenomai@xenomai.org" , "'jan.kiszka@domain.hid'" Yes. watchdog is enabled with 4 sec in both 2.4.6.1 and 2.5.1 builds. -- John=20 -----Original Message----- From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org Sent: Friday, February 26, 2010 11:53 AM To: Charlton, John Cc: 'jan.kiszka@domain.hid'; xenomai@xenomai.org Subject: Re: [Xenomai-help] mlockall error after calling mlockall() Charlton, John wrote: > I am attaching a simpler portion of the timer loop that demonstrates=20 > the problem. As I said before the problem does not occur with > xenomai-2.4.6.1/linux-2.6.27.7 but does occur with=20 > xenomai-2.5.1/linux-2.6.32.7. >=20 > I had some problems applying your patch so I will let you know if I am=20 > able to do that. But did you have the watchdog enabled with 2.4.6.1 ? --=20 Gilles. From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Charlton, John" Date: Mon, 1 Mar 2010 10:52:12 -0500 Message-ID: References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> In-Reply-To: <4B87FC70.90903@domain.hid> Content-Language: en-US Content-Type: multipart/mixed; boundary="_002_CF7FB0793253794F9F45991443E5FE2006483DE98Fus194mx002tyc_" MIME-Version: 1.0 Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Gilles Chanteperdrix' Cc: "xenomai@xenomai.org" , "'jan.kiszka@domain.hid'" --_002_CF7FB0793253794F9F45991443E5FE2006483DE98Fus194mx002tyc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am attaching a much simpler tar ball that demonstrates the difference bet= ween xenomai-2.4.6.1 and xenomai-2.5.1 rt_cond_wait() function. The differ= ence is that in the new version of xenomai-2.5.1 the rt_cond_wait() functio= n does wait for the condition for the specified timeout interval but when i= t timesout it returns 0 and I have not been able to get it to return -ETIME= DOUT. The CanFestival timers_xeno task depends on the value of -ETIMEDOUT = being returned when a timeout occurs. -- John -----Original Message----- From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org Sent: Friday, February 26, 2010 11:53 AM To: Charlton, John Cc: 'jan.kiszka@domain.hid'; xenomai@xenomai.org Subject: Re: [Xenomai-help] mlockall error after calling mlockall() Charlton, John wrote: > I am attaching a simpler portion of the timer loop that demonstrates=20 > the problem. As I said before the problem does not occur with > xenomai-2.4.6.1/linux-2.6.27.7 but does occur with=20 > xenomai-2.5.1/linux-2.6.32.7. >=20 > I had some problems applying your patch so I will let you know if I am=20 > able to do that. But did you have the watchdog enabled with 2.4.6.1 ? --=20 Gilles. --_002_CF7FB0793253794F9F45991443E5FE2006483DE98Fus194mx002tyc_ Content-Type: application/x-compressed; name="timers_xeno.tgz" Content-Description: timers_xeno.tgz Content-Disposition: attachment; filename="timers_xeno.tgz"; size=12849; creation-date="Fri, 26 Feb 2010 11:35:26 GMT"; modification-date="Fri, 26 Feb 2010 11:35:26 GMT" Content-Transfer-Encoding: base64 H4sIADv5h0sAA+xaC3BUVZq+3emQ0J1IHMEXUY8QNIGkk0464e0SQgLBADEPDKPYXLpvcq/0y3tv RyI4gpFZ25BdRnF2ytqdlcHZ0XlsOaszC6hrpkKNyLozyLoW66MGZ7GqI9ld1h0RAc3+37nndncC uDVVjFVbOxdOn/s/z///5z/PG1OLKLoR2KxEY5XSH+ipomdubS1q39zaquzafiSfr8bvmzvXTz9S la/aX1cjsdo/lEHZT8IwZZ0xqsnG+dXzL8335fT/o4+Z1f9Z7964HrtsbaCD6/z+S/Z/XXWd6P86 n89fTf1fW1vjl1jVZbPgS57/5/3v7mhc1dpS39HIFjM5Hnc3rFnd1LycVSxmkVjQ7W7vqF/evHp5 YFlzGzGUlJRmIcrcmtEYiZt945Bsi5sxNl6uMmHoleFYUA5XxpSKkNJbaUbilRT4Hi3a436QmlnT 2dbQ2M7mLGbZSUgGdDWuXhMQRnEDshBl7mAsaspa1MjGljPvbEhXELFb6/HOtkzSosFwIqSwUq+3 kv6DIyJrXkKXETWiGIbco5TO6DTIJNZlUZkS7dX0WDSiRM0ZZWSoEjYUrk3R9ZheOqND1QxGQ6VH lyNMV+5LaLpiMFNVLqnBbbfUbnnPQpq+gPwaF1f3V9f/F47/YHePV72sbfwv47+6tspvj//a6mqM f3+dr/qP4/+reCpnu3kSd2thhSGZZd1ksW7WIEebFMPUeuVwOZNZWNuoy3of0yLxsIJkRuoSz5q4 EmWUysFNXuZ2N8TifbrWo5qstKFsAWsMxRKyHmIdze3tjW31qzuYHA2xJl2OBqmlZZ2tzatp6CsK a1jTuo6S3zKiO6azoK3IYCGFRnjY8LotO9OGkMk6iRqxbvN+WVcWsr5YggXlKA3DkGaYurYxYZJH JtqsjOnuSCykdfcBkYiGFJ0PUlPRIwa8BbB8dSdrocFJtOVKVNHlMGtNbAxrQXeLFlSiNPBlCg8w hqqE2MY+LtUEI9qFEawpRsplU4tFFzJFI7ru7qUhRTCr9vrsloS+ckaelsomLNdZLA6xMjK3j4Vl sowJyYt4nnEwRPMa16nG4uSPStrIw/u1cJhtVFjCULoT4XI3cbI7mztWrOnsYPWr17E769vQHesW Eqepxoiq9CqWHnSwRmrJHeons49sdq9qbGtYQfz1S5tbmjvWweym5o7Vje3trGlNG6tnrfVtHc0N nS31bay1s611TXujl5YARbHj6r5oXO048B6PxCh8mb5eR51pkGXhEFPlXoU6NahovWSXzHPj9+iz cIwyFW6SQCaKC5nWzaIxs5zdr2uUJ2bswt50Z3qznDVHg95yVjufdSgYAqw1LAepB9sTkK6pqSpn S2OGCc5V9YxVVft8vgpfTdVcxjrb692zK93umVo3JV43CwQ6mimi7Q1NywMrAgH3TEJqUeUCPAmI JWtRlIzoVSpN2djkVW+7CAET90UpEcqRzRel0OoYuijBUCIXxcthWecUd2Ul66AWaSBRri1gUSON odUvFk4gYoSv828keuk3auf5WZ8i60ZZ2ld4ura+hbXhZSI2sKq+i32jlNPKqtLUVe2BjjUBwVMa McoY080Adz0QNapNLbjJKBVSEWO2z1pcMm12jpNPfKl8wpKnlThtW3377QEaBMtaGsnqAEAiKlGa VL7C1fryP5fY/1/WNr78/Of319TVpc9/Nb5arP9za+f+cf3/Kp6HGluaHA5HGnZKORKgop2ufD/V x8UhnI5jUp5UKs2SZkiTOExlG/FQOQ4+KrlUXFRyqEwlJVO3u/JRriL4KkFziMIfkkUpvkaSUCAv FVl0jvsB0ai8RYhWp8TbBZ1epSqiVxENhREdZZJoA6WU4FJqG4URzLJod3xohi4WC1u+khaJynCo IqxFE5u9RsxbbeGLhO206ohYWTLAz6JSLvRMo3L1BN0zstq4Trx7RHt4bqYyncoVVG6F/VTmCNqV E3TlU7k+C55N5WtUZgr4FioUHukmyYr7lz3wAXHPmYB3XIQXE91k8Z5HpVC8w/+p4v3aCTJTqBRI VvxvoHJjFq1Y1IhdCZWyS9hYI+ofSZafDwvjrhPwLU4LXiTgFwR9voDPCfkPBFyUpRt23TQBPkjl jd0uhJn4C6U5Qt9cIf8rAS9xWPArAo4Ieruw55eC/qzQ/aagPybg3wp4dIJ/hY4JMOkbJXuQK1dS hjwo+IeE/qcE/JLg96P952z+ayR7Nrfbb5jA3ybgPU4L/rlo3y/oS4U/djzlCfYuFPRXhT23C3im oB8W/HZ/uSb4lyD+U89a8S6S/mvse4J/UNizVfAHBH+xgDeJ9rYTX/i5jHwFwSzL/5uFPacF/7tC /6jQ93MB/1TA0Qn2KEJ+nt2+gHOFvrepfiZp5wuNEpo/rE0TJo8aKRDoicSiASw0ZiAgBVb2BtqU HtrDK3pDWKbdqyERgW/VAiElrJgKYGzQAkFdkS0Qm78skHZpWbycyPWnJe+XNTOjdoIeI6wocVtN Fo1vhggMSQHa9WgZeTnI7zYyCJ3alo2MoYbWE5XDtsq07t40wwRjJ4D3xrQowqaboQiC5gMQCluT L8ensT1UKqq9VUBUARE3VZhswXGZDj0UcUXXo7EA7pywG81iC2SpotY2WWJkR1zXomZ3+i0QJAej iXgGQQExIWWYoeCcOZCrAxhJv/UEgwEjrTxo4QPNa6hnQlo0QIaFJGUzKYknTEPqUcy4FpKIRgcw VGSy1M2PI1KEDN8kh8NSt7AqEIBGkUIRmYJlRG2SQmcUmTg2GobIgQDtS6XlLc1LGwIUKJ6rzqwZ 3p7bJ2Jy0vic9C9oOXyVcIzDYJeAfzlOaz5lGCuaVgi5bzptrQ4p7MjMtxbdmaa30hibhAWRxmru VGvM5tJCsIHweSQXQk28KmpqOoyaBnUcNS1aJmqS34yaFqatqGn4bUNNi+sjqGnxeRQ1tbwTNS2w u1DTwrQbNRn3HdQ0kP8SNS2YT6OmRfwZ1LSQP4uaFtQfo6YF7nnUNJm9iJoW4n2oafF+GTUtakOo abE7iJoWvEOoKUBvoKaF/ghq2hC8hZoWv2OoadF+DzUt/sdR02J4AjUt7p3JD9v7R10pxOyu7cPP kMqBJ86PjY3tOGrmpqKETf2YwpR6j3zvuuv14bHaLpIcm3W3mMPGZiGi/E5v5DiJjc1CZFXQRo5w GBFW0U0jQxxGpFUs5SPPcxgRV9HFI09zGJFXsUUZ2cVh9ICKRBvZxmH0hIrpciTOYfSIugTwBg6j Z9QVgFs5jB5SWwEv4TB6Su0CXMVh9Ji6ATDjMHpOhUMjRRxGD6pxwBKH0ZPqZsCnvgCMHlW3cf85 jJ5VH+X+cxg9rO7i/nMYPa1+h/vPYfS4+jT3n8PoefVZ7j+HkQHq89x/DiMT1H3cfw4jI9Qh7j+H kRnqIe4/h5Eh6hHuP4eRKeox7j+HkTHqce4/h5E5aor7z2FkkHqK+89hZJJ6hvv/OeDjvP8d8J/D J3j/Az5CsJT1+P79nuQH/SdOtXa0qVW70Wv0c8dadcO3XPmpBlL+u127RD5uW1yCRTdRua+UNuEV JfTzizPOwa6xk4VL9pYSaWzqDiD34H3+Mf2jX+ZCwNF11/phUtE/mt+/uJzoknk1QiXtGDIL+0cL VODGjvQfLHp9mNryHU1+6BvqH7022VHiSq4/k0ycTy4ryX/NVTKPlKXQHykP+SQQyeHk23Nu6MLb tBb6nV57N/3uXQHet4g3eWyAdHw8QFpG1w93k/7XYcq1pHlgfb5viNQPJAqSLSX51IrLbmUBJG+o gtZaP/3a+IcJT/pea8zvINBSOrKKQpo8PfgytvFS5z7MrdxbEgLX3nJIlhLT62jfJqnA/pZjB/mG ZPBVLk8mcfvIGnq1POe83efBO15+4+fpQKQmnefvaDJ12HpvxfttFs8GvC8lPIW9gOBT1M+p72XR vvn5OP0c97UJ/HoW/1qLH/ZSdvi5m4Pr30t99xyFo7iETC/YN/qkC3HN34e5BC6lNiBYd/NIf0bE 1DZqwXd0H85F+6stpiLqjQLq/XzBx1tbwS1JbLBism/J4y67wzh5smVoWaqIWh+QCL3EatqVupFI qVmUMf0H/ZSJgy/iuCQJ3WHYcP6cTezelfr1WaFgqq3g/TR5sFfMzX6iY21MvXkO7U7ZgSPrHqxn +3GwO8BzgHKK4oE0Ju5DlraC1KskkXrgbCZG0749MUaLEJMhTnRYODsUvNNfOWu1WU/EVBUB+5nV nMtW6RUqUx+fQ3RJVwdFNKOG50WvUPMO/Bj5LGOQ/wKDfnQu3Wk81W4Xog9B9G8/u4gFC2wL4hlR nplxLmpevwebgAPTwXY32YWx7ipJ/R1ReRjRgZaKgn1XiRjYwXCltpy1e2TXvukWm4sr5LpIz73E MLKR+vwS9JWg512aPht0TDVol1Ne2vkkJ3MzPWf5MIA9qb+m90HzFkmM/0EKAk2nY/ed9w1RrtzR PzpV5KnE8+UMd7/402Pco45xjZPmn37GNUcJn8olzamd1ojDDip10CI+DGKK3lMPIbX/wcLuBvYo sH3IsLd40k71Da1bPyifH87MT/b4/j74nWeQaTDug09yeWifP8O1vQzqiU/57GQNGFse4/3OtTQG irP9+uxTKyP+imJCuKMQ/z7hUuVn0cIAn5v3YkL1De3FjLpnhdXLI4jAND5nd/H8IKERHJhFs6mb yKUBPhXn3ACZAT4hX1ULhcnGVPLYHPrpHE1+PJ1+rOkSiYaMPzDPenGlDpPW/jOPJ1+b8siAxC3k efwCemPMvLJ/7LxZ0D/2OI3vKTsOEMMeTGbw5ydYIofGTcZc8jqS3AOjBhbDnJvPLJmy4w7Kp/2g +k773k2afLRhZUnn/rJPM8vWa6k6UnFye9Jau/iqZSsvPiPG/4QVIHSaArrwC66EI/aSQtvURzqp +e5dya28vXPogJLTyIHiu+4JrB9RT1tpeqnEm4e4LyXdu8Y/wycLx8Gd1Pepeygq24c9tIWn9Xsg XFKaav6E1PcfIvnBJ/BbdiT52i/GnGal7/T4/BlYVlKSDFurLb0zants9wsQaZr/hf5B/8ECmDs8 UFwyzPcdL+FCkDYfJ3Npi3DSNZDTf2Ys8TtsKdL7EnufvJUmilQr+bGO9sQ5/DzilJpkLayE8L0H R07rwxA+XejhWCzOcBaVsniso7H1Nwlg4IfVchaMhRQ2K4T7sAwvP3pdgjXBvxG0KHIvvpu2g5M3 2mI3ymYZbomjmumUuYDZB0DWndYPDP7WIKgYBqOTX4xFlEhM71vALcmSbSFGErFZLS4YkLatYlZI 4kbAGnOc99yQdh84GvE3DlYIwMcJ1SCs4uQG/pvVbthyzz3+xCw8sKwEQpPD2gPphr1SVtwYzAAG xmQhGqOmokMErS3TjLhsBlV3Op7jsRP6gXvlvQBNGNirXOB+yJv+noOjRHYtSZn7a5R5DqtuFHWr qO8SdVjUT4j6b0T9nqhPivoTUeMsjbtS3CXhbvUNcee3Yjudi6nu2EHnZap3P+zKh5G7nNYdMg5u 04R9yPMO2t1jgShyWPeyuD/GffDuR135eN9KNe6tcMDDYoqDIA242CLCk6sxyJ6i+sSfWufH3/fB nbz9/hH5cpaK+zFX/vVUZlNZQGUlla9TuZfKA1Qeo/IUlR9SOUDlMJV3qHxE5SwV9wDJU5lNZQGV lVS+TuVeKg9QeYzKU1R+SOUAlcNU3qHyEZWzA1l+LG9oWMBKl6/uLGN+b4235qvF8Htu6/rDuvlH X88QfZ19V1/M+X6T5nt6pyt/e16Gbun57zybfiRp5coJkTP2g7tTS89U4i0jUo9iNobluKGEMG6k tYQyFGs6kh4ioJ1GX3pykp5wWfOWsgrXftIzBPLRaIE/I5DzNojLssOEEBdnAdxf/YYrzJ7uJJYr ZWYNqZsgfp/1gkDbA1k6lJs1Y1m3hJjSpPtoCOBGUcPFnnUbKfUTLusvVgT2SYvT1GNhLi/9YJJQ GSCPpf2TJjYg/SOhwrJh3YRaF6Hv26hYMJjQlVCAfweX/jObM5YwuUYHhRiTl3WRyuP/bqa/059U LvhzuIr7TL+3jv9R3P0xfVOlVjevrkKO9hhkesT6DFWJa89gRbV3foVeU+utrtyY0MKhiotxBo1E ZZDmdm/75WkpDUMzPn6x+nb8Ocs8ybGtKA/uWZf6SFkH5rgvRL7eTLn4Hvzfip+3cT+U48p70Ikq FycklyuXlgkpJz/31wTluvJynHkraQbLcUzCN5QcR/5Kzpy3mUOTWlA5cxHZnPw8gyAnhkTOvEY0 8OeQHMRHGucOvP7ZNnqd5MpzraU6Hz/7qUxukfDFx42PJLtzK/owhwYoS11FjtsgOlPyfEA41zTH Xg66PC8AvFqA+Z53SbfrGgEWeK4C9VoBFnl+hlBcJ8CpHnxndF0vwGs97wOcLsBiz39AtliAzIO7 TdeNAizx/AQN3STAUs+dkGUCLPc0IX4zHH+PIMys8vwFmEscr3DQ76kB9Rbh0TzPP4E6W4CLPFgw XOWOAQ4u8XwK5irHGg4u83wMZp9jEwebPM/ByGrHMNe83PM+mOsc/8zBFdjzSa4/cXybM7d4boDs CsceDnZ4cCh2NQuwy9MFVSsFeLenB+DtAtzgWQzmFscsDoY8/wJwtbBZ9fgBtjr+lbcblgq2IFgv ur+LNdN1AGEoXAaWl6yISIW3QvvLVkBchVcAGrKU5Ut5rm0E57n225kBd3hmAIuc4NgRG3urdIVr 0lIsroUBfIheGrJSRXIuQI4tBaMTk2veIk5ZR6/5C/vo1T0Nr5OXIq3599LJDZ4cy0CN6snLLE0u yfkYGmu8GUQnKG9CxO2GT+45W2xxd7kQl5yPUE+4KzYAxBcvdwxMbtwqFni8h2wBT5Xd3n1Ue2oO 5VgBOYvEr80EBM45n4bAvG/h9d9Iu2fLr6DyRXR5wcwxW2XBrLQNfvKu4NYTAHFbU6CCaYoDOxnH Fge9jWJv0++gvchR4M47rs6xJocvdlqLMtafK3XF+B/2rj04ruq837t3116tZWNbxg9s7LuSTVZm tbJk2TCWbSxLK1tEr+phbAO9rPYhbSztLvswEgZPqHn0jwQwdob2jySktAOk0GmnpUkwdAi0GZq2 YWgZQmc6TdIE4nRgSiFT2mbS9Pudx73n3l0/wIK0M76j1TnfOd/9zvv1ne/7rqb/ElHsDn25/jPy 6u/p2hf9wZvo10OBWJsahkDu34AIbq+2Qp+hUP3wbYRznH5forArN1DQ5wk4Tb9vIwBN8BgBL9Lv XQpYqZ/AVDWtI8B80B9coyPwVqSZ0BEwTD/s6lbpX0Hg9wDvesgfvB2SBgGWYZrtX0Xt4YS7+lpg /f1TqMyTY2t05OmnP6B3qCQ4eejX6nvo7fGT/uBrhJ6xKURB4Zc2hRZBYRmugvQtiLwVi8dV+svI 8EKdjQawYj+k3zGKeoZIrcV9pb6Axa1t5H6Er2NUgiz8L3ysZz/OSr8LOGFde8QfbKffP+GaVf9X pPBFHYw0zNtBys+NtMZdnShOavoX2Bg9KXL9IChiPPJ8PgRwhMD1N4LGl1nrALwTZfoKwHvptwHN 8OQpagb66d/YgGb6K/K+BvBbmvkC4QROYrzqupmhyMAjAngFi8MpDoTBpdev/EeQDhg4HodfRMTK +3kIzsHhcfSSVSIEzK0w7ir01SE/C8HhOzwBnDXjHAc8w/CjCFm7koeAtRBGc+vrRAjO5eH9oHC1 CMF5P9wJnA2oAgrB2Vu7hy35Pkw4+h1+fjXGVtxkMj04lZnIx0qf/MKsL9OWLhhfYATXBjcFG3B6 0Jfpm5Y0LDKWrF2yTF+uL6XG9a3UjCU7FnUu6qOtp7FRW7RoN8VjIeFeGqAB7qVJ7gryUB+CA/Sg rvc16OSpC2t9Da0UFWrQjSWLFoEewhct5sQDfQ3X02mlXqZFk8hiO1nELGnQnbeuiGk31PPYz9Sb hLw0pjsBfQ3I+p4FwFzWQZsATsVHZVmu4jlYVHSZFrBWOOQ5Dk0PMa2tQQIr1eRl4CqHtEN4dYdD mAqxJqRJDBqv9gsBd57XBuw6ofEpChDgWbs64JSHCK7vcGV8w9UilwcXHaJaMZ3YG+p30qExrAbg fa26B7zJOiaGsq7/Ysli+q+Lo6z+yW9JtVistTRXSqULpdZJyOpmk7Q759tUygE4AxA5iCX5djng w8nIWKKHW8O7DocnJ1tbfQHKsd9HUTgsGe9oIo6qR9ex//Fps76PWLZkMV8qscIxoa/JZLJmSdnp rVVIxJ538AqllppU8Jqg0TqRLZ9/FrhIQpdEQyjB2JlKlGZk2LzSzVXoTFi5tPJW0WQCNi4BVuo7 Gg5gqVQ6E2PXneW5QrpEXh+TycnmyWswDOlNlPMz2ST5/Q5ywPHihMiEruFjgtHwCKFqTRxEuQ9d Fvsa4xe63hjdEt29f+qDw8XPpifThw8bM++HW55p2bkruOvM852VtPH28TcaD9xcOnTI2HTj5Bnj 6BvhlkPBQ0Y+NnmGng+eP2NMxybhnNVijdGpm33XrPi5L9IwHPzqZ4O5Qy9/aBR+y1gazBgvHX94 7swDwdbO4C5fU0Pw+w/g/zP4/wH71x98xPeZBuNo2ZgL/oT9ZoNvBE8a/6AHM19tqVD8H5059MKZ w4fPHL7ZuPd4cOfkmWAYqb7fGL33gweeP9SaPmMZc+U/NZYElx8KlnYf2O1rXHl9+8wLRsbXqAcr wd3BD/NbjbryGaP3OWNnsGz0HzR2PPfWf9NLxsjDvjANxGE27VxTc9qhlqdKdNZFnVckuBnGBj0c Dvt0wqcQ8DWMFicERxjw5Qi4K1jv9/+27sgTohnAku5aErzP17M4MHS/cQI8ERnPdpVKfO8J/35s FqQMI3aT62X8vsUBGY5N5QoZvtcJx97SVOjJcGwvb6uBjx3mFiVcykxil/muQqfnhGHLU2L/eKXP eQdxG2V+aTP4KLk99bpW59d7qTq6BVrXvUq52IZPSVfWB/Z8P9LV+gjc73/A0PKFxO0VCFPdXkmk rLJm5adTVj6TAasDu41uwdVyWCojY1DC69Fmc4licsrio4veTFaKxXSOM0u4RFTiaJpJKQFgMk8M Kk3li2Uwt7VS9s40vehiLnm5PpTawPhY/KA13N/VHd8/1N8TH1EIFspFzlqyhdYKUNqYolKkiwxv opKxJiDFVovP1DqVn0m3SrHvVgr7XDpZLrUOdI+2dhUKvcXETJotjarYvAUVJnIVLpA1kygeIQTt aGKaatPFkPKwn2rwmaiMo/EBVwk9DCr3BCjF7dSiCtkypgnD/qGCIRt3xK5ClcdnUfpEZLoyk1N5 fVYhX1Jql9UbHQ6OalaJ6lFklCH09vXH3by8Sg7ygemUmZxKUI1YhURqK9VEBdQ52AFaSSWP9ivI rNC4qGpoXrWUA/Qb5AKBTMoPvamaI+jhfdrY6CqyQ+BN1E3SSdcWa1T7D3Ldxp12tkrkEiBZyUHO r51HbNOsXHq2LPq1q0gql5QPtHYtQy3LmoUyNS06gIURt70Dww8+uFSJ1Ks9bFWW/UTyCJFkTcNk DhVGq5WZTkyWKF8z+ZRSco4r+b/W0XJiYjotBznTcnXG64QQ+ORjRKmL2dxUIpeaxoAVM0DtDiv5 pEzJRuRICkC62c5IEzVBFDW+VtASUmYs1AD3sxuR32T+is3d76UfZPMXaKOn/AdO2YxwzMIJQQNu WtCA+w0PDeAeZWEnmYv4haBXqXcIvki/bwuCcF8RBOH+s4fgDzUueg5cuD8WuHB/7sFlq6IuCqtz EWNWWJ2rOKi4gMMCF26TwIX7eQ8u4HsELtwTAhfuH3twAf+JwIX7rMCF+2WfG3c9wYzloA2Dq9DD vQlyZrn3ODn3ca985zEfFzUHfbiPc38QLi4UVPrNBuc00OtgKRzj3j8k58+5921y3uVeH/hvfuZt JWcb9w6RM869eXIqfldenqU0X+TZe4hifscd+yKBf+nnOYX7XRb9G3D+TgTDfZX7g3BvCrgL8BaF vc+pGhR1RcCVwG0EJgKiX5Kb5P4g3Ec8lB4j+GsCF+4fCFy49yx0495KG1JrAUvqZ+QcWAjvTTL2 BXrjVZ6RWyjmyEJXnurohVs4vSk17DsLnHH1HvnHFlaPM+euFKe379APR7UfnHbu32Q8dniv0w/7 urNKvBYrzc3QJERuucjdKenLYrkoaLFcvpyOde3ta6EjgxabSpSmtFhqLkcvcpcm89hkrhITCrQu wKK4YnoaeNxTmC6DMs2QsTKm6hgTfI8V80yqOpaesjJY6bVYspynRTyW4s7nkkWWWII2OJRAvsz+ cWr8zYkSoSXzM9CWprD0RGXSShTpZJMuSbBQmcCiYcPZXCZvo05MFNNHJUTnoLT0i/xwgBVW4NCm RXhFMh/hge4Rn2WF3pbu1h2Sl1fQ6Vgo8Jh+lc4ZXPKRXaFNkzM1v7/eT3j9uhMvdbFwXbNI4OFe +7QYkAGRptS7ukHjd9vAwz34WIDff3vzt4/3MXaHjfvrn1BmDyr58kkaGr/zhh/33jupB+5R8izx caSsE2G4N78ryO/N1XKg804reLhnPx3k9+9+zdHzAl5F5BUnRoyR36eXVD1HSbeg4GGcvA48nxsP v2MKHnT2ltZr2vPKrb2Uvb9HwcOY/NsVynlISfcBzekHGJdnCa/FV433kIK3+lF/cPUqJ07F+12B h7Zj+nyreD148R5T8CA0vPEceE8oeBAUjp4j3adFWYHH9ARX8QUzoOCB/rMKPegjDK+upoffcwoe 5CvGCO90DbyXFbyzhHd2de1y/LVIn2lUPOUPvrea9yH5mML9nubWxQPecQWWcd/34BXWiCsS8cg8 vO3B++Eavjnw0vsPD95tNEHMBqvxfLob702aIFbUGJdLPXjvbNK0v/FX463z4H1zs6allAD5SrPA k2NnXVTT7vfQw6/DQ+/36IWnDTcenhs8eMMdfD6Qjyw65GdUXcmHCW+gRv3JsSGfJzupDoJcbuN6 zZnX6jz0vtmtabsDDqzmyftgntbY+xwrYsM85f02zFPA/MphXlGYRznME5TyPgbnZ7F5kcNc8OQu G+a1cdqGuVao1IEzNC5C9boNL2Lw0i9IuJ7BUsfSEJqkZ214CYMxr3D4Cgave0LCfFbbaMNcQzZq w8sZvMWG+Uo2/KSEOUdkzIa59NRZGxbau09JeJWr3g2Plqtha/RK+CoPvNYDr/PAV3vg9R54gwc2 PXDY1U/82r//KuiBGzwwUpD1CW4a7l032vAyDffaURteztbVDtF+Pmq/W4EPbQ4Wv4rNXRGhcwn4 TnLvUPC96d9Prqmkf0pz2lun9v6aJ30I3j592qHnLd/LHvg1Dww5FNneuu9K7X2l/JpvqWbobnil 7vQf3degbRAVLHVWW3Wnv5jUX3aIeKnjegDvU30AATqokyJe6ijPCVjq1OIgBn0bncH1TGYQt5v1 4v3HdWf8IP7rBO9X6H9L0PuRoPeS0iFM+r3mgd/S+XiTOsW4px9WdGb/S3frQP9KvC91oOvF5CZ1 oK8SsNSBvtajA71fwFIH+YCA/0XAGZ+7fise+F6fWwf6FMFjSn5xMJXtQa2nfZ3gg0r94PZY8j9R f9/1OXxewG+K9KRO9Vs+h6+L+PdEvNSZ/h/ASvpLDXf51hsO/xfv435f8n0BX2e46fUS/I7I/zLf Sm1UxEud7AmCb1PKA2GOyBMSf5l2nGCoak0K+g+K96UO92MClv3tzwx3/b4kYKnD/bqAm0T8TwUs +/d/et6HzIOqM73Y7/DLkZ/VBE8p9bVZrNVSx7sTsODLA79HxEud73EBS53vlN+t8531OzxyvF/y u3XA7xPvSx3wL/kdvjfwnxLxUif8OQFLnfBXPOV7VcRLnfAf+x3+Pei9L+Kljrgv4NxLIH4ZwU/I 8eWr1yIBh4+P+JaAW6d8K8FRpTzswjSWVO9Nk8VyqVzJZMhrWd1jQyNWf9/oGBTOrR4XdGO3AqTy 1uR0fiIxbbGTrZWozGp0ai1APTsV27Z1S7uGCCubmgXUobHjp5WqzMzMyXTigz2MVu9I10DchpCM 9DupJO1U3Izr9HSmRZTJ2tc/tLer3xrq7R2NgwO7tz8OIoi2YJdqjl8dqAFC8bnn0GDXQF93lT49 juQSx6MbvmePoyldxankStoqiqMpLnSyk6UKV5b3Xk+I9DzseltD/iKsAliZgjV1h/vKwFbMd/Tm 3RrqVQrsVbrjnuK4bQB47QV4tPtVXX6PartzDUTt7dR3jUsN192Am/HrMl+g3D64LRfwGw1PORQj CO5rI4XT7rGrQBkt5S3OvPYaWfDczYhBJDu03fSsznmPUPMjFThq1LWoPa7qr8ZnqsnUMsDA7Sqo +v7K5U31nQerMZWmze1nthJqVaJsX4wy5waBM+pVfNgxUOFa12i1LEaodia49QJpzUCl5rnggOUE Ndp7l2NBciBGoVYhaZWnKrkjsYlZfgHIG8kjmX35waPa/xpIHEnj/jI2z4bALmD/s2NLR7u0/7Vl awfsf23v2HbZ/uen8jSFzckZavdQqCnUZLoMeJrt1Gxmf6KCq3tzL+zWFlOERH81TYYmE7nMhUyG wsgi4eUL6RyRKcFwqELxYxv3bDIvwbxnk3lJBj6bzHkw8VmzDj6qmc8m8xINfTaZl27qs6l2LZ/H 2Ccr+yUb/FRa8RJMfjaZ82f0swkWcbul+euJbK41mUwkUfXVIm4tk8mk2TIDqZldBYyVygytnmZL tjRHG8KZeRAUNFuG2kNDw2NWd29/175RyhYCbGBjxIlrDg2PDO1zEM2WnvHRuAUb22ZL3zwK8RFh i1rU4ua/AY3E44NjzFRwy01Qf20pZAsMjaVuWeTtie8d32dRz4agwegQHQ2GBu3g+EjN4IHRfa7g ydDQqEUnBVg970fuQl3U72XI7PXbqQbivX0Ha9kuv/jihkLcoqvVM9J3IA5D6MrCGgr1DXb3j/fE WVP0xUKhob038pZwvdUcI9TRkW4mVVMzPhkK0aaIkemfj8ah8XKJlBiFm6aje+YpO62FfCk7G7uj mCgUqP7ms5zTXI6UPDA9Rk5qmvnpnzQ0Rl5hO8zxWQwD9sNokFNH3VHVLKGQN2SHiVFGjdwcqtsY 6e9pJrCfDzizJV9FQCIDi5qXCG7K7zA3JfFydzeCxWglnzJeCTwGsIf6L83bd1Os7Gg8mT1mS9Lc uDMUYueiHaG6IhU7Y2ctNFOkmYeqeYfJEP5fW7e9/FzoqbL/O8+2//FceP+/zbb/D8P/W9q2Xrft 8vc/PpXnsv3/y/b/L9v//3Tt/3P215TL9r8TpljeVz7Iohrkp10QFZGHuoznj0gL9X2DY/F98ZG2 7TDWb7/YCFZbbKqRAjebLfIxmbILG5rJfI5mwxwbdRlmq4UCFEwqhju5Xtqvm1s8gV0jA/Ees80T OjbSt89srxFoDcdH+oZ6zK3esgwODdKZoA1FQBZRd0fz2ZQZ2czZu7TtgsCzVW6OdA9ZPVS2zWYq ao4Pjm5tN7Op5k72pQIaKZVkWThWSVQ0zWA0lI4BoY5euB6siHK6k8EOMQ57UqNJhns7TarGMcbQ 4AFmpkK9BLUkyLJ8XABNfgqBJtpOVwCTdkQo3h9OF7M0gSWzNCL5i3fz4smaOV8xXVCnp/VhJ6ic 533A1dKtm2VzjKbLXeDbR6h2s/STBYmaTKUhahZY7ppNzsONNG4qRc1NhGi/yAJcv+Zbco1Rix1q LCtKA6CfdqvwNdF7TUilyUmmSaTTJBLqNK2LzROrLNfYsN+s1Wmi5rlaO2oqLYUEJCjz5E2nJz3N 03GF8rsGwmZdWb0IiSCkuap5aGaaSPPxyGf7CmY7mgIcJCojoyYZ+xFXTomkhN0scztB/hkLdLMa 8xG6wq97k3L5+cSec33/LzmPaZx//9+2dfs2m//f0b59K77/13Zd2+X9/6fxOLuKUjlFmyP3TqOS o52m5zNBpblS68xMIsd3H/PwjaJzfXDoY3y7yP5GkRPDbLzzrxY5GyFnB9XoCqfzg5UqEqUiYpxw kflGzxalf2homCumdY/Eu8Zo1yMetmnxriS4wCSIJlypdWd6RAY6Q1yLzqy6xbVjVFmATjMk1K1M ++69sy4klNY8pgg7Q8CmXJtugYRONdR1Td/pxRdCEVQAWuZN5zrV3GVuOeeCFsLnEm2hiUhjTVt+ tBmghYh/kMm+5Y+0yQ+EyjhJo5bhP07ibiyfm0PmZhNX1ia7E8c+ZCZRmMoXxTa3W9Y6LZDFLBTe QqZcQ+3rbiX3KG0xXebFNJkOoykV/m7e2n4rVYhp0l7MY6FRWF5kxxvBcxTE0kXUmRQRiAx091vd 4yMjcToh32UC6h0fGx+Js2LTwhwhfHykkn1Z0xRSAhEuAxE1Gz++2UjswZAZlpDJOmikjQF3h1wJ Ucu7E6ppY1K2orzMj8hKippQ5807Ac1EjRmZpPS5iE2kmTcyq2aXUErkmqrREDUdym3UvLSN7B2y a4tonKe2qqxaskqwM8YLf/GFaL/YQqgDV83/lk8i/6ZZR38XXYqB8zaFKhHEyqFOWZ6k5y//F535 7vNmXpH2iVxjz5KfVK7PN2SEeVTvPAXxJz7rmGNEDkF7Cgl8TxbDEUdFVLYzQbnEpSKYoGjmkWsL lVl9iw1GdZpuExOpItSl1ArPF0tFkZlSJ0LUkyJ5Jt6115hmM0xzZDOvQzlZX9jirpw37lZWAC6C VJWAWnNMvstEqZ35PWqKXpmsmuPZ1A9xIJamZ8YXsmLuJcsR1qoxB8k1SRUzrBodzWp9u4ok6rsq HXWacPrm/5k6H0scoYqkk6aocKcaHVm96kos1JzDxwasvsHevsG+sbh7RLB+iWFWMyFH2K06oaO1 Gwq0cS1YziarzvdMhtRm6TgFVUekSLmGeBvLgrk5UZysuVVwFnuXjGaEJv3B8f7+i1zgz2VPmc1B LXL9Rku6t0k1LSHzhidEDzOA0fBu9WQ5qjeHFOPdR2LKbt1slovZyUmqu0y2WCqbHJmzrBzWCwrP lj5X7bMQvtnjO0/VbIgT6hhHYOU4d4FjspPzhzyp/LFQXR0L8UpW1ljZ3B0UL2Uzkeoq2qV+uLSZ 4R0TibqXIci0RuzsKKuRE+bNgx2j5MUOa+6sq+O8xZzJdsxmJVfOTpswOSG/aE41L7LikcOsPVdR N8I3zmX+1QbgBXFENyN21ToNUtUrzGtrHB/OWTfoPlUFSREZqD+bdlE+at1FlAy2uMpEmwWkyT7r zuPBAs/+b3tX29PGEYQ/279iqwrLRgTOd+ezBZEqB2xESw06TBWpiU5ueiGoYCJsCFLJf+/Mvty+ njFtg/JhniiE7NzO7sy+zOzu3B6eD5UPn6FXwNjeEV1HNv+taPFXI2zzg5PzaefvqpzgKDF7q3pw 3bZAGPOqkWqts4x0Y3KsUkWLsn9R+tem+vn1yyc8m2sr+SP2+MgqXRxNprmVUCmHtVrsB+2CuAu5 uivY+cx2qy2kFdCOkjXEigsaRHo+vBlwjvEUxhPlU2LiiXS6qy/cWDddDHn//6cy7KIV1vxlOmlm 6HI7aBuc9XODyxRYW67rB5u3+9vucFM7BvW3/vsOLQyM4PcPxECshq8RM++6Ds46pwd/p8XPJ0cT fKPD8rxZnf+y+gsMWGn+NofsssDq7nYuraG0R6HvMoRE4M95ErQCRn/Lst0rq7/yoxBu7S9uIAe/ c8ew5+6eR/jjEX7rKVU0mpzjLnYuw6m3Pa5SfYAB9yqwt/OZ9ws4e3efje7OzxN0L685b1AO2XPN a8D54AwtR3vlnPXEykZKe4jSgoyl8H645DCg5h/EQMdqCGPAJRd6BFeUPwbO9Hw2v1mUWM6Cq2LV 4QpXhfJaFnv/US/CogbNMG5tebb3VXBTb21lCsF5vUF5fM8Pl09t/AUv69oSs9Umer/3eop7SX9X DY7Ad0WU76c39MTeFN9ZjDtqz+7M+PqICO0z2HqfJlFM3fldzLH4Ok3bnm/dT5loBtYqnuexFqIi SbZBhC3wbfb/zfMfvSv+/5bxRPxXP0r7VfxX0k3x++9p3KPzn5cAxX9R/BfFf71s/Nfw9PT4aH98 iDEv52+tMDCPZGT7ZZRPRsf4uHFmi0dpzvmsuN3YPbKVVxpDMi4HDaIIjDfIGAzCo1DYgagWagbf TAFRP4A9KtkuqHG5vOJ3tl7CkIP2++PyQv6vqQNTnoMmaBYcL/BTRSzOPa6KHrpxkg7f7B+AzRTO BoawAaV1j/YxLxd3V0vef2ZOlez6Nhnm+z16z5lydjyhKxKGb1RCLBKSVCUk72U9vPK0xCsLw5xW YZp37JaeGPXDLrODx5jL8gLfeTBi72R03wDdrUGxdNO7GRK6mU+JU6QksU/B4KcwJY2QgheQepRB HaWX1VGytKKgdOfGjaiemDwujzF8xdoSE9JBRJFuSSk6jiBYogABRA8TQD5BsKqLhEENoZfVELLU JKB8eTm7smTKR8PjJG58vLqZLa1EyAvWEo+icad0H7ySm2ulFRmhiWv+RZVJ7AAUumWTGhII2Ksj DVhWQwIh+02XJvXolSTV6BUjteiVIZXY57JOwDhyQXH2rvoBrEiU5bye4S39Zk+K0yIukrg964D9 ZK9xzPTHCPYTDMxdNnuMHsZjGTtgZkwjyJilZkbpg44VLBaIqILNahBkpRl5rKKohlUvC7AyGQUF 06xMXtC94Y/k1UJGgoFVYIb6SyPjIYQuLfDwwHrYrJr/cC/zitcP47A4qKKL0ZDz/QnuGoLVnaNj KVpcBKGuaU34ILv86FrKhqzar2eH7e3tbRmi+hdrF8Vvw2KYH54VRQdNIrgDKsYS33XMp8OjQO6d TbU2dVhg6R4TfGURmAQss8dYroFZtQh264cmey1OipHDoDLqtu7xxchRnq9StaHZ0DuWzR9xDa9r geT2/O56C2OReTRuhxl419S/Y50xVnjjT+ja0duNB7axEP/WBAfbbPeUXp6swGr5wRt+lvz2q6de 8UCulf8FpPeLr6Q3o+g32f5wIoOS90Kk05N8WsUGUwQwgUAgEAgEAoFAIBAIBAKBQCAQCAQCgUAg EAgEAoFAIBAIBAKB8D3gH2cUpgwAyAAA --_002_CF7FB0793253794F9F45991443E5FE2006483DE98Fus194mx002tyc_-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Charlton, John" Date: Mon, 1 Mar 2010 15:30:23 -0500 Message-ID: References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Charlton, John" , 'Gilles Chanteperdrix' Cc: "xenomai@xenomai.org" , "'jan.kiszka@domain.hid'" I added some printk output to the cond.c file in xenomai-2.5.1 and it shows= that xnsync_sleep_on returned -ETIMEDOUT as it should: Xenomai: registered exported object M1-1908 (mutexes) Xenomai: registered exported object C1-1908 (condvars) xnsynch_sleep_on returned: -110 xnsynch_sleep_on returned: -110 xnsynch_sleep_on returned: -110 xnsynch_sleep_on returned: -110 xnsynch_sleep_on returned: -110 xnsynch_sleep_on returned: -110 xnsynch_sleep_on returned: -4 Xenomai: native: cleaning up cond "C1-1908" (ret=3D0). Xenomai: unregistered exported object C1-1908 (condvars) Xenomai: native: cleaning up mutex "M1-1908" (ret=3D0). Xenomai: unregistered exported object M1-1908 (mutexes) Xenomai: POSIX: destroyed thread df5a0800 I put the printk on line cond.c:433 after err is set in rt_cond_wait_prolog= ue(): info =3D xnsynch_sleep_on(&cond->synch_base, timeout, timeout_mode); if (info & XNRMID) err =3D -EIDRM; /* Condvar deleted while pending. */ else if (info & XNTIMEO) { err =3D -ETIMEDOUT; /* Timeout. */ } else if (info & XNBREAK) { err =3D -EINTR; /* Unblocked. */ } printk(KERN_DEBUG "xnsynch_sleep_on returned: %d\n", err); I put a printk in rt_cond_wait_inner() which is called directly by rt_cond_= wait() from user mode but did not see the output in the dmesg output for th= at one. -- John -----Original Message----- From: xenomai-help-bounces@domain.hid [mailto:xenomai-help-bounces@domain.hid] On= Behalf Of Charlton, John Sent: Monday, March 01, 2010 10:52 AM To: 'Gilles Chanteperdrix' Cc: xenomai@xenomai.org; 'jan.kiszka@domain.hid' Subject: Re: [Xenomai-help] mlockall error after calling mlockall() I am attaching a much simpler tar ball that demonstrates the difference bet= ween xenomai-2.4.6.1 and xenomai-2.5.1 rt_cond_wait() function. The differ= ence is that in the new version of xenomai-2.5.1 the rt_cond_wait() functio= n does wait for the condition for the specified timeout interval but when i= t timesout it returns 0 and I have not been able to get it to return -ETIME= DOUT. The CanFestival timers_xeno task depends on the value of -ETIMEDOUT = being returned when a timeout occurs. -- John -----Original Message----- From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] Sent: Friday, February 26, 2010 11:53 AM To: Charlton, John Cc: 'jan.kiszka@domain.hid'; xenomai@xenomai.org Subject: Re: [Xenomai-help] mlockall error after calling mlockall() Charlton, John wrote: > I am attaching a simpler portion of the timer loop that demonstrates=20 > the problem. As I said before the problem does not occur with > xenomai-2.4.6.1/linux-2.6.27.7 but does occur with=20 > xenomai-2.5.1/linux-2.6.32.7. >=20 > I had some problems applying your patch so I will let you know if I am=20 > able to do that. But did you have the watchdog enabled with 2.4.6.1 ? --=20 Gilles. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8C23F9.3050109@domain.hid> Date: Mon, 01 Mar 2010 21:30:49 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig58A4F38C250CB3B442FB13B8" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Charlton, John" Cc: "xenomai@xenomai.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig58A4F38C250CB3B442FB13B8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Charlton, John wrote: > I am attaching a much simpler tar ball that demonstrates the difference= between xenomai-2.4.6.1 and xenomai-2.5.1 rt_cond_wait() function. The = difference is that in the new version of xenomai-2.5.1 the rt_cond_wait()= function does wait for the condition for the specified timeout interval = but when it timesout it returns 0 and I have not been able to get it to r= eturn -ETIMEDOUT. The CanFestival timers_xeno task depends on the value = of -ETIMEDOUT being returned when a timeout occurs. >=20 Yes, there are unfortunately breakages in rt_cond_wait[_until] - fairly obvious ones when looking from the right angle... :-/. I'm looking into this. Thanks, Jan --------------enig58A4F38C250CB3B442FB13B8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkuMI/0ACgkQitSsb3rl5xQUKACguujI6U9nF3BNb8t/TdoB/hy8 F2UAoN4HAW2NS6q4M42GcpNCeyaeXGAD =aE3e -----END PGP SIGNATURE----- --------------enig58A4F38C250CB3B442FB13B8-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8C2490.1040604@domain.hid> Date: Mon, 01 Mar 2010 21:33:20 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4E2F5D5E81CA25BAE20858CC" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Charlton, John" Cc: "xenomai@xenomai.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4E2F5D5E81CA25BAE20858CC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Charlton, John wrote: > I added some printk output to the cond.c file in xenomai-2.5.1 and it s= hows that xnsync_sleep_on returned -ETIMEDOUT as it should: > Xenomai: registered exported object M1-1908 (mutexes) > Xenomai: registered exported object C1-1908 (condvars) > xnsynch_sleep_on returned: -110 > xnsynch_sleep_on returned: -110 > xnsynch_sleep_on returned: -110 > xnsynch_sleep_on returned: -110 > xnsynch_sleep_on returned: -110 > xnsynch_sleep_on returned: -110 > xnsynch_sleep_on returned: -4 > Xenomai: native: cleaning up cond "C1-1908" (ret=3D0). > Xenomai: unregistered exported object C1-1908 (condvars) > Xenomai: native: cleaning up mutex "M1-1908" (ret=3D0). > Xenomai: unregistered exported object M1-1908 (mutexes) > Xenomai: POSIX: destroyed thread df5a0800 >=20 > I put the printk on line cond.c:433 after err is set in rt_cond_wait_pr= ologue(): >=20 > info =3D xnsynch_sleep_on(&cond->synch_base, > timeout, timeout_mode); > if (info & XNRMID) > err =3D -EIDRM; /* Condvar deleted while pending. */ > else if (info & XNTIMEO) { > err =3D -ETIMEDOUT; /* Timeout. */ > } > else if (info & XNBREAK) { > err =3D -EINTR; /* Unblocked. */ > } > printk(KERN_DEBUG "xnsynch_sleep_on returned: %d\n", err); >=20 > I put a printk in rt_cond_wait_inner() which is called directly by rt_c= ond_wait() from user mode but did not see the output in the dmesg output = for that one. One of our problems is the prologue/epilogue split up (both in kernel and user space): the epilogue can eat the error code or the prologue, including the -ETIMEDOUT. Jan --------------enig4E2F5D5E81CA25BAE20858CC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkuMJJAACgkQitSsb3rl5xTYDgCbBCSH/uWtiaVNh7AxQbpTEHEq VHcAoLuBaztL+/QeKTFB270zIQWY9+Av =1CCC -----END PGP SIGNATURE----- --------------enig4E2F5D5E81CA25BAE20858CC-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8C25B9.8090705@domain.hid> Date: Mon, 01 Mar 2010 21:38:17 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> <4B8C2490.1040604@domain.hid> In-Reply-To: <4B8C2490.1040604@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: "xenomai@xenomai.org" Jan Kiszka wrote: > Charlton, John wrote: >> I added some printk output to the cond.c file in xenomai-2.5.1 and it shows that xnsync_sleep_on returned -ETIMEDOUT as it should: >> Xenomai: registered exported object M1-1908 (mutexes) >> Xenomai: registered exported object C1-1908 (condvars) >> xnsynch_sleep_on returned: -110 >> xnsynch_sleep_on returned: -110 >> xnsynch_sleep_on returned: -110 >> xnsynch_sleep_on returned: -110 >> xnsynch_sleep_on returned: -110 >> xnsynch_sleep_on returned: -110 >> xnsynch_sleep_on returned: -4 >> Xenomai: native: cleaning up cond "C1-1908" (ret=0). >> Xenomai: unregistered exported object C1-1908 (condvars) >> Xenomai: native: cleaning up mutex "M1-1908" (ret=0). >> Xenomai: unregistered exported object M1-1908 (mutexes) >> Xenomai: POSIX: destroyed thread df5a0800 >> >> I put the printk on line cond.c:433 after err is set in rt_cond_wait_prologue(): >> >> info = xnsynch_sleep_on(&cond->synch_base, >> timeout, timeout_mode); >> if (info & XNRMID) >> err = -EIDRM; /* Condvar deleted while pending. */ >> else if (info & XNTIMEO) { >> err = -ETIMEDOUT; /* Timeout. */ >> } >> else if (info & XNBREAK) { >> err = -EINTR; /* Unblocked. */ >> } >> printk(KERN_DEBUG "xnsynch_sleep_on returned: %d\n", err); >> >> I put a printk in rt_cond_wait_inner() which is called directly by rt_cond_wait() from user mode but did not see the output in the dmesg output for that one. > > One of our problems is the prologue/epilogue split up (both in kernel > and user space): the epilogue can eat the error code or the prologue, > including the -ETIMEDOUT. Ah. My fault. Looks user-space is Ok though. Only kernel-space has a problem. > > Jan > -- Gilles. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8C2797.2000501@domain.hid> Date: Mon, 01 Mar 2010 21:46:15 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> <4B8C2490.1040604@domain.hid> <4B8C25B9.8090705@domain.hid> <4B8C26F7.3020306@domain.hid> In-Reply-To: <4B8C26F7.3020306@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA07C0A67C7C9DB64A04AB15B" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: "xenomai@xenomai.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA07C0A67C7C9DB64A04AB15B Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Charlton, John wrote: >>>> I added some printk output to the cond.c file in xenomai-2.5.1 and i= t shows that xnsync_sleep_on returned -ETIMEDOUT as it should: >>>> Xenomai: registered exported object M1-1908 (mutexes) >>>> Xenomai: registered exported object C1-1908 (condvars) >>>> xnsynch_sleep_on returned: -110 >>>> xnsynch_sleep_on returned: -110 >>>> xnsynch_sleep_on returned: -110 >>>> xnsynch_sleep_on returned: -110 >>>> xnsynch_sleep_on returned: -110 >>>> xnsynch_sleep_on returned: -110 >>>> xnsynch_sleep_on returned: -4 >>>> Xenomai: native: cleaning up cond "C1-1908" (ret=3D0). >>>> Xenomai: unregistered exported object C1-1908 (condvars) >>>> Xenomai: native: cleaning up mutex "M1-1908" (ret=3D0). >>>> Xenomai: unregistered exported object M1-1908 (mutexes) >>>> Xenomai: POSIX: destroyed thread df5a0800 >>>> >>>> I put the printk on line cond.c:433 after err is set in rt_cond_wait= _prologue(): >>>> >>>> info =3D xnsynch_sleep_on(&cond->synch_base, >>>> timeout, timeout_mode); >>>> if (info & XNRMID) >>>> err =3D -EIDRM; /* Condvar deleted while pending. */ >>>> else if (info & XNTIMEO) { >>>> err =3D -ETIMEDOUT; /* Timeout. */ >>>> } >>>> else if (info & XNBREAK) { >>>> err =3D -EINTR; /* Unblocked. */ >>>> } >>>> printk(KERN_DEBUG "xnsynch_sleep_on returned: %d\n", err); >>>> >>>> I put a printk in rt_cond_wait_inner() which is called directly by r= t_cond_wait() from user mode but did not see the output in the dmesg outp= ut for that one. >>> One of our problems is the prologue/epilogue split up (both in kernel= >>> and user space): the epilogue can eat the error code or the prologue,= >>> including the -ETIMEDOUT. >> Ah. My fault. Looks user-space is Ok though. Only kernel-space has a >> problem. >> >=20 > Both are affected. >=20 > Could you help me with what issues > 97323b3287b5ee8cad99a7fa67cd050bc51f76c4 should fix? Ah, restart after RT-signals! So far we blocked on the concluding rt_mutex_lock without breaking out to user space, now we have to loop over -EINTR to allow signals, right? Jan --------------enigA07C0A67C7C9DB64A04AB15B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkuMJ5cACgkQitSsb3rl5xTbQgCgkZ9HfnWRiPx+2yRISZp/Viya XqYAn0zch0bGW3zlQMfMF3PkT7fsW4YF =8bs1 -----END PGP SIGNATURE----- --------------enigA07C0A67C7C9DB64A04AB15B-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8C26F7.3020306@domain.hid> Date: Mon, 01 Mar 2010 21:43:35 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> <4B8C2490.1040604@domain.hid> <4B8C25B9.8090705@domain.hid> In-Reply-To: <4B8C25B9.8090705@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7C181BFDE241B7C5490F9133" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: "xenomai@xenomai.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7C181BFDE241B7C5490F9133 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Charlton, John wrote: >>> I added some printk output to the cond.c file in xenomai-2.5.1 and it= shows that xnsync_sleep_on returned -ETIMEDOUT as it should: >>> Xenomai: registered exported object M1-1908 (mutexes) >>> Xenomai: registered exported object C1-1908 (condvars) >>> xnsynch_sleep_on returned: -110 >>> xnsynch_sleep_on returned: -110 >>> xnsynch_sleep_on returned: -110 >>> xnsynch_sleep_on returned: -110 >>> xnsynch_sleep_on returned: -110 >>> xnsynch_sleep_on returned: -110 >>> xnsynch_sleep_on returned: -4 >>> Xenomai: native: cleaning up cond "C1-1908" (ret=3D0). >>> Xenomai: unregistered exported object C1-1908 (condvars) >>> Xenomai: native: cleaning up mutex "M1-1908" (ret=3D0). >>> Xenomai: unregistered exported object M1-1908 (mutexes) >>> Xenomai: POSIX: destroyed thread df5a0800 >>> >>> I put the printk on line cond.c:433 after err is set in rt_cond_wait_= prologue(): >>> >>> info =3D xnsynch_sleep_on(&cond->synch_base, >>> timeout, timeout_mode); >>> if (info & XNRMID) >>> err =3D -EIDRM; /* Condvar deleted while pending. */ >>> else if (info & XNTIMEO) { >>> err =3D -ETIMEDOUT; /* Timeout. */ >>> } >>> else if (info & XNBREAK) { >>> err =3D -EINTR; /* Unblocked. */ >>> } >>> printk(KERN_DEBUG "xnsynch_sleep_on returned: %d\n", err); >>> >>> I put a printk in rt_cond_wait_inner() which is called directly by rt= _cond_wait() from user mode but did not see the output in the dmesg outpu= t for that one. >> One of our problems is the prologue/epilogue split up (both in kernel >> and user space): the epilogue can eat the error code or the prologue, >> including the -ETIMEDOUT. >=20 > Ah. My fault. Looks user-space is Ok though. Only kernel-space has a > problem. >=20 Both are affected. Could you help me with what issues 97323b3287b5ee8cad99a7fa67cd050bc51f76c4 should fix? Jan --------------enig7C181BFDE241B7C5490F9133 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkuMJvcACgkQitSsb3rl5xT2ugCfZlQfOOZQWT7vFmeAoHc02Q6E cG8An1K2nCquO661OJQVNlvzlUrlY0D6 =43iz -----END PGP SIGNATURE----- --------------enig7C181BFDE241B7C5490F9133-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8C29E1.7070404@domain.hid> Date: Mon, 01 Mar 2010 21:56:01 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> <4B8C2490.1040604@domain.hid> <4B8C25B9.8090705@domain.hid> <4B8C26F7.3020306@domain.hid> <4B8C2797.2000501@domain.hid> In-Reply-To: <4B8C2797.2000501@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: "xenomai@xenomai.org" Jan Kiszka wrote: > Jan Kiszka wrote: >> Gilles Chanteperdrix wrote: >>> Jan Kiszka wrote: >>>> Charlton, John wrote: >>>>> I added some printk output to the cond.c file in xenomai-2.5.1 and it shows that xnsync_sleep_on returned -ETIMEDOUT as it should: >>>>> Xenomai: registered exported object M1-1908 (mutexes) >>>>> Xenomai: registered exported object C1-1908 (condvars) >>>>> xnsynch_sleep_on returned: -110 >>>>> xnsynch_sleep_on returned: -110 >>>>> xnsynch_sleep_on returned: -110 >>>>> xnsynch_sleep_on returned: -110 >>>>> xnsynch_sleep_on returned: -110 >>>>> xnsynch_sleep_on returned: -110 >>>>> xnsynch_sleep_on returned: -4 >>>>> Xenomai: native: cleaning up cond "C1-1908" (ret=0). >>>>> Xenomai: unregistered exported object C1-1908 (condvars) >>>>> Xenomai: native: cleaning up mutex "M1-1908" (ret=0). >>>>> Xenomai: unregistered exported object M1-1908 (mutexes) >>>>> Xenomai: POSIX: destroyed thread df5a0800 >>>>> >>>>> I put the printk on line cond.c:433 after err is set in rt_cond_wait_prologue(): >>>>> >>>>> info = xnsynch_sleep_on(&cond->synch_base, >>>>> timeout, timeout_mode); >>>>> if (info & XNRMID) >>>>> err = -EIDRM; /* Condvar deleted while pending. */ >>>>> else if (info & XNTIMEO) { >>>>> err = -ETIMEDOUT; /* Timeout. */ >>>>> } >>>>> else if (info & XNBREAK) { >>>>> err = -EINTR; /* Unblocked. */ >>>>> } >>>>> printk(KERN_DEBUG "xnsynch_sleep_on returned: %d\n", err); >>>>> >>>>> I put a printk in rt_cond_wait_inner() which is called directly by rt_cond_wait() from user mode but did not see the output in the dmesg output for that one. >>>> One of our problems is the prologue/epilogue split up (both in kernel >>>> and user space): the epilogue can eat the error code or the prologue, >>>> including the -ETIMEDOUT. >>> Ah. My fault. Looks user-space is Ok though. Only kernel-space has a >>> problem. >>> >> Both are affected. >> >> Could you help me with what issues >> 97323b3287b5ee8cad99a7fa67cd050bc51f76c4 should fix? > > Ah, restart after RT-signals! So far we blocked on the concluding > rt_mutex_lock without breaking out to user space, now we have to loop > over -EINTR to allow signals, right? Yes, it is needed even for handling linux signals (getting gdb working for instance). However, since we do not want rt_cond_wait to result into two syscalls all the time, we handle everything in the first syscall if possible. Try this: diff --git a/ksrc/skins/native/syscall.c b/ksrc/skins/native/syscall.c index 40e5cfd..d4e885c 100644 --- a/ksrc/skins/native/syscall.c +++ b/ksrc/skins/native/syscall.c @@ -1869,9 +1869,12 @@ static int __rt_cond_wait_prologue(struct pt_regs *regs) err = rt_cond_wait_prologue(cond, mutex, &lockcnt, timeout_mode, timeout); - if (err == 0 || err == -ETIMEDOUT) - err = rt_cond_wait_epilogue(mutex, lockcnt); - + if (err == 0 || err == -ETIMEDOUT) { + int loc_err = rt_cond_wait_epilogue(mutex, lockcnt); + if (loc_err < 0) + err = loc_err; + } + if (err == -EINTR && __xn_reg_arg3(regs) && __xn_safe_copy_to_user((void __user *)__xn_reg_arg3(regs), &lockcnt, sizeof(lockcnt))) > > Jan > -- Gilles. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8C2B08.8080907@domain.hid> Date: Mon, 01 Mar 2010 22:00:56 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> <4B8C2490.1040604@domain.hid> <4B8C25B9.8090705@domain.hid> <4B8C26F7.3020306@domain.hid> <4B8C2797.2000501@domain.hid> <4B8C29E1.7070404@domain.hid> In-Reply-To: <4B8C29E1.7070404@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: "xenomai@xenomai.org" Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Jan Kiszka wrote: >>> Gilles Chanteperdrix wrote: >>>> Jan Kiszka wrote: >>>>> Charlton, John wrote: >>>>>> I added some printk output to the cond.c file in xenomai-2.5.1 and it shows that xnsync_sleep_on returned -ETIMEDOUT as it should: >>>>>> Xenomai: registered exported object M1-1908 (mutexes) >>>>>> Xenomai: registered exported object C1-1908 (condvars) >>>>>> xnsynch_sleep_on returned: -110 >>>>>> xnsynch_sleep_on returned: -110 >>>>>> xnsynch_sleep_on returned: -110 >>>>>> xnsynch_sleep_on returned: -110 >>>>>> xnsynch_sleep_on returned: -110 >>>>>> xnsynch_sleep_on returned: -110 >>>>>> xnsynch_sleep_on returned: -4 >>>>>> Xenomai: native: cleaning up cond "C1-1908" (ret=0). >>>>>> Xenomai: unregistered exported object C1-1908 (condvars) >>>>>> Xenomai: native: cleaning up mutex "M1-1908" (ret=0). >>>>>> Xenomai: unregistered exported object M1-1908 (mutexes) >>>>>> Xenomai: POSIX: destroyed thread df5a0800 >>>>>> >>>>>> I put the printk on line cond.c:433 after err is set in rt_cond_wait_prologue(): >>>>>> >>>>>> info = xnsynch_sleep_on(&cond->synch_base, >>>>>> timeout, timeout_mode); >>>>>> if (info & XNRMID) >>>>>> err = -EIDRM; /* Condvar deleted while pending. */ >>>>>> else if (info & XNTIMEO) { >>>>>> err = -ETIMEDOUT; /* Timeout. */ >>>>>> } >>>>>> else if (info & XNBREAK) { >>>>>> err = -EINTR; /* Unblocked. */ >>>>>> } >>>>>> printk(KERN_DEBUG "xnsynch_sleep_on returned: %d\n", err); >>>>>> >>>>>> I put a printk in rt_cond_wait_inner() which is called directly by rt_cond_wait() from user mode but did not see the output in the dmesg output for that one. >>>>> One of our problems is the prologue/epilogue split up (both in kernel >>>>> and user space): the epilogue can eat the error code or the prologue, >>>>> including the -ETIMEDOUT. >>>> Ah. My fault. Looks user-space is Ok though. Only kernel-space has a >>>> problem. >>>> >>> Both are affected. >>> >>> Could you help me with what issues >>> 97323b3287b5ee8cad99a7fa67cd050bc51f76c4 should fix? >> Ah, restart after RT-signals! So far we blocked on the concluding >> rt_mutex_lock without breaking out to user space, now we have to loop >> over -EINTR to allow signals, right? > > Yes, it is needed even for handling linux signals (getting gdb working > for instance). However, since we do not want rt_cond_wait to result into > two syscalls all the time, we handle everything in the first syscall if > possible. > > Try this: > > diff --git a/ksrc/skins/native/syscall.c b/ksrc/skins/native/syscall.c > index 40e5cfd..d4e885c 100644 > --- a/ksrc/skins/native/syscall.c > +++ b/ksrc/skins/native/syscall.c > @@ -1869,9 +1869,12 @@ static int __rt_cond_wait_prologue(struct pt_regs *regs) > > err = rt_cond_wait_prologue(cond, mutex, &lockcnt, timeout_mode, timeout); > > - if (err == 0 || err == -ETIMEDOUT) > - err = rt_cond_wait_epilogue(mutex, lockcnt); > - > + if (err == 0 || err == -ETIMEDOUT) { > + int loc_err = rt_cond_wait_epilogue(mutex, lockcnt); > + if (loc_err < 0) > + err = loc_err; > + } > + > if (err == -EINTR && __xn_reg_arg3(regs) > && __xn_safe_copy_to_user((void __user *)__xn_reg_arg3(regs), > &lockcnt, sizeof(lockcnt))) No. That is not ok either. We need to store the first status somewhere for returning it to user-space after looping several times in the epilogue function. -- Gilles. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8C2B3E.8020505@domain.hid> Date: Mon, 01 Mar 2010 22:01:50 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> <4B8C2490.1040604@domain.hid> <4B8C25B9.8090705@domain.hid> <4B8C26F7.3020306@domain.hid> <4B8C2797.2000501@domain.hid> <4B8C29E1.7070404@domain.hid> In-Reply-To: <4B8C29E1.7070404@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF0ABDFEA4BC99F69053FE60F" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: "xenomai@xenomai.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF0ABDFEA4BC99F69053FE60F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Jan Kiszka wrote: >>> Gilles Chanteperdrix wrote: >>>> Jan Kiszka wrote: >>>>> Charlton, John wrote: >>>>>> I added some printk output to the cond.c file in xenomai-2.5.1 and= it shows that xnsync_sleep_on returned -ETIMEDOUT as it should: >>>>>> Xenomai: registered exported object M1-1908 (mutexes) >>>>>> Xenomai: registered exported object C1-1908 (condvars) >>>>>> xnsynch_sleep_on returned: -110 >>>>>> xnsynch_sleep_on returned: -110 >>>>>> xnsynch_sleep_on returned: -110 >>>>>> xnsynch_sleep_on returned: -110 >>>>>> xnsynch_sleep_on returned: -110 >>>>>> xnsynch_sleep_on returned: -110 >>>>>> xnsynch_sleep_on returned: -4 >>>>>> Xenomai: native: cleaning up cond "C1-1908" (ret=3D0). >>>>>> Xenomai: unregistered exported object C1-1908 (condvars) >>>>>> Xenomai: native: cleaning up mutex "M1-1908" (ret=3D0). >>>>>> Xenomai: unregistered exported object M1-1908 (mutexes) >>>>>> Xenomai: POSIX: destroyed thread df5a0800 >>>>>> >>>>>> I put the printk on line cond.c:433 after err is set in rt_cond_wa= it_prologue(): >>>>>> >>>>>> info =3D xnsynch_sleep_on(&cond->synch_base, >>>>>> timeout, timeout_mode); >>>>>> if (info & XNRMID) >>>>>> err =3D -EIDRM; /* Condvar deleted while pending. */ >>>>>> else if (info & XNTIMEO) { >>>>>> err =3D -ETIMEDOUT; /* Timeout. */ >>>>>> } >>>>>> else if (info & XNBREAK) { >>>>>> err =3D -EINTR; /* Unblocked. */ >>>>>> } >>>>>> printk(KERN_DEBUG "xnsynch_sleep_on returned: %d\n", err);= >>>>>> >>>>>> I put a printk in rt_cond_wait_inner() which is called directly by= rt_cond_wait() from user mode but did not see the output in the dmesg ou= tput for that one. >>>>> One of our problems is the prologue/epilogue split up (both in kern= el >>>>> and user space): the epilogue can eat the error code or the prologu= e, >>>>> including the -ETIMEDOUT. >>>> Ah. My fault. Looks user-space is Ok though. Only kernel-space has a= >>>> problem. >>>> >>> Both are affected. >>> >>> Could you help me with what issues >>> 97323b3287b5ee8cad99a7fa67cd050bc51f76c4 should fix? >> Ah, restart after RT-signals! So far we blocked on the concluding >> rt_mutex_lock without breaking out to user space, now we have to loop >> over -EINTR to allow signals, right? >=20 > Yes, it is needed even for handling linux signals (getting gdb working = > for instance). However, since we do not want rt_cond_wait to result int= o > two syscalls all the time, we handle everything in the first syscall if= =20 > possible. >=20 > Try this: >=20 > diff --git a/ksrc/skins/native/syscall.c b/ksrc/skins/native/syscall.c > index 40e5cfd..d4e885c 100644 > --- a/ksrc/skins/native/syscall.c > +++ b/ksrc/skins/native/syscall.c > @@ -1869,9 +1869,12 @@ static int __rt_cond_wait_prologue(struct pt_reg= s *regs) >=20 > err =3D rt_cond_wait_prologue(cond, mutex, &lockcnt, timeout_mo= de, timeout); >=20 > - if (err =3D=3D 0 || err =3D=3D -ETIMEDOUT) > - err =3D rt_cond_wait_epilogue(mutex, lockcnt); > - > + if (err =3D=3D 0 || err =3D=3D -ETIMEDOUT) { > + int loc_err =3D rt_cond_wait_epilogue(mutex, lockcnt); > + if (loc_err < 0) > + err =3D loc_err; > + } > + > if (err =3D=3D -EINTR && __xn_reg_arg3(regs) > && __xn_safe_copy_to_user((void __user *)__xn_reg_arg3(regs= ), > &lockcnt, sizeof(lockcnt))) >=20 Same issue exists in user space. And rt_cond_wait_inner needs fixing. And then there is a spurious sign inversion: diff --git a/src/skins/native/cond.c b/src/skins/native/cond.c index 478321d..f874678 100644 --- a/src/skins/native/cond.c +++ b/src/skins/native/cond.c @@ -96,9 +96,9 @@ int rt_cond_wait_until(RT_COND *cond, RT_MUTEX *mutex, = RTIME timeout) &saved_lockcnt, XN_REALTIME, &timeout); =20 while (err =3D=3D -EINTR) - err =3D -XENOMAI_SKINCALL2(__native_muxid, - __native_cond_wait_epilogue, mutex, - saved_lockcnt); + err =3D XENOMAI_SKINCALL2(__native_muxid, + __native_cond_wait_epilogue, mutex, + saved_lockcnt); #endif /* !CONFIG_XENO_FASTSYNCH */ =20 return err; Jan --------------enigF0ABDFEA4BC99F69053FE60F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkuMK0EACgkQitSsb3rl5xQMWACfQ8ehKpsLgKq3LpnL+6LSoDV5 bycAn2NzPE09xiB/w3nAsb5py1uIN7Q5 =8v+w -----END PGP SIGNATURE----- --------------enigF0ABDFEA4BC99F69053FE60F-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8C2B76.9020405@domain.hid> Date: Mon, 01 Mar 2010 22:02:46 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> <4B8C2490.1040604@domain.hid> <4B8C25B9.8090705@domain.hid> <4B8C26F7.3020306@domain.hid> <4B8C2797.2000501@domain.hid> <4B8C29E1.7070404@domain.hid> <4B8C2B08.8080907@domain.hid> In-Reply-To: <4B8C2B08.8080907@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig79CCC2D4D3EF47F5199C59FA" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: "xenomai@xenomai.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig79CCC2D4D3EF47F5199C59FA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gilles Chanteperdrix wrote: > Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Jan Kiszka wrote: >>>> Gilles Chanteperdrix wrote: >>>>> Jan Kiszka wrote: >>>>>> Charlton, John wrote: >>>>>>> I added some printk output to the cond.c file in xenomai-2.5.1 an= d it shows that xnsync_sleep_on returned -ETIMEDOUT as it should: >>>>>>> Xenomai: registered exported object M1-1908 (mutexes) >>>>>>> Xenomai: registered exported object C1-1908 (condvars) >>>>>>> xnsynch_sleep_on returned: -110 >>>>>>> xnsynch_sleep_on returned: -110 >>>>>>> xnsynch_sleep_on returned: -110 >>>>>>> xnsynch_sleep_on returned: -110 >>>>>>> xnsynch_sleep_on returned: -110 >>>>>>> xnsynch_sleep_on returned: -110 >>>>>>> xnsynch_sleep_on returned: -4 >>>>>>> Xenomai: native: cleaning up cond "C1-1908" (ret=3D0). >>>>>>> Xenomai: unregistered exported object C1-1908 (condvars) >>>>>>> Xenomai: native: cleaning up mutex "M1-1908" (ret=3D0). >>>>>>> Xenomai: unregistered exported object M1-1908 (mutexes) >>>>>>> Xenomai: POSIX: destroyed thread df5a0800 >>>>>>> >>>>>>> I put the printk on line cond.c:433 after err is set in rt_cond_w= ait_prologue(): >>>>>>> >>>>>>> info =3D xnsynch_sleep_on(&cond->synch_base, >>>>>>> timeout, timeout_mode); >>>>>>> if (info & XNRMID) >>>>>>> err =3D -EIDRM; /* Condvar deleted while pending. */ >>>>>>> else if (info & XNTIMEO) { >>>>>>> err =3D -ETIMEDOUT; /* Timeout. */ >>>>>>> } >>>>>>> else if (info & XNBREAK) { >>>>>>> err =3D -EINTR; /* Unblocked. */ >>>>>>> } >>>>>>> printk(KERN_DEBUG "xnsynch_sleep_on returned: %d\n", err)= ; >>>>>>> >>>>>>> I put a printk in rt_cond_wait_inner() which is called directly b= y rt_cond_wait() from user mode but did not see the output in the dmesg o= utput for that one. >>>>>> One of our problems is the prologue/epilogue split up (both in ker= nel >>>>>> and user space): the epilogue can eat the error code or the prolog= ue, >>>>>> including the -ETIMEDOUT. >>>>> Ah. My fault. Looks user-space is Ok though. Only kernel-space has = a >>>>> problem. >>>>> >>>> Both are affected. >>>> >>>> Could you help me with what issues >>>> 97323b3287b5ee8cad99a7fa67cd050bc51f76c4 should fix? >>> Ah, restart after RT-signals! So far we blocked on the concluding >>> rt_mutex_lock without breaking out to user space, now we have to loop= >>> over -EINTR to allow signals, right? >> Yes, it is needed even for handling linux signals (getting gdb working= =20 >> for instance). However, since we do not want rt_cond_wait to result in= to >> two syscalls all the time, we handle everything in the first syscall i= f=20 >> possible. >> >> Try this: >> >> diff --git a/ksrc/skins/native/syscall.c b/ksrc/skins/native/syscall.c= >> index 40e5cfd..d4e885c 100644 >> --- a/ksrc/skins/native/syscall.c >> +++ b/ksrc/skins/native/syscall.c >> @@ -1869,9 +1869,12 @@ static int __rt_cond_wait_prologue(struct pt_re= gs *regs) >> >> err =3D rt_cond_wait_prologue(cond, mutex, &lockcnt, timeout_m= ode, timeout); >> >> - if (err =3D=3D 0 || err =3D=3D -ETIMEDOUT) >> - err =3D rt_cond_wait_epilogue(mutex, lockcnt); >> - >> + if (err =3D=3D 0 || err =3D=3D -ETIMEDOUT) { >> + int loc_err =3D rt_cond_wait_epilogue(mutex, lockcnt);= >> + if (loc_err < 0) >> + err =3D loc_err; >> + } >> + >> if (err =3D=3D -EINTR && __xn_reg_arg3(regs) >> && __xn_safe_copy_to_user((void __user *)__xn_reg_arg3(reg= s), >> &lockcnt, sizeof(lockcnt))) >=20 > No. That is not ok either. We need to store the first status somewhere > for returning it to user-space after looping several times in the > epilogue function. Precisely (also in user space). Jan --------------enig79CCC2D4D3EF47F5199C59FA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkuMK3YACgkQitSsb3rl5xRxyQCfYselVvaiSJJH4XluLHF0zliZ shQAoOKZoilmcbu8Oznwpl/JvQvRIXMY =OkHY -----END PGP SIGNATURE----- --------------enig79CCC2D4D3EF47F5199C59FA-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8C2C35.6030006@domain.hid> Date: Mon, 01 Mar 2010 22:05:57 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> <4B8C2490.1040604@domain.hid> <4B8C25B9.8090705@domain.hid> <4B8C26F7.3020306@domain.hid> <4B8C2797.2000501@domain.hid> <4B8C29E1.7070404@domain.hid> <4B8C2B3E.8020505@domain.hid> In-Reply-To: <4B8C2B3E.8020505@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: "xenomai@xenomai.org" Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Jan Kiszka wrote: >>>> Gilles Chanteperdrix wrote: >>>>> Jan Kiszka wrote: >>>>>> Charlton, John wrote: >>>>>>> I added some printk output to the cond.c file in xenomai-2.5.1 and it shows that xnsync_sleep_on returned -ETIMEDOUT as it should: >>>>>>> Xenomai: registered exported object M1-1908 (mutexes) >>>>>>> Xenomai: registered exported object C1-1908 (condvars) >>>>>>> xnsynch_sleep_on returned: -110 >>>>>>> xnsynch_sleep_on returned: -110 >>>>>>> xnsynch_sleep_on returned: -110 >>>>>>> xnsynch_sleep_on returned: -110 >>>>>>> xnsynch_sleep_on returned: -110 >>>>>>> xnsynch_sleep_on returned: -110 >>>>>>> xnsynch_sleep_on returned: -4 >>>>>>> Xenomai: native: cleaning up cond "C1-1908" (ret=0). >>>>>>> Xenomai: unregistered exported object C1-1908 (condvars) >>>>>>> Xenomai: native: cleaning up mutex "M1-1908" (ret=0). >>>>>>> Xenomai: unregistered exported object M1-1908 (mutexes) >>>>>>> Xenomai: POSIX: destroyed thread df5a0800 >>>>>>> >>>>>>> I put the printk on line cond.c:433 after err is set in rt_cond_wait_prologue(): >>>>>>> >>>>>>> info = xnsynch_sleep_on(&cond->synch_base, >>>>>>> timeout, timeout_mode); >>>>>>> if (info & XNRMID) >>>>>>> err = -EIDRM; /* Condvar deleted while pending. */ >>>>>>> else if (info & XNTIMEO) { >>>>>>> err = -ETIMEDOUT; /* Timeout. */ >>>>>>> } >>>>>>> else if (info & XNBREAK) { >>>>>>> err = -EINTR; /* Unblocked. */ >>>>>>> } >>>>>>> printk(KERN_DEBUG "xnsynch_sleep_on returned: %d\n", err); >>>>>>> >>>>>>> I put a printk in rt_cond_wait_inner() which is called directly by rt_cond_wait() from user mode but did not see the output in the dmesg output for that one. >>>>>> One of our problems is the prologue/epilogue split up (both in kernel >>>>>> and user space): the epilogue can eat the error code or the prologue, >>>>>> including the -ETIMEDOUT. >>>>> Ah. My fault. Looks user-space is Ok though. Only kernel-space has a >>>>> problem. >>>>> >>>> Both are affected. >>>> >>>> Could you help me with what issues >>>> 97323b3287b5ee8cad99a7fa67cd050bc51f76c4 should fix? >>> Ah, restart after RT-signals! So far we blocked on the concluding >>> rt_mutex_lock without breaking out to user space, now we have to loop >>> over -EINTR to allow signals, right? >> Yes, it is needed even for handling linux signals (getting gdb working >> for instance). However, since we do not want rt_cond_wait to result into >> two syscalls all the time, we handle everything in the first syscall if >> possible. >> >> Try this: >> >> diff --git a/ksrc/skins/native/syscall.c b/ksrc/skins/native/syscall.c >> index 40e5cfd..d4e885c 100644 >> --- a/ksrc/skins/native/syscall.c >> +++ b/ksrc/skins/native/syscall.c >> @@ -1869,9 +1869,12 @@ static int __rt_cond_wait_prologue(struct pt_regs *regs) >> >> err = rt_cond_wait_prologue(cond, mutex, &lockcnt, timeout_mode, timeout); >> >> - if (err == 0 || err == -ETIMEDOUT) >> - err = rt_cond_wait_epilogue(mutex, lockcnt); >> - >> + if (err == 0 || err == -ETIMEDOUT) { >> + int loc_err = rt_cond_wait_epilogue(mutex, lockcnt); >> + if (loc_err < 0) >> + err = loc_err; >> + } >> + >> if (err == -EINTR && __xn_reg_arg3(regs) >> && __xn_safe_copy_to_user((void __user *)__xn_reg_arg3(regs), >> &lockcnt, sizeof(lockcnt))) >> > > Same issue exists in user space. And rt_cond_wait_inner needs fixing. > And then there is a spurious sign inversion: > > diff --git a/src/skins/native/cond.c b/src/skins/native/cond.c > index 478321d..f874678 100644 > --- a/src/skins/native/cond.c > +++ b/src/skins/native/cond.c > @@ -96,9 +96,9 @@ int rt_cond_wait_until(RT_COND *cond, RT_MUTEX *mutex, RTIME timeout) > &saved_lockcnt, XN_REALTIME, &timeout); > > while (err == -EINTR) > - err = -XENOMAI_SKINCALL2(__native_muxid, > - __native_cond_wait_epilogue, mutex, > - saved_lockcnt); > + err = XENOMAI_SKINCALL2(__native_muxid, > + __native_cond_wait_epilogue, mutex, > + saved_lockcnt); > #endif /* !CONFIG_XENO_FASTSYNCH */ Ok for the sign inversion, but in this case the status is Ok. We call cond_wait_epilogue only if prologue returned -EINTR, and update the status, this is what we want. There is only one way out which will not break the ABI: do not call cond_wait_epilogue in the kernel-space cond_wait_prologue. -- Gilles. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8C2C40.1070209@domain.hid> Date: Mon, 01 Mar 2010 22:06:08 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> <4B8C2490.1040604@domain.hid> <4B8C25B9.8090705@domain.hid> <4B8C26F7.3020306@domain.hid> <4B8C2797.2000501@domain.hid> <4B8C29E1.7070404@domain.hid> <4B8C2B08.8080907@domain.hid> <4B8C2B76.9020405@domain.hid> In-Reply-To: <4B8C2B76.9020405@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigADAE7417B3B4FDC35AAA9BDC" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: "xenomai@xenomai.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigADAE7417B3B4FDC35AAA9BDC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Gilles Chanteperdrix wrote: >>> Try this: >>> >>> diff --git a/ksrc/skins/native/syscall.c b/ksrc/skins/native/syscall.= c >>> index 40e5cfd..d4e885c 100644 >>> --- a/ksrc/skins/native/syscall.c >>> +++ b/ksrc/skins/native/syscall.c >>> @@ -1869,9 +1869,12 @@ static int __rt_cond_wait_prologue(struct pt_r= egs *regs) >>> >>> err =3D rt_cond_wait_prologue(cond, mutex, &lockcnt, timeout_= mode, timeout); >>> >>> - if (err =3D=3D 0 || err =3D=3D -ETIMEDOUT) >>> - err =3D rt_cond_wait_epilogue(mutex, lockcnt); >>> - >>> + if (err =3D=3D 0 || err =3D=3D -ETIMEDOUT) { >>> + int loc_err =3D rt_cond_wait_epilogue(mutex, lockcnt)= ; >>> + if (loc_err < 0) >>> + err =3D loc_err; >>> + } >>> + >>> if (err =3D=3D -EINTR && __xn_reg_arg3(regs) >>> && __xn_safe_copy_to_user((void __user *)__xn_reg_arg3(re= gs), >>> &lockcnt, sizeof(lockcnt))) >> No. That is not ok either. We need to store the first status somewhere= >> for returning it to user-space after looping several times in the >> epilogue function. >=20 > Precisely (also in user space). >=20 As we do not specify if rt_cond_wait behaves like pthread_cond_wait on signals or errors of the cond variable, I checked the 2.4 behavior again: we used to ignore all errors of the final rt_mutex_lock. Guess we should restore that for all contexts (except for -EINTR). Jan --------------enigADAE7417B3B4FDC35AAA9BDC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkuMLEAACgkQitSsb3rl5xR5yACbBxZAECQWf4nb6sii4pMkk88R BvIAn2eVr8mBMAEhNtSWBpiYiX27lOQT =4qdm -----END PGP SIGNATURE----- --------------enigADAE7417B3B4FDC35AAA9BDC-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8C2FE6.5000406@domain.hid> Date: Mon, 01 Mar 2010 22:21:42 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> <4B8C2490.1040604@domain.hid> <4B8C25B9.8090705@domain.hid> <4B8C26F7.3020306@domain.hid> <4B8C2797.2000501@domain.hid> <4B8C29E1.7070404@domain.hid> <4B8C2B3E.8020505@domain.hid> <4B8C2C35.6030006@domain.hid> In-Reply-To: <4B8C2C35.6030006@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD9C55174A10D894A8C71C5FA" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: "xenomai@xenomai.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD9C55174A10D894A8C71C5FA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Gilles Chanteperdrix wrote: >>> Jan Kiszka wrote: >>>> Jan Kiszka wrote: >>>>> Gilles Chanteperdrix wrote: >>>>>> Jan Kiszka wrote: >>>>>>> Charlton, John wrote: >>>>>>>> I added some printk output to the cond.c file in xenomai-2.5.1 a= nd it shows that xnsync_sleep_on returned -ETIMEDOUT as it should: >>>>>>>> Xenomai: registered exported object M1-1908 (mutexes) >>>>>>>> Xenomai: registered exported object C1-1908 (condvars) >>>>>>>> xnsynch_sleep_on returned: -110 >>>>>>>> xnsynch_sleep_on returned: -110 >>>>>>>> xnsynch_sleep_on returned: -110 >>>>>>>> xnsynch_sleep_on returned: -110 >>>>>>>> xnsynch_sleep_on returned: -110 >>>>>>>> xnsynch_sleep_on returned: -110 >>>>>>>> xnsynch_sleep_on returned: -4 >>>>>>>> Xenomai: native: cleaning up cond "C1-1908" (ret=3D0). >>>>>>>> Xenomai: unregistered exported object C1-1908 (condvars) >>>>>>>> Xenomai: native: cleaning up mutex "M1-1908" (ret=3D0). >>>>>>>> Xenomai: unregistered exported object M1-1908 (mutexes) >>>>>>>> Xenomai: POSIX: destroyed thread df5a0800 >>>>>>>> >>>>>>>> I put the printk on line cond.c:433 after err is set in rt_cond_= wait_prologue(): >>>>>>>> >>>>>>>> info =3D xnsynch_sleep_on(&cond->synch_base, >>>>>>>> timeout, timeout_mode); >>>>>>>> if (info & XNRMID) >>>>>>>> err =3D -EIDRM; /* Condvar deleted while pending. */ >>>>>>>> else if (info & XNTIMEO) { >>>>>>>> err =3D -ETIMEDOUT; /* Timeout. */ >>>>>>>> } >>>>>>>> else if (info & XNBREAK) { >>>>>>>> err =3D -EINTR; /* Unblocked. */ >>>>>>>> } >>>>>>>> printk(KERN_DEBUG "xnsynch_sleep_on returned: %d\n", err= ); >>>>>>>> >>>>>>>> I put a printk in rt_cond_wait_inner() which is called directly = by rt_cond_wait() from user mode but did not see the output in the dmesg = output for that one. >>>>>>> One of our problems is the prologue/epilogue split up (both in ke= rnel >>>>>>> and user space): the epilogue can eat the error code or the prolo= gue, >>>>>>> including the -ETIMEDOUT. >>>>>> Ah. My fault. Looks user-space is Ok though. Only kernel-space has= a >>>>>> problem. >>>>>> >>>>> Both are affected. >>>>> >>>>> Could you help me with what issues >>>>> 97323b3287b5ee8cad99a7fa67cd050bc51f76c4 should fix? >>>> Ah, restart after RT-signals! So far we blocked on the concluding >>>> rt_mutex_lock without breaking out to user space, now we have to loo= p >>>> over -EINTR to allow signals, right? >>> Yes, it is needed even for handling linux signals (getting gdb workin= g=20 >>> for instance). However, since we do not want rt_cond_wait to result i= nto >>> two syscalls all the time, we handle everything in the first syscall = if=20 >>> possible. >>> >>> Try this: >>> >>> diff --git a/ksrc/skins/native/syscall.c b/ksrc/skins/native/syscall.= c >>> index 40e5cfd..d4e885c 100644 >>> --- a/ksrc/skins/native/syscall.c >>> +++ b/ksrc/skins/native/syscall.c >>> @@ -1869,9 +1869,12 @@ static int __rt_cond_wait_prologue(struct pt_r= egs *regs) >>> >>> err =3D rt_cond_wait_prologue(cond, mutex, &lockcnt, timeout_= mode, timeout); >>> >>> - if (err =3D=3D 0 || err =3D=3D -ETIMEDOUT) >>> - err =3D rt_cond_wait_epilogue(mutex, lockcnt); >>> - >>> + if (err =3D=3D 0 || err =3D=3D -ETIMEDOUT) { >>> + int loc_err =3D rt_cond_wait_epilogue(mutex, lockcnt)= ; >>> + if (loc_err < 0) >>> + err =3D loc_err; >>> + } >>> + >>> if (err =3D=3D -EINTR && __xn_reg_arg3(regs) >>> && __xn_safe_copy_to_user((void __user *)__xn_reg_arg3(re= gs), >>> &lockcnt, sizeof(lockcnt))) >>> >> Same issue exists in user space. And rt_cond_wait_inner needs fixing. >> And then there is a spurious sign inversion: >> >> diff --git a/src/skins/native/cond.c b/src/skins/native/cond.c >> index 478321d..f874678 100644 >> --- a/src/skins/native/cond.c >> +++ b/src/skins/native/cond.c >> @@ -96,9 +96,9 @@ int rt_cond_wait_until(RT_COND *cond, RT_MUTEX *mute= x, RTIME timeout) >> &saved_lockcnt, XN_REALTIME, &timeout); >> =20 >> while (err =3D=3D -EINTR) >> - err =3D -XENOMAI_SKINCALL2(__native_muxid, >> - __native_cond_wait_epilogue, mutex, >> - saved_lockcnt); >> + err =3D XENOMAI_SKINCALL2(__native_muxid, >> + __native_cond_wait_epilogue, mutex, >> + saved_lockcnt); >> #endif /* !CONFIG_XENO_FASTSYNCH */ >=20 > Ok for the sign inversion, but in this case the status is Ok. We call > cond_wait_epilogue only if prologue returned -EINTR, and update the > status, this is what we want. >=20 > There is only one way out which will not break the ABI: do not call > cond_wait_epilogue in the kernel-space cond_wait_prologue. >=20 Unfortunately, that ABI is broken: If we get -ETIMEDOUT on cond wait an -EINTR on mutex lock, we lose the former, don't we? If we can't find a workaround, I'm for breaking the ABI for this particular service - but let's search for an alternative first. Jan --------------enigD9C55174A10D894A8C71C5FA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkuML+YACgkQitSsb3rl5xRSWQCg0G4FHcXXn/CkGj48nikjKfVL RaYAn3Ed6L7kdKMIkJD/4uAivIPaVri4 =uZge -----END PGP SIGNATURE----- --------------enigD9C55174A10D894A8C71C5FA-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8C30DA.3000705@domain.hid> Date: Mon, 01 Mar 2010 22:25:46 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> <4B8C2490.1040604@domain.hid> <4B8C25B9.8090705@domain.hid> <4B8C26F7.3020306@domain.hid> <4B8C2797.2000501@domain.hid> <4B8C29E1.7070404@domain.hid> <4B8C2B3E.8020505@domain.hid> <4B8C2C35.6030006@domain.hid> <4B8C2FE6.5000406@domain.hid> In-Reply-To: <4B8C2FE6.5000406@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF0D070D584B268E76912FDD3" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: "xenomai@xenomai.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF0D070D584B268E76912FDD3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Same issue exists in user space. And rt_cond_wait_inner needs fixing.= >>> And then there is a spurious sign inversion: >>> >>> diff --git a/src/skins/native/cond.c b/src/skins/native/cond.c >>> index 478321d..f874678 100644 >>> --- a/src/skins/native/cond.c >>> +++ b/src/skins/native/cond.c >>> @@ -96,9 +96,9 @@ int rt_cond_wait_until(RT_COND *cond, RT_MUTEX *mut= ex, RTIME timeout) >>> &saved_lockcnt, XN_REALTIME, &timeout); >>> =20 >>> while (err =3D=3D -EINTR) >>> - err =3D -XENOMAI_SKINCALL2(__native_muxid, >>> - __native_cond_wait_epilogue, mutex, >>> - saved_lockcnt); >>> + err =3D XENOMAI_SKINCALL2(__native_muxid, >>> + __native_cond_wait_epilogue, mutex, >>> + saved_lockcnt); >>> #endif /* !CONFIG_XENO_FASTSYNCH */ >> Ok for the sign inversion, but in this case the status is Ok. We call >> cond_wait_epilogue only if prologue returned -EINTR, and update the >> status, this is what we want. >> >> There is only one way out which will not break the ABI: do not call >> cond_wait_epilogue in the kernel-space cond_wait_prologue. >> >=20 > Unfortunately, that ABI is broken: If we get -ETIMEDOUT on cond wait an= > -EINTR on mutex lock, we lose the former, don't we? >=20 > If we can't find a workaround, I'm for breaking the ABI for this > particular service - but let's search for an alternative first. >=20 The only way around ABI changes: save the return code of cond_wait /somewhere/ across prologue and epilogue syscalls - but where??? Jan --------------enigF0D070D584B268E76912FDD3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkuMMNoACgkQitSsb3rl5xT4jQCgxH1ZSFIWRage+s5DkA3mgXi7 NiQAoJr3wntw82DNwx/18l0SG8okxfIT =mJLY -----END PGP SIGNATURE----- --------------enigF0D070D584B268E76912FDD3-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8C33FC.3080806@domain.hid> Date: Mon, 01 Mar 2010 22:39:08 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> <4B8C2490.1040604@domain.hid> <4B8C25B9.8090705@domain.hid> <4B8C26F7.3020306@domain.hid> <4B8C2797.2000501@domain.hid> <4B8C29E1.7070404@domain.hid> <4B8C2B3E.8020505@domain.hid> <4B8C2C35.6030006@domain.hid> <4B8C2FE6.5000406@domain.hid> <4B8C30DA.3000705@domain.hid> In-Reply-To: <4B8C30DA.3000705@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig802343509418D54681BCAF93" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: "xenomai@xenomai.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig802343509418D54681BCAF93 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jan Kiszka wrote: > Jan Kiszka wrote: >> Gilles Chanteperdrix wrote: >>> Jan Kiszka wrote: >>>> Same issue exists in user space. And rt_cond_wait_inner needs fixing= =2E >>>> And then there is a spurious sign inversion: >>>> >>>> diff --git a/src/skins/native/cond.c b/src/skins/native/cond.c >>>> index 478321d..f874678 100644 >>>> --- a/src/skins/native/cond.c >>>> +++ b/src/skins/native/cond.c >>>> @@ -96,9 +96,9 @@ int rt_cond_wait_until(RT_COND *cond, RT_MUTEX *mu= tex, RTIME timeout) >>>> &saved_lockcnt, XN_REALTIME, &timeout); >>>> =20 >>>> while (err =3D=3D -EINTR) >>>> - err =3D -XENOMAI_SKINCALL2(__native_muxid, >>>> - __native_cond_wait_epilogue, mutex, >>>> - saved_lockcnt); >>>> + err =3D XENOMAI_SKINCALL2(__native_muxid, >>>> + __native_cond_wait_epilogue, mutex, >>>> + saved_lockcnt); >>>> #endif /* !CONFIG_XENO_FASTSYNCH */ >>> Ok for the sign inversion, but in this case the status is Ok. We call= >>> cond_wait_epilogue only if prologue returned -EINTR, and update the >>> status, this is what we want. >>> >>> There is only one way out which will not break the ABI: do not call >>> cond_wait_epilogue in the kernel-space cond_wait_prologue. >>> >> Unfortunately, that ABI is broken: If we get -ETIMEDOUT on cond wait a= n >> -EINTR on mutex lock, we lose the former, don't we? >> >> If we can't find a workaround, I'm for breaking the ABI for this >> particular service - but let's search for an alternative first. >> >=20 > The only way around ABI changes: save the return code of cond_wait > /somewhere/ across prologue and epilogue syscalls - but where??? >=20 In-kernel RT_TASK, that's probably the only place. Once __rt_cond_wait_epilogue has acquired the mutex (or failed without receiving a -EINTR), it can then pick up the original error that this task received from rt_cond_wait_prologue and return it. What do you think= ? Jan --------------enig802343509418D54681BCAF93 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkuMNAAACgkQitSsb3rl5xSN5QCgstX0gSD3iVZg6J1iYL0QOtUq gzkAn2QWz0zyEa9oowWZSZsbrfwVJUKQ =TMEW -----END PGP SIGNATURE----- --------------enig802343509418D54681BCAF93-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8C358E.9050303@domain.hid> Date: Mon, 01 Mar 2010 22:45:50 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> <4B8C2490.1040604@domain.hid> <4B8C25B9.8090705@domain.hid> <4B8C26F7.3020306@domain.hid> <4B8C2797.2000501@domain.hid> <4B8C29E1.7070404@domain.hid> <4B8C2B3E.8020505@domain.hid> <4B8C2C35.6030006@domain.hid> <4B8C2FE6.5000406@domain.hid> <4B8C30DA.3000705@domain.hid> <4B8C33FC.3080806@domain.hid> In-Reply-To: <4B8C33FC.3080806@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: "xenomai@xenomai.org" Jan Kiszka wrote: > Jan Kiszka wrote: >> Jan Kiszka wrote: >>> Gilles Chanteperdrix wrote: >>>> Jan Kiszka wrote: >>>>> Same issue exists in user space. And rt_cond_wait_inner needs fixing. >>>>> And then there is a spurious sign inversion: >>>>> >>>>> diff --git a/src/skins/native/cond.c b/src/skins/native/cond.c >>>>> index 478321d..f874678 100644 >>>>> --- a/src/skins/native/cond.c >>>>> +++ b/src/skins/native/cond.c >>>>> @@ -96,9 +96,9 @@ int rt_cond_wait_until(RT_COND *cond, RT_MUTEX *mutex, RTIME timeout) >>>>> &saved_lockcnt, XN_REALTIME, &timeout); >>>>> >>>>> while (err == -EINTR) >>>>> - err = -XENOMAI_SKINCALL2(__native_muxid, >>>>> - __native_cond_wait_epilogue, mutex, >>>>> - saved_lockcnt); >>>>> + err = XENOMAI_SKINCALL2(__native_muxid, >>>>> + __native_cond_wait_epilogue, mutex, >>>>> + saved_lockcnt); >>>>> #endif /* !CONFIG_XENO_FASTSYNCH */ >>>> Ok for the sign inversion, but in this case the status is Ok. We call >>>> cond_wait_epilogue only if prologue returned -EINTR, and update the >>>> status, this is what we want. >>>> >>>> There is only one way out which will not break the ABI: do not call >>>> cond_wait_epilogue in the kernel-space cond_wait_prologue. >>>> >>> Unfortunately, that ABI is broken: If we get -ETIMEDOUT on cond wait an >>> -EINTR on mutex lock, we lose the former, don't we? >>> >>> If we can't find a workaround, I'm for breaking the ABI for this >>> particular service - but let's search for an alternative first. >>> >> The only way around ABI changes: save the return code of cond_wait >> /somewhere/ across prologue and epilogue syscalls - but where??? >> > > In-kernel RT_TASK, that's probably the only place. Once > __rt_cond_wait_epilogue has acquired the mutex (or failed without > receiving a -EINTR), it can then pick up the original error that this > task received from rt_cond_wait_prologue and return it. What do you think? I was thinking about the same idea, by using the xnthread errno. However, it is not reentrant, in the sense that if a signal handler emits a syscall which overrides this value, we are toast. -- Gilles. From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Charlton, John" Date: Mon, 1 Mar 2010 16:53:44 -0500 Message-ID: References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> <4B8C2490.1040604@domain.hid> <4B8C25B9.8090705@domain.hid> <4B8C26F7.3020306@domain.hid> <4B8C2797.2000501@domain.hid> <4B8C29E1.7070404@domain.hid> <4B8C2B3E.8020505@domain.hid> <4B8C2C35.6030006@domain.hid> <4B8C2FE6.5000406@domain.hid> <4B8C30DA.3000705@domain.hid> In-Reply-To: <4B8C30DA.3000705@domain.hid> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Jan Kiszka' , Gilles Chanteperdrix Cc: "xenomai@xenomai.org" =20 -----Original Message----- From: xenomai-help-bounces@domain.hid [mailto:xenomai-help-bounces@domain.hid] On= Behalf Of Jan Kiszka Sent: Monday, March 01, 2010 4:26 PM To: Gilles Chanteperdrix Cc: xenomai@xenomai.org Subject: Re: [Xenomai-help] mlockall error after calling mlockall() Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Same issue exists in user space. And rt_cond_wait_inner needs fixing. >>> And then there is a spurious sign inversion: >>> >>> diff --git a/src/skins/native/cond.c b/src/skins/native/cond.c index=20 >>> 478321d..f874678 100644 >>> --- a/src/skins/native/cond.c >>> +++ b/src/skins/native/cond.c >>> @@ -96,9 +96,9 @@ int rt_cond_wait_until(RT_COND *cond, RT_MUTEX *mutex= , RTIME timeout) >>> &saved_lockcnt, XN_REALTIME, &timeout); >>> =20 >>> while (err =3D=3D -EINTR) >>> - err =3D -XENOMAI_SKINCALL2(__native_muxid, >>> - __native_cond_wait_epilogue, mutex, >>> - saved_lockcnt); >>> + err =3D XENOMAI_SKINCALL2(__native_muxid, >>> + __native_cond_wait_epilogue, mutex, >>> + saved_lockcnt); >>> #endif /* !CONFIG_XENO_FASTSYNCH */ >> Ok for the sign inversion, but in this case the status is Ok. We call=20 >> cond_wait_epilogue only if prologue returned -EINTR, and update the=20 >> status, this is what we want. >> >> There is only one way out which will not break the ABI: do not call=20 >> cond_wait_epilogue in the kernel-space cond_wait_prologue. >> >=20 > Unfortunately, that ABI is broken: If we get -ETIMEDOUT on cond wait=20 > an -EINTR on mutex lock, we lose the former, don't we? >=20 > If we can't find a workaround, I'm for breaking the ABI for this=20 > particular service - but let's search for an alternative first. >=20 The only way around ABI changes: save the return code of cond_wait /somewhe= re/ across prologue and epilogue syscalls - but where??? Jan I will make the changes above and those to syscall.c since it looks like th= ey will fix the immediate problem I am having. My .config for the linux ke= rnel always has CONFIG_XENO_FASTSYNC=3D'y' even if I set it manually it is = reset to 'y' so the else !CONFIG_XENO_FASTSYNC is not a factor for my kerne= l build. I also added a saved_err to the user mode rt_cond_wait/wait_unitl= to return the prologue error code to the application. I will keep monitor= ing until you determine a better solution. Thanks for the help, -- John From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8CCC56.3000709@domain.hid> Date: Tue, 02 Mar 2010 09:29:10 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> <4B8C2490.1040604@domain.hid> <4B8C25B9.8090705@domain.hid> <4B8C26F7.3020306@domain.hid> <4B8C2797.2000501@domain.hid> <4B8C29E1.7070404@domain.hid> <4B8C2B3E.8020505@domain.hid> <4B8C2C35.6030006@domain.hid> <4B8C2FE6.5000406@domain.hid> <4B8C30DA.3000705@domain.hid> <4B8C33FC.3080806@domain.hid> <4B8C358E.9050303@domain.hid> In-Reply-To: <4B8C358E.9050303@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig964219BB891EFF1149B94948" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: "xenomai@xenomai.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig964219BB891EFF1149B94948 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Jan Kiszka wrote: >>> Jan Kiszka wrote: >>>> Gilles Chanteperdrix wrote: >>>>> Jan Kiszka wrote: >>>>>> Same issue exists in user space. And rt_cond_wait_inner needs fixi= ng. >>>>>> And then there is a spurious sign inversion: >>>>>> >>>>>> diff --git a/src/skins/native/cond.c b/src/skins/native/cond.c >>>>>> index 478321d..f874678 100644 >>>>>> --- a/src/skins/native/cond.c >>>>>> +++ b/src/skins/native/cond.c >>>>>> @@ -96,9 +96,9 @@ int rt_cond_wait_until(RT_COND *cond, RT_MUTEX *= mutex, RTIME timeout) >>>>>> &saved_lockcnt, XN_REALTIME, &timeout); >>>>>> =20 >>>>>> while (err =3D=3D -EINTR) >>>>>> - err =3D -XENOMAI_SKINCALL2(__native_muxid, >>>>>> - __native_cond_wait_epilogue, mutex, >>>>>> - saved_lockcnt); >>>>>> + err =3D XENOMAI_SKINCALL2(__native_muxid, >>>>>> + __native_cond_wait_epilogue, mutex, >>>>>> + saved_lockcnt); >>>>>> #endif /* !CONFIG_XENO_FASTSYNCH */ >>>>> Ok for the sign inversion, but in this case the status is Ok. We ca= ll >>>>> cond_wait_epilogue only if prologue returned -EINTR, and update the= >>>>> status, this is what we want. >>>>> >>>>> There is only one way out which will not break the ABI: do not call= >>>>> cond_wait_epilogue in the kernel-space cond_wait_prologue. >>>>> >>>> Unfortunately, that ABI is broken: If we get -ETIMEDOUT on cond wait= an >>>> -EINTR on mutex lock, we lose the former, don't we? >>>> >>>> If we can't find a workaround, I'm for breaking the ABI for this >>>> particular service - but let's search for an alternative first. >>>> >>> The only way around ABI changes: save the return code of cond_wait >>> /somewhere/ across prologue and epilogue syscalls - but where??? >>> >> In-kernel RT_TASK, that's probably the only place. Once >> __rt_cond_wait_epilogue has acquired the mutex (or failed without >> receiving a -EINTR), it can then pick up the original error that this >> task received from rt_cond_wait_prologue and return it. What do you th= ink? >=20 > I was thinking about the same idea, by using the xnthread errno. > However, it is not reentrant, in the sense that if a signal handler > emits a syscall which overrides this value, we are toast. Right. But that's the price someone unable/unwilling to update their user space libs along with the next kernel update will have to pay. I don't expect there are many, though, and the sketched scenario is fairly uncommon as well. So let's head this way: Install some workaround for the existing __rt_cond_wait_prologue syscall, but also introduce __rt_cond_wait_prologue2 which writes the cond-wait error code back like it already happens for lockcnt. That syscall is used by updated user space libs if they find it, otherwise we fall back to the old pattern. Jan --------------enig964219BB891EFF1149B94948 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkuMzFkACgkQitSsb3rl5xTEcwCg5mDyeWobc0Y/1bJ/fgAn6YW1 j0YAn0KRl26y7MXV3ktjJMthJqM8hbPx =Yiwg -----END PGP SIGNATURE----- --------------enig964219BB891EFF1149B94948-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8CCE15.5060706@domain.hid> Date: Tue, 02 Mar 2010 09:36:37 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> <4B8C2490.1040604@domain.hid> <4B8C25B9.8090705@domain.hid> <4B8C26F7.3020306@domain.hid> <4B8C2797.2000501@domain.hid> <4B8C29E1.7070404@domain.hid> <4B8C2B3E.8020505@domain.hid> <4B8C2C35.6030006@domain.hid> <4B8C2FE6.5000406@domain.hid> <4B8C30DA.3000705@domain.hid> <4B8C33FC.3080806@domain.hid> <4B8C358E.9050303@domain.hid> <4B8CCC56.3000709@domain.hid> In-Reply-To: <4B8CCC56.3000709@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6FC880998E86FA005B1867D0" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: "xenomai@xenomai.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6FC880998E86FA005B1867D0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Jan Kiszka wrote: >>>> Jan Kiszka wrote: >>>>> Gilles Chanteperdrix wrote: >>>>>> Jan Kiszka wrote: >>>>>>> Same issue exists in user space. And rt_cond_wait_inner needs fix= ing. >>>>>>> And then there is a spurious sign inversion: >>>>>>> >>>>>>> diff --git a/src/skins/native/cond.c b/src/skins/native/cond.c >>>>>>> index 478321d..f874678 100644 >>>>>>> --- a/src/skins/native/cond.c >>>>>>> +++ b/src/skins/native/cond.c >>>>>>> @@ -96,9 +96,9 @@ int rt_cond_wait_until(RT_COND *cond, RT_MUTEX = *mutex, RTIME timeout) >>>>>>> &saved_lockcnt, XN_REALTIME, &timeout); >>>>>>> =20 >>>>>>> while (err =3D=3D -EINTR) >>>>>>> - err =3D -XENOMAI_SKINCALL2(__native_muxid, >>>>>>> - __native_cond_wait_epilogue, mutex, >>>>>>> - saved_lockcnt); >>>>>>> + err =3D XENOMAI_SKINCALL2(__native_muxid, >>>>>>> + __native_cond_wait_epilogue, mutex, >>>>>>> + saved_lockcnt); >>>>>>> #endif /* !CONFIG_XENO_FASTSYNCH */ >>>>>> Ok for the sign inversion, but in this case the status is Ok. We c= all >>>>>> cond_wait_epilogue only if prologue returned -EINTR, and update th= e >>>>>> status, this is what we want. >>>>>> >>>>>> There is only one way out which will not break the ABI: do not cal= l >>>>>> cond_wait_epilogue in the kernel-space cond_wait_prologue. >>>>>> >>>>> Unfortunately, that ABI is broken: If we get -ETIMEDOUT on cond wai= t an >>>>> -EINTR on mutex lock, we lose the former, don't we? >>>>> >>>>> If we can't find a workaround, I'm for breaking the ABI for this >>>>> particular service - but let's search for an alternative first. >>>>> >>>> The only way around ABI changes: save the return code of cond_wait >>>> /somewhere/ across prologue and epilogue syscalls - but where??? >>>> >>> In-kernel RT_TASK, that's probably the only place. Once >>> __rt_cond_wait_epilogue has acquired the mutex (or failed without >>> receiving a -EINTR), it can then pick up the original error that this= >>> task received from rt_cond_wait_prologue and return it. What do you t= hink? >> I was thinking about the same idea, by using the xnthread errno. >> However, it is not reentrant, in the sense that if a signal handler >> emits a syscall which overrides this value, we are toast. >=20 > Right. But that's the price someone unable/unwilling to update their > user space libs along with the next kernel update will have to pay. I > don't expect there are many, though, and the sketched scenario is fairl= y > uncommon as well. >=20 > So let's head this way: Install some workaround for the existing > __rt_cond_wait_prologue syscall, but also introduce > __rt_cond_wait_prologue2 which writes the cond-wait error code back lik= e > it already happens for lockcnt. That syscall is used by updated user > space libs if they find it, otherwise we fall back to the old pattern. >=20 Ah, and as it looks like, we also need a __pthread_cond_wait_prologue2. Hope that's all then. Jan --------------enig6FC880998E86FA005B1867D0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkuMzhUACgkQitSsb3rl5xTw5wCg1JxuGiEOAUUs8vyUKhsRqV+i rmIAoLPn/daSjD+uVJtLonV1FE2vp/wD =fDAl -----END PGP SIGNATURE----- --------------enig6FC880998E86FA005B1867D0-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Charlton, John" Date: Tue, 2 Mar 2010 08:26:53 -0500 Message-ID: References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> <4B8C2490.1040604@domain.hid> <4B8C25B9.8090705@domain.hid> <4B8C26F7.3020306@domain.hid> <4B8C2797.2000501@domain.hid> <4B8C29E1.7070404@domain.hid> <4B8C2B3E.8020505@domain.hid> <4B8C2C35.6030006@domain.hid> <4B8C2FE6.5000406@domain.hid> <4B8C30DA.3000705@domain.hid> In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Charlton, John" , 'Jan Kiszka' , Gilles Chanteperdrix Cc: "xenomai@xenomai.org" While I was debugging this problem, it looked like I could change ksrc/skin= s/native/cond.c by modifying the rt_cond_wait_inner function as follows: --- xenomai-2.5.1_bak/ksrc/skins/native/cond.c 2010-01-15 19:09:31.0000000= 00 -0500 +++ xenomai-2.5.1/ksrc/skins/native/cond.c 2010-03-01 17:17:22.0000000= 00 -0500 @@ -468,15 +468,22 @@ { unsigned lockcnt; int err; + int err_save; err =3D rt_cond_wait_prologue(cond, mutex, &lockcnt, timeout_mode, timeout); + err_save =3D err; if(!err || err =3D=3D -ETIMEDOUT || err =3D=3D -EINTR) do { err =3D rt_cond_wait_epilogue(mutex, lockcnt); } while (err =3D=3D -EINTR); + if (err_save =3D=3D -ETIMEDOUT) + { + err =3D err_save; + } + return err; } /** When I made these changes and put a printk in rt_cond_wait_inner also the p= rintk did not get printed and the change above did not seem to make any dif= ference. So should I revert these changes or should they be made in additi= on to the syscall.c kernel and cond.c user space changes as follows: --- xenomai-2.5.1_bak/ksrc/skins/native/syscall.c 2010-02-01 20:01:09= .000000000 -0500 +++ xenomai-2.5.1/ksrc/skins/native/syscall.c 2010-03-01 16:13:20.0000000= 00 -0500 @@ -1869,8 +1869,12 @@ err =3D rt_cond_wait_prologue(cond, mutex, &lockcnt, timeout_mode, = timeout); - if (err =3D=3D 0 || err =3D=3D -ETIMEDOUT) - err =3D rt_cond_wait_epilogue(mutex, lockcnt); + if (err =3D=3D 0 || err =3D=3D -ETIMEDOUT) { + int loc_err =3D rt_cond_wait_epilogue(mutex, lockcnt); + if (loc_err < 0) + err =3D loc_err; + } + if (err =3D=3D -EINTR && __xn_reg_arg3(regs) && __xn_safe_copy_to_user((void __user *)__xn_reg_arg3(regs), --- xenomai-2.5.1_bak/src/skins/native/cond.c 2010-01-15 19:09:32.0000000= 00 -0500 +++ xenomai-2.5.1/src/skins/native/cond.c 2010-03-01 16:44:48.0000000= 00 -0500 @@ -41,7 +41,7 @@ = =20 = =20 int rt_cond_wait(RT_COND *cond, RT_MUTEX *mutex, RTIME timeout) = =20 { = =20 - int saved_lockcnt, err; = =20 + int saved_lockcnt, err, saved_err; = =20 = =20 #ifdef CONFIG_XENO_FASTSYNCH = =20 saved_lockcnt =3D mutex->lockcnt; = =20 @@ -49,7 +49,7 @@ = =20 err =3D XENOMAI_SKINCALL5(__native_muxid, = =20 __native_cond_wait_prologue, cond, mutex, = =20 NULL, XN_RELATIVE, &timeout); = =20 - = =20 + saved_err =3D err; = =20 while (err =3D=3D -EINTR) = =20 err =3D XENOMAI_SKINCALL2(__native_muxid, = =20 __native_cond_wait_epilogue, mutex,= =20 @@ -62,6 +62,7 @@ = =20 __native_cond_wait_prologue, cond, mutex, = =20 &saved_lockcnt, XN_RELATIVE, &timeout); = =20 = =20 + saved_err =3D err; = =20 while (err =3D=3D -EINTR) = =20 err =3D XENOMAI_SKINCALL2(__native_muxid, = =20 __native_cond_wait_epilogue, mutex,= =20 @@ -69,12 +70,12 @@ = =20 = =20 #endif /* !CONFIG_XENO_FASTSYNCH */ - return err; + return saved_err; } int rt_cond_wait_until(RT_COND *cond, RT_MUTEX *mutex, RTIME timeout) { - int saved_lockcnt, err; + int saved_lockcnt, err, saved_err; #ifdef CONFIG_XENO_FASTSYNCH saved_lockcnt =3D mutex->lockcnt; @@ -82,7 +83,7 @@ err =3D XENOMAI_SKINCALL5(__native_muxid, __native_cond_wait_prologue, cond, mutex, NULL, XN_REALTIME, &timeout); - + saved_err =3D err; while (err =3D=3D -EINTR) err =3D XENOMAI_SKINCALL2(__native_muxid, __native_cond_wait_epilogue, mutex, @@ -94,14 +95,14 @@ err =3D XENOMAI_SKINCALL5(__native_muxid, __native_cond_wait_prologue, cond, mutex, &saved_lockcnt, XN_REALTIME, &timeout); - + saved_err =3D err; while (err =3D=3D -EINTR) - err =3D -XENOMAI_SKINCALL2(__native_muxid, + err =3D XENOMAI_SKINCALL2(__native_muxid, __native_cond_wait_epilogue, mutex= , saved_lockcnt); #endif /* !CONFIG_XENO_FASTSYNCH */ - return err; + return saved_err; } int rt_cond_signal(RT_COND *cond) -----Original Message----- From: xenomai-help-bounces@domain.hid [mailto:xenomai-help-bounces@domain.hid] On= Behalf Of Jan Kiszka Sent: Monday, March 01, 2010 4:26 PM To: Gilles Chanteperdrix Cc: xenomai@xenomai.org Subject: Re: [Xenomai-help] mlockall error after calling mlockall() Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Same issue exists in user space. And rt_cond_wait_inner needs fixing. >>> And then there is a spurious sign inversion: >>> >>> diff --git a/src/skins/native/cond.c b/src/skins/native/cond.c index >>> 478321d..f874678 100644 >>> --- a/src/skins/native/cond.c >>> +++ b/src/skins/native/cond.c >>> @@ -96,9 +96,9 @@ int rt_cond_wait_until(RT_COND *cond, RT_MUTEX *mutex= , RTIME timeout) >>> &saved_lockcnt, XN_REALTIME, &timeout); >>> =20 >>> while (err =3D=3D -EINTR) >>> - err =3D -XENOMAI_SKINCALL2(__native_muxid, >>> - __native_cond_wait_epilogue, mutex, >>> - saved_lockcnt); >>> + err =3D XENOMAI_SKINCALL2(__native_muxid, >>> + __native_cond_wait_epilogue, mutex, >>> + saved_lockcnt); >>> #endif /* !CONFIG_XENO_FASTSYNCH */ >> Ok for the sign inversion, but in this case the status is Ok. We call=20 >> cond_wait_epilogue only if prologue returned -EINTR, and update the=20 >> status, this is what we want. >> >> There is only one way out which will not break the ABI: do not call=20 >> cond_wait_epilogue in the kernel-space cond_wait_prologue. >> >=20 > Unfortunately, that ABI is broken: If we get -ETIMEDOUT on cond wait=20 > an -EINTR on mutex lock, we lose the former, don't we? >=20 > If we can't find a workaround, I'm for breaking the ABI for this=20 > particular service - but let's search for an alternative first. >=20 The only way around ABI changes: save the return code of cond_wait /somewhe= re/ across prologue and epilogue syscalls - but where??? Jan I will make the changes above and those to syscall.c since it looks like th= ey will fix the immediate problem I am having. My .config for the linux ke= rnel always has CONFIG_XENO_FASTSYNC=3D'y' even if I set it manually it is = reset to 'y' so the else !CONFIG_XENO_FASTSYNC is not a factor for my kerne= l build. I also added a saved_err to the user mode rt_cond_wait/wait_unitl= to return the prologue error code to the application. I will keep monitor= ing until you determine a better solution. Thanks for the help, -- John _______________________________________________ Xenomai-help mailing list Xenomai-help@domain.hid https://mail.gna.org/listinfo/xenomai-help From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8D1B17.6000507@domain.hid> Date: Tue, 02 Mar 2010 15:05:11 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> <4B8C2490.1040604@domain.hid> <4B8C25B9.8090705@domain.hid> <4B8C26F7.3020306@domain.hid> <4B8C2797.2000501@domain.hid> <4B8C29E1.7070404@domain.hid> <4B8C2B3E.8020505@domain.hid> <4B8C2C35.6030006@domain.hid> <4B8C2FE6.5000406@domain.hid> <4B8C30DA.3000705@domain.hid> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Charlton, John" Cc: "xenomai@xenomai.org" Charlton, John wrote: > While I was debugging this problem, it looked like I could change ksrc/skins/native/cond.c by modifying the rt_cond_wait_inner function as follows: > --- xenomai-2.5.1_bak/ksrc/skins/native/cond.c 2010-01-15 19:09:31.000000000 -0500 > +++ xenomai-2.5.1/ksrc/skins/native/cond.c 2010-03-01 17:17:22.000000000 -0500 > @@ -468,15 +468,22 @@ > { > unsigned lockcnt; > int err; > + int err_save; > > err = rt_cond_wait_prologue(cond, mutex, &lockcnt, > timeout_mode, timeout); > > + err_save = err; > if(!err || err == -ETIMEDOUT || err == -EINTR) > do { > err = rt_cond_wait_epilogue(mutex, lockcnt); > } while (err == -EINTR); > > + if (err_save == -ETIMEDOUT) > + { > + err = err_save; > + } > + > return err; > } > /** That is for in-kernel cond_wait only. > > When I made these changes and put a printk in rt_cond_wait_inner also the printk did not get printed and the change above did not seem to make any difference. So should I revert these changes or should they be made in addition to the syscall.c kernel and cond.c user space changes as follows: > > --- xenomai-2.5.1_bak/ksrc/skins/native/syscall.c 2010-02-01 20:01:09.000000000 -0500 > +++ xenomai-2.5.1/ksrc/skins/native/syscall.c 2010-03-01 16:13:20.000000000 -0500 > @@ -1869,8 +1869,12 @@ > > err = rt_cond_wait_prologue(cond, mutex, &lockcnt, timeout_mode, timeout); > > - if (err == 0 || err == -ETIMEDOUT) > - err = rt_cond_wait_epilogue(mutex, lockcnt); > + if (err == 0 || err == -ETIMEDOUT) { > + int loc_err = rt_cond_wait_epilogue(mutex, lockcnt); > + if (loc_err < 0) > + err = loc_err; > + } > + > > if (err == -EINTR && __xn_reg_arg3(regs) > && __xn_safe_copy_to_user((void __user *)__xn_reg_arg3(regs), > > --- xenomai-2.5.1_bak/src/skins/native/cond.c 2010-01-15 19:09:32.000000000 -0500 > +++ xenomai-2.5.1/src/skins/native/cond.c 2010-03-01 16:44:48.000000000 -0500 > @@ -41,7 +41,7 @@ > > int rt_cond_wait(RT_COND *cond, RT_MUTEX *mutex, RTIME timeout) > { > - int saved_lockcnt, err; > + int saved_lockcnt, err, saved_err; > > #ifdef CONFIG_XENO_FASTSYNCH > saved_lockcnt = mutex->lockcnt; > @@ -49,7 +49,7 @@ > err = XENOMAI_SKINCALL5(__native_muxid, > __native_cond_wait_prologue, cond, mutex, > NULL, XN_RELATIVE, &timeout); > - > + saved_err = err; > while (err == -EINTR) > err = XENOMAI_SKINCALL2(__native_muxid, > __native_cond_wait_epilogue, mutex, > @@ -62,6 +62,7 @@ > __native_cond_wait_prologue, cond, mutex, > &saved_lockcnt, XN_RELATIVE, &timeout); > > + saved_err = err; > while (err == -EINTR) > err = XENOMAI_SKINCALL2(__native_muxid, > __native_cond_wait_epilogue, mutex, > @@ -69,12 +70,12 @@ > > #endif /* !CONFIG_XENO_FASTSYNCH */ > > - return err; > + return saved_err; > } > > int rt_cond_wait_until(RT_COND *cond, RT_MUTEX *mutex, RTIME timeout) > { > - int saved_lockcnt, err; > + int saved_lockcnt, err, saved_err; > > #ifdef CONFIG_XENO_FASTSYNCH > saved_lockcnt = mutex->lockcnt; > @@ -82,7 +83,7 @@ > err = XENOMAI_SKINCALL5(__native_muxid, > __native_cond_wait_prologue, cond, mutex, > NULL, XN_REALTIME, &timeout); > - > + saved_err = err; > while (err == -EINTR) > err = XENOMAI_SKINCALL2(__native_muxid, > __native_cond_wait_epilogue, mutex, > @@ -94,14 +95,14 @@ > err = XENOMAI_SKINCALL5(__native_muxid, > __native_cond_wait_prologue, cond, mutex, > &saved_lockcnt, XN_REALTIME, &timeout); > - > + saved_err = err; > while (err == -EINTR) > - err = -XENOMAI_SKINCALL2(__native_muxid, > + err = XENOMAI_SKINCALL2(__native_muxid, > __native_cond_wait_epilogue, mutex, > saved_lockcnt); > #endif /* !CONFIG_XENO_FASTSYNCH */ > > - return err; > + return saved_err; > } > > int rt_cond_signal(RT_COND *cond) > Yep, the easiest approach for you is to throw away the epilogue error for now (just loop over -EINTR). That's what 2.4.x did as well. We are still struggling with proper fixes for all corner cases. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux