Re: [Xenomai-core] Basic Xenomai Questions?
On Sat, 2009-10-31 at 16:19 -0700, Wael Showair wrote: Thanks philippe for ur reply, i have already read this part but i am little confused about the same 2 questions i have sent __ From: Philippe Gerum r...@xenomai.org To: Wael Showair showair2...@yahoo.com Cc: Xenomai-core@gna.org Sent: Sat, October 31, 2009 1:01:59 PM Subject: Re: [Xenomai-core] Basic Xenomai Questions? On Fri, 2009-10-30 at 18:22 -0700, Wael Showair wrote: Hi All, i am beginner to Xenomai i m trying to understand how will it go in the future so i have 2 questions: 1. the patch of Adeos just enables the sharing of hardware between different OS, (Linux Vanilla kernel Xenomai Nucleus), does it make this step only? Yes, but in a limited form. It simply enables interrupts, exceptions and syscalls to be controlled on a per-OS basis, and prioritized. This is by no mean a complete bare metal hypervisor. 2. In Xenomai 2, there r 2 different kernels Normal Linux Vanilla Xenomai Nucleus, but i read that Xenomai 3 will tend to use PREEMPT_RT support which leads to the only one Native kernel will exist, does it mean that the Nucleus will vanish will it be the patched RT Vanilla Linux Kernel itself? The roadmap explicitly states there that the dual kernel approach will be kept, and the ability to run over -rt will be introduced. There is no one-fits-it-all solution, for all hw and sw combos, for all use cases, so we must keep the two options open. or does it mean that the Nuecleuse will no longer be a part of the kernel space so it will be in user space? The nucleus is currently two parts: - a real-time enabling core; the thing that provides a RTOS stack running side-by-side with a non-RT Linux. This layer is tightly coupled with Adeos. Both cooperate to make a Linux system real-time aware via a dual kernel architecture. - an emulation core; a set of basic building blocks for implementing RTOS APIs of all sorts. This is somewhat equivalent to a kernel API, but with semantics close to traditional RTOS ones. When X3 runs over -rt, -rt is fully in charge of providing real-time guarantees. So neither Adeos nor the real-time enabling part of the nucleus will be used in this context, and a userland implementation of its emulation core will appear. The only remaining piece of Xenomai code running in kernel space should be a native RTDM module, to natively support real-time drivers coming from the dual kernel world, fully relying on the regular kernel services. I beleive in the nucleus of Xenomai must exist in all cases? An emulation core must exist in all cases, in order to support real-time APIs. With -rt, that core will support all APIs; in dual kernel mode, it will support those APIs but the POSIX and Xenomai/native ones, which will still be directly based on the nucleus services as they are today. The connection between the emulation core in userland and the RTOS services in kernel space will be the POSIX API, the standard NPTL one with -rt, the Xenomai POSIX API in dual kernel mode. A prototype for the userland emulation core already exists, it's the Xenomai/SOLO base library. http://git.denx.de/?p=xenomai-solo.git;a=tree It will be extended for X3, but the main logic is already there. http://www.xenomai.org/index.php/Xenomai:Roadmap#Toward_Xenomai_3 Regards, Wael ___ 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 -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] Check frequency in xnarch_init_timeconv()
In some conditions, while testing Xenomai in VirtualBox, I had the error that
xnarch_init_timeconv() is called from init_32.h with a frequency of 0. That
leads to a division by zero, followed by a system oops.
Of course that is a bug in the virtualisation and Linux reports a CPU frequency
of 0 in /proc/cpuinfo. However, there's no harm if Xenomai checks that instead
of crashing the whole system.
Signed-off-by: Bernhard Walle bernh...@bwalle.de
include/asm-arm/bits/init.h | 4 +++-
include/asm-blackfin/bits/init.h| 4 +++-
include/asm-generic/bits/timeconv.h | 18 +-
include/asm-nios2/bits/init.h | 4 +++-
include/asm-powerpc/bits/init.h | 4 +++-
include/asm-x86/bits/init_32.h | 4 +++-
include/asm-x86/bits/init_64.h | 4 +++-
src/skins/native/timer.c| 7 ++-
src/skins/posix/clock.c | 8 +++-
9 files changed, 48 insertions(+), 9 deletions(-)
In some conditions, while testing Xenomai in VirtualBox, I had the error that
xnarch_init_timeconv() is called from init_32.h with a frequency of 0. That
leads to a division by zero, followed by a system oops.
Of course that is a bug in the virtualisation and Linux reports a CPU frequency
of 0 in /proc/cpuinfo. However, there's no harm if Xenomai checks that instead
of crashing the whole system.
Signed-off-by: Bernhard Walle bernh...@bwalle.de
diff --git a/include/asm-arm/bits/init.h b/include/asm-arm/bits/init.h
--- a/include/asm-arm/bits/init.h
+++ b/include/asm-arm/bits/init.h
@@ -82,7 +82,9 @@
set_cpus_allowed(current, cpumask_of_cpu(0));
#endif /* CONFIG_SMP MODULE */
- xnarch_init_timeconv(RTHAL_CPU_FREQ);
+ ret = xnarch_init_timeconv(RTHAL_CPU_FREQ);
+ if (ret)
+ return ret;
ret = xnarch_calibrate_sched();
if (ret)
diff --git a/include/asm-blackfin/bits/init.h b/include/asm-blackfin/bits/init.h
--- a/include/asm-blackfin/bits/init.h
+++ b/include/asm-blackfin/bits/init.h
@@ -83,7 +83,9 @@
set_cpus_allowed(current, cpumask_of_cpu(0));
#endif /* CONFIG_SMP MODULE */
- xnarch_init_timeconv(RTHAL_CPU_FREQ);
+ ret = xnarch_init_timeconv(RTHAL_CPU_FREQ);
+ if (ret)
+ return ret;
ret = xnarch_calibrate_sched();
if (ret)
diff --git a/include/asm-generic/bits/timeconv.h b/include/asm-generic/bits/timeconv.h
--- a/include/asm-generic/bits/timeconv.h
+++ b/include/asm-generic/bits/timeconv.h
@@ -100,8 +100,23 @@
}
#endif /* !XNARCH_HAVE_NODIV_LLIMD */
-static inline void xnarch_init_timeconv(unsigned long long freq)
+#ifndef xnarch_logerr
+#define xnarch_logerr(fmt, args...)
+#endif
+
+static inline int xnarch_init_timeconv(unsigned long long freq)
{
+ /*
+ * Division by zero is not defined (and in kernel context, it
+ * especially leads to an oops)
+ */
+ if (freq == 0) {
+ xnarch_logerr(xnarch_init_timeconv called with a
+ frequency of 0. Probably this indicates a
+ broken TSC.);
+ return -EINVAL;
+ }
+
clockfreq = freq;
#ifdef XNARCH_HAVE_LLMULSHFT
xnarch_init_llmulshft(10, freq, tsc_scale, tsc_shift);
@@ -110,6 +125,7 @@
xnarch_init_u32frac(bln_frac, 1, 10);
#endif
#endif
+ return 0;
}
#ifdef __KERNEL__
diff --git a/include/asm-nios2/bits/init.h b/include/asm-nios2/bits/init.h
--- a/include/asm-nios2/bits/init.h
+++ b/include/asm-nios2/bits/init.h
@@ -72,7 +72,9 @@
if (ret)
return ret;
- xnarch_init_timeconv(RTHAL_CLOCK_FREQ);
+ ret = xnarch_init_timeconv(RTHAL_CLOCK_FREQ);
+ if (ret)
+ return ret;
ret = xnarch_calibrate_sched();
if (ret)
diff --git a/include/asm-powerpc/bits/init.h b/include/asm-powerpc/bits/init.h
--- a/include/asm-powerpc/bits/init.h
+++ b/include/asm-powerpc/bits/init.h
@@ -82,7 +82,9 @@
set_cpus_allowed(current, cpumask_of_cpu(0));
#endif /* CONFIG_SMP MODULE */
- xnarch_init_timeconv(RTHAL_CPU_FREQ);
+ ret = xnarch_init_timeconv(RTHAL_CPU_FREQ);
+ if (ret)
+ return ret;
ret = xnarch_calibrate_sched();
if (ret)
diff --git a/include/asm-x86/bits/init_32.h b/include/asm-x86/bits/init_32.h
--- a/include/asm-x86/bits/init_32.h
+++ b/include/asm-x86/bits/init_32.h
@@ -88,7 +88,9 @@
set_cpus_allowed(current, cpumask_of_cpu(0));
#endif /* CONFIG_SMP MODULE */
- xnarch_init_timeconv(RTHAL_CPU_FREQ);
+ ret = xnarch_init_timeconv(RTHAL_CPU_FREQ);
+ if (ret)
+ return ret;
ret = xnarch_calibrate_sched();
if (ret)
diff --git a/include/asm-x86/bits/init_64.h b/include/asm-x86/bits/init_64.h
--- a/include/asm-x86/bits/init_64.h
+++ b/include/asm-x86/bits/init_64.h
@@ -85,7 +85,9 @@
set_cpus_allowed(current, cpumask_of_cpu(0));
#endif /* CONFIG_SMP MODULE */
- xnarch_init_timeconv(RTHAL_CPU_FREQ);
+ ret = xnarch_init_timeconv(RTHAL_CPU_FREQ);
+ if (ret)
+ return ret;
ret = xnarch_calibrate_sched();
if (ret)
diff --git a/src/skins/native/timer.c b/src/skins/native/timer.c
--- a/src/skins/native/timer.c
+++ b/src/skins/native/timer.c
@@ -35,7 +35,12 @@
exit(EXIT_FAILURE);
}
- xnarch_init_timeconv(sysinfo.cpufreq);
+
Re: [Xenomai-core] [PATCH] Check frequency in xnarch_init_timeconv()
On Sun, 2009-11-01 at 19:58 +, Bernhard Walle wrote: In some conditions, while testing Xenomai in VirtualBox, I had the error that xnarch_init_timeconv() is called from init_32.h with a frequency of 0. That leads to a division by zero, followed by a system oops. Of course that is a bug in the virtualisation and Linux reports a CPU frequency of 0 in /proc/cpuinfo. However, there's no harm if Xenomai checks that instead of crashing the whole system. I agree with the conclusion, not with the fix. - the userland part reuses the frequency value returned by the nucleus, so testing the issue up front when the nucleus initializes would be enough. No need to propagate error detection to userland. - the kernel side should rather test RTHAL_CPU_FREQ for consistency in the generic hal init code, and bail out with an error if 0 is detected, since there is no way for the nucleus to operate properly with such setting anyway. It turns out that no change have to be done in xnarch_init_timeconv() which should remain a void routine, but its argument - RTHAL_CPU_FREQ - should rather be tested as early as possible for consistency, directly from kernel space. Signed-off-by: Bernhard Walle bernh...@bwalle.de include/asm-arm/bits/init.h | 4 +++- include/asm-blackfin/bits/init.h| 4 +++- include/asm-generic/bits/timeconv.h | 18 +- include/asm-nios2/bits/init.h | 4 +++- include/asm-powerpc/bits/init.h | 4 +++- include/asm-x86/bits/init_32.h | 4 +++- include/asm-x86/bits/init_64.h | 4 +++- src/skins/native/timer.c| 7 ++- src/skins/posix/clock.c | 8 +++- 9 files changed, 48 insertions(+), 9 deletions(-) ___ 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
[Xenomai-core] lots of mode switches in xenomai-head tree?
Hi, I am working with the latest xenomai-head tree (we need analogy for our NI board ...). Under Xenomai 2.4.8 our code did not have any mode switches. Using the xenomai-head, we get a lot of mode switches. Using he backtrace_symbols_fd, we get print-outs like: xsimulation[0x808553b] [0xe400] /usr/xenomai/lib/librtdk.so.0(assert_nrt+0x85)[0xb7fa2ea5] /usr/xenomai/lib/librtdk.so.0(__wrap_clock_gettime+0x17)[0xb7fa2ef7] xsimulation[0x807cd16] xsimulation[0x807d7fb] /usr/xenomai/lib/libnative.so.3[0xb7fab689] /lib/tls/i686/cmov/libpthread.so.0[0xb7f824ff] /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7e8f49e] Which indicates that the wrapper for clock_gettime causes this trouble, which is also confirmed by commenting clock_gettime out, and the mode switches disappear. Maybe something that needs fixing? Best wishes, -Stefan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] lots of mode switches in xenomai-head tree?
Stefan Schaal wrote: Hi, I am working with the latest xenomai-head tree (we need analogy for our NI board ...). Under Xenomai 2.4.8 our code did not have any mode switches. Using the xenomai-head, we get a lot of mode switches. Using he backtrace_symbols_fd, we get print-outs like: xsimulation[0x808553b] [0xe400] /usr/xenomai/lib/librtdk.so.0(assert_nrt+0x85)[0xb7fa2ea5] /usr/xenomai/lib/librtdk.so.0(__wrap_clock_gettime+0x17)[0xb7fa2ef7] xsimulation[0x807cd16] xsimulation[0x807d7fb] /usr/xenomai/lib/libnative.so.3[0xb7fab689] /lib/tls/i686/cmov/libpthread.so.0[0xb7f824ff] /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7e8f49e] Which indicates that the wrapper for clock_gettime causes this trouble, which is also confirmed by commenting clock_gettime out, and the mode switches disappear. Maybe something that needs fixing? Do you wrap link against the POSIX library, ie. use that skin as well? If not, your code is actually using clock_gettime incorrectly as it then falls back to the Linux service which can trigger syscalls (or even deadlocks when the TSC is used). If you do use libpthread_rt, then my next question is if your work is based on today's git head or some older version not including 4a2cb7b817. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
