Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Jan Kiszka kirjoitti: Heikki Lindholm wrote: Jan Kiszka kirjoitti: Heikki Lindholm wrote: Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but not yet set last_task_used_math to NULL. As a result the tasks MSR_FP will get set, although it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee Is it still broken with latest revision 376? Philippe had merged the fix for my mess, and it worked at least for 2.6 on my box again. I'd say this has been unchanged since the beginning (0.9?). Then, what latency are we talking about? My last modifications went to src/testsuite/latency. Did you mean ksrc/skins/native/demos/latency.c? Sorry, I misinterpreted in a hurry. I was (still) talking about the fpu ;) It might be that the latency test didn't compile, because I didn't even enable the rtdm measuring device in kernel config or something(?). I'll try again. -- Heikki Lindholm
Re: [Xenomai-core] heres a go at an adeos-ipipe-2.6.15-i386-1.1-01.patch
Jim Cromie posted a patch attempt for 2.6.15 (yeah!), and the patch applied, but it doesn't compile for me: [...] LD init/built-in.o LD .tmp_vmlinux1 arch/i386/kernel/built-in.o: In function `__ipipe_sync_stage': : undefined reference to `ret_from_intr' arch/i386/kernel/built-in.o: In function `__ipipe_sync_stage': : undefined reference to `ret_from_intr' make: *** [.tmp_vmlinux1] Error 1 ~/linux-2.6.15$ For a .config I started with the stock Ubuntu 2.6.12-10-686 config file and then took the defaults for all the oldconfig questions. Suggestions? Thanks, -kb
[Xenomai-core] Re: [PATCH, RFC] nucleus:shared irq and possible ipipe problem
On 05/01/06, Philippe Gerum <[EMAIL PROTECTED]> wrote: Dmitry Adamushko wrote:>> err... I have to orginize some issues next few days so I'll be out of my> notebook. Then I'll finilize the ipipe-irq-related patch so to be ready> for the .01 version. >Meanwhile, I have finished merging the shared IRQ infrastructure intothe Adeos codebase for all supported archs. The Xenomai trunk/ has beenupgraded accordingly too. Thanks and sorry for aditionally taking your time on some work I shoud have completed on my own. Actually this infrastructure is by no means a _must_ for introducing the shared irq feature on the nucleus layer. I doubt that we may gain any noticeable benefits, latency-wise, having got the one-layer-less irq processing chain. Just hope there is no regression. So, my hope is rather that the new interface has become a bit more clear and usefull, e.g. there is no need to implement any other per-irq tables to introduce the "cookie" concept no matter where it has to be used (even directly at the adeos layer). x86-wise, please make sure to rebase yourdevelopment on 1.1-02 . Sure. --Philippe.-- Best regards, Dmitry Adamushko
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Jan Kiszka wrote: > Heikki Lindholm wrote: > >>Jan Kiszka kirjoitti: >> >> >>>Heikki Lindholm wrote: >>> >>> Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but not yet set last_task_used_math to NULL. As a result the tasks MSR_FP will get set, although it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee >>> >>> >>> >>>Is it still broken with latest revision 376? Philippe had merged the fix >>>for my mess, and it worked at least for 2.6 on my box again. >> >> >>I'd say this has been unchanged since the beginning (0.9?). >> > > > Then, what latency are we talking about? My last modifications went to > src/testsuite/latency. Did you mean ksrc/skins/native/demos/latency.c? > BTW, the latter compiles fine for me as well (in my case by providing the full path to xeno-config via XENO_CONFIG to "make"). Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] Re: [PATCH] latency tracer update
Jan Kiszka wrote: > Jan Kiszka wrote: > >>... >>Meanwhile I found a solution for the described unterminated trace (put >>an explicite trace_end at the end of __ipipe_unstall_iret_root), >>included the irq number in the begin/end report, and stumbled over some >>other remaining unterminated trace on a different machine. So, no need >>to hurry with the merge (not the review! ;) ), I will publish a second >>revision first. >> > > > And here comes this revision finally. Should apply (almost) cleanly > against latest ipipe versions. Additionally to the changes of the first > revision this one addresses the following topics: > > o fix trace overrun handling > o report IRQ number to tracer on IRQ entry/exit > o fix virtually leaking IRQs-off in __ipipe_unstall_iret_root() > o fix another potential NMI race > o really trace the maximum IRQs-off time, not the maximum time of >consecutive IRQs-off times (that scenario will soon be addressed >instead in the latency benchmark tool => reset&freeze the maximum >latency from the user's point of view) ...and it turned out that the existing functions were no sufficient for this. So here comes an add-on patch to update3: o allow ipipe_trace_{frozen|max}_reset from every context (well, at least give it a try and just fail on locked traces) o mark border between valid and invalid trace points o show invalid points border Apply order: ipipe_tracer.update3 ipipe_tracer.update3-1 The front-end to the first change, a modified latency+timerbench will get committed to Xenomai soon. It already works nicely, automatically creating a freeze of the maximum latency turn the benchmark perceives. Jan --- linux-2.6.14.3/kernel/ipipe/tracer.c.orig 2006-01-06 11:13:41.0 +0100 +++ linux-2.6.14.3/kernel/ipipe/tracer.c2006-01-06 20:11:10.0 +0100 @@ -134,10 +134,14 @@ __ipipe_migrate_pre_trace(struct ipipe_t int i; new_tp->trace_pos = pre_trace+1; + for (i = new_tp->trace_pos; i > 0; i--) memcpy(&new_tp->point[WRAP_POINT_NO(new_tp->trace_pos-i)], &old_tp->point[WRAP_POINT_NO(old_pos-i)], sizeof(struct ipipe_trace_point)); + + /* mark the end (i.e. the point before point[0]) invalid */ + new_tp->point[IPIPE_TRACE_POINTS-1].eip = 0; } static notrace struct ipipe_trace_path * @@ -436,21 +440,23 @@ void notrace ipipe_trace_special(unsigne } EXPORT_SYMBOL(ipipe_trace_special); -void ipipe_trace_max_reset(void) +int ipipe_trace_max_reset(void) { int cpu_id; unsigned long flags; struct ipipe_trace_path *path; + int ret = 0; - /* only allowed from root domain (we sync with /proc routines) */ - if (ipipe_current_domain != ipipe_root_domain) - return; - - down(&out_mutex); flags = __ipipe_global_path_lock(); for_each_cpu(cpu_id) { path = &trace_paths[cpu_id][max_path[cpu_id]]; + + if (path->dump_lock) { + ret = -EBUSY; + break; + } + path->begin = -1; path->end = -1; path->trace_pos = 0; @@ -458,25 +464,28 @@ void ipipe_trace_max_reset(void) } __ipipe_global_path_unlock(flags); - up(&out_mutex); + + return ret; } EXPORT_SYMBOL(ipipe_trace_max_reset); -void ipipe_trace_frozen_reset(void) +int ipipe_trace_frozen_reset(void) { int cpu_id; unsigned long flags; struct ipipe_trace_path *path; + int ret = 0; - /* only allowed from root domain (we sync with /proc routines) */ - if (ipipe_current_domain != ipipe_root_domain) - return; - - down(&out_mutex); flags = __ipipe_global_path_lock(); for_each_cpu(cpu_id) { path = &trace_paths[cpu_id][frozen_path[cpu_id]]; + + if (path->dump_lock) { + ret = -EBUSY; + break; + } + path->begin = -1; path->end = -1; path->trace_pos = 0; @@ -484,7 +493,8 @@ void ipipe_trace_frozen_reset(void) } __ipipe_global_path_unlock(flags); - up(&out_mutex); + + return ret; } EXPORT_SYMBOL(ipipe_trace_frozen_reset); @@ -684,8 +694,10 @@ static int __ipipe_prtrace_show(struct s unsigned long long abs_delta; struct ipipe_trace_point *point = p; - if (!point->eip) + if (!point->eip) { + seq_puts(m, "--\n"); return 0; + } /* ipipe_tsc2us works on unsigned => handle sign separately */ delta = point->timestamp - @@ -749,7 +761,10 @@ static ssize_t __ipipe_max_reset(struct file *file, const char __user *pbuffer, size_t count, loff_t *data) { + down(&out_mutex); ipipe_trace_max_reset(); + up(&out_mutex
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Heikki Lindholm wrote: > Jan Kiszka kirjoitti: > >> Heikki Lindholm wrote: >> >>> Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but >>> not yet set last_task_used_math to NULL. As a result the tasks MSR_FP >>> will get set, although it should be cleared. If the task happens to hit >>> one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU >>> state might be saved to the task. The attached patch should fix this. I >>> couldn't try it on most recent Xenomai trunk, because latency wouldn't >>> build anymore. However, I see no reason it shouldn't work. All thee >> >> >> >> Is it still broken with latest revision 376? Philippe had merged the fix >> for my mess, and it worked at least for 2.6 on my box again. > > > I'd say this has been unchanged since the beginning (0.9?). > Then, what latency are we talking about? My last modifications went to src/testsuite/latency. Did you mean ksrc/skins/native/demos/latency.c? Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Jan Kiszka kirjoitti: Heikki Lindholm wrote: Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but not yet set last_task_used_math to NULL. As a result the tasks MSR_FP will get set, although it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee Is it still broken with latest revision 376? Philippe had merged the fix for my mess, and it worked at least for 2.6 on my box again. I'd say this has been unchanged since the beginning (0.9?). -- hl
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Heikki Lindholm wrote: > Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but > not yet set last_task_used_math to NULL. As a result the tasks MSR_FP > will get set, although it should be cleared. If the task happens to hit > one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU > state might be saved to the task. The attached patch should fix this. I > couldn't try it on most recent Xenomai trunk, because latency wouldn't > build anymore. However, I see no reason it shouldn't work. All thee Is it still broken with latest revision 376? Philippe had merged the fix for my mess, and it worked at least for 2.6 on my box again. > having trouble with X and Xenomai, give this a shot. > > -- Heikki Lindholm > Jan signature.asc Description: OpenPGP digital signature
[Xenomai-core] [PATCH] Fix ppc fpu support
Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but not yet set last_task_used_math to NULL. As a result the tasks MSR_FP will get set, although it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee having trouble with X and Xenomai, give this a shot. -- Heikki Lindholm diff -Nru xenomai/include/asm-powerpc/system.h xenomai-devel/include/asm-powerpc/system.h --- xenomai/include/asm-powerpc/system.h2006-01-06 15:55:19.0 +0200 +++ xenomai-devel/include/asm-powerpc/system.h 2006-01-06 16:44:53.0 +0200 @@ -55,6 +55,7 @@ rthal_fpenv_t fpuenv __attribute__ ((aligned (16))); rthal_fpenv_t *fpup; /* Pointer to the FPU backup area */ struct task_struct *user_fpu_owner; +unsigned long user_fpu_owner_prev_msr; /* Pointer the the FPU owner in userspace: - NULL for RT K threads, - last_task_used_math for Linux US threads (only current or NULL when MP) @@ -368,7 +369,10 @@ rthal_save_fpu(tcb->fpup); if(tcb->user_fpu_owner && tcb->user_fpu_owner->thread.regs) +{ +tcb->user_fpu_owner_prev_msr = tcb->user_fpu_owner->thread.regs->msr; tcb->user_fpu_owner->thread.regs->msr &= ~MSR_FP; +} } #endif /* CONFIG_XENO_HW_FPU */ @@ -383,7 +387,13 @@ { rthal_restore_fpu(tcb->fpup); -if(tcb->user_fpu_owner && tcb->user_fpu_owner->thread.regs) + /* Note: Only enable FP in MSR, if it was enabled when we saved the +* fpu state. We might have preempted Linux when it had disabled FP +* for the thread, but not yet set last_task_used_math to NULL +*/ +if(tcb->user_fpu_owner && + tcb->user_fpu_owner->thread.regs && + ((tcb->user_fpu_owner_prev_msr & MSR_FP) != 0)) tcb->user_fpu_owner->thread.regs->msr |= MSR_FP; }
Re: [Xenomai-core] Re: Oops, I broke something
Jan Kiszka wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: > Jan Kiszka wrote: > > But this raised the question to me again if we really need the "xenomai" > > prefix for all the skin headers /from within xenomai/. Why not doing the > > same linking dance for the other skins as well? Or do you also prefer > > that user include instead of just ? > > We need this for building from within the kernel. Other options would > require to either alter the Xenomai source tree adding symlinks there, > pollute linux/include with symlinks to reach the individual Xeno > components, or refer to some external tree that eventually redirects to > the Xenomai tree, which is not acceptable in any case. Maybe we could add EXTRA_CFLAGS=-I$(TOPDIR)/include/xenomai to every xenomai kernel makefile Yes, I would preferably merge that instead of playing with symlinks. and to the cflags returned by xeno-config for kernel-space applications ? There no such support in xeno-config anymore. Kernel module flags and dependencies now exclusively belong to the kernel build system; xeno-config is only relevant for building user-space apps. Actually, my concerns only targeted the userspace applications, more precisely those few being built inside the xeno tree. External user apps can still use the standard, non-prefixed headers. Thus my idea was to unify the includes for those in-tree applications so that users who are taking them as reference only see the standard way. Ack, but this is a matter of general consistency. Now that the issue is raised and that we need to address it, it's better if we don't have to fiddle with exception cases uselessly, so using the proper include directives for both internal/external cases is the best way to go; provided it works, but it should. External kernel applications and drivers can and should catch this prefix by adding /include/xenomai to their makefiles. Jan -- Philippe.
Re: [Xenomai-core] Re: Oops, I broke something
Philippe Gerum wrote: > Gilles Chanteperdrix wrote: > >> Philippe Gerum wrote: >> > Jan Kiszka wrote: >> > > But this raised the question to me again if we really need the >> "xenomai" >> > > prefix for all the skin headers /from within xenomai/. Why not >> doing the >> > > same linking dance for the other skins as well? Or do you also >> prefer >> > > that user include instead of just >> ? >> > > We need this for building from within the kernel. Other options >> would > require to either alter the Xenomai source tree adding >> symlinks there, > pollute linux/include with symlinks to reach the >> individual Xeno > components, or refer to some external tree that >> eventually redirects to > the Xenomai tree, which is not acceptable >> in any case. >> >> Maybe we could add EXTRA_CFLAGS=-I$(TOPDIR)/include/xenomai to every >> xenomai kernel makefile > > > Yes, I would preferably merge that instead of playing with symlinks. > > and to the cflags returned by xeno-config for > >> kernel-space applications ? >> > > There no such support in xeno-config anymore. Kernel module flags and > dependencies now exclusively belong to the kernel build system; > xeno-config is only relevant for building user-space apps. > Actually, my concerns only targeted the userspace applications, more precisely those few being built inside the xeno tree. External user apps can still use the standard, non-prefixed headers. Thus my idea was to unify the includes for those in-tree applications so that users who are taking them as reference only see the standard way. External kernel applications and drivers can and should catch this prefix by adding /include/xenomai to their makefiles. Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] Re: Oops, I broke something
Gilles Chanteperdrix wrote: Philippe Gerum wrote: > Jan Kiszka wrote: > > But this raised the question to me again if we really need the "xenomai" > > prefix for all the skin headers /from within xenomai/. Why not doing the > > same linking dance for the other skins as well? Or do you also prefer > > that user include instead of just ? > > We need this for building from within the kernel. Other options would > require to either alter the Xenomai source tree adding symlinks there, > pollute linux/include with symlinks to reach the individual Xeno > components, or refer to some external tree that eventually redirects to > the Xenomai tree, which is not acceptable in any case. Maybe we could add EXTRA_CFLAGS=-I$(TOPDIR)/include/xenomai to every xenomai kernel makefile While checking the 2.4 builds for ppc and x86, I stumbled upon cases where we do need this fix right now (e.g. benchmark and 16550A drivers). So I will handle this global change right after -rc2 is out. -- Philippe.
Re: [Xenomai-core] Problem with #define uint "i"
Wolfgang Grandegger wrote: Hallo, when trying to build RTnet with Xenomai and Linux 2.4.25 for PowerPC, I stumbeld over the following problem: In "linuxppc_2_4_devel/include/asm-generic/xenomai/wrappers.h" there is defined: #define ulong "i" #define uint "i" This makes trouble when a driver uses the types uint or ulong, which is the case for the MPC RTnet drivers. Can we use different names for the above definitions? Yes, will fix in Xenomai. Actually, since module_param() has been backported in its simplest forms to 2.4, the above hack should be useless. Thanks. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe.
Re: [Xenomai-core] Re: Oops, I broke something
Gilles Chanteperdrix wrote: Philippe Gerum wrote: > Jan Kiszka wrote: > > But this raised the question to me again if we really need the "xenomai" > > prefix for all the skin headers /from within xenomai/. Why not doing the > > same linking dance for the other skins as well? Or do you also prefer > > that user include instead of just ? > > We need this for building from within the kernel. Other options would > require to either alter the Xenomai source tree adding symlinks there, > pollute linux/include with symlinks to reach the individual Xeno > components, or refer to some external tree that eventually redirects to > the Xenomai tree, which is not acceptable in any case. Maybe we could add EXTRA_CFLAGS=-I$(TOPDIR)/include/xenomai to every xenomai kernel makefile Yes, I would preferably merge that instead of playing with symlinks. and to the cflags returned by xeno-config for kernel-space applications ? There no such support in xeno-config anymore. Kernel module flags and dependencies now exclusively belong to the kernel build system; xeno-config is only relevant for building user-space apps. -- Philippe.
Re: [Xenomai-core] Re: Oops, I broke something
Philippe Gerum wrote: > Jan Kiszka wrote: > > But this raised the question to me again if we really need the "xenomai" > > prefix for all the skin headers /from within xenomai/. Why not doing the > > same linking dance for the other skins as well? Or do you also prefer > > that user include instead of just ? > > We need this for building from within the kernel. Other options would > require to either alter the Xenomai source tree adding symlinks there, > pollute linux/include with symlinks to reach the individual Xeno > components, or refer to some external tree that eventually redirects to > the Xenomai tree, which is not acceptable in any case. Maybe we could add EXTRA_CFLAGS=-I$(TOPDIR)/include/xenomai to every xenomai kernel makefile and to the cflags returned by xeno-config for kernel-space applications ? -- Gilles Chanteperdrix.
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Jan Kiszka kirjoitti: Heikki Lindholm wrote: Jan Kiszka kirjoitti: Heikki Lindholm wrote: Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but not yet set last_task_used_math to NULL. As a result the tasks MSR_FP will get set, although it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee Is it still broken with latest revision 376? Philippe had merged the fix for my mess, and it worked at least for 2.6 on my box again. I'd say this has been unchanged since the beginning (0.9?). Then, what latency are we talking about? My last modifications went to src/testsuite/latency. Did you mean ksrc/skins/native/demos/latency.c? Sorry, I misinterpreted in a hurry. I was (still) talking about the fpu ;) It might be that the latency test didn't compile, because I didn't even enable the rtdm measuring device in kernel config or something(?). I'll try again. -- Heikki Lindholm ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] heres a go at an adeos-ipipe-2.6.15-i386-1.1-01.patch
Jim Cromie posted a patch attempt for 2.6.15 (yeah!), and the patch applied, but it doesn't compile for me: [...] LD init/built-in.o LD .tmp_vmlinux1 arch/i386/kernel/built-in.o: In function `__ipipe_sync_stage': : undefined reference to `ret_from_intr' arch/i386/kernel/built-in.o: In function `__ipipe_sync_stage': : undefined reference to `ret_from_intr' make: *** [.tmp_vmlinux1] Error 1 ~/linux-2.6.15$ For a .config I started with the stock Ubuntu 2.6.12-10-686 config file and then took the defaults for all the oldconfig questions. Suggestions? Thanks, -kb ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: Oops, I broke something
Jan Kiszka wrote: Hi Philippe, my RTDM header "optimisation" broke the compilation of testsuite/latency. I need an extra link for the userspace compilation inside xeno now. Please apply this patch --- configure.in(Revision 372) +++ configure.in(Arbeitskopie) @@ -348,6 +348,8 @@ base=include AC_CONFIG_LINKS([src/include/xenomai:$base]) +base=rtdm +AC_CONFIG_LINKS([src/include/$base:include/$base]) base=asm-$XENO_TARGET_ARCH AC_CONFIG_LINKS([src/include/asm/xenomai:include/$base]) base=asm-generic and run bootstrap. Sorry. But this raised the question to me again if we really need the "xenomai" prefix for all the skin headers /from within xenomai/. Why not doing the same linking dance for the other skins as well? Or do you also prefer that user include instead of just ? Nope, people writing apps should not have to handle our internal issues, asking them to prefix with xenomai/ is not an option. Jan -- Philippe.
[Xenomai-core] Re: Oops, I broke something
Jan Kiszka wrote: Hi Philippe, my RTDM header "optimisation" broke the compilation of testsuite/latency. I need an extra link for the userspace compilation inside xeno now. Please apply this patch --- configure.in(Revision 372) +++ configure.in(Arbeitskopie) @@ -348,6 +348,8 @@ base=include AC_CONFIG_LINKS([src/include/xenomai:$base]) +base=rtdm +AC_CONFIG_LINKS([src/include/$base:include/$base]) base=asm-$XENO_TARGET_ARCH AC_CONFIG_LINKS([src/include/asm/xenomai:include/$base]) base=asm-generic and run bootstrap. Sorry. But this raised the question to me again if we really need the "xenomai" prefix for all the skin headers /from within xenomai/. Why not doing the same linking dance for the other skins as well? Or do you also prefer that user include instead of just ? We need this for building from within the kernel. Other options would require to either alter the Xenomai source tree adding symlinks there, pollute linux/include with symlinks to reach the individual Xeno components, or refer to some external tree that eventually redirects to the Xenomai tree, which is not acceptable in any case. -- Philippe.
[Xenomai-core] Oops, I broke something
Hi Philippe, my RTDM header "optimisation" broke the compilation of testsuite/latency. I need an extra link for the userspace compilation inside xeno now. Please apply this patch --- configure.in(Revision 372) +++ configure.in(Arbeitskopie) @@ -348,6 +348,8 @@ base=include AC_CONFIG_LINKS([src/include/xenomai:$base]) +base=rtdm +AC_CONFIG_LINKS([src/include/$base:include/$base]) base=asm-$XENO_TARGET_ARCH AC_CONFIG_LINKS([src/include/asm/xenomai:include/$base]) base=asm-generic and run bootstrap. Sorry. But this raised the question to me again if we really need the "xenomai" prefix for all the skin headers /from within xenomai/. Why not doing the same linking dance for the other skins as well? Or do you also prefer that user include instead of just ? Jan signature.asc Description: OpenPGP digital signature
[Xenomai-core] Re: [Adeos-main] Re: [PATCH] latency tracer update
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Hi again, here comes the first update of the new latency tracer. arch/i386/kernel/entry.S | 27 +++ Is there any good reason to patch the callers of __ipipe_handle_irq instead of instrumenting the callee directly? To capture the invocation delay of __ipipe_handle_irq itself. Ok. arch/i386/kernel/ipipe-root.c |4 include/asm-i386/system.h | 70 + include/linux/ipipe_trace.h |3 kernel/ipipe/Kconfig | 18 ++ kernel/ipipe/tracer.c | 247 +++--- 6 files changed, 288 insertions(+), 81 deletions(-) Meanwhile I found a solution for the described unterminated trace (put an explicite trace_end at the end of __ipipe_unstall_iret_root), Yeah, sorry for the delay in answering. That's indeed the way to do it. included the irq number in the begin/end report, and stumbled over some other remaining unterminated trace on a different machine. So, no need to hurry with the merge (not the review! ;) ), I will publish a second revision first. Jan ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main -- Philippe.
[Xenomai-core] Re: [PATCH, RFC] nucleus:shared irq and possible ipipe problem
On 05/01/06, Philippe Gerum <[EMAIL PROTECTED]> wrote: Dmitry Adamushko wrote:>> err... I have to orginize some issues next few days so I'll be out of my> notebook. Then I'll finilize the ipipe-irq-related patch so to be ready> for the .01 version. >Meanwhile, I have finished merging the shared IRQ infrastructure intothe Adeos codebase for all supported archs. The Xenomai trunk/ has beenupgraded accordingly too. Thanks and sorry for aditionally taking your time on some work I shoud have completed on my own. Actually this infrastructure is by no means a _must_ for introducing the shared irq feature on the nucleus layer. I doubt that we may gain any noticeable benefits, latency-wise, having got the one-layer-less irq processing chain. Just hope there is no regression. So, my hope is rather that the new interface has become a bit more clear and usefull, e.g. there is no need to implement any other per-irq tables to introduce the "cookie" concept no matter where it has to be used (even directly at the adeos layer). x86-wise, please make sure to rebase yourdevelopment on 1.1-02 . Sure. --Philippe.-- Best regards, Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Jan Kiszka wrote: > Heikki Lindholm wrote: > >>Jan Kiszka kirjoitti: >> >> >>>Heikki Lindholm wrote: >>> >>> Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but not yet set last_task_used_math to NULL. As a result the tasks MSR_FP will get set, although it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee >>> >>> >>> >>>Is it still broken with latest revision 376? Philippe had merged the fix >>>for my mess, and it worked at least for 2.6 on my box again. >> >> >>I'd say this has been unchanged since the beginning (0.9?). >> > > > Then, what latency are we talking about? My last modifications went to > src/testsuite/latency. Did you mean ksrc/skins/native/demos/latency.c? > BTW, the latter compiles fine for me as well (in my case by providing the full path to xeno-config via XENO_CONFIG to "make"). Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: [PATCH] latency tracer update
Jan Kiszka wrote: > Jan Kiszka wrote: > >>... >>Meanwhile I found a solution for the described unterminated trace (put >>an explicite trace_end at the end of __ipipe_unstall_iret_root), >>included the irq number in the begin/end report, and stumbled over some >>other remaining unterminated trace on a different machine. So, no need >>to hurry with the merge (not the review! ;) ), I will publish a second >>revision first. >> > > > And here comes this revision finally. Should apply (almost) cleanly > against latest ipipe versions. Additionally to the changes of the first > revision this one addresses the following topics: > > o fix trace overrun handling > o report IRQ number to tracer on IRQ entry/exit > o fix virtually leaking IRQs-off in __ipipe_unstall_iret_root() > o fix another potential NMI race > o really trace the maximum IRQs-off time, not the maximum time of >consecutive IRQs-off times (that scenario will soon be addressed >instead in the latency benchmark tool => reset&freeze the maximum >latency from the user's point of view) ...and it turned out that the existing functions were no sufficient for this. So here comes an add-on patch to update3: o allow ipipe_trace_{frozen|max}_reset from every context (well, at least give it a try and just fail on locked traces) o mark border between valid and invalid trace points o show invalid points border Apply order: ipipe_tracer.update3 ipipe_tracer.update3-1 The front-end to the first change, a modified latency+timerbench will get committed to Xenomai soon. It already works nicely, automatically creating a freeze of the maximum latency turn the benchmark perceives. Jan --- linux-2.6.14.3/kernel/ipipe/tracer.c.orig 2006-01-06 11:13:41.0 +0100 +++ linux-2.6.14.3/kernel/ipipe/tracer.c2006-01-06 20:11:10.0 +0100 @@ -134,10 +134,14 @@ __ipipe_migrate_pre_trace(struct ipipe_t int i; new_tp->trace_pos = pre_trace+1; + for (i = new_tp->trace_pos; i > 0; i--) memcpy(&new_tp->point[WRAP_POINT_NO(new_tp->trace_pos-i)], &old_tp->point[WRAP_POINT_NO(old_pos-i)], sizeof(struct ipipe_trace_point)); + + /* mark the end (i.e. the point before point[0]) invalid */ + new_tp->point[IPIPE_TRACE_POINTS-1].eip = 0; } static notrace struct ipipe_trace_path * @@ -436,21 +440,23 @@ void notrace ipipe_trace_special(unsigne } EXPORT_SYMBOL(ipipe_trace_special); -void ipipe_trace_max_reset(void) +int ipipe_trace_max_reset(void) { int cpu_id; unsigned long flags; struct ipipe_trace_path *path; + int ret = 0; - /* only allowed from root domain (we sync with /proc routines) */ - if (ipipe_current_domain != ipipe_root_domain) - return; - - down(&out_mutex); flags = __ipipe_global_path_lock(); for_each_cpu(cpu_id) { path = &trace_paths[cpu_id][max_path[cpu_id]]; + + if (path->dump_lock) { + ret = -EBUSY; + break; + } + path->begin = -1; path->end = -1; path->trace_pos = 0; @@ -458,25 +464,28 @@ void ipipe_trace_max_reset(void) } __ipipe_global_path_unlock(flags); - up(&out_mutex); + + return ret; } EXPORT_SYMBOL(ipipe_trace_max_reset); -void ipipe_trace_frozen_reset(void) +int ipipe_trace_frozen_reset(void) { int cpu_id; unsigned long flags; struct ipipe_trace_path *path; + int ret = 0; - /* only allowed from root domain (we sync with /proc routines) */ - if (ipipe_current_domain != ipipe_root_domain) - return; - - down(&out_mutex); flags = __ipipe_global_path_lock(); for_each_cpu(cpu_id) { path = &trace_paths[cpu_id][frozen_path[cpu_id]]; + + if (path->dump_lock) { + ret = -EBUSY; + break; + } + path->begin = -1; path->end = -1; path->trace_pos = 0; @@ -484,7 +493,8 @@ void ipipe_trace_frozen_reset(void) } __ipipe_global_path_unlock(flags); - up(&out_mutex); + + return ret; } EXPORT_SYMBOL(ipipe_trace_frozen_reset); @@ -684,8 +694,10 @@ static int __ipipe_prtrace_show(struct s unsigned long long abs_delta; struct ipipe_trace_point *point = p; - if (!point->eip) + if (!point->eip) { + seq_puts(m, "--\n"); return 0; + } /* ipipe_tsc2us works on unsigned => handle sign separately */ delta = point->timestamp - @@ -749,7 +761,10 @@ static ssize_t __ipipe_max_reset(struct file *file, const char __user *pbuffer, size_t count, loff_t *data) { + down(&out_mutex); ipipe_trace_max_reset(); + up(&out_mutex
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Heikki Lindholm wrote: > Jan Kiszka kirjoitti: > >> Heikki Lindholm wrote: >> >>> Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but >>> not yet set last_task_used_math to NULL. As a result the tasks MSR_FP >>> will get set, although it should be cleared. If the task happens to hit >>> one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU >>> state might be saved to the task. The attached patch should fix this. I >>> couldn't try it on most recent Xenomai trunk, because latency wouldn't >>> build anymore. However, I see no reason it shouldn't work. All thee >> >> >> >> Is it still broken with latest revision 376? Philippe had merged the fix >> for my mess, and it worked at least for 2.6 on my box again. > > > I'd say this has been unchanged since the beginning (0.9?). > Then, what latency are we talking about? My last modifications went to src/testsuite/latency. Did you mean ksrc/skins/native/demos/latency.c? Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Jan Kiszka kirjoitti: Heikki Lindholm wrote: Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but not yet set last_task_used_math to NULL. As a result the tasks MSR_FP will get set, although it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee Is it still broken with latest revision 376? Philippe had merged the fix for my mess, and it worked at least for 2.6 on my box again. I'd say this has been unchanged since the beginning (0.9?). -- hl ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: [PATCH] latency tracer update
Jan Kiszka wrote: > ... > Meanwhile I found a solution for the described unterminated trace (put > an explicite trace_end at the end of __ipipe_unstall_iret_root), > included the irq number in the begin/end report, and stumbled over some > other remaining unterminated trace on a different machine. So, no need > to hurry with the merge (not the review! ;) ), I will publish a second > revision first. > And here comes this revision finally. Should apply (almost) cleanly against latest ipipe versions. Additionally to the changes of the first revision this one addresses the following topics: o fix trace overrun handling o report IRQ number to tracer on IRQ entry/exit o fix virtually leaking IRQs-off in __ipipe_unstall_iret_root() o fix another potential NMI race o really trace the maximum IRQs-off time, not the maximum time of consecutive IRQs-off times (that scenario will soon be addressed instead in the latency benchmark tool => reset&freeze the maximum latency from the user's point of view) o remove the ipipe_trace_special reporting in local_irq_xxx trace points (cleans up the traces inside IRQ-off paths) The tracer has undergone a significant number of tests now and it really looks like it is stable. I will now have to fix/improve some minor issues on the Xenomai side regarding tracing. Jan --- linux-2.6.14.3/arch/i386/kernel/entry.S.orig2006-01-03 19:30:15.0 +0100 +++ linux-2.6.14.3/arch/i386/kernel/entry.S 2006-01-05 03:37:24.0 +0100 @@ -106,6 +106,33 @@ VM_MASK= 0x0002 call __ipipe_divert_exception ; \ testl %eax,%eax ; \ jnz restore_raw + +#ifdef CONFIG_IPIPE_TRACE_IRQSOFF +# ifdef CONFIG_REGPARM +# define LOAD_ARG +# define REMOVE_ARG +# else /* !CONFIG_REGPARM */ +# define LOAD_ARG pushl %eax +# define REMOVE_ARGaddl $4, %esp +# endif /* CONFIG_REGPARM */ +# define IPIPE_TRACE_IRQ_ENTER \ + lea EIP-4(%esp), %ebp; \ + movl ORIG_EAX(%esp), %eax; \ + LOAD_ARG; \ + call ipipe_trace_begin; \ + REMOVE_ARG +# define IPIPE_TRACE_IRQ_EXIT \ + pushl %eax; \ + movl ORIG_EAX+4(%esp), %eax; \ + LOAD_ARG; \ + call ipipe_trace_end; \ + REMOVE_ARG; \ + popl %eax +#else /* !CONFIG_IPIPE_TRACE_IRQSOFF */ +# define IPIPE_TRACE_IRQ_ENTER +# define IPIPE_TRACE_IRQ_EXIT +#endif /* CONFIG_IPIPE_TRACE_IRQSOFF */ + #else /* !CONFIG_IPIPE */ #define CLI cli #define STI sti @@ -474,7 +501,9 @@ vector=vector+1 ALIGN common_interrupt: SAVE_ALL + IPIPE_TRACE_IRQ_ENTER; \ call __ipipe_handle_irq + IPIPE_TRACE_IRQ_EXIT; \ testl %eax,%eax jnz ret_from_intr RESTORE_REGS @@ -485,7 +514,9 @@ common_interrupt: ENTRY(name)\ pushl $nr-288; /* nr - (256 + FIRST_EXTERNAL_VECTOR) */ \ SAVE_ALL; \ + IPIPE_TRACE_IRQ_ENTER; \ call __ipipe_handle_irq;\ + IPIPE_TRACE_IRQ_EXIT; \ testl %eax,%eax;\ jnz ret_from_intr; \ RESTORE_REGS; \ --- linux-2.6.14.3/arch/i386/kernel/ipipe-root.c.orig 2006-01-02 20:42:58.0 +0100 +++ linux-2.6.14.3/arch/i386/kernel/ipipe-root.c2006-01-06 02:47:31.0 +0100 @@ -283,7 +283,7 @@ asmlinkage int __ipipe_kpreempt_root(str } __ipipe_stall_root(); - local_irq_enable_hw(); + local_irq_enable_hw_notrace(); return 1; /* Ok, may reschedule now. */ } @@ -320,6 +320,9 @@ asmlinkage void __ipipe_unstall_iret_roo irq_pending_hi & IPIPE_IRQMASK_VIRT) != 0) __ipipe_sync_stage(IPIPE_IRQMASK_VIRT); } +#ifdef CONFIG_IPIPE_TRACE_IRQSOFF + ipipe_trace_end(0x800D); +#endif /* CONFIG_IPIPE_TRACE_IRQSOFF */ } asmlinkage int __ipipe_syscall_root(struct pt_regs regs) --- linux-2.6.14.3/kernel/ipipe/tracer.c.orig 2006-01-02 20:44:21.0 +0100 +++ linux-2.6.14.3/kernel/ipipe/tracer.c2006-01-06 02:35:08.0 +0100 @@ -47,8 +47,10 @@ #define IPIPE_TFLG_NMI_LOCK 0x0001 #define IPIPE_TFLG_NMI_HIT 0x0002 -#define IPIPE_TFLG_HWIRQ_OFF0x0004 -#define IPIPE_TFLG_FREEZING 0x0008 +#define IPIPE_TFLG_NMI_FREEZE_REQ 0x0004 + +#define IPIPE_TFLG_HWIRQ_OFF0x0100 +#define IPIPE_TFLG_FREEZING 0x0200 struct ipipe_trace_point{ @@ -63,10 +65,13 @@ struct ipipe_trace_point{ struct ipipe_trace_path{ volatile int flags; int dump_lock; /* separated from flags due to cross-cpu access */ - int trace_pos; - int begin, end; - int post_trace; - unsigned long long length; + int trace_pos; /* next point to fill */ + int begin, end; /* finalised path begin and end */ + int post_t
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Heikki Lindholm wrote: > Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but > not yet set last_task_used_math to NULL. As a result the tasks MSR_FP > will get set, although it should be cleared. If the task happens to hit > one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU > state might be saved to the task. The attached patch should fix this. I > couldn't try it on most recent Xenomai trunk, because latency wouldn't > build anymore. However, I see no reason it shouldn't work. All thee Is it still broken with latest revision 376? Philippe had merged the fix for my mess, and it worked at least for 2.6 on my box again. > having trouble with X and Xenomai, give this a shot. > > -- Heikki Lindholm > Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Problem with #define uint "i"
Hallo, when trying to build RTnet with Xenomai and Linux 2.4.25 for PowerPC, I stumbeld over the following problem: In "linuxppc_2_4_devel/include/asm-generic/xenomai/wrappers.h" there is defined: #define ulong "i" #define uint "i" This makes trouble when a driver uses the types uint or ulong, which is the case for the MPC RTnet drivers. Can we use different names for the above definitions? Thanks. Wolfgang.
[Xenomai-core] [PATCH] Fix ppc fpu support
Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but not yet set last_task_used_math to NULL. As a result the tasks MSR_FP will get set, although it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee having trouble with X and Xenomai, give this a shot. -- Heikki Lindholm diff -Nru xenomai/include/asm-powerpc/system.h xenomai-devel/include/asm-powerpc/system.h --- xenomai/include/asm-powerpc/system.h2006-01-06 15:55:19.0 +0200 +++ xenomai-devel/include/asm-powerpc/system.h 2006-01-06 16:44:53.0 +0200 @@ -55,6 +55,7 @@ rthal_fpenv_t fpuenv __attribute__ ((aligned (16))); rthal_fpenv_t *fpup; /* Pointer to the FPU backup area */ struct task_struct *user_fpu_owner; +unsigned long user_fpu_owner_prev_msr; /* Pointer the the FPU owner in userspace: - NULL for RT K threads, - last_task_used_math for Linux US threads (only current or NULL when MP) @@ -368,7 +369,10 @@ rthal_save_fpu(tcb->fpup); if(tcb->user_fpu_owner && tcb->user_fpu_owner->thread.regs) +{ +tcb->user_fpu_owner_prev_msr = tcb->user_fpu_owner->thread.regs->msr; tcb->user_fpu_owner->thread.regs->msr &= ~MSR_FP; +} } #endif /* CONFIG_XENO_HW_FPU */ @@ -383,7 +387,13 @@ { rthal_restore_fpu(tcb->fpup); -if(tcb->user_fpu_owner && tcb->user_fpu_owner->thread.regs) + /* Note: Only enable FP in MSR, if it was enabled when we saved the +* fpu state. We might have preempted Linux when it had disabled FP +* for the thread, but not yet set last_task_used_math to NULL +*/ +if(tcb->user_fpu_owner && + tcb->user_fpu_owner->thread.regs && + ((tcb->user_fpu_owner_prev_msr & MSR_FP) != 0)) tcb->user_fpu_owner->thread.regs->msr |= MSR_FP; } ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: Oops, I broke something
Jan Kiszka wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: > Jan Kiszka wrote: > > But this raised the question to me again if we really need the "xenomai" > > prefix for all the skin headers /from within xenomai/. Why not doing the > > same linking dance for the other skins as well? Or do you also prefer > > that user include instead of just ? > > We need this for building from within the kernel. Other options would > require to either alter the Xenomai source tree adding symlinks there, > pollute linux/include with symlinks to reach the individual Xeno > components, or refer to some external tree that eventually redirects to > the Xenomai tree, which is not acceptable in any case. Maybe we could add EXTRA_CFLAGS=-I$(TOPDIR)/include/xenomai to every xenomai kernel makefile Yes, I would preferably merge that instead of playing with symlinks. and to the cflags returned by xeno-config for kernel-space applications ? There no such support in xeno-config anymore. Kernel module flags and dependencies now exclusively belong to the kernel build system; xeno-config is only relevant for building user-space apps. Actually, my concerns only targeted the userspace applications, more precisely those few being built inside the xeno tree. External user apps can still use the standard, non-prefixed headers. Thus my idea was to unify the includes for those in-tree applications so that users who are taking them as reference only see the standard way. Ack, but this is a matter of general consistency. Now that the issue is raised and that we need to address it, it's better if we don't have to fiddle with exception cases uselessly, so using the proper include directives for both internal/external cases is the best way to go; provided it works, but it should. External kernel applications and drivers can and should catch this prefix by adding /include/xenomai to their makefiles. Jan -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: Oops, I broke something
Philippe Gerum wrote: > Gilles Chanteperdrix wrote: > >> Philippe Gerum wrote: >> > Jan Kiszka wrote: >> > > But this raised the question to me again if we really need the >> "xenomai" >> > > prefix for all the skin headers /from within xenomai/. Why not >> doing the >> > > same linking dance for the other skins as well? Or do you also >> prefer >> > > that user include instead of just >> ? >> > > We need this for building from within the kernel. Other options >> would > require to either alter the Xenomai source tree adding >> symlinks there, > pollute linux/include with symlinks to reach the >> individual Xeno > components, or refer to some external tree that >> eventually redirects to > the Xenomai tree, which is not acceptable >> in any case. >> >> Maybe we could add EXTRA_CFLAGS=-I$(TOPDIR)/include/xenomai to every >> xenomai kernel makefile > > > Yes, I would preferably merge that instead of playing with symlinks. > > and to the cflags returned by xeno-config for > >> kernel-space applications ? >> > > There no such support in xeno-config anymore. Kernel module flags and > dependencies now exclusively belong to the kernel build system; > xeno-config is only relevant for building user-space apps. > Actually, my concerns only targeted the userspace applications, more precisely those few being built inside the xeno tree. External user apps can still use the standard, non-prefixed headers. Thus my idea was to unify the includes for those in-tree applications so that users who are taking them as reference only see the standard way. External kernel applications and drivers can and should catch this prefix by adding /include/xenomai to their makefiles. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: Oops, I broke something
Gilles Chanteperdrix wrote: Philippe Gerum wrote: > Jan Kiszka wrote: > > But this raised the question to me again if we really need the "xenomai" > > prefix for all the skin headers /from within xenomai/. Why not doing the > > same linking dance for the other skins as well? Or do you also prefer > > that user include instead of just ? > > We need this for building from within the kernel. Other options would > require to either alter the Xenomai source tree adding symlinks there, > pollute linux/include with symlinks to reach the individual Xeno > components, or refer to some external tree that eventually redirects to > the Xenomai tree, which is not acceptable in any case. Maybe we could add EXTRA_CFLAGS=-I$(TOPDIR)/include/xenomai to every xenomai kernel makefile While checking the 2.4 builds for ppc and x86, I stumbled upon cases where we do need this fix right now (e.g. benchmark and 16550A drivers). So I will handle this global change right after -rc2 is out. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with #define uint "i"
Wolfgang Grandegger wrote: Hallo, when trying to build RTnet with Xenomai and Linux 2.4.25 for PowerPC, I stumbeld over the following problem: In "linuxppc_2_4_devel/include/asm-generic/xenomai/wrappers.h" there is defined: #define ulong "i" #define uint "i" This makes trouble when a driver uses the types uint or ulong, which is the case for the MPC RTnet drivers. Can we use different names for the above definitions? Yes, will fix in Xenomai. Actually, since module_param() has been backported in its simplest forms to 2.4, the above hack should be useless. Thanks. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: Oops, I broke something
Gilles Chanteperdrix wrote: Philippe Gerum wrote: > Jan Kiszka wrote: > > But this raised the question to me again if we really need the "xenomai" > > prefix for all the skin headers /from within xenomai/. Why not doing the > > same linking dance for the other skins as well? Or do you also prefer > > that user include instead of just ? > > We need this for building from within the kernel. Other options would > require to either alter the Xenomai source tree adding symlinks there, > pollute linux/include with symlinks to reach the individual Xeno > components, or refer to some external tree that eventually redirects to > the Xenomai tree, which is not acceptable in any case. Maybe we could add EXTRA_CFLAGS=-I$(TOPDIR)/include/xenomai to every xenomai kernel makefile Yes, I would preferably merge that instead of playing with symlinks. and to the cflags returned by xeno-config for kernel-space applications ? There no such support in xeno-config anymore. Kernel module flags and dependencies now exclusively belong to the kernel build system; xeno-config is only relevant for building user-space apps. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: Oops, I broke something
Philippe Gerum wrote: > Jan Kiszka wrote: > > But this raised the question to me again if we really need the "xenomai" > > prefix for all the skin headers /from within xenomai/. Why not doing the > > same linking dance for the other skins as well? Or do you also prefer > > that user include instead of just ? > > We need this for building from within the kernel. Other options would > require to either alter the Xenomai source tree adding symlinks there, > pollute linux/include with symlinks to reach the individual Xeno > components, or refer to some external tree that eventually redirects to > the Xenomai tree, which is not acceptable in any case. Maybe we could add EXTRA_CFLAGS=-I$(TOPDIR)/include/xenomai to every xenomai kernel makefile and to the cflags returned by xeno-config for kernel-space applications ? -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: Oops, I broke something
Jan Kiszka wrote: Hi Philippe, my RTDM header "optimisation" broke the compilation of testsuite/latency. I need an extra link for the userspace compilation inside xeno now. Please apply this patch --- configure.in(Revision 372) +++ configure.in(Arbeitskopie) @@ -348,6 +348,8 @@ base=include AC_CONFIG_LINKS([src/include/xenomai:$base]) +base=rtdm +AC_CONFIG_LINKS([src/include/$base:include/$base]) base=asm-$XENO_TARGET_ARCH AC_CONFIG_LINKS([src/include/asm/xenomai:include/$base]) base=asm-generic and run bootstrap. Sorry. But this raised the question to me again if we really need the "xenomai" prefix for all the skin headers /from within xenomai/. Why not doing the same linking dance for the other skins as well? Or do you also prefer that user include instead of just ? Nope, people writing apps should not have to handle our internal issues, asking them to prefix with xenomai/ is not an option. Jan -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: Oops, I broke something
Jan Kiszka wrote: Hi Philippe, my RTDM header "optimisation" broke the compilation of testsuite/latency. I need an extra link for the userspace compilation inside xeno now. Please apply this patch --- configure.in(Revision 372) +++ configure.in(Arbeitskopie) @@ -348,6 +348,8 @@ base=include AC_CONFIG_LINKS([src/include/xenomai:$base]) +base=rtdm +AC_CONFIG_LINKS([src/include/$base:include/$base]) base=asm-$XENO_TARGET_ARCH AC_CONFIG_LINKS([src/include/asm/xenomai:include/$base]) base=asm-generic and run bootstrap. Sorry. But this raised the question to me again if we really need the "xenomai" prefix for all the skin headers /from within xenomai/. Why not doing the same linking dance for the other skins as well? Or do you also prefer that user include instead of just ? We need this for building from within the kernel. Other options would require to either alter the Xenomai source tree adding symlinks there, pollute linux/include with symlinks to reach the individual Xeno components, or refer to some external tree that eventually redirects to the Xenomai tree, which is not acceptable in any case. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Oops, I broke something
Hi Philippe, my RTDM header "optimisation" broke the compilation of testsuite/latency. I need an extra link for the userspace compilation inside xeno now. Please apply this patch --- configure.in(Revision 372) +++ configure.in(Arbeitskopie) @@ -348,6 +348,8 @@ base=include AC_CONFIG_LINKS([src/include/xenomai:$base]) +base=rtdm +AC_CONFIG_LINKS([src/include/$base:include/$base]) base=asm-$XENO_TARGET_ARCH AC_CONFIG_LINKS([src/include/asm/xenomai:include/$base]) base=asm-generic and run bootstrap. Sorry. But this raised the question to me again if we really need the "xenomai" prefix for all the skin headers /from within xenomai/. Why not doing the same linking dance for the other skins as well? Or do you also prefer that user include instead of just ? Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [Adeos-main] Re: [PATCH] latency tracer update
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Hi again, here comes the first update of the new latency tracer. arch/i386/kernel/entry.S | 27 +++ Is there any good reason to patch the callers of __ipipe_handle_irq instead of instrumenting the callee directly? To capture the invocation delay of __ipipe_handle_irq itself. Ok. arch/i386/kernel/ipipe-root.c |4 include/asm-i386/system.h | 70 + include/linux/ipipe_trace.h |3 kernel/ipipe/Kconfig | 18 ++ kernel/ipipe/tracer.c | 247 +++--- 6 files changed, 288 insertions(+), 81 deletions(-) Meanwhile I found a solution for the described unterminated trace (put an explicite trace_end at the end of __ipipe_unstall_iret_root), Yeah, sorry for the delay in answering. That's indeed the way to do it. included the irq number in the begin/end report, and stumbled over some other remaining unterminated trace on a different machine. So, no need to hurry with the merge (not the review! ;) ), I will publish a second revision first. Jan ___ Adeos-main mailing list [EMAIL PROTECTED] https://mail.gna.org/listinfo/adeos-main -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: [PATCH] latency tracer update
Jan Kiszka wrote: > ... > Meanwhile I found a solution for the described unterminated trace (put > an explicite trace_end at the end of __ipipe_unstall_iret_root), > included the irq number in the begin/end report, and stumbled over some > other remaining unterminated trace on a different machine. So, no need > to hurry with the merge (not the review! ;) ), I will publish a second > revision first. > And here comes this revision finally. Should apply (almost) cleanly against latest ipipe versions. Additionally to the changes of the first revision this one addresses the following topics: o fix trace overrun handling o report IRQ number to tracer on IRQ entry/exit o fix virtually leaking IRQs-off in __ipipe_unstall_iret_root() o fix another potential NMI race o really trace the maximum IRQs-off time, not the maximum time of consecutive IRQs-off times (that scenario will soon be addressed instead in the latency benchmark tool => reset&freeze the maximum latency from the user's point of view) o remove the ipipe_trace_special reporting in local_irq_xxx trace points (cleans up the traces inside IRQ-off paths) The tracer has undergone a significant number of tests now and it really looks like it is stable. I will now have to fix/improve some minor issues on the Xenomai side regarding tracing. Jan --- linux-2.6.14.3/arch/i386/kernel/entry.S.orig2006-01-03 19:30:15.0 +0100 +++ linux-2.6.14.3/arch/i386/kernel/entry.S 2006-01-05 03:37:24.0 +0100 @@ -106,6 +106,33 @@ VM_MASK= 0x0002 call __ipipe_divert_exception ; \ testl %eax,%eax ; \ jnz restore_raw + +#ifdef CONFIG_IPIPE_TRACE_IRQSOFF +# ifdef CONFIG_REGPARM +# define LOAD_ARG +# define REMOVE_ARG +# else /* !CONFIG_REGPARM */ +# define LOAD_ARG pushl %eax +# define REMOVE_ARGaddl $4, %esp +# endif /* CONFIG_REGPARM */ +# define IPIPE_TRACE_IRQ_ENTER \ + lea EIP-4(%esp), %ebp; \ + movl ORIG_EAX(%esp), %eax; \ + LOAD_ARG; \ + call ipipe_trace_begin; \ + REMOVE_ARG +# define IPIPE_TRACE_IRQ_EXIT \ + pushl %eax; \ + movl ORIG_EAX+4(%esp), %eax; \ + LOAD_ARG; \ + call ipipe_trace_end; \ + REMOVE_ARG; \ + popl %eax +#else /* !CONFIG_IPIPE_TRACE_IRQSOFF */ +# define IPIPE_TRACE_IRQ_ENTER +# define IPIPE_TRACE_IRQ_EXIT +#endif /* CONFIG_IPIPE_TRACE_IRQSOFF */ + #else /* !CONFIG_IPIPE */ #define CLI cli #define STI sti @@ -474,7 +501,9 @@ vector=vector+1 ALIGN common_interrupt: SAVE_ALL + IPIPE_TRACE_IRQ_ENTER; \ call __ipipe_handle_irq + IPIPE_TRACE_IRQ_EXIT; \ testl %eax,%eax jnz ret_from_intr RESTORE_REGS @@ -485,7 +514,9 @@ common_interrupt: ENTRY(name)\ pushl $nr-288; /* nr - (256 + FIRST_EXTERNAL_VECTOR) */ \ SAVE_ALL; \ + IPIPE_TRACE_IRQ_ENTER; \ call __ipipe_handle_irq;\ + IPIPE_TRACE_IRQ_EXIT; \ testl %eax,%eax;\ jnz ret_from_intr; \ RESTORE_REGS; \ --- linux-2.6.14.3/arch/i386/kernel/ipipe-root.c.orig 2006-01-02 20:42:58.0 +0100 +++ linux-2.6.14.3/arch/i386/kernel/ipipe-root.c2006-01-06 02:47:31.0 +0100 @@ -283,7 +283,7 @@ asmlinkage int __ipipe_kpreempt_root(str } __ipipe_stall_root(); - local_irq_enable_hw(); + local_irq_enable_hw_notrace(); return 1; /* Ok, may reschedule now. */ } @@ -320,6 +320,9 @@ asmlinkage void __ipipe_unstall_iret_roo irq_pending_hi & IPIPE_IRQMASK_VIRT) != 0) __ipipe_sync_stage(IPIPE_IRQMASK_VIRT); } +#ifdef CONFIG_IPIPE_TRACE_IRQSOFF + ipipe_trace_end(0x800D); +#endif /* CONFIG_IPIPE_TRACE_IRQSOFF */ } asmlinkage int __ipipe_syscall_root(struct pt_regs regs) --- linux-2.6.14.3/kernel/ipipe/tracer.c.orig 2006-01-02 20:44:21.0 +0100 +++ linux-2.6.14.3/kernel/ipipe/tracer.c2006-01-06 02:35:08.0 +0100 @@ -47,8 +47,10 @@ #define IPIPE_TFLG_NMI_LOCK 0x0001 #define IPIPE_TFLG_NMI_HIT 0x0002 -#define IPIPE_TFLG_HWIRQ_OFF0x0004 -#define IPIPE_TFLG_FREEZING 0x0008 +#define IPIPE_TFLG_NMI_FREEZE_REQ 0x0004 + +#define IPIPE_TFLG_HWIRQ_OFF0x0100 +#define IPIPE_TFLG_FREEZING 0x0200 struct ipipe_trace_point{ @@ -63,10 +65,13 @@ struct ipipe_trace_point{ struct ipipe_trace_path{ volatile int flags; int dump_lock; /* separated from flags due to cross-cpu access */ - int trace_pos; - int begin, end; - int post_trace; - unsigned long long length; + int trace_pos; /* next point to fill */ + int begin, end; /* finalised path begin and end */ + int post_t
[Xenomai-core] Problem with #define uint "i"
Hallo, when trying to build RTnet with Xenomai and Linux 2.4.25 for PowerPC, I stumbeld over the following problem: In "linuxppc_2_4_devel/include/asm-generic/xenomai/wrappers.h" there is defined: #define ulong "i" #define uint "i" This makes trouble when a driver uses the types uint or ulong, which is the case for the MPC RTnet drivers. Can we use different names for the above definitions? Thanks. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core