[Xenomai-core] Buildbot: sim fails ../../ksrc/nucleus/pod.c:1440: label `unlock_and_exit' used but not defined
Hi Since February 12 building the sim fails with if ../gcic/gcic -DHAVE_CONFIG_H -I. -I. -I../include -D__IN_XENO__ --gcic-backend=/var/buildbot/bin/sim/libexec/gcic --kernel-code -I./../include -I../../include -g -MT pod.o -MD -MP -MF .deps/pod.Tpo -c -o pod.o ../../ksrc/nucleus/pod.c; \ then mv -f .deps/pod.Tpo .deps/pod.Po; else rm -f .deps/pod.Tpo; exit 1; fi ../../ksrc/nucleus/pod.c:59: warning: parameter names (without types) in function declaration ../../ksrc/nucleus/pod.c:59: warning: data definition has no type or storage class ../../ksrc/nucleus/pod.c: In function `xnpod_suspend_thread': ../../ksrc/nucleus/pod.c:1440: label `unlock_and_exit' used but not defined make[1]: *** [pod.o] Fehler 1 make[1]: Leaving directory `/var/buildbot/slave/sim_f/build/sim/nucleus' For details look at: http://ngiger.dyndns.org/buildbot-full/sim_f/builds/98/step-make_sim/1 Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] buildbot: how to setup for ppc with 2.6.19 kernel?
Hi Compiling ppc fails for me with 2.6.19 kernels. ( I compile on a Pegasos PPC 601 Debian Linux). If I use ARCH=ppc then I get the following error: CHK include/linux/version.h CHK include/linux/utsrelease.h CHK include/linux/compile.h gcc: include/asm/byteorder.h: No such file or directory gcc: no input files CC arch/ppc/xenomai/hal.o arch/ppc/xenomai/hal.c: In function 'rthal_arch_init': arch/ppc/xenomai/hal.c:353: error: invalid type argument of '-' make[1]: *** [arch/ppc/xenomai/hal.o] Fehler 1 Trying to use ARCH=powerpc fails already while configuring the kernel like this: make ARCH=powerpc menuconfig HOSTCC scripts/kconfig/mconf.o HOSTLD scripts/kconfig/mconf scripts/kconfig/mconf arch/powerpc/Kconfig init/Kconfig:564:warning: 'select' used by config symbol 'XENOMAI' refer to undefined symbol 'IPIPE' # # configuration written to .config # And a make gives me make ARCH=powerpc menuconfig HOSTCC scripts/kconfig/mconf.o HOSTLD scripts/kconfig/mconf scripts/kconfig/mconf arch/powerpc/Kconfig init/Kconfig:564:warning: 'select' used by config symbol 'XENOMAI' refer to undefined symbol 'IPIPE' # # configuration written to .config # What is wrong? Did I miss something in my setup? Wrong config? Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Buildbot: sim fails ../../ksrc/nucleus/pod.c:1440: label `unlock_and_exit' used but not defined
On Sun, 2007-02-18 at 13:42 +0100, Niklaus Giger wrote: Hi Since February 12 building the sim fails with if ../gcic/gcic -DHAVE_CONFIG_H -I. -I. -I../include -D__IN_XENO__ --gcic-backend=/var/buildbot/bin/sim/libexec/gcic --kernel-code -I./../include -I../../include -g -MT pod.o -MD -MP -MF .deps/pod.Tpo -c -o pod.o ../../ksrc/nucleus/pod.c; \ then mv -f .deps/pod.Tpo .deps/pod.Po; else rm -f .deps/pod.Tpo; exit 1; fi ../../ksrc/nucleus/pod.c:59: warning: parameter names (without types) in function declaration ../../ksrc/nucleus/pod.c:59: warning: data definition has no type or storage class ../../ksrc/nucleus/pod.c: In function `xnpod_suspend_thread': ../../ksrc/nucleus/pod.c:1440: label `unlock_and_exit' used but not defined make[1]: *** [pod.o] Fehler 1 make[1]: Leaving directory `/var/buildbot/slave/sim_f/build/sim/nucleus' For details look at: http://ngiger.dyndns.org/buildbot-full/sim_f/builds/98/step-make_sim/1 Fixed, thanks. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] buildbot: how to setup for ppc with 2.6.19 kernel?
On Sun, 2007-02-18 at 13:51 +0100, Niklaus Giger wrote: Hi Compiling ppc fails for me with 2.6.19 kernels. ( I compile on a Pegasos PPC 601 Debian Linux). If I use ARCH=ppc then I get the following error: CHK include/linux/version.h CHK include/linux/utsrelease.h CHK include/linux/compile.h gcc: include/asm/byteorder.h: No such file or directory gcc: no input files CC arch/ppc/xenomai/hal.o arch/ppc/xenomai/hal.c: In function 'rthal_arch_init': arch/ppc/xenomai/hal.c:353: error: invalid type argument of '-' make[1]: *** [arch/ppc/xenomai/hal.o] Fehler 1 Fixed, thanks. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] buildbot: how to setup for ppc with 2.6.19 kernel?
Niklaus Giger wrote:
Hi
Compiling ppc fails for me with 2.6.19 kernels.
( I compile on a Pegasos PPC 601 Debian Linux).
If I use ARCH=ppc then I get the following error:
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CHK include/linux/compile.h
gcc: include/asm/byteorder.h: No such file or directory
Hmm, strange.
gcc: no input files
CC arch/ppc/xenomai/hal.o
arch/ppc/xenomai/hal.c: In function 'rthal_arch_init':
arch/ppc/xenomai/hal.c:353: error: invalid type argument of '-'
make[1]: *** [arch/ppc/xenomai/hal.o] Fehler 1
That looks like an altivec problem. Does the attached patch for Xenomai
help?
Trying to use ARCH=powerpc fails already while configuring the kernel
like this:
make ARCH=powerpc menuconfig
HOSTCC scripts/kconfig/mconf.o
HOSTLD scripts/kconfig/mconf
scripts/kconfig/mconf arch/powerpc/Kconfig
init/Kconfig:564:warning: 'select' used by config symbol 'XENOMAI' refer to
undefined symbol 'IPIPE' #
# configuration written to .config
#
And a make gives me
make ARCH=powerpc menuconfig
HOSTCC scripts/kconfig/mconf.o
HOSTLD scripts/kconfig/mconf
scripts/kconfig/mconf arch/powerpc/Kconfig
init/Kconfig:564:warning: 'select' used by config symbol 'XENOMAI' refer to
undefined symbol 'IPIPE' #
# configuration written to .config
#
The powerpc tree is not yet supported.
What is wrong? Did I miss something in my setup? Wrong config?
Seems to be an untested configuration!?
Wolfgang.
+ diff -u xenomai/ksrc/arch/powerpc/hal.c.OLD xenomai/ksrc/arch/powerpc/hal.c
--- xenomai/ksrc/arch/powerpc/hal.c.OLD 2007-02-18 15:25:24.0 +0100
+++ xenomai/ksrc/arch/powerpc/hal.c 2007-02-18 15:46:17.0 +0100
@@ -347,11 +347,7 @@
int rthal_arch_init(void)
{
#ifdef CONFIG_ALTIVEC
-#ifdef CONFIG_PPC64
if (!(cur_cpu_spec-cpu_features CPU_FTR_ALTIVEC)) {
-#else /* !CONFIG_PPC64 */
-if (!(cur_cpu_spec[0]-cpu_features CPU_FTR_ALTIVEC)) {
-#endif /* CONFIG_PPC64 */
printk
(Xenomai: ALTIVEC support enabled in kernel but no hardware found.\n
Disable CONFIG_ALTIVEC in the kernel configuration.\n);
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] buildbot: how to setup for ppc with 2.6.19 kernel?
On Sun, 2007-02-18 at 15:55 +0100, Wolfgang Grandegger wrote: Niklaus Giger wrote: Hi Compiling ppc fails for me with 2.6.19 kernels. ( I compile on a Pegasos PPC 601 Debian Linux). If I use ARCH=ppc then I get the following error: CHK include/linux/version.h CHK include/linux/utsrelease.h CHK include/linux/compile.h gcc: include/asm/byteorder.h: No such file or directory Hmm, strange. gcc: no input files CC arch/ppc/xenomai/hal.o arch/ppc/xenomai/hal.c: In function 'rthal_arch_init': arch/ppc/xenomai/hal.c:353: error: invalid type argument of '-' make[1]: *** [arch/ppc/xenomai/hal.o] Fehler 1 That looks like an altivec problem. Does the attached patch for Xenomai help? It does, but we also need to remain compatible with older kernels (namely 2.6.14 since the ppc64 port is still based on it), so I fixed this by using cpu_has_feature() instead. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [RFC][PATCH 1/2] real-time print library
Philippe Gerum wrote:
ubarrier.h is redundant. include/asm-*/atomic.h is already there for
such purpose.
Here comes version 2 of the patch, getting rid of ubarrier.h
Jan
---
configure.in |1
examples/native/Makefile |8 +
examples/native/rtprint.c | 48
include/Makefile.am |5
include/asm-i386/atomic.h |4
include/rtprint.h | 59 +
src/Makefile.am |2
src/rtprint/Makefile.am | 12 ++
src/rtprint/api.c | 273 ++
src/rtprint/init.c| 75
src/rtprint/internal.h| 69 +++
src/rtprint/output.c | 96
12 files changed, 650 insertions(+), 2 deletions(-)
Index: xenomai/configure.in
===
--- xenomai.orig/configure.in
+++ xenomai/configure.in
@@ -611,6 +611,7 @@ AC_CONFIG_FILES([ \
scripts/xeno-load \
scripts/xeno-test \
src/Makefile \
+ src/rtprint/Makefile \
src/skins/Makefile \
src/skins/posix/Makefile \
src/skins/native/Makefile \
Index: xenomai/examples/native/Makefile
===
--- xenomai.orig/examples/native/Makefile
+++ xenomai/examples/native/Makefile
@@ -1,7 +1,7 @@
## CONFIGURATION ##
### List of applications to be build
-APPLICATIONS = trivial-periodic sigxcpu
+APPLICATIONS = trivial-periodic sigxcpu rtprint
### Note: to override the search path for the xeno-config script, use make XENO=...
@@ -44,6 +44,12 @@ endif
+## SPECIAL TARGET RULES ##
+rtprint: rtprint.c
+ $(CC) $(CFLAGS) $? $(LDFLAGS) -lrtprint -o $@
+
+
+
## KERNEL MODULE BUILD (no change required normally) ##
ifneq ($(MODULES),)
Index: xenomai/examples/native/rtprint.c
===
--- /dev/null
+++ xenomai/examples/native/rtprint.c
@@ -0,0 +1,48 @@
+#include stdio.h
+#include sys/mman.h
+#include native/task.h
+#include rtprint.h
+
+void task2_func(void *arg)
+{
+ int i = 0;
+
+ rt_printf(This triggers auto-init of rt_print for the
+ calling thread.\n
+ A last switch to secondary mode can occure here,
+ but future invocations of rt_printf are safe.\n);
+
+ rt_task_set_mode(0, T_WARNSW, NULL);
+
+ while (1) {
+ rt_task_sleep(333LL);
+ rt_fprintf(stderr, %s: #%d Yet another RT printer -
+ but to stderr.\n, rt_print_buffer_name(), ++i);
+ }
+}
+
+int main(int argc, char **argv)
+{
+ RT_TASK task1, task2;
+ int i = 0;
+
+ mlockall(MCL_CURRENT|MCL_FUTURE);
+
+ /* Perform auto-init of rt_print buffers if the task doesn't do so */
+ rt_print_auto_init(1);
+
+ /* Initialise the rt_print buffer for this task explicitly */
+ rt_print_init(4096, Task 1);
+
+ rt_task_shadow(task1, Task 1, 10, 0);
+ rt_task_spawn(task2, Task 2, 0, 11, 0, task2_func, NULL);
+
+ /* To demonstrate that rt_printf is safe */
+ rt_task_set_mode(0, T_WARNSW, NULL);
+
+ while (1) {
+ rt_task_sleep(500LL);
+ rt_printf(%s: #%d Hello RT world!\n,
+ rt_print_buffer_name(), ++i);
+ }
+}
Index: xenomai/include/Makefile.am
===
--- xenomai.orig/include/Makefile.am
+++ xenomai/include/Makefile.am
@@ -1,3 +1,8 @@
+includedir = $(prefix)/include
+
+include_HEADERS = \
+ rtprint.h
+
nodist_include_HEADERS=$(CONFIG_HEADER)
SUBDIRS = \
Index: xenomai/include/rtprint.h
===
--- /dev/null
+++ xenomai/include/rtprint.h
@@ -0,0 +1,59 @@
+/*
+ * Copyright (C) 2007 Jan Kiszka [EMAIL PROTECTED].
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#ifndef _RTPRINT_H
+#define _RTPRINT_H
+
+#ifdef __KERNEL__
+
+#define rt_printf(format, ...) printk(format __VA_ARGS__)
+
+static inline int rt_print_init(size_t buffer_size, const char *buffer_name)
+{
+ return 0;
+}
+
+#define rt_print_cleanup() do { } while (0)
+
+static inline void rt_print_auto_init(int enable)
+{
+}
+
+static inline const char *rt_print_buffer_name(void)
+{
+ return unknown;
+}
+
+#else /* !__KERNEL__ */
+
+#include stdio.h
+#include stdarg.h
+
+int rt_vfprintf(FILE *stream, const char *format, va_list args);
+int rt_vprintf(const char
Re: [Xenomai-core] Re: Extended CAN frame filtering
Wolfgang Grandegger wrote: ... Attached is a revised patch including change log entry. As this patch just extends the existing filter capabilities, it could be applied to trunk and the 2.3.x branch as well. You are just forgetting the other changes to the filter mechanism you implemented. Thanks for the patch, I just merged your patch into trunk. For v2.3.x, I applied my first patch I sent on Wednesday to align it to what was specified on release of 2.3. No breakage inside the stable series unless something really forces us. 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: Magics of [CAN] message filtering
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Oliver Hartkopp wrote:
When you're touching anything inside your API, have you ever thought to add
__attribute__ ((aligned(8)))
to the data[8] element of the struct can_frame?
This would enable you to make 64 bit compares directly in the data
section of the can_frame ...
typedef __u32 canid_t;
struct can_frame {
canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */
__u8can_dlc; /* data length code: 0 .. 8 */
__u8data[8] __attribute__ ((aligned(8)));
};
[Swallowing down my well-known opinion on typeof(can_dlc) :)]
Yes, this should be done, already for the more urging sake of
unambiguous layout of the structure across the kernel/user space border.
Is this not already the case? At least the size of struct can_frame is
16 bytes.
On all target archs? With all supported compilers? Better make it explicit.
gcc -Os is such an example, toasting the assumed can_frame layout by
moving that 3-byte hole *after* data.
So this was an urging ABI bug, and I applied the alignment to both
stable and trunk Xenomai SVNs. Thanks to Oliver for insisting on this!
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: RT-CAN tx_sem
Jan Kiszka wrote:
I thought about this issue again and found the reason for my vague bad
feeling: re-init is not atomic, thus racy. But also the test+sem_init
pattern I suggested is not save.
I guess we need to enhance rtdm_XXX_init in this regard to make the
RT-CAN use case an officially allowed one. /me is planning to spend more
thoughts on this the next days.
OK, done, rtdm_{event,sem,mutex}_init are now protected by the nklock in
trunk. This should make the in-place re-initialisation of RTDM IPC
objects race-free and allow to use them in RT-CAN as originally
intended. I think I will back-port that pieces also to v2.3.x later.
What patch should now go in to avoid double init/destroy and fix rtcan_virt?
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] [RFC][PATCH 1/2] real-time print library
Philippe Gerum wrote: On Sat, 2007-02-17 at 18:43 +0100, Jan Kiszka wrote: Philippe Gerum wrote: On Sat, 2007-02-17 at 10:02 +0100, Jan Kiszka wrote: The code is stuffed into src/rtprint for now as patch 2/2 will need this lib to be built before the skin libraries. Better suggestions are welcome though. I basically agree that we need to provide more co-scheduler-based-rt-safe services, so a non-intrusive print out support should be welcome. A few things more: Actually, rt-safe printing is independent of co- vs. native scheduling. Even with a fully preemptible kernel, the worst-case complexity of normal printf may not be acceptable. I think rt_printf is generally useful in real-time programs. You seem to be talking specifically about a (non-intrusive) trace logging feature, rather than plain printf() then, because the latter does not make much sense to be used in a real-time scenario unless the caller does accept to pay the price of running a complex operation anyway. No, I'm also talking about plain printf scenarios from hard-RT threads. There is a difference between just doing a fairly simple snprintf to format the output and going into the kernel to write it to some console, file, network link, or whatever. If, on the other hand, you want to provide more efficient replacements of existing standard routines in terms of performance, then those should bear the standard names. Otherwise, people would start mixing printf() and rt_printf() in their application [experience already showed us that it's inevitable], and for instance, you would start receiving complaints about inaccurate output order, leading to incorrect interpretation of traces, because both implementations would obviously rely on distinct internal buffers. I agree that there is an ordering issue when writing to stdout or stderr /wrt to standard glibc routines. But the question is where to draw the line. We surely do not want to redirect each and every file write to a server thread _automatically_ (would be quite a performance PITA...) just because some fprintf may otherwise happen to come out in an unexpected order. We cannot avoid that the user has to be - to some degree - really _aware_ of what (s)he's doing. - looking beyond print out, we will probably want to iron more ANSI services in the future. In order to prevent API proliferation, let's consider the hardened print out support as the beginning of some libansi_rt service collection. I was already considering to include the TLSF memory allocator for real-time malloc/free into some Xenomai library, but there were still technical issues with its lacking 64-bit support e.g., preventing some quick-hack. What further services do you have on your radar? My impression is that there will not be a lot beyond printing and memory allocation. And that would already be enough to explain why we would not want to ask people to stuff their Makefile with LDFLAGS += -lrt_printf -lrt_malloc, IMO. Because after a few years, my feeling is that the LDFLAGS would grow out of any reasonable proportion, and our maintenance burden the same way. So your point is single vs. multiple rt-helper libs? I don't see a problem bundling fairly small services (a few kB) into a single lib, common to all skins. But once it takes a bit more to provide a certain service, we have to keep memory-restricted embedded applications in mind. Configuring features at build time is one way. Providing reasonably clustered libraries is another. Hard to draw a line now without having all components already at hand or at least in mind. I would also consider things like stdio in general, not just printf, by mean of server thread(s) the way you did it. Being able to send/receive a file stream without resorting -at least explicitely- to a proxy thread would simplify a bunch of existing applications for instance. Yeah, the way rt_printf writes out data might be extended to a common pattern also for other stdio output services. If async stdio-like reading is also worth providing in a generic way is something I would like to see backed up by concrete application scenarios. Maybe. Aside of purely ANSI services, there are some POSIX/SVID calls which are not relevant to libpthread_rt, but for which a hardened counterpart would make sense over a co-kernel, like SunRPC (over RTNet's UDP, that is), syslog routines, random, or libcrypt members for instance. My point being that we cannot anticipate the exact list of features we would want to harden in the future, but we do know already that applications ported/created over Xenomai are always more complex, so we will likely need more of those features. Componentization must have a limit, and my guts feeling is that going for a specific API for each and every feature would lead to maintenance chaos and user confusion. Additionally, sharing internal routines common to those features would be possible with a centralized
Re: [Xenomai-core] Re: Extended CAN frame filtering
Jan Kiszka wrote: Wolfgang Grandegger wrote: ... Attached is a revised patch including change log entry. As this patch just extends the existing filter capabilities, it could be applied to trunk and the 2.3.x branch as well. You are just forgetting the other changes to the filter mechanism you implemented. Thanks for the patch, I just merged your patch into trunk. For v2.3.x, I applied my first patch I sent on Wednesday to align it to what was specified on release of 2.3. No breakage inside the stable series unless something really forces us. OK, thanks. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: More RTCAN patches
Wolfgang Grandegger wrote: Hi Jan, I have two more patches in my quilt stack: Sigh. ;) 2007-02-18 Wolfgang Grandegger [EMAIL PROTECTED] * ksrc/drivers/can/rtcan_raw.c, ksrc/drivers/can/rtcan_socket.h: add prefix RTCAN_ to TIMESTAMP_SIZE, HAS_TIMESTAMP and HAS_NO_TIMESTAMP to avoid name clashes, e.g. TIMESTAMP_SIZE is used by the kernel starting with 2.6.20. These are only internal flags, right? Should go into stable as well then, I guess. * include/rtdm/rtcan.h: add __attribute__ ((aligned(8))) to the data[8] element of the struct can_frame. Was already committed. 2007-02-18 Wolfgang Grandegger [EMAIL PROTECTED] * include/rtdm/rtcan.h ksrc/drivers/can/Config.in, ksrc/drivers/can/Kconfig, ksrc/drivers/can/rtcan_dev.h, ksrc/drivers/can/rtcan_module.c, ksrc/drivers/can/rtcan_raw.c, ksrc/drivers/can/rtcan_raw.h, ksrc/drivers/can/rtcan_socket.c, ksrc/drivers/can/rtcan_socket.h, ksrc/drivers/can/rtcan_socket.h, ksrc/drivers/can/rtcan_virt.c, ksrc/drivers/can/sja1000/rtcan_sja1000.c, ksrc/drivers/can/mscan/rtcan_mscan.c, src/utils/can/rtcansend.c: The socket option CAN_RAW_TX_LOOPBACK has been renamed to CAN_RAW_LOOPBACK to be compatible with the Socket-CAN implementation. Furthermore, all lower and upper case strings tx_loopback have been replaced with loopback (to shorten names). Will commit to trunk. The first one also fixes the alignment issue discussed on the Socket-CAN mailing list. Any comments or objections? Wolfgang. 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: RT-CAN tx_sem
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
I thought about this issue again and found the reason for my vague bad
feeling: re-init is not atomic, thus racy. But also the test+sem_init
pattern I suggested is not save.
I guess we need to enhance rtdm_XXX_init in this regard to make the
RT-CAN use case an officially allowed one. /me is planning to spend more
thoughts on this the next days.
OK, done, rtdm_{event,sem,mutex}_init are now protected by the nklock in
trunk. This should make the in-place re-initialisation of RTDM IPC
objects race-free and allow to use them in RT-CAN as originally
intended. I think I will back-port that pieces also to v2.3.x later.
What patch should now go in to avoid double init/destroy and fix
rtcan_virt?
Attached. Thanks.
Just applied to trunk.
To avoid lock nesting where possible, I reordered some code in
rtcan_raw_sendmsg. Please re-check if I messed anything up. Then I could
commit to stable, too.
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: More RTCAN patches
Jan Kiszka wrote: Wolfgang Grandegger wrote: Hi Jan, I have two more patches in my quilt stack: Sigh. ;) 2007-02-18 Wolfgang Grandegger [EMAIL PROTECTED] * ksrc/drivers/can/rtcan_raw.c, ksrc/drivers/can/rtcan_socket.h: add prefix RTCAN_ to TIMESTAMP_SIZE, HAS_TIMESTAMP and HAS_NO_TIMESTAMP to avoid name clashes, e.g. TIMESTAMP_SIZE is used by the kernel starting with 2.6.20. These are only internal flags, right? Should go into stable as well then, I guess. Two times yes. * include/rtdm/rtcan.h: add __attribute__ ((aligned(8))) to the data[8] element of the struct can_frame. Was already committed. I realized in the meantime. 2007-02-18 Wolfgang Grandegger [EMAIL PROTECTED] * include/rtdm/rtcan.h ksrc/drivers/can/Config.in, ksrc/drivers/can/Kconfig, ksrc/drivers/can/rtcan_dev.h, ksrc/drivers/can/rtcan_module.c, ksrc/drivers/can/rtcan_raw.c, ksrc/drivers/can/rtcan_raw.h, ksrc/drivers/can/rtcan_socket.c, ksrc/drivers/can/rtcan_socket.h, ksrc/drivers/can/rtcan_socket.h, ksrc/drivers/can/rtcan_virt.c, ksrc/drivers/can/sja1000/rtcan_sja1000.c, ksrc/drivers/can/mscan/rtcan_mscan.c, src/utils/can/rtcansend.c: The socket option CAN_RAW_TX_LOOPBACK has been renamed to CAN_RAW_LOOPBACK to be compatible with the Socket-CAN implementation. Furthermore, all lower and upper case strings tx_loopback have been replaced with loopback (to shorten names). Will commit to trunk. Great, thank. Hope you didn't need a lot manual fiddling. The first one also fixes the alignment issue discussed on the Socket-CAN mailing list. Any comments or objections? Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: I-pipe 1.7 breaks mlockall safety check
Hi Philippe,
I just verfied that the mlockall issue persists. But it doesn't appear
to be a regression anymore. This little posix demo exposes it now on
both 2.6.20-1.7-02 and 2.6.19-1.6-06 against latest trunk:
#include stdio.h
#include sys/mman.h
#include pthread.h
int main(int argc, char *argv[])
{
struct sched_param param = { .sched_priority = 10 };
// mlockall(MCL_CURRENT|MCL_FUTURE);
pthread_setschedparam(pthread_self(), SCHED_FIFO, param);
printf(shouldn't be printed...\n);
pause();
}
In contrast, the same done via the native skin (rt_task_shadow) triggers
warning and program termination as expected.
It looks to me like the temporary mlockall during libpthread_rt init is
not really reverted (but munlockall is actually called) or not
propagated to the mm state that is later checked on xnshadow_map.
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: I-pipe 1.7 breaks mlockall safety check
On Mon, 2007-02-19 at 00:31 +0100, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi Philippe,
I just verfied that the mlockall issue persists. But it doesn't appear
to be a regression anymore. This little posix demo exposes it now on
both 2.6.20-1.7-02 and 2.6.19-1.6-06 against latest trunk:
#include stdio.h
#include sys/mman.h
#include pthread.h
int main(int argc, char *argv[])
{
struct sched_param param = { .sched_priority = 10 };
// mlockall(MCL_CURRENT|MCL_FUTURE);
pthread_setschedparam(pthread_self(), SCHED_FIFO, param);
printf(shouldn't be printed...\n);
pause();
}
In contrast, the same done via the native skin (rt_task_shadow) triggers
warning and program termination as expected.
It looks to me like the temporary mlockall during libpthread_rt init is
not really reverted (but munlockall is actually called) or not
propagated to the mm state that is later checked on xnshadow_map.
The problem is that the root thread is already shadowed in this program
when pthread_setschedparam is called. So, xnshadow_map is not called and
the flag is not checked.
Yep. This makes sense, since kernel-wise, sys_munlockall does clear the
VM_LOCKED bit from the caller's mm default flags.
Since this behaviour is specific to the POSIX skin because it silently
shadows the main thread as a Xenomai thread from the SCHED_NORMAL class,
maybe we should check the mm state in the POSIX thread creation routine
too, when SCHED_FIFO or SCHED_RR are passed as the scheduling class.
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: I-pipe 1.7 breaks mlockall safety check
Philippe Gerum wrote:
On Mon, 2007-02-19 at 00:31 +0100, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi Philippe,
I just verfied that the mlockall issue persists. But it doesn't appear
to be a regression anymore. This little posix demo exposes it now on
both 2.6.20-1.7-02 and 2.6.19-1.6-06 against latest trunk:
#include stdio.h
#include sys/mman.h
#include pthread.h
int main(int argc, char *argv[])
{
struct sched_param param = { .sched_priority = 10 };
// mlockall(MCL_CURRENT|MCL_FUTURE);
pthread_setschedparam(pthread_self(), SCHED_FIFO, param);
printf(shouldn't be printed...\n);
pause();
}
In contrast, the same done via the native skin (rt_task_shadow) triggers
warning and program termination as expected.
It looks to me like the temporary mlockall during libpthread_rt init is
not really reverted (but munlockall is actually called) or not
propagated to the mm state that is later checked on xnshadow_map.
The problem is that the root thread is already shadowed in this program
when pthread_setschedparam is called. So, xnshadow_map is not called and
the flag is not checked.
Yep. This makes sense, since kernel-wise, sys_munlockall does clear the
VM_LOCKED bit from the caller's mm default flags.
Since this behaviour is specific to the POSIX skin because it silently
shadows the main thread as a Xenomai thread from the SCHED_NORMAL class,
maybe we should check the mm state in the POSIX thread creation routine
too, when SCHED_FIFO or SCHED_RR are passed as the scheduling class.
The flag is checked if another thread is created, since xnshadow_map is
called. The only solution I see at the moment is to remove the call to
munlockall in the library initialization.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: I-pipe 1.7 breaks mlockall safety check
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
On Mon, 2007-02-19 at 00:31 +0100, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi Philippe,
I just verfied that the mlockall issue persists. But it doesn't appear
to be a regression anymore. This little posix demo exposes it now on
both 2.6.20-1.7-02 and 2.6.19-1.6-06 against latest trunk:
#include stdio.h
#include sys/mman.h
#include pthread.h
int main(int argc, char *argv[])
{
struct sched_param param = { .sched_priority = 10 };
//mlockall(MCL_CURRENT|MCL_FUTURE);
pthread_setschedparam(pthread_self(), SCHED_FIFO, param);
printf(shouldn't be printed...\n);
pause();
}
In contrast, the same done via the native skin (rt_task_shadow)
triggers
warning and program termination as expected.
It looks to me like the temporary mlockall during libpthread_rt init
is
not really reverted (but munlockall is actually called) or not
propagated to the mm state that is later checked on xnshadow_map.
The problem is that the root thread is already shadowed in this program
when pthread_setschedparam is called. So, xnshadow_map is not called and
the flag is not checked.
Yep. This makes sense, since kernel-wise, sys_munlockall does clear the
VM_LOCKED bit from the caller's mm default flags.
Since this behaviour is specific to the POSIX skin because it silently
shadows the main thread as a Xenomai thread from the SCHED_NORMAL class,
maybe we should check the mm state in the POSIX thread creation routine
too, when SCHED_FIFO or SCHED_RR are passed as the scheduling class.
The flag is checked if another thread is created, since xnshadow_map is
called. The only solution I see at the moment is to remove the call to
munlockall in the library initialization.
So this piece of code should trigger again?
#include stdio.h
#include sys/mman.h
#include pthread.h
void *thread(void *arg)
{
struct sched_param param = { .sched_priority = 10 };
pthread_setschedparam(pthread_self(), SCHED_FIFO, param);
printf(shouldn't be printed...\n);
return NULL;
}
int main(int argc, char *argv[])
{
pthread_t th;
pthread_create(th, NULL, thread, NULL);
pthread_join(th, NULL);
}
Well, it doesn't in fact, and I think I found my regression again. This
demo behaves as expected over 1.6-06, but remains silent over I-pipe 1.7-02.
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
