[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
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 xenomai/native/task.h instead of just native/task.h? 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] 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 xenomai/native/task.h instead of just native/task.h? 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 linuxsrc/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
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 xenomai/native/task.h instead of just native/task.h? 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 linuxsrc/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] [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
[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 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] 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.
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 = resetfreeze 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_trace; /*
[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.
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 xenomai/native/task.h instead of just native/task.h? 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] 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 xenomai/native/task.h instead of just native/task.h? 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] 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 xenomai/native/task.h instead of just native/task.h? 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 linuxsrc/include/xenomai to their makefiles. Jan signature.asc Description: OpenPGP digital signature
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 xenomai/native/task.h instead of just native/task.h? 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 linuxsrc/include/xenomai to their makefiles. Jan -- Philippe.
[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] [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
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: 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 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] 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
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
