Re: [Xenomai-core] Problems with gcc 4.6.0 (rt_task_shadow fails with ENOSYS)
On 27/07/11 20:55, Gilles Chanteperdrix wrote: The issue has been investigated, as explained in the mail you are quoting, it seems to be due to the implementation of pseudo-signals which as in xenomai 2.5 code and no longer is in xenomai-head code. In order to get confirmation, I am still waiting for someone to test xenomai-head with gcc 4.6. Thank you Gilles. I was checking if any confirmation of the cause of the bug was given, just to not waste the limited time I have to test this performing a test with known results. I'll compile xenomai-head with gcc 4.6 and report my results. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Exception #14
On Wed, 2011-07-27 at 20:52 +0200, Gilles Chanteperdrix wrote:
On 07/26/2011 09:36 AM, zenati wrote:
Dear,
I'm developping the skin Arinc 653 for Xenomai. I'm trying to run
process with my skin but I have an exception :
Xenomai: suspending kernel thread d8824c40 ('�') at 0xb76dbdfc after
exception #14
What is the exception 14 ? Have you an idea how can I solve them?
Thank you for your attention and for your help.
Sincerely,
The meaning of the fault number depends on the platform you are using,
see /proc/xenomai/faults for human readable messages for your platform.
I guess this is PF on x86, and this thread's TCB in kernel space looks
badly trashed. You should probably check the behavior of your Xenomai
kernel threads wrt memory writes, and possibly for stack overflows as
well.
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] Fixes for domain migration races
On 2011-07-27 20:44, Gilles Chanteperdrix wrote: On 07/19/2011 08:44 AM, Jan Kiszka wrote: Hi, I've just uploaded my upstream queue that mostly deals with the various races I found in the domain migration code. One of my concerns raised earlier turned out to be for no reason: We do not allow Linux to wake up a task that has TASK_ATOMICSWITCH set. So the deletion race can indeed be fixed by the patch I sent earlier. So, I still have the same question: is not the solution of synchronizing with the gatekeeper as soon as we get out from schedule in secondary mode better than waiting the task_exit callback? It looks more correct, and it avoids gksched. Yes, I was on the wrong track /wrt wakeup races during the early migration phase. It is a possible and valid scenario that the task returns from schedule() without being migrated. That can only happen if a signal was queued in the meantime. The task will not be woken up again, that is prevented by ATOMICSWITCH, but it will check for pending signals itself before falling asleep. In that case it will enter TASK_RUNNING again and return either before the gatekeeper could run or, on SMP, may continue in parallel on a different CPU. What saves us now from the fatal scenario that both the task runs and the gatekeeper resumes its Xenomai part is that TASK_INTERRUPTIBLE state was left. And if we wait for the gatekeeper to realize this like you suggested, we ensure that neither the object is deleted too early nor TASK_INTERRUPTIBLE is reentered again by doing Linux work. I've cleaned up my queue correspondingly and just pushed it. Thanks, Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] __wrap_clock_gettime
On 2011-07-27 20:49, Gilles Chanteperdrix wrote: On 07/22/2011 05:04 PM, Jan Kiszka wrote: Hi Gilles, pulling assert_context.c into the common libxenomai created a problem around picking the right __wrap_clock_gettime. As libpthread_rt depends on libxenomai, the latter is loaded first and defines the debug version of __wrap_clock_gettime as the default. There is no chance to pull the posix skin implementation. I don't have a nice idea yes how to resolve this. Options are: - drop __wrap_clock_gettime from assert_context.c (affects any skin user != posix) - put assert_context stuff into separate library again - put __wrap_clock_gettime in all skin libs != posix I'm favoring the simplest approach ATM, ie. the first one. Other ideas? I agree, but I would have thought __attriibute__((weak)) takes care of this issue. The point is that once you have pulled in that weak symbol into a process, the dynamic loader won't update it if a non-weak version is pulled in via dlopen. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] __wrap_clock_gettime
On 2011-07-28 18:56, Jan Kiszka wrote: On 2011-07-27 20:49, Gilles Chanteperdrix wrote: On 07/22/2011 05:04 PM, Jan Kiszka wrote: Hi Gilles, pulling assert_context.c into the common libxenomai created a problem around picking the right __wrap_clock_gettime. As libpthread_rt depends on libxenomai, the latter is loaded first and defines the debug version of __wrap_clock_gettime as the default. There is no chance to pull the posix skin implementation. I don't have a nice idea yes how to resolve this. Options are: - drop __wrap_clock_gettime from assert_context.c (affects any skin user != posix) - put assert_context stuff into separate library again - put __wrap_clock_gettime in all skin libs != posix I'm favoring the simplest approach ATM, ie. the first one. Other ideas? I agree, but I would have thought __attriibute__((weak)) takes care of this issue. The point is that once you have pulled in that weak symbol into a process, the dynamic loader won't update it if a non-weak version is pulled in via dlopen. Mmh, maybe we have a fourth option: disabling the weak version if CONFIG_XENO_LIBS_DLOPEN is set. OTOH, the correlation may not be obvious to users. So that result could be even more confusing. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] gdb and lost priority
Hi, i know that debugging a user application with gdb can broke the task priority but also if i insert no breakpoints ? I explain better, in the 2.5.6 version a see that if i launch an application with gdbserver a task that has an inferior priority execute while another task with a high priority is running. It's possible or the task has switched on secondary mode ? Thanks for all ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
