[PATCH 0/8] Assorted fixes

[PATCH 0/8] Assorted fixes

[Philippe Gerum]

From: Philippe Gerum <rpm@xenomai.org>

The first four commits fix the doc generation which has been broken
for some time, the rest addresses runtime issues detected in the
field. See commit logs for details.

These patches are on top of the master branch.

Philippe Gerum (8):
  doc: fix assorted Doxygen warnings
  doc: do not discard pdflatex output
  build: fix make distcheck
  doc: fix asciidoc generation
  cobalt/registry: fix export/unexport race on object deletion
  cobalt/registry: prevent use-after-free triggered by object removal
  drivers/ipc: bufp: fix rd/rd and wr/wr races
  boilerplate: setup: fix infinite loop in CPU list parser

 Makefile.am                                   | 13 ++++-
 configure.ac                                  |  2 +-
 doc/asciidoc/Makefile.am                      |  8 ++--
 doc/doxygen/Makefile.am                       |  2 +-
 doc/doxygen/xeno3prm-common.conf.in           | 13 ++---
 include/cobalt/kernel/registry.h              |  5 +-
 .../cobalt/kernel/rtdm/analogy/subdevice.h    |  2 -
 include/cobalt/kernel/rtdm/driver.h           |  6 +--
 include/cobalt/kernel/stat.h                  |  2 +-
 include/cobalt/kernel/timer.h                 |  2 -
 include/rtdm/uapi/can.h                       |  4 +-
 kernel/cobalt/registry.c                      | 48 ++++++++++++-------
 kernel/cobalt/rtdm/device.c                   |  2 +-
 kernel/cobalt/timer.c                         |  3 ++
 kernel/drivers/ipc/bufp.c                     | 26 ++++++----
 lib/boilerplate/setup.c                       |  3 +-
 16 files changed, 84 insertions(+), 57 deletions(-)

-- 
2.24.1

[PATCH 1/8] doc: fix assorted Doxygen warnings

[Philippe Gerum]

From: Philippe Gerum <rpm@xenomai.org>

WARN_IF_UNDOCUMENTED is switched to "NO" to prevent a truckload of
useless warnings from Doxygen since most ioctl calls are not
documented.

Signed-off-by: Philippe Gerum <rpm@xenomai.org>
---
 doc/doxygen/xeno3prm-common.conf.in            | 13 ++++---------
 include/cobalt/kernel/rtdm/analogy/subdevice.h |  2 --
 include/cobalt/kernel/rtdm/driver.h            |  6 ++----
 include/cobalt/kernel/stat.h                   |  2 +-
 include/cobalt/kernel/timer.h                  |  2 --
 include/rtdm/uapi/can.h                        |  4 ++--
 kernel/cobalt/rtdm/device.c                    |  2 +-
 kernel/cobalt/timer.c                          |  3 +++
 8 files changed, 13 insertions(+), 21 deletions(-)

diff --git a/doc/doxygen/xeno3prm-common.conf.in b/doc/doxygen/xeno3prm-common.conf.in
index 097a5827a..cd7765053 100644
--- a/doc/doxygen/xeno3prm-common.conf.in
+++ b/doc/doxygen/xeno3prm-common.conf.in
@@ -131,9 +131,9 @@ TAB_SIZE               = 8
 # You can put \n's in the value part of an alias to insert newlines.
 
 ALIASES                = \
- 		       "coretags{1}=@par Tags\n@ref cobalt-core-tags \"\1\""	\
- 		       "apitags{1}=@par Tags\n@ref api-tags \"\1\""	\
-		       "sideeffect=@par Side effects\n"
+ 		       "coretags{1}=@par Tags^^@ref cobalt-core-tags \"\1\""	\
+ 		       "apitags{1}=@par Tags^^@ref api-tags \"\1\""	\
+		       "sideeffect=@par Side effects^^"
 
 # Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources 
 # only. Doxygen will then generate output that is more tailored for C. 
@@ -316,7 +316,7 @@ WARNINGS               = YES
 # for undocumented members. If EXTRACT_ALL is set to YES then this flag will 
 # automatically be disabled.
 
-WARN_IF_UNDOCUMENTED   = YES
+WARN_IF_UNDOCUMENTED   = NO
 
 # If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for 
 # potential errors in the documentation, such as not documenting some 
@@ -710,11 +710,6 @@ ALLEXTERNALS           = NO
 
 EXTERNAL_GROUPS        = YES
 
-# The PERL_PATH should be the absolute path and name of the perl script 
-# interpreter (i.e. the result of `which perl').
-
-PERL_PATH              = /usr/bin/perl
-
 #---------------------------------------------------------------------------
 # Configuration options related to the dot tool   
 #---------------------------------------------------------------------------
diff --git a/include/cobalt/kernel/rtdm/analogy/subdevice.h b/include/cobalt/kernel/rtdm/analogy/subdevice.h
index 62433c7e1..21c09dfb9 100644
--- a/include/cobalt/kernel/rtdm/analogy/subdevice.h
+++ b/include/cobalt/kernel/rtdm/analogy/subdevice.h
@@ -89,8 +89,6 @@ struct a4l_subdevice {
 		  /**< Private data */
 };
 
-/*! @} subdevice */
-
 /* --- Subdevice related functions and macros --- */
 
 struct a4l_channel *a4l_get_chfeat(struct a4l_subdevice * sb, int idx);
diff --git a/include/cobalt/kernel/rtdm/driver.h b/include/cobalt/kernel/rtdm/driver.h
index 57495f12f..894e6f67e 100644
--- a/include/cobalt/kernel/rtdm/driver.h
+++ b/include/cobalt/kernel/rtdm/driver.h
@@ -210,7 +210,7 @@ static inline struct rtdm_device *rtdm_fd_device(struct rtdm_fd *fd)
  * This descriptor details the profile information associated to a
  * RTDM class of device managed by a driver.
  *
- * @anchor rtdm_profile_info @name RTDM profile information descriptor
+ * @anchor rtdm_profile_info
  */
 struct rtdm_profile_info {
 	/** Device class name */
@@ -218,7 +218,7 @@ struct rtdm_profile_info {
 	/** Device class ID, see @ref RTDM_CLASS_xxx */
 	int class_id;
 	/** Device sub-class, see RTDM_SUBCLASS_xxx definition in the
-	 *  @ref rtdm_profiles "Device Profiles" */
+	    @ref rtdm_profiles "Device Profiles" */
 	int subclass_id;
 	/** Supported device profile version */
 	int version;
@@ -389,8 +389,6 @@ struct rtdm_device {
 	};
 };
 
-/** @} devregister */
-
 /* --- device registration --- */
 
 int rtdm_dev_register(struct rtdm_device *device);
diff --git a/include/cobalt/kernel/stat.h b/include/cobalt/kernel/stat.h
index 2e0651417..b857cd19f 100644
--- a/include/cobalt/kernel/stat.h
+++ b/include/cobalt/kernel/stat.h
@@ -22,7 +22,7 @@
 
 #include <cobalt/kernel/clock.h>
 
-/*
+/**
  * @ingroup cobalt_core_thread
  * @defgroup cobalt_core_stat Thread runtime statistics
  * @{
diff --git a/include/cobalt/kernel/timer.h b/include/cobalt/kernel/timer.h
index 3ea2d3ce3..889504324 100644
--- a/include/cobalt/kernel/timer.h
+++ b/include/cobalt/kernel/timer.h
@@ -502,8 +502,6 @@ static inline void xntimer_dequeue(struct xntimer *timer,
 	timer->status |= XNTIMER_DEQUEUED;
 }
 
-/** @} */
-
 unsigned long long xntimer_get_overruns(struct xntimer *timer,
 					struct xnthread *waiter,
 					xnticks_t now);
diff --git a/include/rtdm/uapi/can.h b/include/rtdm/uapi/can.h
index a33003f68..8d0d837d5 100644
--- a/include/rtdm/uapi/can.h
+++ b/include/rtdm/uapi/can.h
@@ -466,9 +466,9 @@ struct can_ifreq {
  * @anchor CANIOCTLs @name IOCTLs
  * CAN device IOCTLs
  *
- * @deprecated Passing <TT>struct ifreq<TT> as a request descriptor
+ * @deprecated Passing \c struct \c ifreq as a request descriptor
  * for CAN IOCTLs is still accepted for backward compatibility,
- * however it is recommended to switch to <TT>struct can_ifreq<TT> at
+ * however it is recommended to switch to \c struct \c can_ifreq at
  * the first opportunity.
  *
  * @{ */
diff --git a/kernel/cobalt/rtdm/device.c b/kernel/cobalt/rtdm/device.c
index 7d76d2cc5..736e82da7 100644
--- a/kernel/cobalt/rtdm/device.c
+++ b/kernel/cobalt/rtdm/device.c
@@ -646,4 +646,4 @@ void rtdm_cleanup(void)
 	 */
 }
 
-/*@}*/
+/** @} */
diff --git a/kernel/cobalt/timer.c b/kernel/cobalt/timer.c
index ae3f2e5ba..b8b60c4e5 100644
--- a/kernel/cobalt/timer.c
+++ b/kernel/cobalt/timer.c
@@ -601,6 +601,9 @@ void xntimer_release_ipi(void)
  *
  * @param timer The address of a valid timer descriptor.
  *
+ * @param waiter The thread for which the overrun count is being
+ * collected.
+ *
  * @param now current date (as
  * xnclock_read_raw(xntimer_clock(timer)))
  *
-- 
2.24.1

[PATCH 2/8] doc: do not discard pdflatex output

[Philippe Gerum]

From: Philippe Gerum <rpm@xenomai.org>

We need this information for debugging purpose when latex stop mode is
enabled (--enable-verbose-latex=yes).

Signed-off-by: Philippe Gerum <rpm@xenomai.org>
---
 configure.ac            | 2 +-
 doc/doxygen/Makefile.am | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 14ddd4a78..29fefab30 100644
--- a/configure.ac
+++ b/configure.ac
@@ -447,7 +447,7 @@ LATEX_BATCHMODE=YES
 LATEX_MODE=batch
 AC_MSG_CHECKING(for LaTeX mode)
 AC_ARG_ENABLE(verbose-latex,
-	AS_HELP_STRING([--enable-nonstop-latex], [Use LaTeX non-stop mode]),
+	AS_HELP_STRING([--enable-verbose-latex], [Disable LaTeX non-stop mode]),
 	[case "$enableval" in
 	y | yes)
 	   LATEX_BATCHMODE=NO
diff --git a/doc/doxygen/Makefile.am b/doc/doxygen/Makefile.am
index 963785150..964dfdf44 100644
--- a/doc/doxygen/Makefile.am
+++ b/doc/doxygen/Makefile.am
@@ -20,7 +20,7 @@ html/xeno3prm latex/xeno3prm: FORCE
 	$(DOXYGEN) $(@F)-$(@D).conf
 
 %.pdf: latex/%
-	$(MAKE) -C $< refman.pdf > /dev/null
+	$(MAKE) -C $< refman.pdf
 	mv $</refman.pdf $@
 
 distclean-local:
-- 
2.24.1

[PATCH 3/8] build: fix make distcheck

[Philippe Gerum]

From: Philippe Gerum <rpm@xenomai.org>

Uninstall udev rules.

Signed-off-by: Philippe Gerum <rpm@xenomai.org>
---
 Makefile.am | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index ec1d0a07e..891e53f66 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -29,7 +29,7 @@ dist-hook:
 	rm -fr `find $(distdir) -name '.svn' -o -name CVS  -o -name '.#*' \
 		-o -name '*~' -o -name autom4te.cache`
 
-udev-rules:
+install-udev-rules:
 if XENO_COBALT
 	if test -r $(DESTDIR)/$(sysconfdir)/udev/udev.rules ; then \
 	    for f in $(srcdir)/kernel/cobalt/udev/*.rules ; do \
@@ -45,10 +45,19 @@ if XENO_COBALT
 	fi
 endif
 
+uninstall-udev-rules:
+if XENO_COBALT
+	cd $(srcdir)/kernel/cobalt/udev && for f in *.rules; do \
+	    rm -f $(DESTDIR)/$(sysconfdir)/udev/rules.d/$$f ; \
+	done
+endif
+
 # legacy alias
 install-user: install
 
-install-exec-local: udev-rules
+install-exec-local: install-udev-rules
+
+uninstall-local: uninstall-udev-rules
 
 uninstall-local:
 if XENO_COBALT
-- 
2.24.1

[PATCH 4/8] doc: fix asciidoc generation

[Philippe Gerum]

From: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>
---
 doc/asciidoc/Makefile.am | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/asciidoc/Makefile.am b/doc/asciidoc/Makefile.am
index f88e19391..9d06e7798 100644
--- a/doc/asciidoc/Makefile.am
+++ b/doc/asciidoc/Makefile.am
@@ -105,10 +105,10 @@ $(tmpdir)/%.txt: %.adoc Makefile plaintext.conf plaintext.xsl
 	awk -f $(srcdir)/plaintext_postproc.awk $(tmpdir)/$*.txt > $@
 
 html/asciidoc-icons:
-	@$(RM) -R asciidoc-icons
-	@test -d /usr/share/asciidoc/images && \
-	cp -a /usr/share/asciidoc/images/icons html/asciidoc-icons || \
-	cp -a /usr/share/asciidoc/icons html/asciidoc-icons
+	$(RM) -R asciidoc-icons
+	@test -d /usr/share/doc/asciidoc/images/ && \
+	cp -a /usr/share/doc/asciidoc/images/icons/ html/asciidoc-icons || \
+	cp -a /usr/share/asciidoc/images/icons/ html/asciidoc-icons
 
 html/asciidoc-icons/callouts: html/asciidoc-icons
 
-- 
2.24.1

[PATCH 5/8] cobalt/registry: fix export/unexport race on object deletion

[Philippe Gerum]

From: Philippe Gerum <rpm@xenomai.org>

Running xnregistry_enter() then xnregistry_remove() in quick
succession for the same object might cause the latter to NULLify the
objaddr field while proc_callback() is busy calling the vfile export
handler for the object, which is going to use that same value,
certainly leading to a crash.

This bug is due to the asynchronous nature of the vfile
export/unexport process which is deferred to a regular workqueue on
the root stage when kicked from the head stage.

Fix this by adding a third logic state describing an aborted vfile
export procedure, due to handling an object removal request while the
workqueue is concurrently running for the same object. In addition,
since an exported object might be stale before it is considered for
export, do not anticipate on the next object to process in
proc_callback() as list_for_each_entry_safe() would do, but always
pick the list head under lock.

At this chance, clarify the naming of the magic vfile values
enumerating those states (i.e. XNOBJECT_EXPORT_xxx).

Signed-off-by: Philippe Gerum <rpm@xenomai.org>
---
 include/cobalt/kernel/registry.h |  5 ++--
 kernel/cobalt/registry.c         | 40 ++++++++++++++++++++------------
 2 files changed, 28 insertions(+), 17 deletions(-)

diff --git a/include/cobalt/kernel/registry.h b/include/cobalt/kernel/registry.h
index 25c8f48d3..624db5a78 100644
--- a/include/cobalt/kernel/registry.h
+++ b/include/cobalt/kernel/registry.h
@@ -55,8 +55,9 @@ void xnregistry_cleanup(void);
 
 #ifdef CONFIG_XENO_OPT_VFILE
 
-#define XNOBJECT_PNODE_RESERVED1 ((struct xnvfile *)1)
-#define XNOBJECT_PNODE_RESERVED2 ((struct xnvfile *)2)
+#define XNOBJECT_EXPORT_SCHEDULED  ((struct xnvfile *)1L)
+#define XNOBJECT_EXPORT_INPROGRESS ((struct xnvfile *)2L)
+#define XNOBJECT_EXPORT_ABORTED    ((struct xnvfile *)3L)
 
 struct xnptree {
 	const char *dirname;
diff --git a/kernel/cobalt/registry.c b/kernel/cobalt/registry.c
index dde359ea4..9dfd66b06 100644
--- a/kernel/cobalt/registry.c
+++ b/kernel/cobalt/registry.c
@@ -227,8 +227,8 @@ static DEFINE_SEMAPHORE(export_mutex);
 static void proc_callback(struct work_struct *work)
 {
 	struct xnvfile_directory *rdir, *dir;
-	struct xnobject *object, *tmp;
 	const char *rname, *type;
+	struct xnobject *object;
 	struct xnpnode *pnode;
 	int ret;
 	spl_t s;
@@ -237,21 +237,19 @@ static void proc_callback(struct work_struct *work)
 
 	xnlock_get_irqsave(&nklock, s);
 
-	if (list_empty(&proc_object_list))
-		goto out;
-
-	list_for_each_entry_safe(object, tmp, &proc_object_list, link) {
-		list_del(&object->link);
+	while (!list_empty(&proc_object_list)) {
+		object = list_get_entry(&proc_object_list,
+					struct xnobject, link);
 		pnode = object->pnode;
 		type = pnode->dirname;
 		dir = &pnode->vdir;
 		rdir = &pnode->root->vdir;
 		rname = pnode->root->dirname;
 
-		if (object->vfilp != XNOBJECT_PNODE_RESERVED1)
+		if (object->vfilp != XNOBJECT_EXPORT_SCHEDULED)
 			goto unexport;
 
-		object->vfilp = XNOBJECT_PNODE_RESERVED2;
+		object->vfilp = XNOBJECT_EXPORT_INPROGRESS;
 		list_add_tail(&object->link, &busy_object_list);
 
 		xnlock_put_irqrestore(&nklock, s);
@@ -298,6 +296,9 @@ static void proc_callback(struct work_struct *work)
 		object->vfilp = NULL;
 		object->pnode = NULL;
 
+		if (object->vfilp == XNOBJECT_EXPORT_ABORTED)
+			object->objaddr = NULL;
+
 		if (object->objaddr)
 			list_add_tail(&object->link, &busy_object_list);
 		else {
@@ -321,7 +322,7 @@ static void proc_callback(struct work_struct *work)
 
 		xnlock_get_irqsave(&nklock, s);
 	}
-out:
+
 	xnlock_put_irqrestore(&nklock, s);
 
 	up(&export_mutex);
@@ -464,7 +465,7 @@ EXPORT_SYMBOL_GPL(xnregistry_vlink_ops);
 static inline void registry_export_pnode(struct xnobject *object,
 					 struct xnpnode *pnode)
 {
-	object->vfilp = XNOBJECT_PNODE_RESERVED1;
+	object->vfilp = XNOBJECT_EXPORT_SCHEDULED;
 	object->pnode = pnode;
 	list_del(&object->link);
 	list_add_tail(&object->link, &proc_object_list);
@@ -473,7 +474,7 @@ static inline void registry_export_pnode(struct xnobject *object,
 
 static inline void registry_unexport_pnode(struct xnobject *object)
 {
-	if (object->vfilp != XNOBJECT_PNODE_RESERVED1) {
+	if (object->vfilp != XNOBJECT_EXPORT_SCHEDULED) {
 		/*
 		 * We might have preempted a v-file read op, so bump
 		 * the object's revtag to make sure the data
@@ -818,6 +819,7 @@ EXPORT_SYMBOL_GPL(xnregistry_bind);
 int xnregistry_remove(xnhandle_t handle)
 {
 	struct xnobject *object;
+	void *objaddr;
 	int ret = 0;
 	spl_t s;
 
@@ -829,6 +831,7 @@ int xnregistry_remove(xnhandle_t handle)
 		goto unlock_and_exit;
 	}
 
+	objaddr = object->objaddr;
 	object->objaddr = NULL;
 	object->cstamp = 0;
 
@@ -837,6 +840,11 @@ int xnregistry_remove(xnhandle_t handle)
 
 #ifdef CONFIG_XENO_OPT_VFILE
 		if (object->pnode) {
+			if (object->vfilp == XNOBJECT_EXPORT_INPROGRESS) {
+				object->vfilp = XNOBJECT_EXPORT_ABORTED;
+				object->objaddr = objaddr;
+			}
+
 			registry_unexport_pnode(object);
 			/*
 			 * Leave the update of the object queues to
@@ -850,8 +858,10 @@ int xnregistry_remove(xnhandle_t handle)
 		list_del(&object->link);
 	}
 
-	list_add_tail(&object->link, &free_object_list);
-	nr_active_objects--;
+	if (!IS_ENABLED(CONFIG_XENO_OPT_VFILE) || !object->objaddr) {
+		list_add_tail(&object->link, &free_object_list);
+		nr_active_objects--;
+	}
 
 unlock_and_exit:
 
@@ -882,7 +892,7 @@ int xnregistry_unlink(const char *key)
 		ret = -ESRCH;
 		goto unlock_and_exit;
 	}
-		
+
 	ret = registry_hash_remove(object);
 	if (ret < 0)
 		goto unlock_and_exit;
@@ -900,7 +910,7 @@ int xnregistry_unlink(const char *key)
 #endif /* CONFIG_XENO_OPT_VFILE */
 
 	list_del(&object->link);
-		
+
 	object->key = NULL;
 
 unlock_and_exit:
-- 
2.24.1

[PATCH 6/8] cobalt/registry: prevent use-after-free triggered by object removal

[Philippe Gerum]

From: Philippe Gerum <rpm@xenomai.org>

Since the vfile export and unexport operations are asynchronous,
returning from xnregistry_remove() is no guarantee that the registered
object won't be further accessed, especially by the vfile export
handler.

Plug this race at least for all in-band callers removing objects while
running on root stage like RTIPC protocols by synchronizing with the
workqueue which handles deferred export/unexport requests, before
returning from xnregistry_remove().

This does not cover the issue of removing objects from the head
stage. Fortunately, all users of the vfile export/unexport mechanism
are unregistering objects from the root stage only (typically some
RTDM close() handler).

This issue was reported by KASAN.

Signed-off-by: Philippe Gerum <rpm@xenomai.org>
---
 kernel/cobalt/registry.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/kernel/cobalt/registry.c b/kernel/cobalt/registry.c
index 9dfd66b06..4b01abd63 100644
--- a/kernel/cobalt/registry.c
+++ b/kernel/cobalt/registry.c
@@ -850,8 +850,12 @@ int xnregistry_remove(xnhandle_t handle)
 			 * Leave the update of the object queues to
 			 * the work callback if it has been kicked.
 			 */
-			if (object->pnode)
-				goto unlock_and_exit;
+			if (object->pnode) {
+				xnlock_put_irqrestore(&nklock, s);
+				if (ipipe_root_p)
+					flush_work(&registry_proc_work);
+				return 0;
+			}
 		}
 #endif /* CONFIG_XENO_OPT_VFILE */
 
-- 
2.24.1

[PATCH 7/8] drivers/ipc: bufp: fix rd/rd and wr/wr races

[Philippe Gerum]

From: Philippe Gerum <rpm@xenomai.org>

Concurrent reads or writes to a buffer causing nested buffer space
reservations could end up in a miscalculation of the number of bytes
remaining to be read or written. Fix this by updating these counts
only once the last reservation is committed.

Signed-off-by: Philippe Gerum <rpm@xenomai.org>
---
 kernel/drivers/ipc/bufp.c | 26 ++++++++++++++++++--------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/kernel/drivers/ipc/bufp.c b/kernel/drivers/ipc/bufp.c
index 3d0929df7..45c917eb0 100644
--- a/kernel/drivers/ipc/bufp.c
+++ b/kernel/drivers/ipc/bufp.c
@@ -43,8 +43,10 @@ struct bufp_socket {
 
 	off_t rdoff;
 	off_t rdrsvd;
+	int rdsem;
 	off_t wroff;
 	off_t wrrsvd;
+	int wrsem;
 	size_t fillsz;
 	rtdm_event_t i_event;
 	rtdm_event_t o_event;
@@ -188,6 +190,7 @@ redo:
 		rdoff = sk->rdoff;
 		sk->rdoff = (rdoff + len) % sk->bufsz;
 		sk->rdrsvd += len;
+		sk->rdsem++;
 		rbytes = ret = len;
 
 		do {
@@ -213,14 +216,17 @@ redo:
 			rdoff = (rdoff + n) % sk->bufsz;
 		} while (rbytes > 0);
 
+		if (--sk->rdsem > 0)
+			goto out;
+
 		resched = 0;
-		if (sk->fillsz == sk->bufsz) /* -> writable */
+		if (sk->fillsz == sk->bufsz) /* -> becomes writable */
 			resched |= xnselect_signal(&sk->priv->send_block, POLLOUT);
 
-		sk->rdrsvd -= len;
-		sk->fillsz -= len;
+		sk->fillsz -= sk->rdrsvd;
+		sk->rdrsvd = 0;
 
-		if (sk->fillsz == 0) /* -> non-readable */
+		if (sk->fillsz == 0) /* -> becomes non-readable */
 			resched |= xnselect_signal(&sk->priv->recv_block, 0);
 
 		/*
@@ -431,6 +437,7 @@ static ssize_t __bufp_writebuf(struct bufp_socket *rsk,
 		wroff = rsk->wroff;
 		rsk->wroff = (wroff + len) % rsk->bufsz;
 		rsk->wrrsvd += len;
+		rsk->wrsem++;
 		wbytes = ret = len;
 
 		do {
@@ -459,14 +466,17 @@ static ssize_t __bufp_writebuf(struct bufp_socket *rsk,
 			wroff = (wroff + n) % rsk->bufsz;
 		} while (wbytes > 0);
 
-		rsk->fillsz += len;
-		rsk->wrrsvd -= len;
+		if (--rsk->wrsem > 0)
+			goto out;
 
 		resched = 0;
-		if (rsk->fillsz == len) /* -> readable */
+		if (rsk->fillsz == 0) /* -> becomes readable */
 			resched |= xnselect_signal(&rsk->priv->recv_block, POLLIN);
 
-		if (rsk->fillsz == rsk->bufsz) /* non-writable */
+		rsk->fillsz += rsk->wrrsvd;
+		rsk->wrrsvd = 0;
+
+		if (rsk->fillsz == rsk->bufsz) /* becomes non-writable */
 			resched |= xnselect_signal(&rsk->priv->send_block, 0);
 		/*
 		 * Wake up all threads pending on the input wait
-- 
2.24.1

[PATCH 8/8] boilerplate: setup: fix infinite loop in CPU list parser

[Philippe Gerum]

From: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>
---
 lib/boilerplate/setup.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/boilerplate/setup.c b/lib/boilerplate/setup.c
index 3214d7f04..5139560e8 100644
--- a/lib/boilerplate/setup.c
+++ b/lib/boilerplate/setup.c
@@ -178,7 +178,7 @@ static int collect_cpu_affinity(const char *cpu_list)
 	s = n = strdup(cpu_list);
 	while ((range = strtok_r(n, ",", &range_p)) != NULL) {
 		if (*range == '\0')
-			continue;
+			goto next;
 		end = -1;
 		if (range[strlen(range)-1] == '-')
 			end = nr_cpus - 1;
@@ -203,6 +203,7 @@ static int collect_cpu_affinity(const char *cpu_list)
 		}
 		for (cpu = start; cpu <= end; cpu++)
 			CPU_SET(cpu, &__base_setup_data.cpu_affinity);
+	next:
 		n = NULL;
 	}
 
-- 
2.24.1

Re: [PATCH 3/8] build: fix make distcheck

[Jan Kiszka]

On 31.01.20 16:27, Philippe Gerum via Xenomai wrote:
> From: Philippe Gerum <rpm@xenomai.org>
> 
> Uninstall udev rules.
> 
> Signed-off-by: Philippe Gerum <rpm@xenomai.org>
> ---
>   Makefile.am | 13 +++++++++++--
>   1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/Makefile.am b/Makefile.am
> index ec1d0a07e..891e53f66 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -29,7 +29,7 @@ dist-hook:
>   	rm -fr `find $(distdir) -name '.svn' -o -name CVS  -o -name '.#*' \
>   		-o -name '*~' -o -name autom4te.cache`
>   
> -udev-rules:
> +install-udev-rules:
>   if XENO_COBALT
>   	if test -r $(DESTDIR)/$(sysconfdir)/udev/udev.rules ; then \
>   	    for f in $(srcdir)/kernel/cobalt/udev/*.rules ; do \
> @@ -45,10 +45,19 @@ if XENO_COBALT
>   	fi
>   endif
>   
> +uninstall-udev-rules:
> +if XENO_COBALT
> +	cd $(srcdir)/kernel/cobalt/udev && for f in *.rules; do \
> +	    rm -f $(DESTDIR)/$(sysconfdir)/udev/rules.d/$$f ; \
> +	done
> +endif
> +
>   # legacy alias
>   install-user: install
>   
> -install-exec-local: udev-rules
> +install-exec-local: install-udev-rules
> +
> +uninstall-local: uninstall-udev-rules
>   
>   uninstall-local:
>   if XENO_COBALT
> 

This overlaps with 1a84919771c6.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 0/8] Assorted fixes

[Jan Kiszka]

On 31.01.20 16:27, Philippe Gerum via Xenomai wrote:
> From: Philippe Gerum <rpm@xenomai.org>
> 
> The first four commits fix the doc generation which has been broken
> for some time, the rest addresses runtime issues detected in the
> field. See commit logs for details.

Thanks for the fixes. Patch 3 needs folding - or we simply drop it.

For the other issues: I suppose we need more torture tests...

Jan

> 
> These patches are on top of the master branch.
> 
> Philippe Gerum (8):
>    doc: fix assorted Doxygen warnings
>    doc: do not discard pdflatex output
>    build: fix make distcheck
>    doc: fix asciidoc generation
>    cobalt/registry: fix export/unexport race on object deletion
>    cobalt/registry: prevent use-after-free triggered by object removal
>    drivers/ipc: bufp: fix rd/rd and wr/wr races
>    boilerplate: setup: fix infinite loop in CPU list parser
> 
>   Makefile.am                                   | 13 ++++-
>   configure.ac                                  |  2 +-
>   doc/asciidoc/Makefile.am                      |  8 ++--
>   doc/doxygen/Makefile.am                       |  2 +-
>   doc/doxygen/xeno3prm-common.conf.in           | 13 ++---
>   include/cobalt/kernel/registry.h              |  5 +-
>   .../cobalt/kernel/rtdm/analogy/subdevice.h    |  2 -
>   include/cobalt/kernel/rtdm/driver.h           |  6 +--
>   include/cobalt/kernel/stat.h                  |  2 +-
>   include/cobalt/kernel/timer.h                 |  2 -
>   include/rtdm/uapi/can.h                       |  4 +-
>   kernel/cobalt/registry.c                      | 48 ++++++++++++-------
>   kernel/cobalt/rtdm/device.c                   |  2 +-
>   kernel/cobalt/timer.c                         |  3 ++
>   kernel/drivers/ipc/bufp.c                     | 26 ++++++----
>   lib/boilerplate/setup.c                       |  3 +-
>   16 files changed, 84 insertions(+), 57 deletions(-)
> 

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

RE: [PATCH 0/8] Assorted fixes

[Meng, Fino]

Hi Jan

Regarding to torture tests, do we have a recommend test suite & working flow  from the community? 
I searched xenomai wiki but didn't find a guide for this. 
We plan to recommend UP Extreme board (https://up-board.org/up-xtreme/)  to public users since it's easy to buy for anyone
And we want to write a guide for torture test, at least for these boards, 

BR / Fino Meng (孟祥夫)
Intel – IOTG Developer Enabling

-----Original Message-----
From: Xenomai <xenomai-bounces@xenomai.org> On Behalf Of Jan Kiszka via Xenomai
Sent: Friday, January 31, 2020 11:56 PM
To: Philippe Gerum <rpm@xenomai.org>; xenomai@xenomai.org
Subject: Re: [PATCH 0/8] Assorted fixes

On 31.01.20 16:27, Philippe Gerum via Xenomai wrote:
> From: Philippe Gerum <rpm@xenomai.org>
> 
> The first four commits fix the doc generation which has been broken 
> for some time, the rest addresses runtime issues detected in the 
> field. See commit logs for details.

Thanks for the fixes. Patch 3 needs folding - or we simply drop it.

For the other issues: I suppose we need more torture tests...

Jan

> 
> These patches are on top of the master branch.
> 
> Philippe Gerum (8):
>    doc: fix assorted Doxygen warnings
>    doc: do not discard pdflatex output
>    build: fix make distcheck
>    doc: fix asciidoc generation
>    cobalt/registry: fix export/unexport race on object deletion
>    cobalt/registry: prevent use-after-free triggered by object removal
>    drivers/ipc: bufp: fix rd/rd and wr/wr races
>    boilerplate: setup: fix infinite loop in CPU list parser
> 
>   Makefile.am                                   | 13 ++++-
>   configure.ac                                  |  2 +-
>   doc/asciidoc/Makefile.am                      |  8 ++--
>   doc/doxygen/Makefile.am                       |  2 +-
>   doc/doxygen/xeno3prm-common.conf.in           | 13 ++---
>   include/cobalt/kernel/registry.h              |  5 +-
>   .../cobalt/kernel/rtdm/analogy/subdevice.h    |  2 -
>   include/cobalt/kernel/rtdm/driver.h           |  6 +--
>   include/cobalt/kernel/stat.h                  |  2 +-
>   include/cobalt/kernel/timer.h                 |  2 -
>   include/rtdm/uapi/can.h                       |  4 +-
>   kernel/cobalt/registry.c                      | 48 ++++++++++++-------
>   kernel/cobalt/rtdm/device.c                   |  2 +-
>   kernel/cobalt/timer.c                         |  3 ++
>   kernel/drivers/ipc/bufp.c                     | 26 ++++++----
>   lib/boilerplate/setup.c                       |  3 +-
>   16 files changed, 84 insertions(+), 57 deletions(-)
> 

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux

Re: [PATCH 0/8] Assorted fixes

[Philippe Gerum]

On 1/31/20 4:55 PM, Jan Kiszka wrote:
> On 31.01.20 16:27, Philippe Gerum via Xenomai wrote:
>> From: Philippe Gerum <rpm@xenomai.org>
>>
>> The first four commits fix the doc generation which has been broken
>> for some time, the rest addresses runtime issues detected in the
>> field. See commit logs for details.
> 
> Thanks for the fixes. Patch 3 needs folding - or we simply drop it.
>

Let's drop it, since distcheck works without it now.

> For the other issues: I suppose we need more torture tests...
>

>>    cobalt/registry: fix export/unexport race on object deletion

This can be triggered from userland, by stressing open/close on the nrt
side vs socket/bind/close sequences on the rt side.

>>    cobalt/registry: prevent use-after-free triggered by object removal

This was detected by KASAN, it is unlikely to trigger an easily
reproducible crash.

>>    drivers/ipc: bufp: fix rd/rd and wr/wr races

Non-trivial to reproduce, very timing dependent.

>>    boilerplate: setup: fix infinite loop in CPU list parser
>>

Trivial to reproduce, but no added-value for a regression test IMO.

-- 
Philippe.

Re: [PATCH 0/8] Assorted fixes

[Jan Kiszka]

On 31.01.20 17:35, Philippe Gerum wrote:
> On 1/31/20 4:55 PM, Jan Kiszka wrote:
>> On 31.01.20 16:27, Philippe Gerum via Xenomai wrote:
>>> From: Philippe Gerum <rpm@xenomai.org>
>>>
>>> The first four commits fix the doc generation which has been broken
>>> for some time, the rest addresses runtime issues detected in the
>>> field. See commit logs for details.
>>
>> Thanks for the fixes. Patch 3 needs folding - or we simply drop it.
>>
> 
> Let's drop it, since distcheck works without it now.
> 
>> For the other issues: I suppose we need more torture tests...
>>
> 
>>>     cobalt/registry: fix export/unexport race on object deletion
> 
> This can be triggered from userland, by stressing open/close on the nrt
> side vs socket/bind/close sequences on the rt side.
> 
>>>     cobalt/registry: prevent use-after-free triggered by object removal
> 
> This was detected by KASAN, it is unlikely to trigger an easily
> reproducible crash.
> 
>>>     drivers/ipc: bufp: fix rd/rd and wr/wr races
> 
> Non-trivial to reproduce, very timing dependent.
> 
>>>     boilerplate: setup: fix infinite loop in CPU list parser
>>>
> 
> Trivial to reproduce, but no added-value for a regression test IMO.
> 

Yeah, I know now all issues are easy to catch with test cases. It was 
more a general question to think about running certain critical feature 
tests also in some fuzzing, concurrency fostering modes. But good test 
design remains a tough task.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 0/8] Assorted fixes

[Jan Kiszka]

Hi Fino,

On 31.01.20 17:25, Meng, Fino wrote:
> Hi Jan
> 
> Regarding to torture tests, do we have a recommend test suite & working flow  from the community?
> I searched xenomai wiki but didn't find a guide for this.

Out testing leaves a bit of room for improvement, but it is getting 
better. What we have so far is the smokey testsuite which is part of 
many of our test runs. It has some shortcomings, e.g. unstructured 
reporting, but it is at least a baseline. There are some further tests, 
like switchtest, that are also included when running xeno-test. And then 
there are loose ends like lib/*/testsuite that should probably be hooked up.

> We plan to recommend UP Extreme board (https://up-board.org/up-xtreme/)  to public users since it's easy to buy for anyone
> And we want to write a guide for torture test, at least for these boards,

Defining reference boards is indeed another topic. I think we started 
that at some point on the list, but it did not go very far.

On x86, the situation is rather comfortable as the reference image we 
produce with xenomai-images works well on many boards and larger 
systems. I don't have an UP board around but many products that have at 
least similar SoCs. We once played with a Minnow board but that was, 
well, not recommendable. The UP Xtreme could be another option.

The next level is then automated execution of tests. There are many 
ways, the one we are preparing so far is LAVA-based. Quirin started that 
in 
https://code.siemens.com/ebsy/debian/xenomai-images/tree/master/tests. 
He is busy the next weeks but he wants to follow-up on that with more 
details afterwards so that we can discuss in the community if that could 
become an official pattern for Xenomai.

Any comments, suggestions in this area are of course welcome!

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 0/8] Assorted fixes

[Greg Gallagher]

HI,


On Fri, Jan 31, 2020 at 12:53 PM Jan Kiszka via Xenomai
<xenomai@xenomai.org> wrote:
>
> Hi Fino,
>
> On 31.01.20 17:25, Meng, Fino wrote:
> > Hi Jan
> >
> > Regarding to torture tests, do we have a recommend test suite & working flow  from the community?
> > I searched xenomai wiki but didn't find a guide for this.
>
> Out testing leaves a bit of room for improvement, but it is getting
> better. What we have so far is the smokey testsuite which is part of
> many of our test runs. It has some shortcomings, e.g. unstructured
> reporting, but it is at least a baseline. There are some further tests,
> like switchtest, that are also included when running xeno-test. And then
> there are loose ends like lib/*/testsuite that should probably be hooked up.
Is there anything on the wiki with what tests are needed or what area
we need to focus on for unit tests?

>
> > We plan to recommend UP Extreme board (https://up-board.org/up-xtreme/)  to public users since it's easy to buy for anyone
> > And we want to write a guide for torture test, at least for these boards,
>
> Defining reference boards is indeed another topic. I think we started
> that at some point on the list, but it did not go very far.

IMHO, based on what people on the list are posting as boards being
used, beaglebone black or similar variant, raspberry-pi 2b  or
Zynq-7000 would be good choices for arm boards.  Raspberry pi 3 and
possibly Ultra96 for the ARM64 variants?  I have these boards on hand
and would help out with testing as I can.
>
> On x86, the situation is rather comfortable as the reference image we
> produce with xenomai-images works well on many boards and larger
> systems. I don't have an UP board around but many products that have at
> least similar SoCs. We once played with a Minnow board but that was,
> well, not recommendable. The UP Xtreme could be another option.

> The next level is then automated execution of tests. There are many
> ways, the one we are preparing so far is LAVA-based. Quirin started that
> in
> https://code.siemens.com/ebsy/debian/xenomai-images/tree/master/tests.
> He is busy the next weeks but he wants to follow-up on that with more
> details afterwards so that we can discuss in the community if that could
> become an official pattern for Xenomai.
>
I like the idea of Lava, would there be extra hardware needed if
someone wanted to create the test setup at home?
I can't access the link above, is it possible to open that link up to
the public?

> Any comments, suggestions in this area are of course welcome!
>
> Thanks,
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>

Re: [PATCH 0/8] Assorted fixes

[Jan Kiszka]

On 31.01.20 20:20, Greg Gallagher wrote:
> HI,
> 
> 
> On Fri, Jan 31, 2020 at 12:53 PM Jan Kiszka via Xenomai
> <xenomai@xenomai.org> wrote:
>>
>> Hi Fino,
>>
>> On 31.01.20 17:25, Meng, Fino wrote:
>>> Hi Jan
>>>
>>> Regarding to torture tests, do we have a recommend test suite & working flow  from the community?
>>> I searched xenomai wiki but didn't find a guide for this.
>>
>> Out testing leaves a bit of room for improvement, but it is getting
>> better. What we have so far is the smokey testsuite which is part of
>> many of our test runs. It has some shortcomings, e.g. unstructured
>> reporting, but it is at least a baseline. There are some further tests,
>> like switchtest, that are also included when running xeno-test. And then
>> there are loose ends like lib/*/testsuite that should probably be hooked up.
> Is there anything on the wiki with what tests are needed or what area
> we need to focus on for unit tests?

Nope, not yet.

> 
>>
>>> We plan to recommend UP Extreme board (https://up-board.org/up-xtreme/)  to public users since it's easy to buy for anyone
>>> And we want to write a guide for torture test, at least for these boards,
>>
>> Defining reference boards is indeed another topic. I think we started
>> that at some point on the list, but it did not go very far.
> 
> IMHO, based on what people on the list are posting as boards being
> used, beaglebone black or similar variant, raspberry-pi 2b  or
> Zynq-7000 would be good choices for arm boards.  Raspberry pi 3 and
> possibly Ultra96 for the ARM64 variants?  I have these boards on hand
> and would help out with testing as I can.

We are currently testing on BB black and on the HiKey. But we do not 
need to confine us to only one per arch, in fact we shouldn't.

>>
>> On x86, the situation is rather comfortable as the reference image we
>> produce with xenomai-images works well on many boards and larger
>> systems. I don't have an UP board around but many products that have at
>> least similar SoCs. We once played with a Minnow board but that was,
>> well, not recommendable. The UP Xtreme could be another option.
> 
>> The next level is then automated execution of tests. There are many
>> ways, the one we are preparing so far is LAVA-based. Quirin started that
>> in
>> https://code.siemens.com/ebsy/debian/xenomai-images/tree/master/tests.
>> He is busy the next weeks but he wants to follow-up on that with more
>> details afterwards so that we can discuss in the community if that could
>> become an official pattern for Xenomai.
>>
> I like the idea of Lava, would there be extra hardware needed if
> someone wanted to create the test setup at home?
> I can't access the link above, is it possible to open that link up to
> the public?

Uups, browser history... That was the internal mirror we run the build 
and test with. I meant 
https://gitlab.denx.de/Xenomai/xenomai-images/tree/master/tests

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 0/8] Assorted fixes

[Henning Schild]

Am Fri, 31 Jan 2020 14:20:33 -0500
schrieb Greg Gallagher via Xenomai <xenomai@xenomai.org>:

> HI,
> 
> 
> On Fri, Jan 31, 2020 at 12:53 PM Jan Kiszka via Xenomai
> <xenomai@xenomai.org> wrote:
> >
> > Hi Fino,
> >
> > On 31.01.20 17:25, Meng, Fino wrote:  
> > > Hi Jan
> > >
> > > Regarding to torture tests, do we have a recommend test suite &
> > > working flow  from the community? I searched xenomai wiki but
> > > didn't find a guide for this.  
> >
> > Out testing leaves a bit of room for improvement, but it is getting
> > better. What we have so far is the smokey testsuite which is part of
> > many of our test runs. It has some shortcomings, e.g. unstructured
> > reporting, but it is at least a baseline. There are some further
> > tests, like switchtest, that are also included when running
> > xeno-test. And then there are loose ends like lib/*/testsuite that
> > should probably be hooked up.  
> Is there anything on the wiki with what tests are needed or what area
> we need to focus on for unit tests?
> 
> >  
> > > We plan to recommend UP Extreme board
> > > (https://up-board.org/up-xtreme/)  to public users since it's
> > > easy to buy for anyone And we want to write a guide for torture
> > > test, at least for these boards,  
> >
> > Defining reference boards is indeed another topic. I think we
> > started that at some point on the list, but it did not go very far.
> >  
> 
> IMHO, based on what people on the list are posting as boards being
> used, beaglebone black or similar variant, raspberry-pi 2b  or
> Zynq-7000 would be good choices for arm boards.  Raspberry pi 3 and
> possibly Ultra96 for the ARM64 variants?  I have these boards on hand
> and would help out with testing as I can.
> >
> > On x86, the situation is rather comfortable as the reference image
> > we produce with xenomai-images works well on many boards and larger
> > systems. I don't have an UP board around but many products that
> > have at least similar SoCs. We once played with a Minnow board but
> > that was, well, not recommendable. The UP Xtreme could be another
> > option.  
> 
> > The next level is then automated execution of tests. There are many
> > ways, the one we are preparing so far is LAVA-based. Quirin started
> > that in
> > https://code.siemens.com/ebsy/debian/xenomai-images/tree/master/tests.
> > He is busy the next weeks but he wants to follow-up on that with
> > more details afterwards so that we can discuss in the community if
> > that could become an official pattern for Xenomai.
> >  
> I like the idea of Lava, would there be extra hardware needed if
> someone wanted to create the test setup at home?
> I can't access the link above, is it possible to open that link up to
> the public?

Quickly enabling people to build their own lab is a clear goal.
Community labs could be hooked into the central CI-CD-CT, so an
upstream commit could eventually trigger a test+report in all
maintainers labs wherever those may be.
But in fact private labs would be the prime target. 

Your lab setup will need a machine being able to run docker or you need
to install lava yourself. You will want power-sockets that can be
switched from that box. Serial connections to the target(s), maybe
dhcp+pxe+nfs, remote flashers, USB-mass-storage gadget ...
Ideally you want targets that support fully automatic CD. So full
network boot or boot from USB or boot from a flash that you can write
from the outside, no SDCards and other manual steps.

ARM targets that have a bootloader which supports dhcp/tftp are well
understood and easy to hook in.

Henning

> > Any comments, suggestions in this area are of course welcome!
> >
> > Thanks,
> > Jan
> >
> > --
> > Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> > Corporate Competence Center Embedded Linux
> >  
> 

RE: [PATCH 0/8] Assorted fixes

[Meng, Fino]

Thanks Jan & Henning,  got some ideas.
In 2020 our team's focus is modify UEFI BIOS for real time capability;
Most of OEM's industry PC cannot reach good worst case jitter using out of box BIOS,  these items needed by PnP configs are hidden;
We want to push BIOS vendors and OEMs do real-time, deterministic, predictable BIOS, for Industry PC. 

BR / Fino (孟祥夫)
Intel – IOTG Developer Enabling

-----Original Message-----
From: Xenomai <xenomai-bounces@xenomai.org> On Behalf Of Henning Schild via Xenomai
Sent: Saturday, February 1, 2020 6:23 PM
To: Greg Gallagher via Xenomai <xenomai@xenomai.org>
Subject: Re: [PATCH 0/8] Assorted fixes

Am Fri, 31 Jan 2020 14:20:33 -0500
schrieb Greg Gallagher via Xenomai <xenomai@xenomai.org>:

> HI,
> 
> 
> On Fri, Jan 31, 2020 at 12:53 PM Jan Kiszka via Xenomai 
> <xenomai@xenomai.org> wrote:
> >
> > Hi Fino,
> >
> > On 31.01.20 17:25, Meng, Fino wrote:  
> > > Hi Jan
> > >
> > > Regarding to torture tests, do we have a recommend test suite & 
> > > working flow  from the community? I searched xenomai wiki but 
> > > didn't find a guide for this.
> >
> > Out testing leaves a bit of room for improvement, but it is getting 
> > better. What we have so far is the smokey testsuite which is part of 
> > many of our test runs. It has some shortcomings, e.g. unstructured 
> > reporting, but it is at least a baseline. There are some further 
> > tests, like switchtest, that are also included when running 
> > xeno-test. And then there are loose ends like lib/*/testsuite that 
> > should probably be hooked up.
> Is there anything on the wiki with what tests are needed or what area 
> we need to focus on for unit tests?
> 
> >  
> > > We plan to recommend UP Extreme board
> > > (https://up-board.org/up-xtreme/)  to public users since it's easy 
> > > to buy for anyone And we want to write a guide for torture test, 
> > > at least for these boards,
> >
> > Defining reference boards is indeed another topic. I think we 
> > started that at some point on the list, but it did not go very far.
> >  
> 
> IMHO, based on what people on the list are posting as boards being 
> used, beaglebone black or similar variant, raspberry-pi 2b  or
> Zynq-7000 would be good choices for arm boards.  Raspberry pi 3 and 
> possibly Ultra96 for the ARM64 variants?  I have these boards on hand 
> and would help out with testing as I can.
> >
> > On x86, the situation is rather comfortable as the reference image 
> > we produce with xenomai-images works well on many boards and larger 
> > systems. I don't have an UP board around but many products that have 
> > at least similar SoCs. We once played with a Minnow board but that 
> > was, well, not recommendable. The UP Xtreme could be another option.
> 
> > The next level is then automated execution of tests. There are many 
> > ways, the one we are preparing so far is LAVA-based. Quirin started 
> > that in 
> > https://code.siemens.com/ebsy/debian/xenomai-images/tree/master/tests.
> > He is busy the next weeks but he wants to follow-up on that with 
> > more details afterwards so that we can discuss in the community if 
> > that could become an official pattern for Xenomai.
> >  
> I like the idea of Lava, would there be extra hardware needed if 
> someone wanted to create the test setup at home?
> I can't access the link above, is it possible to open that link up to 
> the public?

Quickly enabling people to build their own lab is a clear goal.
Community labs could be hooked into the central CI-CD-CT, so an upstream commit could eventually trigger a test+report in all maintainers labs wherever those may be.
But in fact private labs would be the prime target. 

Your lab setup will need a machine being able to run docker or you need to install lava yourself. You will want power-sockets that can be switched from that box. Serial connections to the target(s), maybe
dhcp+pxe+nfs, remote flashers, USB-mass-storage gadget ...
Ideally you want targets that support fully automatic CD. So full network boot or boot from USB or boot from a flash that you can write from the outside, no SDCards and other manual steps.

ARM targets that have a bootloader which supports dhcp/tftp are well understood and easy to hook in.

Henning

> > Any comments, suggestions in this area are of course welcome!
> >
> > Thanks,
> > Jan
> >
> > --
> > Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate 
> > Competence Center Embedded Linux
> >  
> 

Re: [PATCH 0/8] Assorted fixes

[Jan Kiszka]

On 01.02.20 12:35, Meng, Fino via Xenomai wrote:
> Thanks Jan & Henning,  got some ideas.
> In 2020 our team's focus is modify UEFI BIOS for real time capability;
> Most of OEM's industry PC cannot reach good worst case jitter using out of box BIOS,  these items needed by PnP configs are hidden;
> We want to push BIOS vendors and OEMs do real-time, deterministic, predictable BIOS, for Industry PC.

That would be highly appreciated from a Xenomai perspective! I know that 
not all IPC vendors so far invests in making their BIOS RT-ready. And 
Xenomai would possibly be able to overcome in such boxes the nasty "turn 
off all NMI sources" hack (where it works at all). I hope your changes 
also find their way into OSS firmware, like Coreboot (which is of 
strategic importance here).

Jan

> 
> BR / Fino (孟祥夫)
> Intel – IOTG Developer Enabling
> 
> -----Original Message-----
> From: Xenomai <xenomai-bounces@xenomai.org> On Behalf Of Henning Schild via Xenomai
> Sent: Saturday, February 1, 2020 6:23 PM
> To: Greg Gallagher via Xenomai <xenomai@xenomai.org>
> Subject: Re: [PATCH 0/8] Assorted fixes
> 
> Am Fri, 31 Jan 2020 14:20:33 -0500
> schrieb Greg Gallagher via Xenomai <xenomai@xenomai.org>:
> 
>> HI,
>>
>>
>> On Fri, Jan 31, 2020 at 12:53 PM Jan Kiszka via Xenomai
>> <xenomai@xenomai.org> wrote:
>>>
>>> Hi Fino,
>>>
>>> On 31.01.20 17:25, Meng, Fino wrote:
>>>> Hi Jan
>>>>
>>>> Regarding to torture tests, do we have a recommend test suite &
>>>> working flow  from the community? I searched xenomai wiki but
>>>> didn't find a guide for this.
>>>
>>> Out testing leaves a bit of room for improvement, but it is getting
>>> better. What we have so far is the smokey testsuite which is part of
>>> many of our test runs. It has some shortcomings, e.g. unstructured
>>> reporting, but it is at least a baseline. There are some further
>>> tests, like switchtest, that are also included when running
>>> xeno-test. And then there are loose ends like lib/*/testsuite that
>>> should probably be hooked up.
>> Is there anything on the wiki with what tests are needed or what area
>> we need to focus on for unit tests?
>>
>>>   
>>>> We plan to recommend UP Extreme board
>>>> (https://up-board.org/up-xtreme/)  to public users since it's easy
>>>> to buy for anyone And we want to write a guide for torture test,
>>>> at least for these boards,
>>>
>>> Defining reference boards is indeed another topic. I think we
>>> started that at some point on the list, but it did not go very far.
>>>   
>>
>> IMHO, based on what people on the list are posting as boards being
>> used, beaglebone black or similar variant, raspberry-pi 2b  or
>> Zynq-7000 would be good choices for arm boards.  Raspberry pi 3 and
>> possibly Ultra96 for the ARM64 variants?  I have these boards on hand
>> and would help out with testing as I can.
>>>
>>> On x86, the situation is rather comfortable as the reference image
>>> we produce with xenomai-images works well on many boards and larger
>>> systems. I don't have an UP board around but many products that have
>>> at least similar SoCs. We once played with a Minnow board but that
>>> was, well, not recommendable. The UP Xtreme could be another option.
>>
>>> The next level is then automated execution of tests. There are many
>>> ways, the one we are preparing so far is LAVA-based. Quirin started
>>> that in
>>> https://code.siemens.com/ebsy/debian/xenomai-images/tree/master/tests.
>>> He is busy the next weeks but he wants to follow-up on that with
>>> more details afterwards so that we can discuss in the community if
>>> that could become an official pattern for Xenomai.
>>>   
>> I like the idea of Lava, would there be extra hardware needed if
>> someone wanted to create the test setup at home?
>> I can't access the link above, is it possible to open that link up to
>> the public?
> 
> Quickly enabling people to build their own lab is a clear goal.
> Community labs could be hooked into the central CI-CD-CT, so an upstream commit could eventually trigger a test+report in all maintainers labs wherever those may be.
> But in fact private labs would be the prime target.
> 
> Your lab setup will need a machine being able to run docker or you need to install lava yourself. You will want power-sockets that can be switched from that box. Serial connections to the target(s), maybe
> dhcp+pxe+nfs, remote flashers, USB-mass-storage gadget ...
> Ideally you want targets that support fully automatic CD. So full network boot or boot from USB or boot from a flash that you can write from the outside, no SDCards and other manual steps.
> 
> ARM targets that have a bootloader which supports dhcp/tftp are well understood and easy to hook in.
> 
> Henning
> 
>>> Any comments, suggestions in this area are of course welcome!
>>>
>>> Thanks,
>>> Jan
>>>
>>> --
>>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate
>>> Competence Center Embedded Linux
>>>   
>>
> 
> 

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 0/8] Assorted fixes

[Jan Kiszka]

On 31.01.20 16:27, Philippe Gerum via Xenomai wrote:
> From: Philippe Gerum <rpm@xenomai.org>
> 
> The first four commits fix the doc generation which has been broken
> for some time, the rest addresses runtime issues detected in the
> field. See commit logs for details.
> 
> These patches are on top of the master branch.
> 
> Philippe Gerum (8):
>    doc: fix assorted Doxygen warnings
>    doc: do not discard pdflatex output
>    build: fix make distcheck
>    doc: fix asciidoc generation

I've just tried to reproduce the doc build, but maybe I'm missing a 
tool, or we have complex version dependencies:

make[3]: Entering directory '/data/xenomai/build64/doc/doxygen/latex/xeno3prm'
rm -f *.ps *.dvi *.aux *.toc *.idx *.ind *.ilg *.log *.out *.brf *.blg *.bbl refman.pdf
pdflatex refman
This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/TeX Live for SUSE Linux) (preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./refman.tex
LaTeX2e <2017-04-15>
Babel <3.10> and hyphenation patterns for 51 language(s) loaded.

make[3]: *** [Makefile:6: refman.pdf] Error 1
make[3]: Leaving directory '/data/xenomai/build64/doc/doxygen/latex/xeno3prm'
make[2]: *** [Makefile:538: xeno3prm.pdf] Error 2
make[2]: Leaving directory '/data/xenomai/build64/doc/doxygen'
make[1]: *** [Makefile:408: all-recursive] Error 1
make[1]: Leaving directory '/data/xenomai/build64/doc'
make: *** [Makefile:459: all-recursive] Error 1

Any idea?

What's your setup exactly? What falls under "Dot packages" on your 
distro?

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 0/8] Assorted fixes

[Jan Kiszka]

On 03.02.20 18:55, Jan Kiszka via Xenomai wrote:
> On 31.01.20 16:27, Philippe Gerum via Xenomai wrote:
>> From: Philippe Gerum <rpm@xenomai.org>
>>
>> The first four commits fix the doc generation which has been broken
>> for some time, the rest addresses runtime issues detected in the
>> field. See commit logs for details.
>>
>> These patches are on top of the master branch.
>>
>> Philippe Gerum (8):
>>     doc: fix assorted Doxygen warnings
>>     doc: do not discard pdflatex output
>>     build: fix make distcheck
>>     doc: fix asciidoc generation
> 
> I've just tried to reproduce the doc build, but maybe I'm missing a
> tool, or we have complex version dependencies:
> 
> make[3]: Entering directory '/data/xenomai/build64/doc/doxygen/latex/xeno3prm'
> rm -f *.ps *.dvi *.aux *.toc *.idx *.ind *.ilg *.log *.out *.brf *.blg *.bbl refman.pdf
> pdflatex refman
> This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/TeX Live for SUSE Linux) (preloaded format=pdflatex)
>   restricted \write18 enabled.
> entering extended mode
> (./refman.tex
> LaTeX2e <2017-04-15>
> Babel <3.10> and hyphenation patterns for 51 language(s) loaded.
> 
> make[3]: *** [Makefile:6: refman.pdf] Error 1
> make[3]: Leaving directory '/data/xenomai/build64/doc/doxygen/latex/xeno3prm'
> make[2]: *** [Makefile:538: xeno3prm.pdf] Error 2
> make[2]: Leaving directory '/data/xenomai/build64/doc/doxygen'
> make[1]: *** [Makefile:408: all-recursive] Error 1
> make[1]: Leaving directory '/data/xenomai/build64/doc'
> make: *** [Makefile:459: all-recursive] Error 1
> 
> Any idea?
> 
> What's your setup exactly? What falls under "Dot packages" on your
> distro?

Ah, found it: texlive-tabu was missing in my case.

Then I just needed to tweak the asciidoc images search path further for 
my distro, patch will follow.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 0/8] Assorted fixes

[Philippe Gerum]

On 2/3/20 6:55 PM, Jan Kiszka wrote:
> On 31.01.20 16:27, Philippe Gerum via Xenomai wrote:
>> From: Philippe Gerum <rpm@xenomai.org>
>>
>> The first four commits fix the doc generation which has been broken
>> for some time, the rest addresses runtime issues detected in the
>> field. See commit logs for details.
>>
>> These patches are on top of the master branch.
>>
>> Philippe Gerum (8):
>>    doc: fix assorted Doxygen warnings
>>    doc: do not discard pdflatex output
>>    build: fix make distcheck
>>    doc: fix asciidoc generation
> 
> I've just tried to reproduce the doc build, but maybe I'm missing a 
> tool, or we have complex version dependencies:
> 
> make[3]: Entering directory '/data/xenomai/build64/doc/doxygen/latex/xeno3prm'
> rm -f *.ps *.dvi *.aux *.toc *.idx *.ind *.ilg *.log *.out *.brf *.blg *.bbl refman.pdf
> pdflatex refman
> This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/TeX Live for SUSE Linux) (preloaded format=pdflatex)
>  restricted \write18 enabled.
> entering extended mode
> (./refman.tex
> LaTeX2e <2017-04-15>
> Babel <3.10> and hyphenation patterns for 51 language(s) loaded.
> 
> make[3]: *** [Makefile:6: refman.pdf] Error 1
> make[3]: Leaving directory '/data/xenomai/build64/doc/doxygen/latex/xeno3prm'
> make[2]: *** [Makefile:538: xeno3prm.pdf] Error 2
> make[2]: Leaving directory '/data/xenomai/build64/doc/doxygen'
> make[1]: *** [Makefile:408: all-recursive] Error 1
> make[1]: Leaving directory '/data/xenomai/build64/doc'
> make: *** [Makefile:459: all-recursive] Error 1
> 
> Any idea?
> 
> What's your setup exactly? What falls under "Dot packages" on your 
> distro?
> 
> Jan
> 

You might also have an issue with pdflatex which might fail with a
cryptic error on generating refman.pdf. You may want to pass
--enable-verbose-latex to get information about the failure.

-- 
Philippe.

Re: [PATCH 0/8] Assorted fixes

[Jan Kiszka]

On 03.02.20 19:21, Philippe Gerum wrote:
> On 2/3/20 6:55 PM, Jan Kiszka wrote:
>> On 31.01.20 16:27, Philippe Gerum via Xenomai wrote:
>>> From: Philippe Gerum <rpm@xenomai.org>
>>>
>>> The first four commits fix the doc generation which has been broken
>>> for some time, the rest addresses runtime issues detected in the
>>> field. See commit logs for details.
>>>
>>> These patches are on top of the master branch.
>>>
>>> Philippe Gerum (8):
>>>     doc: fix assorted Doxygen warnings
>>>     doc: do not discard pdflatex output
>>>     build: fix make distcheck
>>>     doc: fix asciidoc generation
>>
>> I've just tried to reproduce the doc build, but maybe I'm missing a
>> tool, or we have complex version dependencies:
>>
>> make[3]: Entering directory '/data/xenomai/build64/doc/doxygen/latex/xeno3prm'
>> rm -f *.ps *.dvi *.aux *.toc *.idx *.ind *.ilg *.log *.out *.brf *.blg *.bbl refman.pdf
>> pdflatex refman
>> This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/TeX Live for SUSE Linux) (preloaded format=pdflatex)
>>   restricted \write18 enabled.
>> entering extended mode
>> (./refman.tex
>> LaTeX2e <2017-04-15>
>> Babel <3.10> and hyphenation patterns for 51 language(s) loaded.
>>
>> make[3]: *** [Makefile:6: refman.pdf] Error 1
>> make[3]: Leaving directory '/data/xenomai/build64/doc/doxygen/latex/xeno3prm'
>> make[2]: *** [Makefile:538: xeno3prm.pdf] Error 2
>> make[2]: Leaving directory '/data/xenomai/build64/doc/doxygen'
>> make[1]: *** [Makefile:408: all-recursive] Error 1
>> make[1]: Leaving directory '/data/xenomai/build64/doc'
>> make: *** [Makefile:459: all-recursive] Error 1
>>
>> Any idea?
>>
>> What's your setup exactly? What falls under "Dot packages" on your
>> distro?
>>
>> Jan
>>
> 
> You might also have an issue with pdflatex which might fail with a
> cryptic error on generating refman.pdf. You may want to pass
> --enable-verbose-latex to get information about the failure.
> 

Yeah, there was a helpful refman.log left behind that gave the hint - 
didn't fiddle with latex in a while.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

FAILURE run_gdb:287: checking expression "primary_mode", expected "$", found "N"

[Vitaly Chikunov]

Hello,

I try ipipe-core-4.19.114-cip24-x86-12 + xenomai-3.1 patches.
But how to interpret this test result?

  4.19.114-xenomai-alt1.cip24.12:~# xeno-test -k
  Started child 6707: /bin/bash /usr/lib/xenomai/xeno-test-run-wrapper /usr/bin/xeno-test -k
  ++ echo 0
  ++ testdir=/usr/lib/xenomai
  ++ /usr/lib/xenomai/smokey --run --keep-going random_alloc_rounds=64 pattern_check_rounds=64
  arith OK
  bufp OK
  cpu_affinity skipped (no kernel support)
  fpu_stress OK
  FAILURE run_gdb:287: checking expression "primary_mode", expected "$", found "N"
  child 6707 returned: exited with status 1
  4.19.114-xenomai-alt1.cip24.12:~#

System info:

  4.19.114-xenomai-alt1.cip24.12:~# xeno-config --info
  Xenomai version: Xenomai/cobalt v3.0.9 -- #5b99a6128 (2019-11-04 19:44:03 +0100)
  Linux REX 4.19.114-xenomai-alt1.cip24.12 #1 SMP Sun Apr 19 09:59:30 UTC 2020 x86_64 GNU/Linux
  Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-4.19.114-xenomai-alt1.cip24.12 root=UUID=56b25751-2d48-4138-99ac-7e48a8ecbf63 ro nokaslr panic=0 console=ttyS1,115200 kgdboc=ttyS1,115200
  I-pipe release #12 detected
  Cobalt core 3.1 detected
  Compiler: gcc version 9.2.1 20200123 (ALT Sisyphus 9.2.1-alt3) (GCC)
  Build args: --build=x86_64-alt-linux --host=x86_64-alt-linux --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/lib --localstatedir=/var/lib --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --disable-silent-rules --without-included-gettext --with-core=cobalt --includedir=/usr/include/xenomai --with-testdir=/usr/lib/xenomai build_alias=x86_64-alt-linux host_alias=x86_64-alt-linux CFLAGS=-fno-omit-frame-pointer

gdb version is 8.3.

A bit of background: I try to build Xenomai packages for ALT linux, so that
people can experiment with open-source real-time system. This is intended for
amd64 platform. I wish that there is not errors or crashes in basic
functionality.

Thanks,

Re: FAILURE run_gdb:287: checking expression "primary_mode", expected "$", found "N"

[Vitaly Chikunov]

Jan,

On Tue, Apr 21, 2020 at 01:18:50AM +0300, Vitaly Chikunov via Xenomai wrote:
> 
> I try ipipe-core-4.19.114-cip24-x86-12 + xenomai-3.1 patches.
> But how to interpret this test result?
> 
>   4.19.114-xenomai-alt1.cip24.12:~# xeno-test -k
>   Started child 6707: /bin/bash /usr/lib/xenomai/xeno-test-run-wrapper /usr/bin/xeno-test -k
>   ++ echo 0
>   ++ testdir=/usr/lib/xenomai
>   ++ /usr/lib/xenomai/smokey --run --keep-going random_alloc_rounds=64 pattern_check_rounds=64
>   arith OK
>   bufp OK
>   cpu_affinity skipped (no kernel support)
>   fpu_stress OK
>   FAILURE run_gdb:287: checking expression "primary_mode", expected "$", found "N"
>   child 6707 returned: exited with status 1
>   4.19.114-xenomai-alt1.cip24.12:~#

1. I think I found what is the problem.
Symbol `breakpoint_target' is defined static, so it requires debuginfo
to work just after binary load in gdb. Otherwise, there is error which
is unhandled by gdb smoke tester:

  4.19.114-xenomai-alt1.cip24.12:~# /usr/lib/xenomai/smokey --run random_alloc_rounds=64 pattern_check_rounds=64 --run=gdb --trace=99 --verbose=99
  ...
  Reading symbols from /usr/lib/xenomai/smokey...
  Missing separate debuginfo for /usr/lib/xenomai/smokey
  Try to install the hash file /usr/lib/debug/.build-id/ec/389866caa99a27f87698250ed8fda4264c093b.debug
  (No debugging symbols found in /usr/lib/xenomai/smokey)
  (gdb) Function "breakpoint_target" not defined.
  Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
  (gdb) Starting program: /usr/lib/xenomai/smokey --run=4 run_target
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib64/libthread_db.so.1".
  [New Thread 0x7ffff7b0e700 (LWP 8170)]
  Missing separate debuginfo for /lib64/libgcc_s.so.1
  Try to install the hash file /usr/lib/debug/.build-id/d4/1518ee215314a1877b0d17f0ccddfc33582503.debug
  [New Thread 0x7ffff71d8700 (LWP 8171)]
  [Thread 0x7ffff71d8700 (LWP 8171) exited]
  gdb OK
  [Thread 0x7ffff7d90740 (LWP 8166) exited]
  [Inferior 1 (process 8166) exited normally]
  (gdb) resume in primary
  The program is not being run.
  FAILURE run_gdb:287: checking expression "primary_mode", expected "$", found "N"

As you can see it does not find `breakpoint_target' on `b
breakpoint_target'. If debuiginfo is installed test will pass.

I recommend removing `static' from `breakpoint_target' definition, so
that symbol is exported without need of debuginfo.

2. There is additional problem with gdb test, though. If I have in my
`.gdbinit' value of `prompt' redefined - gdb test fails to recognize the
prompt.  I recommend adding `-nx' option to gdb arguments so that
`.gdbinit' is not read by default.

gdb --help:
  --nh               Do not read ~/.gdbinit.
  --nx               Do not read any .gdbinit files in any directory.

I believe these changes will make xeno-test more robust.

3. Also, note that `-k' switch is not worked.

Thanks,


> 
> System info:
> 
>   4.19.114-xenomai-alt1.cip24.12:~# xeno-config --info
>   Xenomai version: Xenomai/cobalt v3.0.9 -- #5b99a6128 (2019-11-04 19:44:03 +0100)
>   Linux REX 4.19.114-xenomai-alt1.cip24.12 #1 SMP Sun Apr 19 09:59:30 UTC 2020 x86_64 GNU/Linux
>   Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-4.19.114-xenomai-alt1.cip24.12 root=UUID=56b25751-2d48-4138-99ac-7e48a8ecbf63 ro nokaslr panic=0 console=ttyS1,115200 kgdboc=ttyS1,115200
>   I-pipe release #12 detected
>   Cobalt core 3.1 detected
>   Compiler: gcc version 9.2.1 20200123 (ALT Sisyphus 9.2.1-alt3) (GCC)
>   Build args: --build=x86_64-alt-linux --host=x86_64-alt-linux --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/lib --localstatedir=/var/lib --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --disable-silent-rules --without-included-gettext --with-core=cobalt --includedir=/usr/include/xenomai --with-testdir=/usr/lib/xenomai build_alias=x86_64-alt-linux host_alias=x86_64-alt-linux CFLAGS=-fno-omit-frame-pointer
> 
> gdb version is 8.3.
> 
> A bit of background: I try to build Xenomai packages for ALT linux, so that
> people can experiment with open-source real-time system. This is intended for
> amd64 platform. I wish that there is not errors or crashes in basic
> functionality.
> 
> Thanks,
> 

Re: FAILURE run_gdb:287: checking expression "primary_mode", expected "$", found "N"

[Vitaly Chikunov]

Jan,

On Tue, Apr 21, 2020 at 03:27:29AM +0300, Vitaly Chikunov via Xenomai wrote:
> On Tue, Apr 21, 2020 at 01:18:50AM +0300, Vitaly Chikunov via Xenomai wrote:
> > 
> > I try ipipe-core-4.19.114-cip24-x86-12 + xenomai-3.1 patches.
> > But how to interpret this test result?
> > 
> >   4.19.114-xenomai-alt1.cip24.12:~# xeno-test -k
> >   Started child 6707: /bin/bash /usr/lib/xenomai/xeno-test-run-wrapper /usr/bin/xeno-test -k
> >   ++ echo 0
> >   ++ testdir=/usr/lib/xenomai
> >   ++ /usr/lib/xenomai/smokey --run --keep-going random_alloc_rounds=64 pattern_check_rounds=64
> >   arith OK
> >   bufp OK
> >   cpu_affinity skipped (no kernel support)
> >   fpu_stress OK
> >   FAILURE run_gdb:287: checking expression "primary_mode", expected "$", found "N"
> >   child 6707 returned: exited with status 1
> >   4.19.114-xenomai-alt1.cip24.12:~#
> 
> 1. I think I found what is the problem.
> Symbol `breakpoint_target' is defined static, so it requires debuginfo
> to work just after binary load in gdb. Otherwise, there is error which
> is unhandled by gdb smoke tester:
> 
>   4.19.114-xenomai-alt1.cip24.12:~# /usr/lib/xenomai/smokey --run random_alloc_rounds=64 pattern_check_rounds=64 --run=gdb --trace=99 --verbose=99
>   ...
>   Reading symbols from /usr/lib/xenomai/smokey...
>   Missing separate debuginfo for /usr/lib/xenomai/smokey
>   Try to install the hash file /usr/lib/debug/.build-id/ec/389866caa99a27f87698250ed8fda4264c093b.debug
>   (No debugging symbols found in /usr/lib/xenomai/smokey)
>   (gdb) Function "breakpoint_target" not defined.
>   Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
>   (gdb) Starting program: /usr/lib/xenomai/smokey --run=4 run_target
>   [Thread debugging using libthread_db enabled]
>   Using host libthread_db library "/lib64/libthread_db.so.1".
>   [New Thread 0x7ffff7b0e700 (LWP 8170)]
>   Missing separate debuginfo for /lib64/libgcc_s.so.1
>   Try to install the hash file /usr/lib/debug/.build-id/d4/1518ee215314a1877b0d17f0ccddfc33582503.debug
>   [New Thread 0x7ffff71d8700 (LWP 8171)]
>   [Thread 0x7ffff71d8700 (LWP 8171) exited]
>   gdb OK
>   [Thread 0x7ffff7d90740 (LWP 8166) exited]
>   [Inferior 1 (process 8166) exited normally]
>   (gdb) resume in primary
>   The program is not being run.
>   FAILURE run_gdb:287: checking expression "primary_mode", expected "$", found "N"
> 
> As you can see it does not find `breakpoint_target' on `b
> breakpoint_target'. If debuiginfo is installed test will pass.
> 
> I recommend removing `static' from `breakpoint_target' definition, so
> that symbol is exported without need of debuginfo.

It turned out that removing `static' was not enough to pass binary
stripping. I will investigate better solution further.

Thanks,

> 
> 2. There is additional problem with gdb test, though. If I have in my
> `.gdbinit' value of `prompt' redefined - gdb test fails to recognize the
> prompt.  I recommend adding `-nx' option to gdb arguments so that
> `.gdbinit' is not read by default.
> 
> gdb --help:
>   --nh               Do not read ~/.gdbinit.
>   --nx               Do not read any .gdbinit files in any directory.
> 
> I believe these changes will make xeno-test more robust.
> 
> 3. Also, note that `-k' switch is not worked.
> 
> Thanks,
> 
> 
> > 
> > System info:
> > 
> >   4.19.114-xenomai-alt1.cip24.12:~# xeno-config --info
> >   Xenomai version: Xenomai/cobalt v3.0.9 -- #5b99a6128 (2019-11-04 19:44:03 +0100)
> >   Linux REX 4.19.114-xenomai-alt1.cip24.12 #1 SMP Sun Apr 19 09:59:30 UTC 2020 x86_64 GNU/Linux
> >   Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-4.19.114-xenomai-alt1.cip24.12 root=UUID=56b25751-2d48-4138-99ac-7e48a8ecbf63 ro nokaslr panic=0 console=ttyS1,115200 kgdboc=ttyS1,115200
> >   I-pipe release #12 detected
> >   Cobalt core 3.1 detected
> >   Compiler: gcc version 9.2.1 20200123 (ALT Sisyphus 9.2.1-alt3) (GCC)
> >   Build args: --build=x86_64-alt-linux --host=x86_64-alt-linux --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/lib --localstatedir=/var/lib --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --disable-silent-rules --without-included-gettext --with-core=cobalt --includedir=/usr/include/xenomai --with-testdir=/usr/lib/xenomai build_alias=x86_64-alt-linux host_alias=x86_64-alt-linux CFLAGS=-fno-omit-frame-pointer
> > 
> > gdb version is 8.3.
> > 
> > A bit of background: I try to build Xenomai packages for ALT linux, so that
> > people can experiment with open-source real-time system. This is intended for
> > amd64 platform. I wish that there is not errors or crashes in basic
> > functionality.
> > 
> > Thanks,
> > 

Re: FAILURE run_gdb:287: checking expression "primary_mode", expected "$", found "N"

[Jan Kiszka]

On 21.04.20 04:43, Vitaly Chikunov via Xenomai wrote:
> Jan,
> 
> On Tue, Apr 21, 2020 at 03:27:29AM +0300, Vitaly Chikunov via Xenomai wrote:
>> On Tue, Apr 21, 2020 at 01:18:50AM +0300, Vitaly Chikunov via Xenomai wrote:
>>>
>>> I try ipipe-core-4.19.114-cip24-x86-12 + xenomai-3.1 patches.
>>> But how to interpret this test result?
>>>
>>>    4.19.114-xenomai-alt1.cip24.12:~# xeno-test -k
>>>    Started child 6707: /bin/bash /usr/lib/xenomai/xeno-test-run-wrapper /usr/bin/xeno-test -k
>>>    ++ echo 0
>>>    ++ testdir=/usr/lib/xenomai
>>>    ++ /usr/lib/xenomai/smokey --run --keep-going random_alloc_rounds=64 pattern_check_rounds=64
>>>    arith OK
>>>    bufp OK
>>>    cpu_affinity skipped (no kernel support)
>>>    fpu_stress OK
>>>    FAILURE run_gdb:287: checking expression "primary_mode", expected "$", found "N"
>>>    child 6707 returned: exited with status 1
>>>    4.19.114-xenomai-alt1.cip24.12:~#
>>
>> 1. I think I found what is the problem.
>> Symbol `breakpoint_target' is defined static, so it requires debuginfo
>> to work just after binary load in gdb. Otherwise, there is error which
>> is unhandled by gdb smoke tester:
>>
>>    4.19.114-xenomai-alt1.cip24.12:~# /usr/lib/xenomai/smokey --run random_alloc_rounds=64 pattern_check_rounds=64 --run=gdb --trace=99 --verbose=99
>>    ...
>>    Reading symbols from /usr/lib/xenomai/smokey...
>>    Missing separate debuginfo for /usr/lib/xenomai/smokey
>>    Try to install the hash file /usr/lib/debug/.build-id/ec/389866caa99a27f87698250ed8fda4264c093b.debug
>>    (No debugging symbols found in /usr/lib/xenomai/smokey)
>>    (gdb) Function "breakpoint_target" not defined.
>>    Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
>>    (gdb) Starting program: /usr/lib/xenomai/smokey --run=4 run_target
>>    [Thread debugging using libthread_db enabled]
>>    Using host libthread_db library "/lib64/libthread_db.so.1".
>>    [New Thread 0x7ffff7b0e700 (LWP 8170)]
>>    Missing separate debuginfo for /lib64/libgcc_s.so.1
>>    Try to install the hash file /usr/lib/debug/.build-id/d4/1518ee215314a1877b0d17f0ccddfc33582503.debug
>>    [New Thread 0x7ffff71d8700 (LWP 8171)]
>>    [Thread 0x7ffff71d8700 (LWP 8171) exited]
>>    gdb OK
>>    [Thread 0x7ffff7d90740 (LWP 8166) exited]
>>    [Inferior 1 (process 8166) exited normally]
>>    (gdb) resume in primary
>>    The program is not being run.
>>    FAILURE run_gdb:287: checking expression "primary_mode", expected "$", found "N"
>>
>> As you can see it does not find `breakpoint_target' on `b
>> breakpoint_target'. If debuiginfo is installed test will pass.
>>
>> I recommend removing `static' from `breakpoint_target' definition, so
>> that symbol is exported without need of debuginfo.
> 
> It turned out that removing `static' was not enough to pass binary
> stripping. I will investigate better solution further.

Stripping must not happen - how did you build things? On debian, we have 
"dh_strip -s --exclude=smokey" in the rules to ensure that smokey keeps 
its debuginfos.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: FAILURE run_gdb:287: checking expression "primary_mode", expected "$", found "N"

[Vitaly Chikunov]

Jan,

On Tue, Apr 21, 2020 at 07:10:55AM +0200, Jan Kiszka via Xenomai wrote:
> On 21.04.20 04:43, Vitaly Chikunov via Xenomai wrote:
> > On Tue, Apr 21, 2020 at 03:27:29AM +0300, Vitaly Chikunov via Xenomai wrote:
> > > On Tue, Apr 21, 2020 at 01:18:50AM +0300, Vitaly Chikunov via Xenomai wrote:
> > > I recommend removing `static' from `breakpoint_target' definition, so
> > > that symbol is exported without need of debuginfo.
> > 
> > It turned out that removing `static' was not enough to pass binary
> > stripping. I will investigate better solution further.
> 
> Stripping must not happen - how did you build things? On debian, we have
> "dh_strip -s --exclude=smokey" in the rules to ensure that smokey keeps its
> debuginfos.

Oh, yes I can disable stripping for snokey in our build system too. So
there is no need to remove `static'. (But other two points remain.)

Thanks!

Re: FAILURE run_gdb:287: checking expression "primary_mode", expected "$", found "N"

[Jan Kiszka]

On 21.04.20 02:27, Vitaly Chikunov via Xenomai wrote:
> 2. There is additional problem with gdb test, though. If I have in my
> `.gdbinit' value of `prompt' redefined - gdb test fails to recognize the
> prompt.  I recommend adding `-nx' option to gdb arguments so that
> `.gdbinit' is not read by default.
> 
> gdb --help:
>    --nh               Do not read ~/.gdbinit.
>    --nx               Do not read any .gdbinit files in any directory.
> 
> I believe these changes will make xeno-test more robust.
> 

Good point! Should be added to the smokey gdb testcase where it starts 
gdb. Would you send a patch?

> 3. Also, note that `-k' switch is not worked.

There are several test cases in smokey, gdb included, that terminate the 
test process on errors. Probably, those need to be changed to return an 
error code from the test main function. Not trivial in all cases.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux