Re: [Xenomai-core] cmd_write
Hi, On Wed, Dec 23, 2009 at 2:12 AM, Stefan Schaal ssch...@usc.edu wrote: dmesg: Analogy: analogy_ni_pcimio: ni_mio_common: interrupt: b_status=0002 m1_status=80a8 [15619.322973] Analogy: analogy_ni_pcimio: ni_ao_wait_for_dma_load: timed out waiting for dma load This bug hapens randomly on a card to which I have a remote access. The occurences were scarce, that is the reason why this bug is still at the tail of my todo list. On your board, I suppose it happens at every try. I will try to fix this bug as soon as possible. -Stefan On Dec 22, 2009, at 16:52, Alexis Berlemont wrote: Hi, Stefan Schaal wrote: Hi, I have been trying to test the functionality of the analogy_ni_pcimio driver on a NI6259 board. I am using a linux kernel 2.6.29.5 with the xenomai-head (rc5). Doing an a4l_sync_write to an analog output channel works fine. Now I am trying to use the cmd structure for writing to the same analog output channel, as done in the cmd_write progam (whose source I found in xenomai_root/src/util/analogy/cmd_write.c . But I am getting the error as indicated below. Any idea why this happens? My own programming gets the same error. Thanks a lot! -Stefan unix /usr/xenomai/bin/cmd_write -v -d analogy0 -s 1 -c 0 -S 1 cmd_write: device analogy0 opened (fd=0) cmd_write: basic descriptor retrieved subdevices count = 14 read subdevice index = 0 write subdevice index = 1 cmd_write: complex descriptor retrieved cmd_write: channel 0 ranges count = 3 range's size = 16 (bits) cmd_write: scan size = 2 cmd_write: size to write = 2 cmd_write: command successfully sent cmd_write: triggering failed (ret=-32) Is there any kernel error messages ? Could you give us the last few lines of `dmesg` ? ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core Alexis. Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH 1/2] Add support for sharing kernel/userland data between Xenomai and Linux
A new structure (struct xnshared) is introduced. It allows us to share
generic data between user and kernel of Linux and Xenomai; a bitmap
of feature flags located at the beginning of the structure identifies
which data are shared. The structure is allocated in the global semaphore
heap, and xnsysinfo.xnshared_offset identifies the offset of the
structure within the heap.
Currently, no shared features are yet supported - the patch only
introduces the necessary ABI changes. When the need arises
to share data between said entities, the structure must
be accordingly extended, and a new feature bit must be added
to the flags.
Signed-off-by: Wolfgang Mauerer wolfgang.maue...@siemens.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/asm-generic/syscall.h |1 +
include/nucleus/Makefile.am |3 +-
include/nucleus/xnvdso.h | 61 +
ksrc/nucleus/module.c |7 +
ksrc/nucleus/shadow.c | 22 +++
5 files changed, 93 insertions(+), 1 deletions(-)
create mode 100644 include/nucleus/xnvdso.h
diff --git a/include/asm-generic/syscall.h b/include/asm-generic/syscall.h
index 483b99f..8f1ddc6 100644
--- a/include/asm-generic/syscall.h
+++ b/include/asm-generic/syscall.h
@@ -53,6 +53,7 @@
typedef struct xnsysinfo {
unsigned long long cpufreq; /* CPU frequency */
unsigned long tickval; /* Tick duration (ns) */
+ unsigned long xnvdso_off; /* Offset of xnvdso in the sem heap */
} xnsysinfo_t;
#define SIGSHADOW SIGWINCH
diff --git a/include/nucleus/Makefile.am b/include/nucleus/Makefile.am
index 4be05f8..26d3fa2 100644
--- a/include/nucleus/Makefile.am
+++ b/include/nucleus/Makefile.am
@@ -34,4 +34,5 @@ includesub_HEADERS = \
trace.h \
types.h \
version.h \
- xenomai.h
+ xenomai.h \
+ xnvdso.h
diff --git a/include/nucleus/xnvdso.h b/include/nucleus/xnvdso.h
new file mode 100644
index 000..fbff8fa
--- /dev/null
+++ b/include/nucleus/xnvdso.h
@@ -0,0 +1,61 @@
+#ifndef _XENO_NUCLEUS_XNVDSO_H
+#define _XENO_NUCLEUS_XNVDSO_H
+
+/*!\file xnvdso.h
+ * \brief Definitions for global semaphore heap shared objects
+ * \author Wolfgang Mauerer
+ *
+ * Copyright (C) 2009 Wolfgang Mauerer wolfgang.maue...@siemens.com.
+ *
+ * Xenomai is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation; either version 2 of the License,
+ * or (at your option) any later version.
+ *
+ * Xenomai 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
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with Xenomai; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
+ * 02111-1307, USA.
+ */
+
+#include nucleus/types.h
+
+/*
+ * Data shared between Xenomai kernel/userland and the Linux kernel/userland
+ * on the global semaphore heap. The features element indicates which data are
+ * shared. Notice that struct xnvdso may only grow, but never shrink.
+ */
+struct xnvdso {
+ unsigned long long features;
+
+ /* Embed domain specific structures that describe the
+* shared data here */
+};
+
+/*
+ * For each shared feature, add a flag below. For now, the set is still
+ * empty.
+ */
+/*
+#define XNVDSO_FEAT_A 0x0001
+#define XNVDSO_FEAT_B 0x0002
+#define XNVDSO_FEAT_C 0x0004
+#define XNVDSO_FEATURES(XNVDSO_FEAT_A | XNVDSO_FEAT_B | XVDSO_FEAT_C)
+*/
+
+#define XNVDSO_FEATURES 0x
+
+extern struct xnvdso *xnvdso;
+
+static inline int xnvdso_test_feature(unsigned long long feature)
+{
+ return testbits(xnvdso-features, feature);
+}
+
+extern void xnheap_init_vdso(void);
+#endif /* _XENO_NUCLEUS_XNVDSO_H */
diff --git a/ksrc/nucleus/module.c b/ksrc/nucleus/module.c
index 5404182..0a17661 100644
--- a/ksrc/nucleus/module.c
+++ b/ksrc/nucleus/module.c
@@ -35,6 +35,11 @@
#endif /* CONFIG_XENO_OPT_PIPE */
#include nucleus/select.h
#include asm/xenomai/bits/init.h
+#ifdef CONFIG_XENO_OPT_PERVASIVE
+#include nucleus/xnvdso.h
+#else
+static inline void xnheap_init_vdso(void) { }
+#endif /* CONFIG_XENO_OPT_PERVASIVE */
MODULE_DESCRIPTION(Xenomai nucleus);
MODULE_AUTHOR(r...@xenomai.org);
@@ -106,6 +111,8 @@ int __init __xeno_sys_init(void)
goto cleanup_arch;
xnheap_set_label(__xnsys_global_ppd.sem_heap, global sem heap);
+
+ xnheap_init_vdso();
#endif
#ifdef __KERNEL__
diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
index d0cb416..bff7dc5 100644
--- a/ksrc/nucleus/shadow.c
+++ b/ksrc/nucleus/shadow.c
@@ -50,6 +50,7 @@
#include nucleus/trace.h
#include nucleus/stat.h
#include
[Xenomai-core] [PATCH 0/2] xnvdso mechanism and unit test
Hi, the following two mails integrate Gilles' comments into the xnvdso patch and add a unit test. Notice that this submission does not consider efficient access of shared data from kernel space. Since this problem is independent from the xnvdso mechanism, it will be addressed when I submit the NTP time correction sharing code. Thanks, Wolfgang ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH 2/2] Testcase for the xnvdso mechanism
This testcase checks if the value in xnvdso-features matches the
value of XNVDSO_FEATURES, that is, if the information is correctly
transferred from kernel to userland.
Notice that the approach will fail once configurations are supported
that know of multiple features and implement only some of them.
In this case, the testcase needs to be extended accordingly
to check that only the expected features are present.
Signed-off-by: Wolfgang Mauerer wolfgang.maue...@siemens.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
src/testsuite/unit/Makefile.am | 15 +-
src/testsuite/unit/runinfo.in |1 +
src/testsuite/unit/xnvdso.c| 43
3 files changed, 58 insertions(+), 1 deletions(-)
create mode 100644 src/testsuite/unit/xnvdso.c
diff --git a/src/testsuite/unit/Makefile.am b/src/testsuite/unit/Makefile.am
index 24d077a..c77cc54 100644
--- a/src/testsuite/unit/Makefile.am
+++ b/src/testsuite/unit/Makefile.am
@@ -2,7 +2,8 @@ testdir = $(exec_prefix)/share/xenomai/testsuite/unit
CCLD = $(top_srcdir)/scripts/wrap-link.sh $(CC)
-bin_PROGRAMS = arith wakeup-time mutex-torture-posix mutex-torture-native
+bin_PROGRAMS = arith wakeup-time mutex-torture-posix mutex-torture-native \
+ xnvdso
arith_SOURCES = arith.c arith-noinline.c arith-noinline.h
@@ -53,6 +54,18 @@ mutex_torture_native_LDADD = \
../../skins/native/libnative.la \
-lpthread -lm
+xnvdso_SOURCES = xnvdso.c
+
+xnvdso_CPPFLAGS = \
+ @XENO_USER_CFLAGS@ \
+ -I$(top_srcdir)/include
+
+xnvdso_LDFLAGS = @XENO_USER_LDFLAGS@
+
+xnvdso_LDADD = \
+ ../../skins/native/libnative.la \
+ -lpthread -lm
+
install-data-local:
$(mkinstalldirs) $(DESTDIR)$(testdir)
@sed -e's,@exec_prefix\@,$(exec_prefix),g' $(srcdir)/runinfo.in
$(DESTDIR)$(testdir)/.runinfo
diff --git a/src/testsuite/unit/runinfo.in b/src/testsuite/unit/runinfo.in
index f4cd208..a22afc0 100644
--- a/src/testsuite/unit/runinfo.in
+++ b/src/testsuite/unit/runinfo.in
@@ -2,3 +2,4 @@ arith:native:!...@exec_prefix@/bin/arith;popall:control_c
wakeup-time:native:!...@exec_prefix@/bin/wakeup-time;popall:control_c
mutex-torture-posix:posix:!...@exec_prefix@/bin/mutex-torture-posix;popall:control_c
mutex-torture-native:native:!...@exec_prefix@/bin/mutex-torture-native;popall:control_c
+xnvdso:native:!...@exec_prefix@/bin/xnvdso;popall:control_c
diff --git a/src/testsuite/unit/xnvdso.c b/src/testsuite/unit/xnvdso.c
new file mode 100644
index 000..6d7d8e1
--- /dev/null
+++ b/src/testsuite/unit/xnvdso.c
@@ -0,0 +1,43 @@
+/*
+ * VDSO feature set testcase
+ * by Wolfgang Mauerer wolfgang.maue...@siemens.com
+ */
+
+#include stdio.h
+#include asm/xenomai/syscall.h
+#include nucleus/xnvdso.h
+
+extern unsigned long xeno_sem_heap[2];
+
+int main(int argc, char **argv)
+{
+ int err;
+ xnsysinfo_t sysinfo;
+ struct xnvdso *xnvdso;
+
+ if (!xeno_sem_heap[1]) {
+ fprintf(stderr, Could not determine position of the
+ global semaphore heap\n);
+ return 1;
+ }
+
+ /* The muxid is irrelevant for this test as long as it's valid */
+ err = XENOMAI_SYSCALL2(__xn_sys_info, 1, sysinfo);
+ if (err 0) {
+ fprintf(stderr, sys_sys_info failed: %d\n, err);
+ return 1;
+ }
+
+ printf(Address of the global semaphore heap: 0x%lx\n,
+ xeno_sem_heap[1]);
+ printf(Offset of xnvdso: %lu\n, sysinfo.xnvdso_off);
+
+ xnvdso = (struct xnvdso *)(xeno_sem_heap[1] + sysinfo.xnvdso_off);
+ printf(Contents of the features flag: %llu\n, xnvdso-features);
+
+ if (xnvdso-features == XNVDSO_FEATURES)
+ return 0;
+
+ fprintf(stderr, error: xnvdso-features != XNVDSO_FEATURES\n);
+ return 1;
+}
--
1.6.4
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 2/2] Testcase for the xnvdso mechanism
Wolfgang Mauerer wrote: This testcase checks if the value in xnvdso-features matches the value of XNVDSO_FEATURES, that is, if the information is correctly transferred from kernel to userland. Notice that the approach will fail once configurations are supported that know of multiple features and implement only some of them. In this case, the testcase needs to be extended accordingly to check that only the expected features are present. Please allow to pass the value we want to check on the test command line. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 2/2] Testcase for the xnvdso mechanism
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
This testcase checks if the value in xnvdso-features matches the
value of XNVDSO_FEATURES, that is, if the information is correctly
transferred from kernel to userland.
Notice that the approach will fail once configurations are supported
that know of multiple features and implement only some of them.
In this case, the testcase needs to be extended accordingly
to check that only the expected features are present.
Please allow to pass the value we want to check on the test command line.
here you go. I suppose keeping XNVDSO_FEATURES as default value
unless something different is specified is okay?
Cheers,
Wolfgang
commit 0f31dc5c50f7034dddbac67c22e53823f1be72d3
Author: Wolfgang Mauerer wolfgang.maue...@siemens.com
Date: Tue Dec 22 23:11:31 2009 +0100
Testcase for the xnvdso mechanism
This testcase checks if the value in xnvdso-features matches the
feature set specified on the command line. When no explicit
feature test set is given, XNVDSO_FEATURES (i.e., the set
of all features known to the current Xenomai revision) is used.
Notice that the default approach will naturally fail once
configurations are supported that know of multiple features and
implement only some of them.
Signed-off-by: Wolfgang Mauerer wolfgang.maue...@siemens.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
diff --git a/src/testsuite/unit/Makefile.am b/src/testsuite/unit/Makefile.am
index 24d077a..c77cc54 100644
--- a/src/testsuite/unit/Makefile.am
+++ b/src/testsuite/unit/Makefile.am
@@ -2,7 +2,8 @@ testdir = $(exec_prefix)/share/xenomai/testsuite/unit
CCLD = $(top_srcdir)/scripts/wrap-link.sh $(CC)
-bin_PROGRAMS = arith wakeup-time mutex-torture-posix mutex-torture-native
+bin_PROGRAMS = arith wakeup-time mutex-torture-posix mutex-torture-native \
+ xnvdso
arith_SOURCES = arith.c arith-noinline.c arith-noinline.h
@@ -53,6 +54,18 @@ mutex_torture_native_LDADD = \
../../skins/native/libnative.la \
-lpthread -lm
+xnvdso_SOURCES = xnvdso.c
+
+xnvdso_CPPFLAGS = \
+ @XENO_USER_CFLAGS@ \
+ -I$(top_srcdir)/include
+
+xnvdso_LDFLAGS = @XENO_USER_LDFLAGS@
+
+xnvdso_LDADD = \
+ ../../skins/native/libnative.la \
+ -lpthread -lm
+
install-data-local:
$(mkinstalldirs) $(DESTDIR)$(testdir)
@sed -e's,@exec_prefix\@,$(exec_prefix),g' $(srcdir)/runinfo.in $(DESTDIR)$(testdir)/.runinfo
diff --git a/src/testsuite/unit/runinfo.in b/src/testsuite/unit/runinfo.in
index f4cd208..a22afc0 100644
--- a/src/testsuite/unit/runinfo.in
+++ b/src/testsuite/unit/runinfo.in
@@ -2,3 +2,4 @@ arith:native:!...@exec_prefix@/bin/arith;popall:control_c
wakeup-time:native:!...@exec_prefix@/bin/wakeup-time;popall:control_c
mutex-torture-posix:posix:!...@exec_prefix@/bin/mutex-torture-posix;popall:control_c
mutex-torture-native:native:!...@exec_prefix@/bin/mutex-torture-native;popall:control_c
+xnvdso:native:!...@exec_prefix@/bin/xnvdso;popall:control_c
diff --git a/src/testsuite/unit/xnvdso.c b/src/testsuite/unit/xnvdso.c
new file mode 100644
index 000..69305c2
--- /dev/null
+++ b/src/testsuite/unit/xnvdso.c
@@ -0,0 +1,52 @@
+/*
+ * VDSO feature set testcase
+ * by Wolfgang Mauerer wolfgang.maue...@siemens.com
+ */
+
+#include stdio.h
+#include stdlib.h
+#include asm/xenomai/syscall.h
+#include nucleus/xnvdso.h
+
+extern unsigned long xeno_sem_heap[2];
+
+int main(int argc, char **argv)
+{
+ int err;
+ xnsysinfo_t sysinfo;
+ struct xnvdso *xnvdso;
+ unsigned long long test_features;
+
+ if (argc != 2) {
+ printf(No specific feature(s) given, using XNVDSO_FEATURE\n);
+ test_features = XNVDSO_FEATURES;
+ } else {
+ test_features = strtoull(argv[1], NULL, 0);
+ }
+
+ if (!xeno_sem_heap[1]) {
+ fprintf(stderr, Could not determine position of the
+ global semaphore heap\n);
+ return 1;
+ }
+
+ /* The muxid is irrelevant for this test as long as it's valid */
+ err = XENOMAI_SYSCALL2(__xn_sys_info, 1, sysinfo);
+ if (err 0) {
+ fprintf(stderr, sys_sys_info failed: %d\n, err);
+ return 1;
+ }
+
+ printf(Address of the global semaphore heap: 0x%lx\n,
+ xeno_sem_heap[1]);
+ printf(Offset of xnvdso: %lu\n, sysinfo.xnvdso_off);
+
+ xnvdso = (struct xnvdso *)(xeno_sem_heap[1] + sysinfo.xnvdso_off);
+ printf(Contents of the features flag: %llu\n, xnvdso-features);
+
+ if (xnvdso-features == test_features)
+ return 0;
+
+ fprintf(stderr, error: xnvdso-features != %llu\n, test_features);
+ return 1;
+}
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 2/2] Testcase for the xnvdso mechanism
Wolfgang Mauerer wrote: Gilles Chanteperdrix wrote: Wolfgang Mauerer wrote: This testcase checks if the value in xnvdso-features matches the value of XNVDSO_FEATURES, that is, if the information is correctly transferred from kernel to userland. Notice that the approach will fail once configurations are supported that know of multiple features and implement only some of them. In this case, the testcase needs to be extended accordingly to check that only the expected features are present. Please allow to pass the value we want to check on the test command line. here you go. I suppose keeping XNVDSO_FEATURES as default value unless something different is specified is okay? Yes, ok. I am fine with the two patches. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
Patrice Kadionik wrote: Gilles Chanteperdrix a écrit : Hi, Since I started talking about it, I have run build tests fixing a few things here and there. The current status is this (still at the same place: http://sisyphus.hd.free.fr/~gilles/bx): Hi, I've watched your log file for nios2 (http://sisyphus.hd.free.fr/~gilles/bx/nios2/2.6.30-nios2-linux-uclibc-gcc-3.4.6/log.html#1). You have this error because you don't have generated before the HW design for the NIOS softcore processor: after synthesis with the Quartus Altera tools, you finally have a file for programming the FPGA circuit and a .ptf file that gives ASCII informations on your SoPC design (in a xml style...). The error: ./arch/nios2/Makefile:131: *** Run make hwselect SYSPTF=system.ptf first. Stop. is due to lack of this .ptf file. This command generates a .h (nios2.h) file that makes relation between hardware and the Linux kernel (peripheral base address, irq number, peripheral name...) Please find here: http://uuu.enseirb.fr/~kadionik/nios-xenomai/std_1s10.ptf a valid .ptf file for Xenomai port. Juste run : $ make hwselect SYSPTF=path_to_std_1s10.ptf for completing the kernel compilation... Ok. Thanks, nios2 now compiles. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
Alexis Berlemont wrote: Hi Gilles, Gilles Chanteperdrix wrote: Hi, Since I started talking about it, I have run build tests fixing a few things here and there. The current status is this (still at the same place: http://sisyphus.hd.free.fr/~gilles/bx): * analogy: I have tried to disable some parts of analogy when compiling on machines without CONFIG_PCI, as compiling parts using PCI on a machine without PCI support, give various levels of warning and even errors depending on the architecture. Doing this, I stumbled across this compilation error: http://sisyphus.hd.free.fr/~gilles/bx/beagle/2.6.28-arm-none-linux-gnueabi-gcc-4.3.3/log.html#1 this is with CONFIG_NI_MIO, but without CONFIG_NI_MITE. So, Alex, could you: - fix that error, if this combination is supposed to make sense Yes it makes sense. I think the MITE is integrated into all PCI boards but the driver should work with the MITE disabled (one day, we could add the ISA boards). - fix the Kconfig/Makefile so that no PCI code is compiled if CONFIG_PCI is not set (I tried and do this myself, but better one who knows than 100 who have to search...). As I said, doing this result in various levels of success depending on the architecture. Ack. I will fix these problems as quickly as possible. Ok. The fix for the second problem would be nice to have soon, as analogy breaks the build on blackfin for this reason. If it is of any help, you can send me a patch for this fix only which I will apply on my side while you are working on other changes. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
