[Xenomai-core] rt_task_delete or rt_task_suspend strange behavior
Hi, i'm using xenomai 2.5.6 stable implemented for Marvell mv78xx on Arm. I have a very strange behaviour. I have 60 tasks and some tasks delete other tasks. In the case that one task delete/suspend a task that is just deleted/suspended, the next delete/suspend kill the wrong task and if i print the sequence i see that rt_task_delete or rt_task_suspend returned the value -3 (-ESRCH) that is NOT documented in the manual. Unfortunately i can't send the source code because it's very large and i cannot see the problem with a small program. Any ideas ? Thanks for all ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] gdb and breakpoint
On 07/20/2011 06:58 PM, Roberto Bielli wrote: > Hi, > > i have little questions. > 1 .A GDB breakpoint in a xenomai task switch to secodary mode the task > or the entire application ? > 2. when i run the application that is halted on a breakpoint, when the > xenomai scheduler enter to restore the task in primary mode, how does ? > (i can say with assurancethe any other task goes before me when i > release the breakpoint ) Hi, I have read your post several times and failed to understand your question. Do you have a test code which behaves unexpectedly with gdb and which you would care to post? Regards. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problems with gcc 4.6.0 (rt_task_shadow fails with ENOSYS)
On 07/26/2011 02:09 PM, Daniele Nicolodi wrote: > On 11/07/11 20:43, Gilles Chanteperdrix wrote: >> On 07/07/2011 11:47 PM, Anders Blomdell wrote: >>> When compiling kernel 2.6.37.3 and xenomai 2.5.6 with "gcc version 4.6.0 >>> 20110530 (Red Hat 4.6.0-9) (GCC)", programs fail with -ENOSYS in >>> rt_task_shadow. If compiled with "gcc version 4.5.1 20100924 (Red Hat >>> 4.5.1-4) (GCC)" everything works as expected. >> >> I think it is due to the modifications of syscall.h I made to implement >> pseudo-signals handling, which implementation was never finished, and >> removed in xenomai-head. Could you try xenomai-head to see if you get >> the failure? I tried backporting it, but the code evolved too much in >> both repositories, the backport needs to spend some time on it, so, I >> would like to know whether it is really needed. > > Has this issue been investigated further? I may have the occasion to try > again to compile a Xenomai kernel with gcc 4.6 this week and I would > like to know where to start to debug and solve this issue. > > Thank you. Cheers, 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. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Exception #14
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.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] __wrap_clock_gettime
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. -- Gilles. ___ 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 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. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Debugging Xenomai kernel
On 07/27/2011 06:16 PM, Jan Kiszka wrote: On 2011-07-27 18:13, zenati wrote: On 07/27/2011 02:12 PM, Jan Kiszka wrote: On 2011-07-27 14:01, zenati wrote: On 07/27/2011 11:23 AM, Jan Kiszka wrote: On 2011-07-26 13:54, zenati wrote: Dear, I'm trying to debug Xenomai kernel with GDB and Qemu. QEMU in emulation or KVM mode? I'm using Qemu in emulation mode. What's your target arch? x84-64, x86-32, or some ARM or PPC etc. x86-32 So, I launch Xenomai in Qemu and make it waiting for GDB. Then I start GDB and connect them to Qemu, make breakpoint at the desired function to debug and start Xenomai. If the function belongs to the linux kernel, the execution stop at the breakpoint. But, if the function belongs to the Xenomai nucleus, GDB recognize the breakpoint at the execution but don't stop. Is Xenomai built as module or part of the main kernel image? The latter is simpler to handle as you don't have to deal with modules as symbol sources, find out their addresses, and load them at the right location. Xenomai is built as a part of the main kernel. OK. Check during runtime of the guest if the disassembly at the desired breakpoint address matches the compiled code. Maybe there is some accidental discrepancy. The breakpoints match correctly the compiled code. Anyway, it must stop at the breakpoint. No? ...if the guest actually executes that address. I haven't used x86 QEMU in emulation mode for quite a while to debug something. Maybe we have a regression there. What's your QEMU version? QEMU PC emulator version 0.12.3 (qemu-kvm-0.12.3), Copyright (c) 2003-2008 Fabrice Bellard Do you have a chance to test with a KVM host? It's faster anyway. I never used it before... But I'm ready to test it if there is no others ways to debug. Jan Omar ZENATi ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Debugging Xenomai kernel
On 2011-07-27 18:13, zenati wrote: > On 07/27/2011 02:12 PM, Jan Kiszka wrote: >> On 2011-07-27 14:01, zenati wrote: >>> On 07/27/2011 11:23 AM, Jan Kiszka wrote: On 2011-07-26 13:54, zenati wrote: > Dear, > > I'm trying to debug Xenomai kernel with GDB and Qemu. QEMU in emulation or KVM mode? >>> I'm using Qemu in emulation mode. >> What's your target arch? x84-64, x86-32, or some ARM or PPC etc. > x86-32 > So, I launch > Xenomai in Qemu and make it waiting for GDB. Then I start GDB and > connect them to Qemu, make breakpoint at the desired function to debug > and start Xenomai. If the function belongs to the linux kernel, the > execution stop at the breakpoint. But, if the function belongs to the > Xenomai nucleus, GDB recognize the breakpoint at the execution but don't > stop. Is Xenomai built as module or part of the main kernel image? The latter is simpler to handle as you don't have to deal with modules as symbol sources, find out their addresses, and load them at the right location. >>> Xenomai is built as a part of the main kernel. >> OK. Check during runtime of the guest if the disassembly at the desired >> breakpoint address matches the compiled code. Maybe there is some >> accidental discrepancy. > The breakpoints match correctly the compiled code. Anyway, it must stop > at the breakpoint. No? ...if the guest actually executes that address. I haven't used x86 QEMU in emulation mode for quite a while to debug something. Maybe we have a regression there. What's your QEMU version? Do you have a chance to test with a KVM host? It's faster anyway. 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] Debugging Xenomai kernel
On 07/27/2011 02:12 PM, Jan Kiszka wrote: On 2011-07-27 14:01, zenati wrote: On 07/27/2011 11:23 AM, Jan Kiszka wrote: On 2011-07-26 13:54, zenati wrote: Dear, I'm trying to debug Xenomai kernel with GDB and Qemu. QEMU in emulation or KVM mode? I'm using Qemu in emulation mode. What's your target arch? x84-64, x86-32, or some ARM or PPC etc. x86-32 So, I launch Xenomai in Qemu and make it waiting for GDB. Then I start GDB and connect them to Qemu, make breakpoint at the desired function to debug and start Xenomai. If the function belongs to the linux kernel, the execution stop at the breakpoint. But, if the function belongs to the Xenomai nucleus, GDB recognize the breakpoint at the execution but don't stop. Is Xenomai built as module or part of the main kernel image? The latter is simpler to handle as you don't have to deal with modules as symbol sources, find out their addresses, and load them at the right location. Xenomai is built as a part of the main kernel. OK. Check during runtime of the guest if the disassembly at the desired breakpoint address matches the compiled code. Maybe there is some accidental discrepancy. The breakpoints match correctly the compiled code. Anyway, it must stop at the breakpoint. No? Jan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Debugging Xenomai kernel
On 2011-07-27 14:01, zenati wrote: > On 07/27/2011 11:23 AM, Jan Kiszka wrote: >> On 2011-07-26 13:54, zenati wrote: >>> Dear, >>> >>> I'm trying to debug Xenomai kernel with GDB and Qemu. >> QEMU in emulation or KVM mode? >> > I'm using Qemu in emulation mode. What's your target arch? x84-64, x86-32, or some ARM or PPC etc.? >>> So, I launch >>> Xenomai in Qemu and make it waiting for GDB. Then I start GDB and >>> connect them to Qemu, make breakpoint at the desired function to debug >>> and start Xenomai. If the function belongs to the linux kernel, the >>> execution stop at the breakpoint. But, if the function belongs to the >>> Xenomai nucleus, GDB recognize the breakpoint at the execution but don't >>> stop. >> Is Xenomai built as module or part of the main kernel image? The latter >> is simpler to handle as you don't have to deal with modules as symbol >> sources, find out their addresses, and load them at the right location. >> > Xenomai is built as a part of the main kernel. OK. Check during runtime of the guest if the disassembly at the desired breakpoint address matches the compiled code. Maybe there is some accidental discrepancy. 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] Debugging Xenomai kernel
On 07/27/2011 11:23 AM, Jan Kiszka wrote: On 2011-07-26 13:54, zenati wrote: Dear, I'm trying to debug Xenomai kernel with GDB and Qemu. QEMU in emulation or KVM mode? I'm using Qemu in emulation mode. So, I launch Xenomai in Qemu and make it waiting for GDB. Then I start GDB and connect them to Qemu, make breakpoint at the desired function to debug and start Xenomai. If the function belongs to the linux kernel, the execution stop at the breakpoint. But, if the function belongs to the Xenomai nucleus, GDB recognize the breakpoint at the execution but don't stop. Is Xenomai built as module or part of the main kernel image? The latter is simpler to handle as you don't have to deal with modules as symbol sources, find out their addresses, and load them at the right location. Xenomai is built as a part of the main kernel. Is it possible to debug Xenomai with GDB and Qemu? Definitely. Is it the good way to debug? Thank you for your attention and your help. Sincerely, Omar ZENATI Jan Omar ZENATI ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Debugging Xenomai kernel
On 2011-07-26 13:54, zenati wrote: > Dear, > > I'm trying to debug Xenomai kernel with GDB and Qemu. QEMU in emulation or KVM mode? > So, I launch > Xenomai in Qemu and make it waiting for GDB. Then I start GDB and > connect them to Qemu, make breakpoint at the desired function to debug > and start Xenomai. If the function belongs to the linux kernel, the > execution stop at the breakpoint. But, if the function belongs to the > Xenomai nucleus, GDB recognize the breakpoint at the execution but don't > stop. Is Xenomai built as module or part of the main kernel image? The latter is simpler to handle as you don't have to deal with modules as symbol sources, find out their addresses, and load them at the right location. > > Is it possible to debug Xenomai with GDB and Qemu? Definitely. > Is it the good way to debug? > > Thank you for your attention and your help. > Sincerely, > > Omar ZENATI 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
