Re: [Xenomai-help] Frequency downscaling of new intel CPU
> On Mon, Oct 3, 2011 at 4:39 AM, Petr Cervenka wrote: > > Any ideas that could help me? > What about looking at /proc/cpuinfo while running your system ? If you > see that the speed is not the maximal, indeed, the frequency scaling > system changes the speed of the processor. /proc/cpuinfo shows always full frequency clock (3292.500 MHz) More details: 1) two xenomai tasks are running with 100us period (controlled by external hardware) 2) one task communicates with hardware (receives data via rtnet) and passes them by rt_queue to the second task (on another core) 3) second task does some computations and returns processed data to the first task 4) first task sends data to hardware The problem is that during waiting on new data from hw CPU puts itself in some deeper idle state with lower frequency. A then, when the data are available, it slowly wakes up to normal state. In other words: computation takes longer time than it takes on older computers (depends on overall CPU load). When some artificial 100% load is running on another core, the computation is as fast as it should be. Petr ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Frequency downscaling of new intel CPU
2011/10/4 Petr Cervenka : > >> On Mon, Oct 3, 2011 at 4:39 AM, Petr Cervenka wrote: > >> > Any ideas that could help me? > >> What about looking at /proc/cpuinfo while running your system ? If you >> see that the speed is not the maximal, indeed, the frequency scaling >> system changes the speed of the processor. > > /proc/cpuinfo shows always full frequency clock (3292.500 MHz) > > More details: > 1) two xenomai tasks are running with 100us period (controlled by external > hardware) > 2) one task communicates with hardware (receives data via rtnet) and passes > them by rt_queue to the second task (on another core) > 3) second task does some computations and returns processed data to the first > task > 4) first task sends data to hardware > > The problem is that during waiting on new data from hw CPU puts itself in > some deeper idle state with lower frequency. A then, when the data are > available, it slowly wakes up to normal state. > In other words: computation takes longer time than it takes on older > computers (depends on overall CPU load). > When some artificial 100% load is running on another core, the computation is > as fast as it should be. Then may be you should ask your computer provider (for the BIOS main board) and/or intel representative (for more info. about Sandy Bridge dynamic frequency features) whether if it's an expected behavior of this kind of processor to behave like that? I think it would be nice to know because you assume the processor is "slowing down" but this cannot be stated from usual way monitoring processor frequency. That said, from this small pieces of informations: http://www.anandtech.com/show/3922/intels-sandy-bridge-architecture-exposed/7 Sandy Bridge seems to be a deterministic computing nightmare, unless all those nice features (TurboBoost and the like) could be disabled ... I mean for sure not theoretically. May be the BIOS is flawed and it is not disabling the dynamic frequency features properly? -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
[Xenomai-help] xenomai-forge: ELF symbol interposition problems
Hi, We're experiencing problems with ELF symbol interposition with xenomai forge. The symbol mem_alloc, declared in include/copperplate/heapobj.h and defined in lib/copperplate/heapobj-malloc.c, is also present in our own executable. When linking our objects with the xenomai-forge libraries, the symbols from our objects take precedence. As a result, when heapobj_alloc() calls mem_alloc(), it calls the mem_alloc from our application code, which of course is totally incompatible. There isn't really a good solution to this problem. I think it will be necessary to make sure that all exported functions from the xenomai-forge libraries have a unique name. The name 'mem_alloc' (and many of the functions in lib/copperplate/heapobj-malloc.c) is too common. Another solution may be to mark certain symbols as hidden, provided they do not need to be exported to applications. Some references to it appear here: http://www.airs.com/blog/archives/307 What is your view on this? Thanks, Thomas ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] xenomai-forge: ELF symbol interposition problems
On Tue, 2011-10-04 at 09:40 +0200, Thomas De Schampheleire wrote: > Hi, > > We're experiencing problems with ELF symbol interposition with xenomai forge. > The symbol mem_alloc, declared in include/copperplate/heapobj.h and > defined in lib/copperplate/heapobj-malloc.c, is also present in our > own executable. When linking our objects with the xenomai-forge > libraries, the symbols from our objects take precedence. > > As a result, when heapobj_alloc() calls mem_alloc(), it calls the > mem_alloc from our application code, which of course is totally > incompatible. > > There isn't really a good solution to this problem. I think it will be > necessary to make sure that all exported functions from the > xenomai-forge libraries have a unique name. The name 'mem_alloc' (and > many of the functions in lib/copperplate/heapobj-malloc.c) is too > common. > > Another solution may be to mark certain symbols as hidden, provided > they do not need to be exported to applications. Some references to it > appear here: > http://www.airs.com/blog/archives/307 > > What is your view on this? Restricted visibility won't work the way we want, since we have references to these symbols from static inlines callable from application code. We need a rename. > > Thanks, > Thomas > > ___ > Xenomai-help mailing list > Xenomai-help@gna.org > https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] xenomai-forge: ELF symbol interposition problems
Hi, On Tue, Oct 4, 2011 at 9:48 AM, Philippe Gerum wrote: > On Tue, 2011-10-04 at 09:40 +0200, Thomas De Schampheleire wrote: >> Hi, >> >> We're experiencing problems with ELF symbol interposition with xenomai forge. >> The symbol mem_alloc, declared in include/copperplate/heapobj.h and >> defined in lib/copperplate/heapobj-malloc.c, is also present in our >> own executable. When linking our objects with the xenomai-forge >> libraries, the symbols from our objects take precedence. >> >> As a result, when heapobj_alloc() calls mem_alloc(), it calls the >> mem_alloc from our application code, which of course is totally >> incompatible. >> >> There isn't really a good solution to this problem. I think it will be >> necessary to make sure that all exported functions from the >> xenomai-forge libraries have a unique name. The name 'mem_alloc' (and >> many of the functions in lib/copperplate/heapobj-malloc.c) is too >> common. >> >> Another solution may be to mark certain symbols as hidden, provided >> they do not need to be exported to applications. Some references to it >> appear here: >> http://www.airs.com/blog/archives/307 >> >> What is your view on this? > > Restricted visibility won't work the way we want, since we have > references to these symbols from static inlines callable from > application code. We need a rename. In the specific case I encountered, renaming the five mem_ functions worked for me. I added 'heapobj_' as prefix for: mem_destroy, mem_extend, mem_alloc, mem_free and mem_inquire. I changed them in include/copperplate/heapobj.h lib/copperplate/heapobj-malloc.c but I assume the same should be done in the other heapobj-* files. Best regards, Thomas ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] xenomai-forge: ELF symbol interposition problems
On Tue, 2011-10-04 at 10:28 +0200, Thomas De Schampheleire wrote: > Hi, > > On Tue, Oct 4, 2011 at 9:48 AM, Philippe Gerum wrote: > > On Tue, 2011-10-04 at 09:40 +0200, Thomas De Schampheleire wrote: > >> Hi, > >> > >> We're experiencing problems with ELF symbol interposition with xenomai > >> forge. > >> The symbol mem_alloc, declared in include/copperplate/heapobj.h and > >> defined in lib/copperplate/heapobj-malloc.c, is also present in our > >> own executable. When linking our objects with the xenomai-forge > >> libraries, the symbols from our objects take precedence. > >> > >> As a result, when heapobj_alloc() calls mem_alloc(), it calls the > >> mem_alloc from our application code, which of course is totally > >> incompatible. > >> > >> There isn't really a good solution to this problem. I think it will be > >> necessary to make sure that all exported functions from the > >> xenomai-forge libraries have a unique name. The name 'mem_alloc' (and > >> many of the functions in lib/copperplate/heapobj-malloc.c) is too > >> common. > >> > >> Another solution may be to mark certain symbols as hidden, provided > >> they do not need to be exported to applications. Some references to it > >> appear here: > >> http://www.airs.com/blog/archives/307 > >> > >> What is your view on this? > > > > Restricted visibility won't work the way we want, since we have > > references to these symbols from static inlines callable from > > application code. We need a rename. > > In the specific case I encountered, renaming the five mem_ functions > worked for me. I added 'heapobj_' as prefix for: > mem_destroy, mem_extend, mem_alloc, mem_free and mem_inquire. > > I changed them in > include/copperplate/heapobj.h > lib/copperplate/heapobj-malloc.c > > but I assume the same should be done in the other heapobj-* files. Yes, this is what I'll commit I think, only adding double underscores prefix to clearly state the fact that these are internals and should not be called directly. > > Best regards, > Thomas -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
[Xenomai-help] Kernel configuration suggestions/hints
Dear all, I am currently building a customized kernel to build a real-time application. At this time, the requirement is very basic : I have one periodic task in userland that acquires data from an analogy card (ni6071e) with a 1ms period/deadline. At that time, the task miss one deadline at each period, meaning that the code is executed in 2ms instead of 1ms (and so, the deadline expires). So, I configured my kernel without power management and with a timer at 1000Hz and a tickless system (see variables below). However I would like to know if there are other relevant configuration parameters that may influence the scheduling of xenomai tasks so that I can make sure that my application meets its requirements. If anyone has a feedback about kernel configuration in that scope, it might be really useful ! In addition, depending on your answer, it may be also good to report good practices about the kernel configuration on the wiki, what do you think about it ? Thanks for any suggestion, Kernel configuration variables: CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_PREEMPT=y CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_PM is not set CONFIG_SFI is not set CONFIG_CPU_FREQ is not set CONFIG_CPU_IDLE is not set ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
[Xenomai-help] Using the analogy layer in kernel tasks
Dear all, I would like to know if somebody already tried to migrate code of user-space tasks that use the analogy layer to the kernel. As kernel tasks may run faster than user-space, it might help to speed application execution. However, when trying to load the application, I encounter the following errors (see below). So, is the analogy layer designed to be used in kernel tasks ? If yes, which functions are allowed, which are forbidden (and in that case, it would be useful to disable functions in /lib/modules/KERNEL_VERSION/build/include/xenomai/analogy/ headers) ? Thanks you for any comment/help regarding that topic, Best regards, [ 1560.700937] test_pcimio: Unknown symbol a4l_open (err 0) [ 1560.701100] test_pcimio: Unknown symbol __floatsidf (err 0) [ 1560.701634] test_pcimio: Unknown symbol __ltdf2 (err 0) [ 1560.701863] test_pcimio: Unknown symbol a4l_get_chinfo (err 0) [ 1560.702501] test_pcimio: Unknown symbol __fixdfsi (err 0) [ 1560.702625] test_pcimio: Unknown symbol a4l_fill_desc (err 0) [ 1560.702855] test_pcimio: Unknown symbol a4l_snd_insnlist (err 0) [ 1560.702977] test_pcimio: Unknown symbol a4l_rawtod (err 0) [ 1560.703099] test_pcimio: Unknown symbol a4l_get_rnginfo (err 0) [ 1560.703682] test_pcimio: Unknown symbol a4l_find_range (err 0) [ 1615.399804] test_pcimio: Unknown symbol a4l_open (err 0) [ 1615.399944] test_pcimio: Unknown symbol __floatsidf (err 0) [ 1615.400073] test_pcimio: Unknown symbol __ltdf2 (err 0) [ 1615.400288] test_pcimio: Unknown symbol a4l_get_chinfo (err 0) [ 1615.400288] test_pcimio: Unknown symbol __fixdfsi (err 0) [ 1615.400288] test_pcimio: Unknown symbol a4l_fill_desc (err 0) [ 1615.400786] test_pcimio: Unknown symbol a4l_snd_insnlist (err 0) [ 1615.400910] test_pcimio: Unknown symbol a4l_rawtod (err 0) [ 1615.401032] test_pcimio: Unknown symbol a4l_get_rnginfo (err 0) [ 1615.401173] test_pcimio: Unknown symbol a4l_find_range (err 0) ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Using the analogy layer in kernel tasks
On Tue, 2011-10-04 at 04:48 -0400, Julien Delange wrote: > Dear all, > > I would like to know if somebody already tried to migrate code of > user-space tasks that use the analogy layer to the kernel. As kernel > tasks may run faster than user-space, No, it won't run that faster, it might switch contexts faster between threads, but that assumption is a fairly red herring now on most architectures, especially on modern x86. The bottom line is that you won't gain an order in magnitude in performance figures by moving to kernel land. i.e. saving 200 ns to 40 us depending on your arch on typical context switch time and maybe some more in avoiding user/supervisor transitions won't fix your 1 ms jitter. However, for sure you will lose the regular programming model, debugging facilities, memory protection and so on. Moving your application code to user space would also kill your upgrade path to Xenomai 3. The upcoming architecture clearly pushes application code to userland, keeping kernel land for RTDM drivers only. Running applications in kernel space is _always_ a really bad idea, for multiple reasons. To sum up, I would rather try to find out the cause of the ms-range jittery, which is clearly pathological over a dual kernel system. However, if your application can't cope with a few microseconds bounded jitter introduced by userland, then maybe it's time reconsidering the current option of running two kernels (linux and xenomai), which permanently conflict on accessing physical resources (e.g. cache, CPU, interrupt controller, buses), all on the same hardware. In that case, maybe what one needs is a dedicated real-time hardware running a single image RTOS, not a dual kernel system including a resource-hungry GPOS. > it might help to speed > application execution. However, when trying to load the application, I > encounter the following errors (see below). So, is the analogy layer > designed to be used in kernel tasks ? If yes, which functions are > allowed, which are forbidden (and in that case, it would be useful to > disable functions in > /lib/modules/KERNEL_VERSION/build/include/xenomai/analogy/ headers) ? > > Thanks you for any comment/help regarding that topic, > > Best regards, > > > > [ 1560.700937] test_pcimio: Unknown symbol a4l_open (err 0) > [ 1560.701100] test_pcimio: Unknown symbol __floatsidf (err 0) > [ 1560.701634] test_pcimio: Unknown symbol __ltdf2 (err 0) > [ 1560.701863] test_pcimio: Unknown symbol a4l_get_chinfo (err 0) > [ 1560.702501] test_pcimio: Unknown symbol __fixdfsi (err 0) > [ 1560.702625] test_pcimio: Unknown symbol a4l_fill_desc (err 0) > [ 1560.702855] test_pcimio: Unknown symbol a4l_snd_insnlist (err 0) > [ 1560.702977] test_pcimio: Unknown symbol a4l_rawtod (err 0) > [ 1560.703099] test_pcimio: Unknown symbol a4l_get_rnginfo (err 0) > [ 1560.703682] test_pcimio: Unknown symbol a4l_find_range (err 0) > [ 1615.399804] test_pcimio: Unknown symbol a4l_open (err 0) > [ 1615.399944] test_pcimio: Unknown symbol __floatsidf (err 0) > [ 1615.400073] test_pcimio: Unknown symbol __ltdf2 (err 0) > [ 1615.400288] test_pcimio: Unknown symbol a4l_get_chinfo (err 0) > [ 1615.400288] test_pcimio: Unknown symbol __fixdfsi (err 0) > [ 1615.400288] test_pcimio: Unknown symbol a4l_fill_desc (err 0) > [ 1615.400786] test_pcimio: Unknown symbol a4l_snd_insnlist (err 0) > [ 1615.400910] test_pcimio: Unknown symbol a4l_rawtod (err 0) > [ 1615.401032] test_pcimio: Unknown symbol a4l_get_rnginfo (err 0) > [ 1615.401173] test_pcimio: Unknown symbol a4l_find_range (err 0) > > ___ > Xenomai-help mailing list > Xenomai-help@gna.org > https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
[Xenomai-help] xenomai-forge [psos] t_start segmentation fault when args == NULL
Hi,
In the xenomai-forge psos library, t_start() does not allow a NULL
args pointer, while I think this is allowed in PSOS.
The below code changes fix the problem.
(Note that I realize this mail is not formatted as a proper patch; if
you prefer patches for these small changes, let me know).
Best regards,
Thomas
diff --git a/lib/psos/task.c b/lib/psos/task.c
--- a/lib/psos/task.c
+++ b/lib/psos/task.c
@@ -335,10 +335,17 @@ u_long t_start(u_long tid,
return ret;
task->args.entry = entry;
- task->args.arg0 = args[0];
- task->args.arg1 = args[1];
- task->args.arg2 = args[2];
- task->args.arg3 = args[3];
+ if (args) {
+ task->args.arg0 = args[0];
+ task->args.arg1 = args[1];
+ task->args.arg2 = args[2];
+ task->args.arg3 = args[3];
+ } else {
+ task->args.arg0 = 0;
+ task->args.arg1 = 0;
+ task->args.arg2 = 0;
+ task->args.arg3 = 0;
+ }
task->mode = mode;
threadobj_start(&task->thobj);
put_psos_task(task);
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
[Xenomai-help] xenomai-forge: enable-smp useful?
Hi, The original Xenomai userland had to be configured explicitly with --enable-smp if the kernel was SMP capable. The xenomai-forge configure script still accepts this parameter. Are we correctly assuming that this flag is no longer needed for xenomai-forge? Thanks, Thomas ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] xenomai-forge [psos] t_start segmentation fault when args == NULL
On Tue, 2011-10-04 at 11:42 +0200, Thomas De Schampheleire wrote:
> Hi,
>
> In the xenomai-forge psos library, t_start() does not allow a NULL
> args pointer, while I think this is allowed in PSOS.
Yes, I think so as well. Good catch.
> The below code changes fix the problem.
> (Note that I realize this mail is not formatted as a proper patch; if
> you prefer patches for these small changes, let me know).
I can deal with the patch below. However, git-generated patches are
preferred.
>
> Best regards,
> Thomas
>
> diff --git a/lib/psos/task.c b/lib/psos/task.c
> --- a/lib/psos/task.c
> +++ b/lib/psos/task.c
> @@ -335,10 +335,17 @@ u_long t_start(u_long tid,
> return ret;
>
> task->args.entry = entry;
> - task->args.arg0 = args[0];
> - task->args.arg1 = args[1];
> - task->args.arg2 = args[2];
> - task->args.arg3 = args[3];
> + if (args) {
> + task->args.arg0 = args[0];
> + task->args.arg1 = args[1];
> + task->args.arg2 = args[2];
> + task->args.arg3 = args[3];
> + } else {
> + task->args.arg0 = 0;
> + task->args.arg1 = 0;
> + task->args.arg2 = 0;
> + task->args.arg3 = 0;
> + }
> task->mode = mode;
> threadobj_start(&task->thobj);
> put_psos_task(task);
>
> ___
> Xenomai-help mailing list
> Xenomai-help@gna.org
> https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] xenomai-forge: enable-smp useful?
On Tue, 2011-10-04 at 11:49 +0200, Thomas De Schampheleire wrote: > Hi, > > The original Xenomai userland had to be configured explicitly with > --enable-smp if the kernel was SMP capable. The xenomai-forge > configure script still accepts this parameter. > > Are we correctly assuming that this flag is no longer needed for > xenomai-forge? This has been inherited from Xenomai 2.x. This flag is accepted whenever you want to compile for the Cobalt core (i.e. the dual kernel mode), in which case it is used as a hint for internal tuning. But since you run over the Mercury core in single image mode, it is useless so far. > > Thanks, > Thomas > > ___ > Xenomai-help mailing list > Xenomai-help@gna.org > https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] xenomai-forge [psos] t_start segmentation fault when args == NULL
> -Original Message- > On Behalf Of Thomas De Schampheleire > Sent: Tuesday, October 04, 2011 11:42 AM > ... > In the xenomai-forge psos library, t_start() does not allow a NULL > args pointer, while I think this is allowed in PSOS. The "pSOSystem System Calls" manual doesn't state the permissibility of a NULL args pointer, as far as I can see: unsigned long t_start( unsigned long tid, /* task identifier */ unsigned long mode, /* initial task attributes */ void (*start_addr)(), /* task address */ unsigned long targs[4] /* startup task arguments */ ) ... targs Specifies four startup values passed to the task (see Startup Values under Target). Target Startup Values ... A new task can receive up to four long words of input arguments. To facilitate retrieval of these arguments, they are passed to the task as if it is invoked as a highlevel language procedure or function. For example, if a C task nice has three input arguments, it can be declared as follows: nice (unsigned long a, unsigned long b, unsigned long c); where targs[0] is passed to a, targs[1] to b, and targs[2] to c. In this case, targs[3] is irrelevant and does not need the calling task to load it. -- Regards, Dietmar manroland AG Vorsitzender des Aufsichtsrates: Hanno C. Fiedler Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592 USt-Ident-Nr. DE 250200933 ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Frequency downscaling of new intel CPU
On 09/26/2011 09:02 AM, Petr Cervenka wrote: > > Hello. > > I recently tried newer computer and I suprusingly realized that it is bigger > load than the old one with our xenomai application. > The problem is in the frequency downscaling of the processor when the load in > under 100%. > Of course I have disabled CPU_FREQ, ACPI_PROCESSOR and INTEL_IDLE as > suggested. > Later I tried also to disable CPU_IDLE, 7300_IDLE (intel chipset idle memory) > and all power efficiency settings in the BIOS, but without success. > The experienced behaviour is following: > when the process is waiting for an event, the processor lowers its frequency > and when the event happens it tries to restore (slowly) its nominal frequency. > > Do you have any advice or tip what to try, because I'm really desperate? Have you tried: - enabling SMI workaround (and do not forget to check the boot logs to check that it actually works with the chipset you use); - if that fails, adding "idle=poll" to kernel arguments? -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Kernel configuration suggestions/hints
On 10/04/2011 10:42 AM, Julien Delange wrote: > Dear all, > > I am currently building a customized kernel to build a real-time > application. At this time, the requirement is very basic : I have one > periodic task in userland that acquires data from an analogy card > (ni6071e) with a 1ms period/deadline. At that time, the task miss one > deadline at each period, meaning that the code is executed in 2ms > instead of 1ms (and so, the deadline expires). So, I configured my > kernel without power management and with a timer at 1000Hz and a > tickless system (see variables below). However I would like to know if > there are other relevant configuration parameters that may influence > the scheduling of xenomai tasks so that I can make sure that my > application meets its requirements. If anyone has a feedback about > kernel configuration in that scope, it might be really useful ! In > addition, depending on your answer, it may be also good to report good > practices about the kernel configuration on the wiki, what do you > think about it ? > > Thanks for any suggestion, > > Kernel configuration variables: > CONFIG_NO_HZ=y > CONFIG_HIGH_RES_TIMERS=y > CONFIG_PREEMPT=y > CONFIG_HZ_1000=y > CONFIG_HZ=1000 > CONFIG_PM is not set > CONFIG_SFI is not set > CONFIG_CPU_FREQ is not set > CONFIG_CPU_IDLE is not set I am sorry, I do not really understand what you are doing, what has CONFIG_HZ to do with your issue? Could you post a self-contained example allowing to reproduce the issue you observe? -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] SIGILL when calling pthread_cleanup_push()
On 10/03/2011 05:33 PM, Gilles Chanteperdrix wrote: > On 10/03/2011 02:26 PM, Gilles Chanteperdrix wrote: >> On 10/03/2011 11:35 AM, Michael Bernhard wrote: >>> Hi >>> >>> We are using Xenomai-2.5.6 together with Linux-2.6.35 on a PXA270 >>> processor. Xenomai works fine so far. However we get SIGILL when using >>> pthread_cleanup_push() in a RT-thread. I now tried the same over >>> Xenomai-2.6 and the behavior is still the same. >>> >>> Here's a simple example which shows the problem (for Xenomai-2.6): >> >> Ok. Thanks for testing xenomai 2.6 by the way. I will try the test >> program on an ARMv5 I have tonight. However, could you tell us a bit >> more about your setup? What toolchain do you use? What threading library? > > And also: is your libc built with iwmmxt support? > Hi Michael, I can not reproduce this issue on another armv5 I have, but it does not support iwmmxt. So, in order to see if the problem you have comes from iwmmxt, you should try and build a root filesystem with a soft-float toolchain, such as, for instance, the codesourcery toolchain. Currently, iwmmxt floats are not supported with Xenomai, so, if you want to get them working, something will have to be done. Regards. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] xenomai-forge [psos] t_start segmentation fault when args == NULL
On Tue, 2011-10-04 at 10:42 +, dietmar.schind...@manroland.com wrote: > > -Original Message- > > On Behalf Of Thomas De Schampheleire > > Sent: Tuesday, October 04, 2011 11:42 AM > > ... > > In the xenomai-forge psos library, t_start() does not allow a NULL > > args pointer, while I think this is allowed in PSOS. > > The "pSOSystem System Calls" manual doesn't state the permissibility of a > NULL args pointer, as far as I can see: > > unsigned long t_start( >unsigned long tid, /* task identifier */ >unsigned long mode, /* initial task attributes */ >void (*start_addr)(), /* task address */ >unsigned long targs[4] /* startup task arguments */ >) > ... > targs Specifies four startup values passed to the task (see Startup > Values under Target). > > Target > Startup Values > ... > A new task can receive up to four long words of input arguments. To > facilitate retrieval of these arguments, they are passed to the task as if it > is invoked as a highlevel language procedure or function. For example, if a C > task nice has three input arguments, it can be declared as follows: > > nice (unsigned long a, unsigned long b, unsigned long c); > > where targs[0] is passed to a, targs[1] to b, and targs[2] to c. In this > case, targs[3] is irrelevant and does not need the calling task to load it. > Accepting NULL was a Xenomai-specific convenience introduced in Xenomai 2.x IIRC, then I changed my mind for 3.x. Granted NULL args would not work when back on real pSOS, but that does not look like a hot issue. So we should probably just accept it anew, and be happy. > -- > Regards, > Dietmar > manroland AG Vorsitzender des > Aufsichtsrates: Hanno C. Fiedler Vorstand: Gerd Finkbeiner (Vorsitzender), > Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle Sitz der Gesellschaft: Offenbach > am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592 USt-Ident-Nr. > DE 250200933 > > > ___ > Xenomai-help mailing list > Xenomai-help@gna.org > https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Kernel configuration suggestions/hints
On Tue, Oct 4, 2011 at 7:16 AM, Gilles Chanteperdrix
wrote:
> I am sorry, I do not really understand what you are doing, what has
> CONFIG_HZ to do with your issue?
I was wondering if this configuration item may have an impact on the
kernel scheduling speed.
> Could you post a self-contained example allowing to reproduce the issue
> you observe?
So, basically, I just create a start a native xenomai thread :
rt_task_create(&task, "Read IO Card", 0, 99, T_FPU);
rt_task_start (&task, &polling_task, 0);
And then, the task itself performs a loop that acquires data on a
periodic basis of 1ms (see code below).
The problem is that when I run the code, the value of missed in either
1 or 2, meaning that the deadline expired and the task does not meet
its timing requirements.
So, if you have any suggestion/comments to improve this code or how
kernel configuration may impact the performance of such piece of code,
it would be very interesting.
void polling_task(void * arg)
{
int i;
doubletmp;
int ret;
uint8_t raw[128 * 16];
double rate = 0.0001;
int result;
unsigned long missed;
a4l_insn_t insn_tab[16];
a4l_insnlst_t insnlst;
insnlst.count = 16;
insnlst.insns = insn_tab;
for (i=0; i<16; i++)
{
insn_tab[i].type = A4L_INSN_READ;
insn_tab[i].idx_subd = 0;
insn_tab[i].chan_desc = chdesc[i];
insn_tab[i].data_size = 8;
insn_tab[i].data = &raw[128 * i];
}
rt_task_set_periodic(NULL, TM_NOW, rate * 10.0);
rt_task_set_mode (0,T_LOCK|T_PRIMARY|T_NOSIG|T_RPIOFF, NULL);
while(1)
{
result = rt_task_wait_period(&missed);
if (result == -ETIMEDOUT)
{
printf("Number of missed deadlines: %lu \n", missed);
}
ret = a4l_snd_insnlist(&device, &insnlst);
if (ret != 0)
{
printf("insnlist error: %d \n", ret);
}
for (i=0; i<16; i++)
{
ret = a4l_rawtod (chinfos[i], rnginfos[i], &tmp, &raw[i*128], 1);
if (ret <= 0)
{
printf("rawtod() error: %d\n", ret);
}
}
return;
}
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Kernel configuration suggestions/hints
2011/10/4 Julien Delange > On Tue, Oct 4, 2011 at 7:16 AM, Gilles Chanteperdrix > wrote: > > I am sorry, I do not really understand what you are doing, what has > > CONFIG_HZ to do with your issue? > > I was wondering if this configuration item may have an impact on the > kernel scheduling speed. > > > > Could you post a self-contained example allowing to reproduce the issue > > you observe? > > So, basically, I just create a start a native xenomai thread : > rt_task_create(&task, "Read IO Card", 0, 99, T_FPU); > rt_task_start (&task, &polling_task, 0); > > > And then, the task itself performs a loop that acquires data on a > periodic basis of 1ms (see code below). > The problem is that when I run the code, the value of missed in either > 1 or 2, meaning that the deadline expired and the task does not meet > its timing requirements. > > So, if you have any suggestion/comments to improve this code or how > kernel configuration may impact the performance of such piece of code, > it would be very interesting. > > Dear Julien, In my opinion, instruction lists are definitely not the way to go for high speed acquisitions. The cost of setting up an instruction (from a kernel/board perspective, not from the user perspective) is very high and it is linear with the number of channels. At this point you want to consider using the "command" infrastructure, which will provide DMA transferred acquisitions. In your case, you can take advantage of your DAQ board's clock and set it up to provide you with precisely timed data. Then you have to decide whether you care more about throughput or lattency. In the first case you can achieve higher transfer rates using larger transfer blocks. In the second case, you will have to use smaller transfer blocks, either with "a4l_set_wake_size()" (or similar, I don't recall right now) or configuring your board with the TRIG_WAKE_EOS flag. Finally, you won't strictly need to program a periodic task. Using blocking xenomai-syscalls you will be able to acquire the DAQ-timed data properly. I hope this helps. Good luck, Fernando ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Kernel configuration suggestions/hints
On 10/04/2011 03:06 PM, Julien Delange wrote:
> void polling_task(void * arg)
> {
>int i;
>doubletmp;
>int ret;
>uint8_t raw[128 * 16];
>double rate = 0.0001;
Your "rate" looks more like a period to me (that is, the reciprocal).
The corresponding rate would be 1.
>int result;
>unsigned long missed;
>a4l_insn_t insn_tab[16];
>a4l_insnlst_t insnlst;
>
>
>insnlst.count = 16;
>insnlst.insns = insn_tab;
>
>for (i=0; i<16; i++)
>{
> insn_tab[i].type = A4L_INSN_READ;
> insn_tab[i].idx_subd = 0;
> insn_tab[i].chan_desc = chdesc[i];
> insn_tab[i].data_size = 8;
> insn_tab[i].data = &raw[128 * i];
>}
>rt_task_set_periodic(NULL, TM_NOW, rate * 10.0);
10.0 * 0.0001 is 10, that is 100us, not 1ms. As of why you
get 2ms (or 200us, maybe ?) is still a mystery. Could you send us your
kernel configuration?
Are not the analogy calls blocking?
--
Gilles.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] SIGILL when calling pthread_cleanup_push()
Gilles Chanteperdrix xenomai.org> writes: > > On 10/03/2011 05:33 PM, Gilles Chanteperdrix wrote: > > On 10/03/2011 02:26 PM, Gilles Chanteperdrix wrote: > >> Ok. Thanks for testing xenomai 2.6 by the way. I will try the test > >> program on an ARMv5 I have tonight. However, could you tell us a bit > >> more about your setup? What toolchain do you use? What threading library? We use codesourcery toolchain arm-2010.09. The rootfs was built using PTXdist. I think, but have to verify, that NPTL is used as threading library. > > And also: is your libc built with iwmmxt support? I don't know, but will find out. > I can not reproduce this issue on another armv5 I have, but it does not > support iwmmxt. So, in order to see if the problem you have comes from > iwmmxt, you should try and build a root filesystem with a soft-float > toolchain, such as, for instance, the codesourcery toolchain. > > Currently, iwmmxt floats are not supported with Xenomai, so, if you want > to get them working, something will have to be done. In the example I gave, no floats were used. Does Xenomai needs to support iwmmxt floats also in this case? And would compiling the application with -msoft-float do the trick? ATM, I'm busy with other things but have time to investigate tomorrow evening. -- Michael ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] SIGILL when calling pthread_cleanup_push()
On 10/04/2011 05:14 PM, Michael Bernhard wrote: > Gilles Chanteperdrix xenomai.org> writes: >> >> On 10/03/2011 05:33 PM, Gilles Chanteperdrix wrote: >>> On 10/03/2011 02:26 PM, Gilles Chanteperdrix wrote: Ok. Thanks for testing xenomai 2.6 by the way. I will try the test program on an ARMv5 I have tonight. However, could you tell us a bit more about your setup? What toolchain do you use? What threading library? > We use codesourcery toolchain arm-2010.09. The rootfs was built using PTXdist. > I think, but have to verify, that NPTL is used as threading library. > >>> And also: is your libc built with iwmmxt support? > I don't know, but will find out. > >> I can not reproduce this issue on another armv5 I have, but it does not >> support iwmmxt. So, in order to see if the problem you have comes from >> iwmmxt, you should try and build a root filesystem with a soft-float >> toolchain, such as, for instance, the codesourcery toolchain. >> >> Currently, iwmmxt floats are not supported with Xenomai, so, if you want >> to get them working, something will have to be done. > In the example I gave, no floats were used. Does Xenomai needs to support > iwmmxt > floats also in this case? And would compiling the application with > -msoft-float > do the trick? > > ATM, I'm busy with other things but have time to investigate tomorrow > evening. The bug happens inside sigsetjmp, which is a routine saving the current context. So, if the libc is compiled with iwmmmxt support, and more importantly, if the kernel is compiled with iwmmxt support, sigsetjmp probably saves the floating point registers. So another simple thing to try is to disable iwmmxt support in kernel configuration. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
On Mon, 2011-09-26 at 22:01 +0200, Ronny Meeus wrote:
> Next to this I also adapted the task priority automatically using
> following algorithm:
> static int check_task_priority(u_long *psos_prio)
> {
> if (*psos_prio < 1 || *psos_prio > 255) /* In theory. */
> return ERR_PRIOR;
> /* Do not change priorities <=10 and >= 240.
> * Priorities in between are divided by 4 */
> if (*psos_prio > 240)
> *psos_prio = 70 + *psos_prio - 240;
> else if (*psos_prio > 10)
> *psos_prio = 11 + ((*psos_prio-10)/4);
>
> if ((int)(*psos_prio) >= threadobj_max_prio - 1) /* In practice. */
> panic("current implementation restricts pSOS "
> "priority levels to range [1..%d]",
> threadobj_max_prio - 2);
>
> return SUCCESS;
> }
>
> It also works well for our application.
> Please share your thoughts.
Since we cannot generalize the priority mapping rules, a better way may
be to allow your own code to be called by the pSOS emulator when such
mapping is required. So I have committed a tentative solution, defining
psos_task_normalize_priority() as a weak function, which receives the
pSOS priority, and should return the POSIX one.
A default implementation is provided by the emulator which does a
trivial 1:1 mapping.
--
Philippe.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Kernel configuration suggestions/hints
On 10/04/2011 03:51 PM, Julien Delange wrote: > On Tue, Oct 4, 2011 at 9:45 AM, Gilles Chanteperdrix > wrote: >> Your "rate" looks more like a period to me (that is, the reciprocal). > > Yes, exactly. > >> 10.0 * 0.0001 is 10, that is 100us, not 1ms. As of why you >> get 2ms (or 200us, maybe ?) is still a mystery. Could you send us your >> kernel configuration? > > My bad, the value of rate is 0.001, this is due to a copy/paste error. > Also, I attach the kernel configuration as requested. > >> Are not the analogy calls blocking? > > I think so but on the other hand, I don't think it would take so much > time : performing the command list would take less than 1ms (I hope > so). Another mail in that thread seem to suggest that it could be long. Have you tried timing the various parts of your loop to see where the time is spent? -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Command code working with comedi not working with analogy
El 3 de octubre de 2011 18:41, Fernando Herrero Carrón escribió: > El 30 de septiembre de 2011 00:16, Alexis Berlemont < > alexis.berlem...@gmail.com> escribió: > >> Hi, >> [...] >> >> With insn_read, did you manage to acquire correct values at least? >> >> > Dear Alexis, > > insn_read does indeed work. If I run "insn_read -S 1000" I get my input > sampled at approx 125kHz. Running cmd_read with and without '-m' only > returns 0x8000. > > I have been playing around with __a4l_info and the driver code to track > down my problem. I am not familiar at all with low-level DAQ programming, so > I just followed my intuition. > > I modified > buffer.c:a4l_read_buf and buffer.h:__consume > > to dump the values that were being consumed from the internal buffer. There > I found the infamous 0x8000, so my conclusion is that those values are > traveling along the kernel side. I decided I would go the other way around > and modified > > drivers/analogy/national_instruments/mio_common.c: handle_a_interrupt > and drivers/analogy/buffer.c: a4l_buf_evt > > I guess that interrupt is being generated every time a DMA transfer has > been completed from the DAQ to analogy's internal buffer. I dump variable > "count" in a4l_buf_evt and it always reports the appropriate byte count to > be transferred, which is "number of channels" * 2. > > My guess is that the DMA transfers are being performed to the wrong place, > because the whole procedure seems to be working ok otherwise. > > All help is appreciated, > Fernando > > > Dear all, More updates on this. I just tested both the "cmd_read" example and my own code on the analogy_fake device. They're both working, I get a sawtooth shape. So my guess is still that there is some error in the DMA transfer in the NI driver(s). Could anyone please help me indicating where DMA is setup in the NI drivers? I'll try to have a look at it myself, but a more experienced advice would be helpful. Thanks, Fernando ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] xenomai-forge [psos] t_start segmentation fault when args == NULL
On Tue, Oct 4, 2011 at 2:00 PM, Philippe Gerum wrote: > On Tue, 2011-10-04 at 10:42 +, dietmar.schind...@manroland.com > wrote: >> > -Original Message- >> > On Behalf Of Thomas De Schampheleire >> > Sent: Tuesday, October 04, 2011 11:42 AM >> > ... >> > In the xenomai-forge psos library, t_start() does not allow a NULL >> > args pointer, while I think this is allowed in PSOS. >> >> The "pSOSystem System Calls" manual doesn't state the permissibility of a >> NULL args pointer, as far as I can see: >> >> unsigned long t_start( >> unsigned long tid, /* task identifier */ >> unsigned long mode, /* initial task attributes */ >> void (*start_addr)(), /* task address */ >> unsigned long targs[4] /* startup task arguments */ >> ) >> ... >> targs Specifies four startup values passed to the task (see Startup >> Values under Target). >> >> Target >> Startup Values >> ... >> A new task can receive up to four long words of input arguments. To >> facilitate retrieval of these arguments, they are passed to the task as if >> it is invoked as a highlevel language procedure or function. For example, if >> a C task nice has three input arguments, it can be declared as follows: >> >> nice (unsigned long a, unsigned long b, unsigned long c); >> >> where targs[0] is passed to a, targs[1] to b, and targs[2] to c. In this >> case, targs[3] is irrelevant and does not need the calling task to load it. >> > > Accepting NULL was a Xenomai-specific convenience introduced in Xenomai > 2.x IIRC, then I changed my mind for 3.x. Granted NULL args would not > work when back on real pSOS, but that does not look like a hot issue. So > we should probably just accept it anew, and be happy. > >> -- >> Regards, >> Dietmar >> manroland AG Vorsitzender des >> Aufsichtsrates: Hanno C. Fiedler Vorstand: Gerd Finkbeiner (Vorsitzender), >> Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle Sitz der Gesellschaft: >> Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592 >> USt-Ident-Nr. DE 250200933 >> >> >> ___ >> Xenomai-help mailing list >> Xenomai-help@gna.org >> https://mail.gna.org/listinfo/xenomai-help > > -- > Philippe. > > > > ___ > Xenomai-help mailing list > Xenomai-help@gna.org > https://mail.gna.org/listinfo/xenomai-help > Hello I think that it is supported since our application does pass a NULL pointer as args argument. The application is originally created in a real pSOS environment 12 years ago. Anyhow thanks for changing it. Ronny ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] xenomai-forge [psos] t_start segmentation fault when args == NULL
On Tue, 2011-10-04 at 23:11 +0200, Ronny Meeus wrote: > On Tue, Oct 4, 2011 at 2:00 PM, Philippe Gerum wrote: > > On Tue, 2011-10-04 at 10:42 +, dietmar.schind...@manroland.com > > wrote: > >> > -Original Message- > >> > On Behalf Of Thomas De Schampheleire > >> > Sent: Tuesday, October 04, 2011 11:42 AM > >> > ... > >> > In the xenomai-forge psos library, t_start() does not allow a NULL > >> > args pointer, while I think this is allowed in PSOS. > >> > >> The "pSOSystem System Calls" manual doesn't state the permissibility of a > >> NULL args pointer, as far as I can see: > >> > >> unsigned long t_start( > >>unsigned long tid, /* task identifier */ > >>unsigned long mode, /* initial task attributes */ > >>void (*start_addr)(), /* task address */ > >>unsigned long targs[4] /* startup task arguments */ > >>) > >> ... > >> targs Specifies four startup values passed to the task (see Startup > >> Values under Target). > >> > >> Target > >> Startup Values > >> ... > >> A new task can receive up to four long words of input arguments. To > >> facilitate retrieval of these arguments, they are passed to the task as if > >> it is invoked as a highlevel language procedure or function. For example, > >> if a C task nice has three input arguments, it can be declared as follows: > >> > >> nice (unsigned long a, unsigned long b, unsigned long c); > >> > >> where targs[0] is passed to a, targs[1] to b, and targs[2] to c. In this > >> case, targs[3] is irrelevant and does not need the calling task to load it. > >> > > > > Accepting NULL was a Xenomai-specific convenience introduced in Xenomai > > 2.x IIRC, then I changed my mind for 3.x. Granted NULL args would not > > work when back on real pSOS, but that does not look like a hot issue. So > > we should probably just accept it anew, and be happy. > > > >> -- > >> Regards, > >> Dietmar > >> manroland AG Vorsitzender des > >> Aufsichtsrates: Hanno C. Fiedler Vorstand: Gerd Finkbeiner (Vorsitzender), > >> Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle Sitz der Gesellschaft: > >> Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592 > >> USt-Ident-Nr. DE 250200933 > >> > >> > >> ___ > >> Xenomai-help mailing list > >> Xenomai-help@gna.org > >> https://mail.gna.org/listinfo/xenomai-help > > > > -- > > Philippe. > > > > > > > > ___ > > Xenomai-help mailing list > > Xenomai-help@gna.org > > https://mail.gna.org/listinfo/xenomai-help > > > > Hello > > I think that it is supported since our application does pass a NULL > pointer as args argument. > The application is originally created in a real pSOS environment 12 years ago. Ok. Was this running on MMU-enabled hw? > > Anyhow thanks for changing it. > > Ronny -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
