[PATCH 0/2] Allow GPIO timestamps also via real-time clock
As discussed, we need to add a separate control to manage whether the monotonic or the real-time clock should be used for GPIO timestamping. Patch 1 adds this, keeping the default to monotonic. This can be added to 3.1.x stable as well. Patch 2 aligns the default to the rest of Xenomai, using real-time from now on. That's 3.2 material. Jan Jan Kiszka (2): drivers/gpio: Add support for selecting real-time clock timestamps drivers/gpio: Flip default for GPIO_RTIOC_TS to real-time clock include/cobalt/kernel/rtdm/gpio.h | 1 + include/rtdm/uapi/gpio.h | 4 +++- kernel/drivers/gpio/gpio-core.c | 14 +++--- 3 files changed, 15 insertions(+), 4 deletions(-) -- 2.31.1
[PATCH 2/2] drivers/gpio: Flip default for GPIO_RTIOC_TS to real-time clock
From: Jan Kiszka
This is in line with other drivers and should avoid surprises like [1]
in the future.
[1] https://xenomai.org/pipermail/xenomai/2021-June/045661.html
Signed-off-by: Jan Kiszka
---
include/rtdm/uapi/gpio.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/rtdm/uapi/gpio.h b/include/rtdm/uapi/gpio.h
index fb84274453..82612a53d3 100644
--- a/include/rtdm/uapi/gpio.h
+++ b/include/rtdm/uapi/gpio.h
@@ -30,8 +30,8 @@ struct rtdm_gpio_readout {
#define GPIO_RTIOC_REQS_IO(RTDM_CLASS_GPIO, 4)
#define GPIO_RTIOC_RELS_IO(RTDM_CLASS_GPIO, 5)
#define GPIO_RTIOC_TS_MONO _IOR(RTDM_CLASS_GPIO, 7, int)
-#define GPIO_RTIOC_TS GPIO_RTIOC_TS_MONO
#define GPIO_RTIOC_TS_REAL _IOR(RTDM_CLASS_GPIO, 8, int)
+#define GPIO_RTIOC_TS GPIO_RTIOC_TS_REAL
#define GPIO_TRIGGER_NONE 0x0 /* unspecified */
#define GPIO_TRIGGER_EDGE_RISING 0x1
--
2.31.1
Re: [PATCH v2,2/2] Add --disable-{demo,testsuite} options
On 13.08.21 17:04, Fabrice Fontaine via Xenomai wrote: > Allow the user to disable demo and testsuite to decrease compilation > time and save disk space. > > Signed-off-by: Fabrice Fontaine > --- > Makefile.am | 12 ++-- > configure.ac | 12 > 2 files changed, 22 insertions(+), 2 deletions(-) > > diff --git a/Makefile.am b/Makefile.am > index 891e53f66..604644277 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -6,9 +6,17 @@ SUBDIRS =\ > config \ > include \ > scripts \ > - testsuite \ > - utils \ > + utils > + > +if XENO_ENABLE_DEMO > +SUBDIRS += \ > demo > +endif > + > +if XENO_ENABLE_TESTSUITE > +SUBDIRS += \ > + testsuite > +endif > > EXTRA_DIST = kernel debian > > diff --git a/configure.ac b/configure.ac > index bd5fd5ba9..29dfd16e5 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -200,6 +200,18 @@ test \! x$debug_mode = x && > AC_DEFINE(CONFIG_XENO_DEBUG,1,[config]) > AM_CONDITIONAL(XENO_DEBUG_FULL,[test x$debug_mode = xfull]) > test x$debug_mode = xfull && AC_DEFINE(CONFIG_XENO_DEBUG_FULL,1,[config]) > > +dnl Demo (default: on) > + > +AC_ARG_ENABLE(demo, > + AS_HELP_STRING([--disable-demo], [Disable demo])) > +AM_CONDITIONAL(XENO_ENABLE_DEMO,[test x$enable_demo != xno]) > + > +dnl Testsuite (default: on) > + > +AC_ARG_ENABLE(testsuite, > + AS_HELP_STRING([--disable-testsuite], [Disable testsuite])) > +AM_CONDITIONAL(XENO_ENABLE_TESTSUITE,[test x$enable_testsuite != xno]) > + > dnl Low resolution clock (default: off) > > unset lores_clock > Thanks, applied this one, with minor tuning of --disable-demo help. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
[PATCH] ci: Add 32-bit x86 compat userland build
From: Jan Kiszka
This should help to catch breakages of the compat case.
We only need to build userland as the kernel is already covered by the
x86 job.
Signed-off-by: Jan Kiszka
---
.gitlab-ci.yml | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 05b226b474..68785f657c 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -27,6 +27,7 @@ variables:
autoconf autogen libtool pkg-config ccache flex libssl-dev"
PACKAGES_arm: "gcc-${GCC_VERSION} gcc-${GCC_VERSION}-arm-linux-gnueabihf
libc6-dev-armhf-cross"
PACKAGES_arm64: "gcc-${GCC_VERSION} gcc-${GCC_VERSION}-aarch64-linux-gnu
libc6-dev-arm64-cross"
+ PACKAGES_i386: "gcc-${GCC_VERSION} gcc-${GCC_VERSION}-i686-linux-gnu
libc6-dev-i386-cross"
PACKAGES_powerpc: "gcc-8 gcc-8-powerpc-linux-gnu libc6-dev-powerpc-cross"
PACKAGES_x86: "gcc-${GCC_VERSION}"
XENOMAI_IMAGES_BRANCH: "master"
@@ -39,7 +40,7 @@ variables:
- apt install -y ${PACKAGES} ${!ARCH_PACKAGES}
- REV=$(git ls-remote --tags --head --refs ${PIPELINE_KERNEL} | sed -e
"s/.*[[:space:]]refs\/\(tags\|heads\)\///" | grep "${PIPELINE_REV}" | sort -r
-n -t - -k 5 -k 6 | head -1)
- test -n "${REV}" || REV="${PIPELINE_REV}"
-- git clone --depth 1 --branch ${REV} ${PIPELINE_KERNEL} ${KDIR}
+- test -n "${PIPELINE_KERNEL}" && git clone --depth 1 --branch ${REV}
${PIPELINE_KERNEL} ${KDIR}
- case "${ARCH}" in
"arm64")
export CROSS_COMPILE=aarch64-linux-gnu-;
@@ -51,6 +52,11 @@ variables:
export CONFIGURE_OPTS="--host=arm-linux-gnueabihf
--with-cc=arm-linux-gnueabihf-gcc";
update-alternatives --install /usr/bin/arm-linux-gnueabihf-gcc
arm-linux-gnueabihf-gcc /usr/bin/arm-linux-gnueabihf-gcc-${GCC_VERSION} 800;
;;
+ "i386")
+ export CROSS_COMPILE=i686-linux-gnu-;
+ export CONFIGURE_OPTS="--host=i686-linux-gnu
--with-cc=i686-linux-gnu-gcc";
+ update-alternatives --install /usr/bin/i686-linux-gnu-gcc
i686-linux-gnu-gcc /usr/bin/i686-linux-gnu-gcc-${GCC_VERSION} 800;
+ ;;
"powerpc")
export GCC_VERSION=8
export CROSS_COMPILE=powerpc-linux-gnu-;
@@ -255,6 +261,17 @@ x86-4.19-cip-release:
PIPELINE_KERNEL: ${IPIPE_URL}/ipipe-x86.git
KERNEL_DEFCONFIG: x86_64_defconfig
+i386-userland:
+ extends: .build
+ variables:
+ARCH: i386
+ script:
+- export CCACHE_DIR=$(pwd)/.ccache
+- scripts/bootstrap
+- ./configure --enable-smp ${CONFIGURE_OPTS}
+- make -j $(nproc)
+- ccache -s
+
powerpc-4.19-release:
extends: .build
image: debian:buster
--
2.31.1
[PATCH] lib/cobalt: x86: Relax asm constraints for syscall wrapper
From: Jan Kiszka
The y2038 test will pass the syscall number as variable. This is in
conflict with immediate constraint the current wrapper uses so far.
Relax it, the compiler will still use immediate where possible.
Signed-off-by: Jan Kiszka
---
Adding this before your series in next.
lib/cobalt/arch/x86/include/asm/xenomai/syscall.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h
b/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h
index 21aace16f9..2e02b9983b 100644
--- a/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h
+++ b/lib/cobalt/arch/x86/include/asm/xenomai/syscall.h
@@ -84,7 +84,7 @@ asm (".L__X'%ebx = 1\n\t"
DOSYSCALL \
RESTOREARGS_##nr\
: "=a" (__resultvar)\
- : "i" (__xn_syscode(op)) ASMFMT_##nr(args) \
+ : "g" (__xn_syscode(op)) ASMFMT_##nr(args) \
: "memory", "cc"); \
(int) __resultvar; \
})
@@ -98,7 +98,7 @@ asm (".L__X'%ebx = 1\n\t"
DOSYSCALLSAFE \
RESTOREARGS_##nr\
: "=a" (__resultvar)\
- : "i" (__xn_syscode(op)) ASMFMT_##nr(args) \
+ : "g" (__xn_syscode(op)) ASMFMT_##nr(args) \
: "memory", "cc"); \
(int) __resultvar; \
})
--
2.31.1
Re: [PATCH v2,1/2] fix build on arc and riscv32
On 13.08.21 17:04, Fabrice Fontaine via Xenomai wrote:
> Fix the following build failures on arc and riscv32 (same issue in
> demo/alchemy/altency.c and testsuite/latency/latency.c):
>
> altency.c: In function ‘display’:
> altency.c:262:21: error: format ‘%ld’ expects argument of type ‘long int’,
> but argument 2 has type ‘time_t’ {aka ‘long long int’} [-Werror=format=]
> 262 | ("RTT| %.2ld:%.2ld:%.2ld (%s, %Ld us period, "
> | ^
> | |
> | long int
> | %.2lld
> 263 | "priority %d)\n", dt / 3600,
> |~
> | |
> | time_t {aka long long int}
> altency.c:262:27: error: format ‘%ld’ expects argument of type ‘long int’,
> but argument 3 has type ‘time_t’ {aka ‘long long int’} [-Werror=format=]
> 262 | ("RTT| %.2ld:%.2ld:%.2ld (%s, %Ld us period, "
> | ^
> | |
> | long int
> | %.2lld
> 263 | "priority %d)\n", dt / 3600,
> 264 | (dt / 60) % 60, dt % 60,
> | ~~
> ||
> |time_t {aka long long int}
> altency.c:262:33: error: format ‘%ld’ expects argument of type ‘long int’,
> but argument 4 has type ‘time_t’ {aka ‘long long int’} [-Werror=format=]
> 262 | ("RTT| %.2ld:%.2ld:%.2ld (%s, %Ld us period, "
> | ^
> | |
> | long int
> | %.2lld
> 263 | "priority %d)\n", dt / 3600,
> 264 | (dt / 60) % 60, dt % 60,
> | ~~~
> | |
> | time_t {aka long long int}
> altency.c: In function ‘cleanup’:
> altency.c:417:7: error: format ‘%ld’ expects argument of type ‘long int’, but
> argument 7 has type ‘time_t’ {aka ‘long long int’} [-Werror=format=]
> 417 |
> ("---|---|---|---||--|-\n"
> |
> ^
> ..
> 420 | goverrun, max_relaxed, actual_duration / 3600, (actual_duration
> / 60) % 60,
> | ~~
> | |
> | time_t {aka long long
> int}
> altency.c:418:49: note: format string is defined here
> 418 | "RTS|%11.3f|%11.3f|%11.3f|%8d|%6u|
> %.2ld:%.2ld:%.2ld/%.2d:%.2d:%.2d\n",
> | ^
> | |
> | long int
> | %.2lld
> altency.c:417:7: error: format ‘%ld’ expects argument of type ‘long int’, but
> argument 8 has type ‘time_t’ {aka ‘long long int’} [-Werror=format=]
> 417 |
> ("---|---|---|---||--|-\n"
> |
> ^
> ..
> 420 | goverrun, max_relaxed, actual_duration / 3600, (actual_duration
> / 60) % 60,
> |
> ~~~
> |
> |
> |
> time_t {aka long long int}
> altency.c:418:55: note: format string is defined here
> 418 | "RTS|%11.3f|%11.3f|%11.3f|%8d|%6u|
> %.2ld:%.2ld:%.2ld/%.2d:%.2d:%.2d\n",
> | ^
> | |
> | long int
> | %.2lld
> altency.c:417:7: error: format ‘%ld’ expects argument of type ‘long int’, but
> argument 9 has type ‘time_t’ {aka ‘long long int’} [-Werror=format=]
> 417 |
> ("---|---|---|---||--|-\n"
> |
> ^
> ..
> 421 | actual_duration % 60, test_duration / 3600,
> |
> | |
> | time_t {aka long long int}
> altency.c:418:61: note: format string is defined here
> 418 | "RTS|%11.3f|%11.3f|%11.3f|%8d|%6u|
>
[PATCH] linux-xenomai: Disable I-pipe debugging on bbb also for 4.4-latest
From: Jan Kiszka
This was missed by 1ba9500dd5.
Signed-off-by: Jan Kiszka
---
recipes-kernel/linux/linux-xenomai_latest.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/recipes-kernel/linux/linux-xenomai_latest.bb
b/recipes-kernel/linux/linux-xenomai_latest.bb
index 09df461..836fa52 100644
--- a/recipes-kernel/linux/linux-xenomai_latest.bb
+++ b/recipes-kernel/linux/linux-xenomai_latest.bb
@@ -34,4 +34,6 @@ GIT_BRANCH_arm64 = "${@'v5.10.y-dovetail-rebase' if
is_kernel(d, '5.10') else 'i
SRC_URI += "${GIT_REPO};protocol=https;branch=${GIT_BRANCH}"
SRCREV = "${AUTOREV}"
+SRC_URI_append_armhf = " ${@ 'file://bbb_4.4.cfg' if is_xeno_3_0(d) and
d.getVar('MACHINE') == 'beagle-bone-black' else '' }"
+
S = "${WORKDIR}/git"
--
2.31.1
Re: [PATCH v2] testsuite/smokey: Fixing a registry leak of the posix_select test
On 13.08.21 16:33, Florian Bezdeka wrote:
> According to POSIX message queues have kernel persistence, which means
> they are not cleaned up until the next reboot.
>
> The test has a mq_unlink() as "precondition", so it will clean up
> failed test runs silently but /proc/xenomai/registry/usage will still
> report a "leak" once the test has completed.
>
> Signed-off-by: Florian Bezdeka
> ---
> testsuite/smokey/posix-select/posix-select.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/testsuite/smokey/posix-select/posix-select.c
> b/testsuite/smokey/posix-select/posix-select.c
> index e9bf938b3..1484fa639 100644
> --- a/testsuite/smokey/posix-select/posix-select.c
> +++ b/testsuite/smokey/posix-select/posix-select.c
> @@ -140,6 +140,8 @@ static int run_posix_select(struct smokey_test *t, int
> argc, char *const argv[])
> ret = test_status;
> out:
> pthread_join(tcb, NULL);
> -
> +
> + mq_unlink("/select_test_mq");
> +
> return ret;
> }
>
Thanks, applied.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [xenomai-images][PATCH] linux-xenomai: Add tracing support to arm64
On 13.08.21 13:36, Florian Bezdeka wrote: > The tracing support was disabled on arm64 but enabled on all other > targets we support. Taking the trace configuration from armhf to be able > to trace on arm64 as well. > > Signed-off-by: Florian Bezdeka > --- > recipes-kernel/linux/files/arm64_defconfig | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/recipes-kernel/linux/files/arm64_defconfig > b/recipes-kernel/linux/files/arm64_defconfig > index a010c30..9bacb82 100644 > --- a/recipes-kernel/linux/files/arm64_defconfig > +++ b/recipes-kernel/linux/files/arm64_defconfig > @@ -6000,7 +6000,10 @@ CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y > CONFIG_HAVE_SYSCALL_TRACEPOINTS=y > CONFIG_HAVE_C_RECORDMCOUNT=y > CONFIG_TRACING_SUPPORT=y > -# CONFIG_FTRACE is not set > +CONFIG_EVENT_TRACING=y > +CONFIG_CONTEXT_SWITCH_TRACER=y > +CONFIG_TRACING=y > +CONFIG_FTRACE=y > # CONFIG_DMA_API_DEBUG is not set > > # > Thanks, applied. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH] Add --disable-{demo,testsuite} options
On 13.08.21 15:17, Fabrice Fontaine wrote:
> Le ven. 13 août 2021 à 10:54, Jan Kiszka a écrit :
>>
>> On 13.08.21 10:12, Fabrice Fontaine via Xenomai wrote:
>>> Allow the user to disable demo and testsuite to avoid the following
>>> build failures on arc and riscv32:
>>
>> Are you working on ports to those archs? Or is xenomai userland just
>> prematurely built for those in buildroot?
> No, I'm not working on ports to those archs. I just sent this patch to
> fix buidlroot autobuilder failures. I'm not even an expert in xenomai.
> In buildroot, we allow to build xenomai userland on all architectures.
> The only requirement on the toolchain is that it must have threads,
> sync and must be uclibc or glibc:
> https://git.buildroot.net/buildroot/commit/package/xenomai/Config.in?id=c35f157486431eafdb8d3583fc52d8ce4c784cf3.
> In cobalt core, we're restricting the architectures to x86, powerpc and ARM.
Ah, ok, these are mercury userland builds. Makes more sense now.
>>
>>>
>>> latency.c: In function 'display':
>>> latency.c:326:21: error: format '%ld' expects argument of type 'long int',
>>> but argument 2 has type 'time_t' {aka 'long long int'} [-Werror=format=]
>>> 326 | ("RTT| %.2ld:%.2ld:%.2ld (%s, %Ld us period, "
>>> | ^
>>> | |
>>> | long int
>>> | %.2lld
>>> 327 | "priority %d)\n", dt / 3600,
>>> |~
>>> | |
>>> | time_t {aka long long int}
>>>
>>> altency.c: In function ‘display’:
>>> altency.c:262:21: error: format ‘%ld’ expects argument of type ‘long int’,
>>> but argument 2 has type ‘time_t’ {aka ‘long long int’} [-Werror=format=]
>>> 262 | ("RTT| %.2ld:%.2ld:%.2ld (%s, %Ld us period, "
>>> | ^
>>> | |
>>> | long int
>>> | %.2lld
>>> 263 | "priority %d)\n", dt / 3600,
>>> |~
>>> | |
>>> | time_t {aka long long int}
>>>
>>
>> How about fixing those issues instead?
> Indeed, fixing those issues would be great. I'll let you handle that.
I wouldn't mind getting patches as well. ;)
> However, I also think that disabling demo and testsuite is a nice
> addition as it will decrease compile time and save disk space.
I don't disagree. I just don't like merging a feature with the argument
"this works around a bug". If you resend with adjusted reasoning, I'm
fine with merging the functional changes.
But then I would still not use that to address the above errors...
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
[xenomai-images][PATCH] ci: Do not rely on S3_BUCKET_URL being terminated by a slash
From: Jan Kiszka
Duplicate slashes cause no harm, but a missing can lead to confusing
errors.
Signed-off-by: Jan Kiszka
---
Inserted before "ci: Add default for S3_BUCKET_URL" which didn't add a
slash, thus triggered this issue.
scripts/deploy_to_aws.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/deploy_to_aws.sh b/scripts/deploy_to_aws.sh
index 5a5b29a..9864cc1 100755
--- a/scripts/deploy_to_aws.sh
+++ b/scripts/deploy_to_aws.sh
@@ -28,7 +28,7 @@ destination="${S3_BUCKET_URL}"
aws_args="--acl=public-read"
isar_base_name="${ISAR_IMAGE}-${ISAR_DISTRIBUTION}-${target}"
-deploy_dir="${destination}${CI_PIPELINE_ID}/${DEPLOY_DIR_EXTENSION}"
+deploy_dir="${destination}/${CI_PIPELINE_ID}/${DEPLOY_DIR_EXTENSION}"
#KERNEL
aws s3 cp "${aws_args}" "${images_dir}/${target}/${isar_base_name}-vmlinuz"
"${deploy_dir}/${isar_base_name}-vmlinuz"
# INITRD
--
2.31.1
[xenomai-images][PATCH v2] ci: Add default for S3_BUCKET_URL
From: Jan Kiszka
This corresponds to the default for LAVA_ARTIFACTS_URL.
Signed-off-by: Jan Kiszka
---
Changes in v2:
- reorder to fix failing consistency check before default was assigned
scripts/deploy_to_aws.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/scripts/deploy_to_aws.sh b/scripts/deploy_to_aws.sh
index 9864cc1..e7c22f0 100755
--- a/scripts/deploy_to_aws.sh
+++ b/scripts/deploy_to_aws.sh
@@ -18,13 +18,13 @@ if [ -z "${target}" ]; then
fi
images_dir=build/tmp/deploy/images
-if [ -z "${S3_BUCKET_URL}" ] || [ -z "${AWS_ACCESS_KEY_ID}" ] || [ -z
"${AWS_SECRET_ACCESS_KEY}" ]; then
+destination="${S3_BUCKET_URL:-s3://xenomai-images-artifacts/artifacts}"
+
+if [ -z "${destination}" ] || [ -z "${AWS_ACCESS_KEY_ID}" ] || [ -z
"${AWS_SECRET_ACCESS_KEY}" ]; then
echo "environment not available or incomplete - do not deploy"
exit 0
fi
-destination="${S3_BUCKET_URL}"
-
aws_args="--acl=public-read"
isar_base_name="${ISAR_IMAGE}-${ISAR_DISTRIBUTION}-${target}"
--
2.31.1
Re: [PATCH] Add --disable-{demo,testsuite} options
On 13.08.21 10:12, Fabrice Fontaine via Xenomai wrote:
> Allow the user to disable demo and testsuite to avoid the following
> build failures on arc and riscv32:
Are you working on ports to those archs? Or is xenomai userland just
prematurely built for those in buildroot?
>
> latency.c: In function 'display':
> latency.c:326:21: error: format '%ld' expects argument of type 'long int',
> but argument 2 has type 'time_t' {aka 'long long int'} [-Werror=format=]
> 326 | ("RTT| %.2ld:%.2ld:%.2ld (%s, %Ld us period, "
> | ^
> | |
> | long int
> | %.2lld
> 327 | "priority %d)\n", dt / 3600,
> |~
> | |
> | time_t {aka long long int}
>
> altency.c: In function ‘display’:
> altency.c:262:21: error: format ‘%ld’ expects argument of type ‘long int’,
> but argument 2 has type ‘time_t’ {aka ‘long long int’} [-Werror=format=]
> 262 | ("RTT| %.2ld:%.2ld:%.2ld (%s, %Ld us period, "
> | ^
> | |
> | long int
> | %.2lld
> 263 | "priority %d)\n", dt / 3600,
> |~
> | |
> | time_t {aka long long int}
>
How about fixing those issues instead?
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH v4 3/5] y2038: cobalt/posix/muqueue: Adding mq_timedreceive64
On 13.08.21 08:53, Jan Kiszka via Xenomai wrote:
> On 12.08.21 18:28, Florian Bezdeka wrote:
>> From: Song Chen
>>
>> Add a syscall specific for mq_timedreceive64 with 64bit time_t.
>>
>> Signed-off-by: Song Chen
>> [Florian:
>> - Reformat commit msg
>> - relocate code
>> - tracing
>> - fix syscall declarations
>> ]
>> Signed-off-by: Florian Bezdeka
>> ---
>>
>> @Jan: This should replace 76607e1a7237 in next. Other patches of the
>> same series were not affected.
>>
>> Changes in v4:
>> - Fixed COBALT_SYSCALL vs. COBALT_SYSCALL_DECL
>>
>> include/cobalt/uapi/syscall.h | 1 +
>> kernel/cobalt/posix/mqueue.c | 28 +++-
>> kernel/cobalt/posix/mqueue.h | 10 ++
>> kernel/cobalt/posix/syscall32.c| 8
>> kernel/cobalt/posix/syscall32.h| 5 +
>> kernel/cobalt/trace/cobalt-posix.h | 3 ++-
>> 6 files changed, 53 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/cobalt/uapi/syscall.h b/include/cobalt/uapi/syscall.h
>> index 464e170cc..c27d6d044 100644
>> --- a/include/cobalt/uapi/syscall.h
>> +++ b/include/cobalt/uapi/syscall.h
>> @@ -130,6 +130,7 @@
>> #define sc_cobalt_clock_adjtime64 107
>> #define sc_cobalt_mutex_timedlock64 108
>> #define sc_cobalt_mq_timedsend64109
>> +#define sc_cobalt_mq_timedreceive64 110
>>
>> #define __NR_COBALT_SYSCALLS128 /* Power of 2 */
>>
>> diff --git a/kernel/cobalt/posix/mqueue.c b/kernel/cobalt/posix/mqueue.c
>> index a1828919c..ebe7cf7b0 100644
>> --- a/kernel/cobalt/posix/mqueue.c
>> +++ b/kernel/cobalt/posix/mqueue.c
>> @@ -629,7 +629,7 @@ redo:
>> ret = fetch_timeout(, u_ts);
>> if (ret)
>> return ERR_PTR(ret);
>> -if (ts.tv_nsec >= ONE_BILLION)
>> +if (!timespec64_valid())
>> return ERR_PTR(-EINVAL);
>> to = ts2ns() + 1;
>> tmode = XN_REALTIME;
>> @@ -1013,6 +1013,24 @@ fail:
>> return ret;
>> }
>>
>> +int __cobalt_mq_timedreceive64(mqd_t uqd, void __user *u_buf,
>> + ssize_t __user *u_len,
>> + unsigned int __user *u_prio,
>> + const void __user *u_ts)
>> +{
>> +ssize_t len;
>> +int ret;
>> +
>> +ret = cobalt_copy_from_user(, u_len, sizeof(len));
>> +if (ret)
>> +return ret;
>> +
>> +ret = __cobalt_mq_timedreceive(uqd, u_buf, , u_prio, u_ts,
>> + u_ts ? mq_fetch_timeout64 : NULL);
>> +
>> +return ret ?: cobalt_copy_to_user(u_len, , sizeof(*u_len));
>> +}
>> +
>> COBALT_SYSCALL(mq_timedreceive, primary,
>> (mqd_t uqd, void __user *u_buf,
>> ssize_t __user *u_len,
>> @@ -1031,3 +1049,11 @@ COBALT_SYSCALL(mq_timedreceive, primary,
>>
>> return ret ?: cobalt_copy_to_user(u_len, , sizeof(*u_len));
>> }
>> +
>> +COBALT_SYSCALL(mq_timedreceive64, primary,
>> + (mqd_t uqd, void __user *u_buf, ssize_t __user *u_len,
>> +unsigned int __user *u_prio,
>> +const struct __kernel_timespec __user *u_ts))
>> +{
>> +return __cobalt_mq_timedreceive64(uqd, u_buf, u_len, u_prio, u_ts);
>> +}
>> diff --git a/kernel/cobalt/posix/mqueue.h b/kernel/cobalt/posix/mqueue.h
>> index f16774a3b..b4b263158 100644
>> --- a/kernel/cobalt/posix/mqueue.h
>> +++ b/kernel/cobalt/posix/mqueue.h
>> @@ -50,6 +50,11 @@ int __cobalt_mq_timedreceive(mqd_t uqd, void __user
>> *u_buf,
>> int (*fetch_timeout)(struct timespec64 *ts,
>>const void __user *u_ts));
>>
>> +int __cobalt_mq_timedreceive64(mqd_t uqd, void __user *u_buf,
>> + ssize_t __user *u_len,
>> + unsigned int __user *u_prio,
>> + const void __user *u_ts);
>> +
>> int __cobalt_mq_notify(mqd_t fd, const struct sigevent *evp);
>>
>> COBALT_SYSCALL_DECL(mq_open,
>> @@ -76,6 +81,11 @@ COBALT_SYSCALL_DECL(mq_timedreceive,
>> unsigned int __user *u_prio,
>> const struct __user_old_timespec __user *u_ts));
>>
>> +COBALT_SYSCALL_DECL(mq_timedreceive64,
>> +(mqd_t
Re: [PATCH v4 0/3] y2038: Adding event_wait64()
On 12.08.21 09:09, Florian Bezdeka wrote: > Hi! > > Just another y2038 related syscall, once again based on v1 sent out by > Song and rebased to current next with some code- and test-cleanups applied. > > @Song: > This one was the last one in my inbox. Please make sure that all > following patches are based on next. IIRC there are 3 or 4 syscalls > remaining. We should take care of [1] as well. We need something in the CI > that tests the full implementation, i.e. including the glibc wrappers > (proper syscall delegation). According to the changelog [2] of recent > glibc we should be able to use 64bit time_t. > > [1]: https://gitlab.com/Xenomai/xenomai-hacker-space/-/issues/21 > [2]: https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html > > Best regards, > Florian > > Changes in v4: > - Rework Patch 3. See commit message for details. > Mostly test improvements. > > Changes in v3: > - None. git send-mail folded two different series together. Resending > to allow maintainers to pick this series at once. Sorry for that. > > > > Florian Bezdeka (1): > y2038: testsuite/smokey/y2038: Adding tests for event_wait64 > > Song Chen (2): > y2038: cobalt/posix/event: Adding event_wait64 > y2038: lib/cobalt/internal: dispatch event_wait > > include/cobalt/uapi/syscall.h | 1 + > kernel/cobalt/posix/event.c| 34 - > kernel/cobalt/posix/event.h| 12 > kernel/cobalt/posix/syscall32.c| 9 +++ > kernel/cobalt/posix/syscall32.h| 7 ++ > kernel/cobalt/trace/cobalt-posix.h | 3 +- > lib/cobalt/internal.c | 5 ++ > testsuite/smokey/y2038/syscall-tests.c | 95 +++--- > 8 files changed, 153 insertions(+), 13 deletions(-) > Thanks, applied. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH v2 0/3] y2038: Adding monitor_wait64()
On 11.08.21 10:11, Florian Bezdeka wrote: > Hi! > > Just another y2038 related syscall, once again based on v1 sent out by > Song and rebased to current next. > > Best regards, > Florian > > Florian Bezdeka (2): > y2038: cobalt/posix/monitor: Adding monitor_wait64 > y2038: testsuite/smokey/y2038: Adding testcases for monitor_wait64() > > Song Chen (1): > y2038: lib/cobalt/internal: dispatch monitor_wait > > include/cobalt/uapi/syscall.h | 1 + > kernel/cobalt/posix/monitor.c | 32 ++- > kernel/cobalt/posix/monitor.h | 10 > kernel/cobalt/posix/syscall32.c| 8 +++ > kernel/cobalt/posix/syscall32.h| 6 ++ > kernel/cobalt/trace/cobalt-posix.h | 3 +- > lib/cobalt/internal.c | 8 ++- > testsuite/smokey/y2038/syscall-tests.c | 78 +- > 8 files changed, 141 insertions(+), 5 deletions(-) > Thanks, applied. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH] testsuite/smokey: Fixing a registry leak of the posix_select test
On 12.08.21 18:38, Florian Bezdeka wrote:
> According to POSIX message queues have kernel persistence, which means
> they are not cleaned up until the next reboot.
>
> The test has a mq_unlink() as "precondition", so it will clean up
> failed test runs silently but /proc/xenomai/registry/usage will still
> report a "leak" once the test has completed.
>
> Signed-off-by: Florian Bezdeka
> ---
> testsuite/smokey/posix-select/posix-select.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/testsuite/smokey/posix-select/posix-select.c
> b/testsuite/smokey/posix-select/posix-select.c
> index e9bf938b3..0a59e4968 100644
> --- a/testsuite/smokey/posix-select/posix-select.c
> +++ b/testsuite/smokey/posix-select/posix-select.c
> @@ -138,6 +138,8 @@ static int run_posix_select(struct smokey_test *t, int
> argc, char *const argv[])
> usleep(30);
> smp_rmb();
> ret = test_status;
> +
> + mq_unlink("/select_test_mq");
> out:
> pthread_join(tcb, NULL);
>
>
Why only cleaning up on successful runs, ie. why doing this before the
"out:" label?
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH v4 3/5] y2038: cobalt/posix/muqueue: Adding mq_timedreceive64
On 12.08.21 18:28, Florian Bezdeka wrote:
> From: Song Chen
>
> Add a syscall specific for mq_timedreceive64 with 64bit time_t.
>
> Signed-off-by: Song Chen
> [Florian:
> - Reformat commit msg
> - relocate code
> - tracing
> - fix syscall declarations
> ]
> Signed-off-by: Florian Bezdeka
> ---
>
> @Jan: This should replace 76607e1a7237 in next. Other patches of the
> same series were not affected.
>
> Changes in v4:
> - Fixed COBALT_SYSCALL vs. COBALT_SYSCALL_DECL
>
> include/cobalt/uapi/syscall.h | 1 +
> kernel/cobalt/posix/mqueue.c | 28 +++-
> kernel/cobalt/posix/mqueue.h | 10 ++
> kernel/cobalt/posix/syscall32.c| 8
> kernel/cobalt/posix/syscall32.h| 5 +
> kernel/cobalt/trace/cobalt-posix.h | 3 ++-
> 6 files changed, 53 insertions(+), 2 deletions(-)
>
> diff --git a/include/cobalt/uapi/syscall.h b/include/cobalt/uapi/syscall.h
> index 464e170cc..c27d6d044 100644
> --- a/include/cobalt/uapi/syscall.h
> +++ b/include/cobalt/uapi/syscall.h
> @@ -130,6 +130,7 @@
> #define sc_cobalt_clock_adjtime64107
> #define sc_cobalt_mutex_timedlock64 108
> #define sc_cobalt_mq_timedsend64 109
> +#define sc_cobalt_mq_timedreceive64 110
>
> #define __NR_COBALT_SYSCALLS 128 /* Power of 2 */
>
> diff --git a/kernel/cobalt/posix/mqueue.c b/kernel/cobalt/posix/mqueue.c
> index a1828919c..ebe7cf7b0 100644
> --- a/kernel/cobalt/posix/mqueue.c
> +++ b/kernel/cobalt/posix/mqueue.c
> @@ -629,7 +629,7 @@ redo:
> ret = fetch_timeout(, u_ts);
> if (ret)
> return ERR_PTR(ret);
> - if (ts.tv_nsec >= ONE_BILLION)
> + if (!timespec64_valid())
> return ERR_PTR(-EINVAL);
> to = ts2ns() + 1;
> tmode = XN_REALTIME;
> @@ -1013,6 +1013,24 @@ fail:
> return ret;
> }
>
> +int __cobalt_mq_timedreceive64(mqd_t uqd, void __user *u_buf,
> +ssize_t __user *u_len,
> +unsigned int __user *u_prio,
> +const void __user *u_ts)
> +{
> + ssize_t len;
> + int ret;
> +
> + ret = cobalt_copy_from_user(, u_len, sizeof(len));
> + if (ret)
> + return ret;
> +
> + ret = __cobalt_mq_timedreceive(uqd, u_buf, , u_prio, u_ts,
> +u_ts ? mq_fetch_timeout64 : NULL);
> +
> + return ret ?: cobalt_copy_to_user(u_len, , sizeof(*u_len));
> +}
> +
> COBALT_SYSCALL(mq_timedreceive, primary,
> (mqd_t uqd, void __user *u_buf,
> ssize_t __user *u_len,
> @@ -1031,3 +1049,11 @@ COBALT_SYSCALL(mq_timedreceive, primary,
>
> return ret ?: cobalt_copy_to_user(u_len, , sizeof(*u_len));
> }
> +
> +COBALT_SYSCALL(mq_timedreceive64, primary,
> +(mqd_t uqd, void __user *u_buf, ssize_t __user *u_len,
> + unsigned int __user *u_prio,
> + const struct __kernel_timespec __user *u_ts))
> +{
> + return __cobalt_mq_timedreceive64(uqd, u_buf, u_len, u_prio, u_ts);
> +}
> diff --git a/kernel/cobalt/posix/mqueue.h b/kernel/cobalt/posix/mqueue.h
> index f16774a3b..b4b263158 100644
> --- a/kernel/cobalt/posix/mqueue.h
> +++ b/kernel/cobalt/posix/mqueue.h
> @@ -50,6 +50,11 @@ int __cobalt_mq_timedreceive(mqd_t uqd, void __user *u_buf,
>int (*fetch_timeout)(struct timespec64 *ts,
> const void __user *u_ts));
>
> +int __cobalt_mq_timedreceive64(mqd_t uqd, void __user *u_buf,
> +ssize_t __user *u_len,
> +unsigned int __user *u_prio,
> +const void __user *u_ts);
> +
> int __cobalt_mq_notify(mqd_t fd, const struct sigevent *evp);
>
> COBALT_SYSCALL_DECL(mq_open,
> @@ -76,6 +81,11 @@ COBALT_SYSCALL_DECL(mq_timedreceive,
>unsigned int __user *u_prio,
>const struct __user_old_timespec __user *u_ts));
>
> +COBALT_SYSCALL_DECL(mq_timedreceive64,
> + (mqd_t uqd, void __user *u_buf, ssize_t __user *u_len,
> + unsigned int __user *u_prio,
> + const struct __kernel_timespec __user *u_ts));
> +
> COBALT_SYSCALL_DECL(mq_notify,
> (mqd_t fd, const struct sigevent *__user evp));
>
> diff --git a/kernel/cobalt/posix/syscall32.c b/kernel/cobalt/posix/syscall32.c
> index d3f87c246..d52be0207 100644
> --- a/kernel/cobalt/posix/syscall32.c
> +++ b/kernel/cobalt/posix/syscall32.c
> @@ -354,6 +354,14 @@ COBALT_SYSCALL32emu(mq_timedreceive, primary,
> return ret ?: cobalt_copy_to_user(u_len, , sizeof(*u_len));
> }
>
> +COBALT_SYSCALL32emu(mq_timedreceive64, primary,
> + (mqd_t uqd, void __user *u_buf, ssize_t __user *u_len,
> + unsigned int __user *u_prio,
> + const struct
Re: posix_select seems to leak a registry element
On 12.08.21 16:39, Bezdeka, Florian (T RDA IOT SES-DE) wrote:
> On Thu, 2021-08-12 at 14:45 +0200, Jan Kiszka wrote:
>> On 12.08.21 14:39, Bezdeka, Florian (T RDA IOT SES-DE) wrote:
>>> Hi all,
>>>
>>> I just noticed that the posix_select test of smokey is leaking one
>>> registry element:
>>>
>>> $ cat /proc/xenomai/registry/usage
>>> 8/512
>>>
>>> $ /smokey --run=posix_select
>>> posix_select OK
>>>
>>> $ cat /proc/xenomai/registry/usage
>>> 9/512
>>>
>>> The following diff would fix that, but I assume the resource cleanup
>>> should happen on process/task exit anyway. For some reason it does not.
>>> Any ideas where to look at? Where (code location) should the cleanup
>>> take place?
>>>
>>> diff --git a/testsuite/smokey/posix-select/posix-select.c
>>> b/testsuite/smokey/posix-select/posix-select.c
>>> index e9bf938b3..0a59e4968 100644
>>> --- a/testsuite/smokey/posix-select/posix-select.c
>>> +++ b/testsuite/smokey/posix-select/posix-select.c
>>> @@ -138,6 +138,8 @@ static int run_posix_select(struct smokey_test *t,
>>> int argc, char *const argv[])
>>> usleep(30);
>>> smp_rmb();
>>> ret = test_status;
>>> +
>>> + mq_unlink("/select_test_mq");
>>> out:
>>> pthread_join(tcb, NULL);
>>>
>>
>> The change is likely correct. I'm now wondering if we are cleaning up a
>> process-shared resource here that the core may not be able to simply
>> destroy when the creator terminates. Needs to be checked if that is the
>> case or if we are truly leaking via the kernel as well.
>
> Just learned that message queues have kernel persistence.
> Taken from [1]:
>
> Persistence
>POSIX message queues have kernel persistence: if not removed by
>mq_unlink(3), a message queue will exist until the system is shut
>down.
>
> I will send the diff mentioned above as proper patch. This way smokey
> will help us detecting such leaks and we don't have false positives
> inside the test suite.
>
TIA!
> Btw: Some of the tests were skipped here because of "no kernel
> support". There might be more...
>
That should no longer be the case with xenomai-images (except for the
cpu-affinity test on dual or single-core targets).
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: posix_select seems to leak a registry element
On 12.08.21 14:39, Bezdeka, Florian (T RDA IOT SES-DE) wrote:
> Hi all,
>
> I just noticed that the posix_select test of smokey is leaking one
> registry element:
>
> $ cat /proc/xenomai/registry/usage
> 8/512
>
> $ /smokey --run=posix_select
> posix_select OK
>
> $ cat /proc/xenomai/registry/usage
> 9/512
>
> The following diff would fix that, but I assume the resource cleanup
> should happen on process/task exit anyway. For some reason it does not.
> Any ideas where to look at? Where (code location) should the cleanup
> take place?
>
> diff --git a/testsuite/smokey/posix-select/posix-select.c
> b/testsuite/smokey/posix-select/posix-select.c
> index e9bf938b3..0a59e4968 100644
> --- a/testsuite/smokey/posix-select/posix-select.c
> +++ b/testsuite/smokey/posix-select/posix-select.c
> @@ -138,6 +138,8 @@ static int run_posix_select(struct smokey_test *t,
> int argc, char *const argv[])
> usleep(30);
> smp_rmb();
> ret = test_status;
> +
> + mq_unlink("/select_test_mq");
> out:
> pthread_join(tcb, NULL);
>
The change is likely correct. I'm now wondering if we are cleaning up a
process-shared resource here that the core may not be able to simply
destroy when the creator terminates. Needs to be checked if that is the
case or if we are truly leaking via the kernel as well.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: cannot link 32 bit app
On 12.08.21 07:50, C Smith wrote: > Hi Jan,Thanks for your prompt reply. I reduced my very large app to > about 200 lines, it only starts one periodic process. but I still get > this error during linkage: > > /usr/xenomai/lib/xenomai/bootstrap.o: In function `xenomai_main': > /usr/src/xenomai-3.1/lib/boilerplate/init/bootstrap.c:94: multiple > definition of `xenomai_main' > /usr/xenomai/lib/xenomai/bootstrap.o:/usr/src/xenomai-3.1/lib/boilerplate/init/bootstrap.c:94: > first defined here > /usr/xenomai/lib/xenomai/bootstrap.o:(.rodata+0x0): multiple definition > of `xenomai_auto_bootstrap' > /usr/xenomai/lib/xenomai/bootstrap.o:(.rodata+0x0): first defined here > /usr/xenomai/lib/xenomai/bootstrap.o: In function `xenomai_main': > /usr/src/xenomai-3.1/lib/boilerplate/init/bootstrap.c:94: multiple > definition of `xenomai_main' > /usr/xenomai/lib/xenomai/bootstrap.o:/usr/src/xenomai-3.1/lib/boilerplate/init/bootstrap.c:94: > first defined here > /usr/xenomai/lib/xenomai/bootstrap.o:(.rodata+0x0): multiple definition > of `xenomai_auto_bootstrap' > /usr/xenomai/lib/xenomai/bootstrap.o:(.rodata+0x0): first defined here > /usr/xenomai/lib/xenomai/bootstrap.o: In function `xenomai_main': > /usr/src/xenomai-3.1/lib/boilerplate/init/bootstrap.c:94: multiple > definition of `xenomai_main' > /usr/xenomai/lib/xenomai/bootstrap.o:/usr/src/xenomai-3.1/lib/boilerplate/init/bootstrap.c:94: > first defined here > /usr/xenomai/lib/xenomai/bootstrap.o:(.rodata+0x0): multiple definition > of `xenomai_auto_bootstrap' > /usr/xenomai/lib/xenomai/bootstrap.o:(.rodata+0x0): first defined here > collect2: error: ld returned 1 exit status > make[1]: *** [: myapp] Error 1 > > I had used your advice to get the compiler args in my Makefile with: > /usr/xenomai/bin/xeno-config --skin=native --cflags --ldflags > The resulting command line is: > > gcc -g3 -m32 -I/usr/xenomai/include/trank -D__XENO_COMPAT__ > -I/usr/xenomai/include/cobalt > -I/usr/xenomai/include -m32 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE > -D_REENTRANT -fasynchronous-unwind-tables > -D__COBALT__ -I/usr/xenomai/include/alchemy -I/usr/xenomai/include/rtdm > -Wl,--no-as-needed -ltrank > -Wl,@/usr/xenomai/lib/modechk.wrappers -lalchemy -lcopperplate > /usr/xenomai/lib/xenomai/bootstrap.o > -Wl,--wrap=main -Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld > -L/usr/xenomai/lib -lcobalt -lmodechk > -lpthread -lrt -m32 -lfuse -pthread -I/usr/include/libxml2 -I"SOEM/" > -I"SOEM/osal" -I"SOEM/oshw/linux" > -I"SOEM/soem" -I"../include/nanopb" -Xlinker -rpath -Xlinker > /usr/xenomai/lib myapp.c ../include/myapp.h > ../include/dia_dev_myapp.h ../include/crc_table.h ../include/dacdefs.h > ../include/version.h > ../include/canopen_drives.h ../include/adcdefs.h > ../include/myapp_version.h ../include/canodefs.h > ../include/preproc_myapp.h ../include/myapp_mem_manager_data.h > ../include/comm_dta_myapp.h ../include/comproto.h > ../modules/rtdinsync.h quad.o dac.o adc.o SOEM/lib/linux/liboshw.a > SOEM/lib/linux/libosal.a SOEM/lib/linux/libsoem.a > ../include/nanopb/nanopb.a -Wl,--no-as-needed -ltrank > -Wl,@/usr/xenomai/lib/modechk.wrappers -lalchemy -lcopperplate > /usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main > -Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld > -L/usr/xenomai/lib -lcobalt -lmodechk -lpthread -lrt -m32 -lfuse > -pthread -Wl,--no-as-needed > -Wl,@/usr/xenomai/lib/cobalt.wrappers -Wl,@/usr/xenomai/lib/modechk.wrappers > /usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main > -Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld > -L/usr/xenomai/lib -lcobalt -lmodechk -lpthread -lrt -m32 -lfuse > -pthread -Wl,--no-as-needed > -Wl,@/usr/xenomai/lib/cobalt.wrappers -Wl,@/usr/xenomai/lib/modechk.wrappers > /usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main > -Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld > -L/usr/xenomai/lib -lcobalt -lmodechk -lpthread -lrt -m32 -lfuse > -pthread -lxml2 -lz -llzma -lm > -ldl -L"SOEM/lib/linux" -Wl,--start-group -loshw -losal -lsoem > -Wl,--end-group -lm -o myapp > > What is going wrong with the linkage? Thanks, C Smith > Something is broken in your makefile. If you look at the end of the resulting gcc call above, you see e.g. bootstrap.o being listed multiple times (which explains the error, obviously). This is not coming from xeno-config. So check your local setup, or just do gcc $(xeno-config ...) -o my-app my-app.c -I my-includes Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
[xenomai-images][PATCH] ci: Make default s3 fetch URL zone-independent
From: Jan Kiszka
No need to encode the European zone here into the default, let AWS sort
this out.
Signed-off-by: Jan Kiszka
---
scripts/run-lava-tests.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/run-lava-tests.sh b/scripts/run-lava-tests.sh
index b1b51bb..dde542c 100755
--- a/scripts/run-lava-tests.sh
+++ b/scripts/run-lava-tests.sh
@@ -16,7 +16,7 @@ if [ -z "${TARGET}" ]; then
fi
# S3 artifacts
-artifact_url="${LAVA_ARTIFACTS_URL:-https://xenomai-images-artifacts.s3.eu-central-1.amazonaws.com/artifacts};
+artifact_url="${LAVA_ARTIFACTS_URL:-https://xenomai-images-artifacts.s3.amazonaws.com/artifacts};
# public master
lava_master_uri="${LAVA_MASTER_URL:-https://lava.xenomai.org};
--
2.31.1
[xenomai-images][PATCH] ci: Add default for S3_BUCKET_URL
From: Jan Kiszka
This corresponds to the default for LAVA_ARTIFACTS_URL.
Signed-off-by: Jan Kiszka
---
scripts/deploy_to_aws.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/deploy_to_aws.sh b/scripts/deploy_to_aws.sh
index 5a5b29a..98deebc 100755
--- a/scripts/deploy_to_aws.sh
+++ b/scripts/deploy_to_aws.sh
@@ -23,7 +23,7 @@ if [ -z "${S3_BUCKET_URL}" ] || [ -z "${AWS_ACCESS_KEY_ID}" ]
|| [ -z "${AWS_SE
exit 0
fi
-destination="${S3_BUCKET_URL}"
+destination="${S3_BUCKET_URL:-s3://xenomai-images-artifacts/artifacts}"
aws_args="--acl=public-read"
--
2.31.1
Re: [Xenomai 4] Heads up
On 10.08.21 20:21, Philippe Gerum via Xenomai wrote: > > I won't join the Xenomai meeting this week, so this is the latest news > from Dovetail and Xenomai 4: > > Dovetail runs on top of v5.14-rc5 (arm, arm64 and x86_64), the code is > visible from the v5.14-dovetail-rebase branch at [1]. As usual, I'm > testing Dovetail with the EVL core (Xenomai 4). The current code is > available at [2] branch v5.14-evl-rebase. > > In addition, several important updates went to the stable Dovetail > (v5.10.y) tree (i.e. RCU NMI in the pipeline entry). There is no kernel > interface change which might affect Xenomai3/Cobalt 3.2 though. > > With respect to Xenomai 4, progress was made with the network > (mini-)stack based on the EVL core. The most important aspect is that > EVL is now able to leverage the common socket interface, for adding new > network protocols or extending existing ones. This is still WIP, but we > are getting closer to something usable, and EVL gained a socket > interface in the process for dealing with real-time protocols. > > In a nutshell, the basic idea is to create an out-of-band data path > traversing the regular network stack which EVL and the applications can > connect to. This means that a netdev can accept in-band and out-of-band > traffic, ethtool is still available to configure the ethernet devices > shared with EVL etc. (as a bonus, there is no need for any proxy in > order to share a single NIC between the out-of-band and in-band network > stacks). There is work ahead, and this is fun stuff. > > [1] g...@source.denx.de:Xenomai/linux-dovetail.git > [2] g...@source.denx.de:Xenomai/xenomai4/linux-evl.git > Surely interesting work. Three even more interesting aspects still needs to be seen, though: - How will driver conversions look like in practice (lock and interrupt conversions, prioritization of data paths over control paths, turning off throughput favoring features)? - How to provide zero copy (not available with RTnet either, yes, but needed for lowest-latency traffic in the future)? - How to make buffer allocation similarly deterministic as with rtskbs (e.g. an evl_net_dev_alloc_skb that needs no timeout but uses a per-socket pool again)? Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH v2 0/3] y2038: sigtimedwait64
On 10.08.21 17:27, Florian Bezdeka wrote: > Hi! > > Here comes the next y2038 related syscall implementation. Once again > based on v1 sent out by Song. I had to rework the patches a bit, mostly > to stay POSIX compatible (EAGAIN vs. ETIMEOUT) and necessary test > adjustments and improvements. > > Best regards, > Florian > > Florian Bezdeka (1): > y2038: testsuite/smokey/y2038: Adding tests for sigtimedwait64 > > Song Chen (2): > y2038: cobalt/posix/signal: Adding sigtimedwait64 > y2038: lib/cobalt/signal: dispatch sigtimedwait > > include/cobalt/uapi/syscall.h | 1 + > kernel/cobalt/posix/signal.c | 21 ++- > kernel/cobalt/posix/signal.h | 5 ++ > kernel/cobalt/posix/syscall32.c| 21 +++ > kernel/cobalt/posix/syscall32.h| 5 ++ > kernel/cobalt/trace/cobalt-posix.h | 4 +- > lib/cobalt/signal.c| 4 ++ > testsuite/smokey/y2038/syscall-tests.c | 80 ++ > 8 files changed, 137 insertions(+), 4 deletions(-) > Thanks, applied to next. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [xenomai-images][RFC][PATCH] ci: Switch to Google nameserver
On 06.08.21 10:50, Jan Kiszka via Xenomai wrote:
> On 02.08.21 17:43, Jan Kiszka via Xenomai wrote:
>> From: Jan Kiszka
>>
>> This is a temporary hack: Our AWS runners see a lot of DNS errors for
>> deb.debian.org. Let's see if they are less with this server.
>>
>> Signed-off-by: Jan Kiszka
>> ---
>>
>> Seems to work, though only one run passed so far. Go this way for now?
>>
>> ci/gitlab-ci-base.yml | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/ci/gitlab-ci-base.yml b/ci/gitlab-ci-base.yml
>> index 2638dec..ce9c800 100644
>> --- a/ci/gitlab-ci-base.yml
>> +++ b/ci/gitlab-ci-base.yml
>> @@ -39,6 +39,7 @@ default:
>>extends: .add-proxy-config
>>stage: build
>>script:
>> +- sudo sh -c "echo 'nameserver 8.8.8.8' > /etc/resolv.conf"
>> - echo "Building
>> kas.yml:board-${TARGET}.yml${XENOMAI_BUILD_OPTION}${LINUX_BUILD_OPTION}${BUILD_OPTIONS}:opt-debug.yml"
>> - kas build
>> kas.yml:board-${TARGET}.yml${XENOMAI_BUILD_OPTION}${LINUX_BUILD_OPTION}${BUILD_OPTIONS}:opt-debug.yml
>> - if [ -n "${USE_S3_BUCKET}" ]; then scripts/deploy_to_aws.sh
>> ${TARGET}; fi
>>
>
> Seems you found the reason in our AWS setup. I'm dropping this from next
> again to confirm that we are safe.
>
Back and forth: As the issue reoccurred with this removed (only the one
before the image runs was apparently resolved), this is back into next
again. So far, it looks good.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH v5 0/5] y2038: Add mutex_timedlock64() support
On 10.08.21 12:33, Jan Kiszka via Xenomai wrote: > On 10.08.21 12:23, Florian Bezdeka wrote: >> Hi! >> >> This series is based on the series posted by Song some time ago. The >> testing part has been heavily reworked. Details are mentioned in the >> description of the last patch. >> >> @Jan: Patch 1 and 2 are re-sends. They are not directly related to the >> y2038 stuff but the testsuite might fail if they are not applied. >> >> Testing was done on x86 only so far, internal CI is still running but no >> problems expected. >> >> Best regards, >> Florian >> >> Changes in v5: >> - Patch 5: Integrated fixes already made by Jan on next >> - Patch 5: Fix typo >> > > Is this series equivalent with bb64c8c66aeec3b5ead55fcfa9c79efda8064f7f > in next? Or do I have to replace next with it? Or do I only have to > replace bb64c8c66a (patch 5)? > Anyway, just pulled them all and put this as well as the mq series on top of new next. Thanks, Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH v5 0/5] y2038: Add mutex_timedlock64() support
On 10.08.21 12:23, Florian Bezdeka wrote: > Hi! > > This series is based on the series posted by Song some time ago. The > testing part has been heavily reworked. Details are mentioned in the > description of the last patch. > > @Jan: Patch 1 and 2 are re-sends. They are not directly related to the > y2038 stuff but the testsuite might fail if they are not applied. > > Testing was done on x86 only so far, internal CI is still running but no > problems expected. > > Best regards, > Florian > > Changes in v5: > - Patch 5: Integrated fixes already made by Jan on next > - Patch 5: Fix typo > Is this series equivalent with bb64c8c66aeec3b5ead55fcfa9c79efda8064f7f in next? Or do I have to replace next with it? Or do I only have to replace bb64c8c66a (patch 5)? Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
[PATCH] testsuite/smokey: net: Ignore late or lost packets when running in VM
From: Jan Kiszka
Do not fail the test if packets arrive late or are lost due to the
delays a VM, specifically an emulator like QEMU, may bring. Only if all
packets are lost, something is wrong and should be reported.
Signed-off-by: Jan Kiszka
---
This now replaces "testsuite/smokey: net_client: skip late packet error
in vm mode" in next.
testsuite/smokey/net_common/client.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/testsuite/smokey/net_common/client.c
b/testsuite/smokey/net_common/client.c
index d13d72918a..914bda4a49 100644
--- a/testsuite/smokey/net_common/client.c
+++ b/testsuite/smokey/net_common/client.c
@@ -204,6 +204,12 @@ static int smokey_net_client_loop(struct smokey_net_client
*client)
} while (err != -ETIMEDOUT);
}
+ if (smokey_on_vm) {
+ glate = 0; /* ignore late arrivals */
+ if (glost != limit)
+ glost = 0; /* ignore some lost packets, not all */
+ }
+
if (glost || glate)
fprintf(stderr, "RTnet %s test failed", client->name);
if (glost) {
--
2.31.1
[PATCH v2] cobalt/arch/arm: arith: Avoid r7 usage in helpers
From: Jan Kiszka
Since gcc-9, direct usage of r7 is in conflict with compiler
allocations. Skip it.
This pushes mach_arm_nodiv_llimd beyond r10. r11 is reserved as frame
pointer, but r12 should be fine between function calls and long branches
like in this case.
Signed-off-by: Jan Kiszka
---
Changes in v2:
- use r12 instead of r11
.../arch/arm/include/asm/xenomai/uapi/arith.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/kernel/cobalt/arch/arm/include/asm/xenomai/uapi/arith.h
b/kernel/cobalt/arch/arm/include/asm/xenomai/uapi/arith.h
index cf897b44fa..cb7fb4aa15 100644
--- a/kernel/cobalt/arch/arm/include/asm/xenomai/uapi/arith.h
+++ b/kernel/cobalt/arch/arm/include/asm/xenomai/uapi/arith.h
@@ -79,9 +79,9 @@ mach_arm_nodiv_ullimd(const unsigned long long op,
register unsigned frach __asm__ ("r3");
register unsigned integ __asm__("r4") = rhs_integ;
register unsigned opl __asm__ ("r6");
- register unsigned oph __asm__ ("r7");
- register unsigned tl __asm__("r8");
- register unsigned th __asm__("r9");
+ register unsigned oph __asm__ ("r8");
+ register unsigned tl __asm__("r9");
+ register unsigned th __asm__("r10");
xnarch_u64tou32(op, oph, opl);
xnarch_u64tou32(frac, frach, fracl);
@@ -109,10 +109,10 @@ mach_arm_nodiv_llimd(const long long op,
register unsigned frach __asm__ ("r3");
register unsigned integ __asm__("r4") = rhs_integ;
register unsigned opl __asm__ ("r6");
- register unsigned oph __asm__ ("r7");
- register unsigned tl __asm__("r8");
- register unsigned th __asm__("r9");
- register unsigned s __asm__("r10");
+ register unsigned oph __asm__ ("r8");
+ register unsigned tl __asm__("r9");
+ register unsigned th __asm__("r10");
+ register unsigned s __asm__("r12");
xnarch_u64tou32(op, oph, opl);
xnarch_u64tou32(frac, frach, fracl);
--
2.31.1
Re: [PATCH] cobalt/arch/arm: arith: Avoid r7 usage in helpers
On 09.08.21 17:11, Jan Kiszka via Xenomai wrote:
> On 09.08.21 17:09, Philippe Gerum wrote:
>>
>> Jan Kiszka writes:
>>
>>> On 07.08.21 17:52, Jan Kiszka via Xenomai wrote:
>>>> From: Jan Kiszka
>>>>
>>>> Since gcc-9, direct usage of r7 is in conflict with compiler
>>>> allocations. Skip it.
>>>>
>>>> Signed-off-by: Jan Kiszka
>>>> ---
>>>> .../arch/arm/include/asm/xenomai/uapi/arith.h | 14 +++---
>>>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/kernel/cobalt/arch/arm/include/asm/xenomai/uapi/arith.h
>>>> b/kernel/cobalt/arch/arm/include/asm/xenomai/uapi/arith.h
>>>> index cf897b44fa..4d3ae65411 100644
>>>> --- a/kernel/cobalt/arch/arm/include/asm/xenomai/uapi/arith.h
>>>> +++ b/kernel/cobalt/arch/arm/include/asm/xenomai/uapi/arith.h
>>>> @@ -79,9 +79,9 @@ mach_arm_nodiv_ullimd(const unsigned long long op,
>>>>register unsigned frach __asm__ ("r3");
>>>>register unsigned integ __asm__("r4") = rhs_integ;
>>>>register unsigned opl __asm__ ("r6");
>>>> - register unsigned oph __asm__ ("r7");
>>>> - register unsigned tl __asm__("r8");
>>>> - register unsigned th __asm__("r9");
>>>> + register unsigned oph __asm__ ("r8");
>>>> + register unsigned tl __asm__("r9");
>>>> + register unsigned th __asm__("r10");
>>>>
>>>>xnarch_u64tou32(op, oph, opl);
>>>>xnarch_u64tou32(frac, frach, fracl);
>>>> @@ -109,10 +109,10 @@ mach_arm_nodiv_llimd(const long long op,
>>>>register unsigned frach __asm__ ("r3");
>>>>register unsigned integ __asm__("r4") = rhs_integ;
>>>>register unsigned opl __asm__ ("r6");
>>>> - register unsigned oph __asm__ ("r7");
>>>> - register unsigned tl __asm__("r8");
>>>> - register unsigned th __asm__("r9");
>>>> - register unsigned s __asm__("r10");
>>>> + register unsigned oph __asm__ ("r8");
>>>> + register unsigned tl __asm__("r9");
>>>> + register unsigned th __asm__("r10");
>>>> + register unsigned s __asm__("r11");
>>>
>>> Florian just pointed out that r11 is the frame pointer. Not many options
>>> remaining - ideas?
>>
>> Try r12(ip) adding it to the clobber list.
>>
>
> Yeah, just had the same idea while browsing the ABI...
>
...but clobbering doesn't work and should not be needed - s is already
specified as output.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH] cobalt/arch/arm: arith: Avoid r7 usage in helpers
On 09.08.21 17:09, Philippe Gerum wrote:
>
> Jan Kiszka writes:
>
>> On 07.08.21 17:52, Jan Kiszka via Xenomai wrote:
>>> From: Jan Kiszka
>>>
>>> Since gcc-9, direct usage of r7 is in conflict with compiler
>>> allocations. Skip it.
>>>
>>> Signed-off-by: Jan Kiszka
>>> ---
>>> .../arch/arm/include/asm/xenomai/uapi/arith.h | 14 +++---
>>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/kernel/cobalt/arch/arm/include/asm/xenomai/uapi/arith.h
>>> b/kernel/cobalt/arch/arm/include/asm/xenomai/uapi/arith.h
>>> index cf897b44fa..4d3ae65411 100644
>>> --- a/kernel/cobalt/arch/arm/include/asm/xenomai/uapi/arith.h
>>> +++ b/kernel/cobalt/arch/arm/include/asm/xenomai/uapi/arith.h
>>> @@ -79,9 +79,9 @@ mach_arm_nodiv_ullimd(const unsigned long long op,
>>> register unsigned frach __asm__ ("r3");
>>> register unsigned integ __asm__("r4") = rhs_integ;
>>> register unsigned opl __asm__ ("r6");
>>> - register unsigned oph __asm__ ("r7");
>>> - register unsigned tl __asm__("r8");
>>> - register unsigned th __asm__("r9");
>>> + register unsigned oph __asm__ ("r8");
>>> + register unsigned tl __asm__("r9");
>>> + register unsigned th __asm__("r10");
>>>
>>> xnarch_u64tou32(op, oph, opl);
>>> xnarch_u64tou32(frac, frach, fracl);
>>> @@ -109,10 +109,10 @@ mach_arm_nodiv_llimd(const long long op,
>>> register unsigned frach __asm__ ("r3");
>>> register unsigned integ __asm__("r4") = rhs_integ;
>>> register unsigned opl __asm__ ("r6");
>>> - register unsigned oph __asm__ ("r7");
>>> - register unsigned tl __asm__("r8");
>>> - register unsigned th __asm__("r9");
>>> - register unsigned s __asm__("r10");
>>> + register unsigned oph __asm__ ("r8");
>>> + register unsigned tl __asm__("r9");
>>> + register unsigned th __asm__("r10");
>>> + register unsigned s __asm__("r11");
>>
>> Florian just pointed out that r11 is the frame pointer. Not many options
>> remaining - ideas?
>
> Try r12(ip) adding it to the clobber list.
>
Yeah, just had the same idea while browsing the ABI...
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH] cobalt/arch/arm: arith: Avoid r7 usage in helpers
On 07.08.21 17:52, Jan Kiszka via Xenomai wrote:
> From: Jan Kiszka
>
> Since gcc-9, direct usage of r7 is in conflict with compiler
> allocations. Skip it.
>
> Signed-off-by: Jan Kiszka
> ---
> .../arch/arm/include/asm/xenomai/uapi/arith.h | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/cobalt/arch/arm/include/asm/xenomai/uapi/arith.h
> b/kernel/cobalt/arch/arm/include/asm/xenomai/uapi/arith.h
> index cf897b44fa..4d3ae65411 100644
> --- a/kernel/cobalt/arch/arm/include/asm/xenomai/uapi/arith.h
> +++ b/kernel/cobalt/arch/arm/include/asm/xenomai/uapi/arith.h
> @@ -79,9 +79,9 @@ mach_arm_nodiv_ullimd(const unsigned long long op,
> register unsigned frach __asm__ ("r3");
> register unsigned integ __asm__("r4") = rhs_integ;
> register unsigned opl __asm__ ("r6");
> - register unsigned oph __asm__ ("r7");
> - register unsigned tl __asm__("r8");
> - register unsigned th __asm__("r9");
> + register unsigned oph __asm__ ("r8");
> + register unsigned tl __asm__("r9");
> + register unsigned th __asm__("r10");
>
> xnarch_u64tou32(op, oph, opl);
> xnarch_u64tou32(frac, frach, fracl);
> @@ -109,10 +109,10 @@ mach_arm_nodiv_llimd(const long long op,
> register unsigned frach __asm__ ("r3");
> register unsigned integ __asm__("r4") = rhs_integ;
> register unsigned opl __asm__ ("r6");
> - register unsigned oph __asm__ ("r7");
> - register unsigned tl __asm__("r8");
> - register unsigned th __asm__("r9");
> - register unsigned s __asm__("r10");
> + register unsigned oph __asm__ ("r8");
> + register unsigned tl __asm__("r9");
> + register unsigned th __asm__("r10");
> + register unsigned s __asm__("r11");
Florian just pointed out that r11 is the frame pointer. Not many options
remaining - ideas?
Jan
>
> xnarch_u64tou32(op, oph, opl);
> xnarch_u64tou32(frac, frach, fracl);
>
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: Arm userland not building with gcc-9 and later
On 06.08.21 15:00, Jan Kiszka via Xenomai wrote: > Hi all, > > just wanted to debug the RTnet issues we now see in CI on arm and arm64. > I picked arm as first target, but that apparently starts to break with > gcc-9 or newer (tried 9.2 and 10.2): > > make[5]: Entering directory '/xenomai/lib/cobalt/arch/arm' > CC libarch_la-features.lo > features.c: In function 'cobalt_arch_check_features': > features.c:82:1: error: r7 cannot be used in 'asm' here >82 | } > | ^ > > That seems to be related to passing the syscall number via r7 on ARM. Is > our ABI soon no longer compilable, or can we fix this? > > Jan > Correction: The issue is likely older. I've just checked buster's gcc-8, and it shows the very same behavior. Will update the commit messages if we stick with my solutions. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
[PATCH] lib/cobalt: arm64: Rework syscall wrappers
From: Jan Kiszka
Converting them into inline functions helps to avoid clobbering of w8.
Without this, the compiler may squeeze function calls between the setup
of __scno in w8 and the actually submission of the syscall. Seen with
the smokey y2038 testcase.
Signed-off-by: Jan Kiszka
---
Close to an out-of-line version, possibly even better.
I'm not sure, though, if that pattern buys us anything on 32-bit arm.
Problem there remains the usage conflict of r7 which static inline may
not resolve.
.../arch/arm64/include/asm/xenomai/syscall.h | 115 ++
1 file changed, 61 insertions(+), 54 deletions(-)
diff --git a/lib/cobalt/arch/arm64/include/asm/xenomai/syscall.h
b/lib/cobalt/arch/arm64/include/asm/xenomai/syscall.h
index d2dfda6846..d896977125 100644
--- a/lib/cobalt/arch/arm64/include/asm/xenomai/syscall.h
+++ b/lib/cobalt/arch/arm64/include/asm/xenomai/syscall.h
@@ -1,5 +1,6 @@
/*
* Copyright (C) 2015 Philippe Gerum .
+ * Copyright (C) Siemens AG, 2021
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
@@ -22,76 +23,82 @@
#include
#include
-#define __emit_asmdecl0
\
- register unsigned int __scno __asm__ ("w8"); \
- register unsigned long __res __asm__ ("x0")
-#define __emit_asmdecl1
\
- __emit_asmdecl0; register unsigned long __x0 __asm__ ("x0")
-#define __emit_asmdecl2
\
- __emit_asmdecl1; register unsigned long __x1 __asm__ ("x1")
-#define __emit_asmdecl3
\
- __emit_asmdecl2; register unsigned long __x2 __asm__ ("x2")
-#define __emit_asmdecl4
\
- __emit_asmdecl3; register unsigned long __x3 __asm__ ("x3")
-#define __emit_asmdecl5
\
- __emit_asmdecl4; register unsigned long __x4 __asm__ ("x4")
-
-#define __load_asminput0(__op) \
- __scno = (unsigned int)__xn_syscode(__op)
-#define __load_asminput1(__op, __a1) \
- __load_asminput0(__op); \
- __x0 = (unsigned long)(__a1)
-#define __load_asminput2(__op, __a1, __a2) \
- __load_asminput1(__op, __a1); \
- __x1 = (unsigned long)(__a2)
-#define __load_asminput3(__op, __a1, __a2, __a3) \
- __load_asminput2(__op, __a1, __a2); \
- __x2 = (unsigned long)(__a3)
-#define __load_asminput4(__op, __a1, __a2, __a3, __a4) \
- __load_asminput3(__op, __a1, __a2, __a3); \
- __x3 = (unsigned long)(__a4)
-#define __load_asminput5(__op, __a1, __a2, __a3, __a4, __a5) \
- __load_asminput4(__op, __a1, __a2, __a3, __a4); \
- __x4 = (unsigned long)(__a5)
+#define __xn_syscall_args0
+#define __xn_syscall_args1 , unsigned long __a1
+#define __xn_syscall_args2 __xn_syscall_args1, unsigned long __a2
+#define __xn_syscall_args3 __xn_syscall_args2, unsigned long __a3
+#define __xn_syscall_args4 __xn_syscall_args3, unsigned long __a4
+#define __xn_syscall_args5 __xn_syscall_args4, unsigned long __a5
#define __emit_syscall0(__args...) \
+ register unsigned int __scno __asm__("w8") = __xn_syscode(__op); \
+ register unsigned long __res __asm__("x0"); \
__asm__ __volatile__ ( \
"svc 0;\n\t"\
: "=r" (__res) \
: "r" (__scno), ##__args\
: "cc", "memory"); \
- __res
-#define __emit_syscall1(__a1, __args...) \
+ return __res
+#define __emit_syscall1(__args...) \
+ register unsigned long __x0 __asm__("x0") = __a1; \
__emit_syscall0("r" (__x0), ##__args)
-#define __emit_syscall2(__a1, __a2, __args...) \
- __emit_syscall1(__a1, "r" (__x1), ##__args)
-#define __emit_syscall3(__a1, __a2, __a3, __args...) \
- __emit_syscall2(__a1, __a2, "r" (__x2), ##__args)
-#define __emit_syscall4(__a1, __a2, __a3, __a4, __args...) \
- __emit_syscall3(__a1, __a2, __a3, "r" (__x3), ##__args)
-#define __emit_syscall5(__a1, __a2, __a3, __a4, __a5, __args...) \
- __emit_syscall4(__a1, __a2, __a3, __a4, "r" (__x4), ##__args)
+#define
Re: arm64: More syscall corruptions
On 09.08.21 10:01, Philippe Gerum wrote: > > Philippe Gerum writes: > >> Jan Kiszka writes: >> >>> Hi all, >>> >>> the failing y2038 testcase we see in CI [1] is caused by another problem >>> of our syscall wrappers, this time on arm64: >>> >>> /* Timeout is never read by the kernel, so NULL should be OK */ >>> ret = XENOMAI_SYSCALL5(sc_nr, mq, msg, strlen(msg), 0, NULL); >>> 235c: b940dfe0ldr w0, [sp, #220] >>> 2360: 3204orr w0, w0, #0x1000 >>> 2364: 2a0003e8mov w8, w0 >>> --> w8 holds the syscall number >>> 2368: b980d3e0ldrsw x0, [sp, #208] >>> 236c: 910043e0add x0, sp, #0x10 >>> 2370: aa0003e1mov x1, x0 >>> 2374: 910043e0add x0, sp, #0x10 >>> 2378: 9400bl 0 >>> 2378: R_AARCH64_CALL26 strlen >>> --> w8 is clobbered >>> 237c: aa0003e2mov x2, x0 >>> 2380: d283mov x3, #0x0// >>> #0 >>> 2384: d284mov x4, #0x0// >>> #0 >>> 2388: d401svc #0x0 >>> >>> The problem is that w8/r8 is the "Indirect result location register", >>> thus can be overwritten when calling a function - and that's what strlen >>> does. >>> >>> What are we missing in our syscall black magic to prevent this? Or this >>> this the final call to move the wrapper into am out-of-line function? >>> >> >> The same way ARM syscalls are passed in r7 (EABI) which might >> unfortunately be used and clobbered by gcc as a temp register, x8 >> carries the syscall number per the aarch64 ABI used by the kernel, and >> it looks like we now have the very same issue than we just had with ARM. >> >> I believe the syscall wrappers should move to their own out-of-line >> routine (libevl just does that, the impact on performance is not >> observable, and we are immune to that kind of issue). > > This said, it looks like w8 is not in the clobber list of these macros, > so adding it might fix the issue at hand since the compiler does not > otherwise complain about using it (unlike in the 32bit case). > You mean the CLOBBER_REGS thing that arm does, but not arm64? Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
arm64: More syscall corruptions
Hi all, the failing y2038 testcase we see in CI [1] is caused by another problem of our syscall wrappers, this time on arm64: /* Timeout is never read by the kernel, so NULL should be OK */ ret = XENOMAI_SYSCALL5(sc_nr, mq, msg, strlen(msg), 0, NULL); 235c: b940dfe0ldr w0, [sp, #220] 2360: 3204orr w0, w0, #0x1000 2364: 2a0003e8mov w8, w0 --> w8 holds the syscall number 2368: b980d3e0ldrsw x0, [sp, #208] 236c: 910043e0add x0, sp, #0x10 2370: aa0003e1mov x1, x0 2374: 910043e0add x0, sp, #0x10 2378: 9400bl 0 2378: R_AARCH64_CALL26 strlen --> w8 is clobbered 237c: aa0003e2mov x2, x0 2380: d283mov x3, #0x0// #0 2384: d284mov x4, #0x0// #0 2388: d401svc #0x0 The problem is that w8/r8 is the "Indirect result location register", thus can be overwritten when calling a function - and that's what strlen does. What are we missing in our syscall black magic to prevent this? Or this this the final call to move the wrapper into am out-of-line function? Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
[PATCH] testsuite/smokey: y2038: Fix evaluation of pthread_join result
From: Jan Kiszka The status value is the pointer, not where the pointer points to. Signed-off-by: Jan Kiszka --- Not yet resolving the unexpected assertion, though. testsuite/smokey/y2038/syscall-tests.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/testsuite/smokey/y2038/syscall-tests.c b/testsuite/smokey/y2038/syscall-tests.c index 90bfe28d48..afbe8d42a6 100644 --- a/testsuite/smokey/y2038/syscall-tests.c +++ b/testsuite/smokey/y2038/syscall-tests.c @@ -150,7 +150,7 @@ static int run_thread(void *(*thread)(void *), void *arg, int exp_result) if (!__T(ret, pthread_join(tid, ))) return ret; - res = *((long *) status); + res = (long)status; return (res == exp_result) ? 0 : ret; } -- 2.31.1
[xenomai-images][PATCH] customizations: Fix runtime dependencies
From: Jan Kiszka
We modify sshd_config, so we need the server to be installed already.
passwd is no longer needed, though.
Signed-off-by: Jan Kiszka
---
recipes-core/customizations/customizations.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/recipes-core/customizations/customizations.bb
b/recipes-core/customizations/customizations.bb
index e35c0a5..0faaff8 100644
--- a/recipes-core/customizations/customizations.bb
+++ b/recipes-core/customizations/customizations.bb
@@ -1,7 +1,7 @@
#
# Xenomai Real-Time System
#
-# Copyright (c) Siemens AG, 2018
+# Copyright (c) Siemens AG, 2018-2021
#
# Authors:
# Jan Kiszka
@@ -18,7 +18,7 @@ SRC_URI = " \
file://ethernet \
file://99-silent-printk.conf"
-DEBIAN_DEPENDS = "passwd"
+DEBIAN_DEPENDS = "openssh-server"
do_install() {
install -v -d ${D}/etc/network/interfaces.d
--
2.31.1
Re: Arm userland not building with gcc-9 and later
On 08.08.21 19:21, Philippe Gerum wrote: > > Jan Kiszka writes: > >> On 07.08.21 19:00, Philippe Gerum wrote: >>> >>> Jan Kiszka writes: >>> Hi all, just wanted to debug the RTnet issues we now see in CI on arm and arm64. I picked arm as first target, but that apparently starts to break with gcc-9 or newer (tried 9.2 and 10.2): make[5]: Entering directory '/xenomai/lib/cobalt/arch/arm' CC libarch_la-features.lo features.c: In function 'cobalt_arch_check_features': features.c:82:1: error: r7 cannot be used in 'asm' here 82 | } | ^ That seems to be related to passing the syscall number via r7 on ARM. Is our ABI soon no longer compilable, or can we fix this? >>> >>> Just tried to reproduce this issue with the latest stable (10.3-2021.07) >>> from ARM [1], and a fairly recent linaro snapshot (11.0.1-2021.03) [2], >>> to no avail. I tried with --enable-debug=symbols, --disable-debug, >>> --enable-debug=full, no issue so far. >>> >>> Can you please share you configure settings? >> >> I'm on ARM gcc 10.3-2021.07 as well. Debian's gcc from bullseye show >> this, too. >> >> ./configure --host=arm-none-linux-gnueabihf --enable-debug=full >> >> on master. And that results in >> >> CC libarch_la-features.lo >> ../../../../../lib/cobalt/arch/arm/features.c: In function >> ‘cobalt_arch_check_features’: >> ../../../../../lib/cobalt/arch/arm/features.c:82:1: error: r7 cannot be used >> in ‘asm’ here >>82 | } >> | ^ >> > > Confirmed, found it. next is fine with this compiler, which is the > version I tested. However, building stable and master does break. > Yeah, I've already pushed the two related fixes into next for testing. Can still be changed if we find a better solution. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
[PATCH 2/2] drivers/net: udp, packet: Respect msg_namelen when filling msg_name
From: Jan Kiszka
We must not write more than what was allocated and reported via
msg_namelen by userspace. We may truncate, though, then reporting what
would have been written if there had been enough space.
Signed-off-by: Jan Kiszka
---
kernel/drivers/net/stack/ipv4/udp/udp.c | 12 +---
kernel/drivers/net/stack/packet/af_packet.c | 11 ---
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/kernel/drivers/net/stack/ipv4/udp/udp.c
b/kernel/drivers/net/stack/ipv4/udp/udp.c
index bceb6b5132..db7a902c35 100644
--- a/kernel/drivers/net/stack/ipv4/udp/udp.c
+++ b/kernel/drivers/net/stack/ipv4/udp/udp.c
@@ -441,12 +441,18 @@ ssize_t rt_udp_recvmsg(struct rtdm_fd *fd, struct
user_msghdr *msg,
sin.sin_family = AF_INET;
sin.sin_port = uh->source;
sin.sin_addr.s_addr = skb->nh.iph->saddr;
- ret = rtnet_put_arg(fd, msg->msg_name, , sizeof(sin));
+
+ if (msg->msg_namelen < 0) {
+ ret = -EINVAL;
+ goto fail;
+ }
+ namelen = min(sizeof(sin), (size_t)msg->msg_namelen);
+
+ ret = rtnet_put_arg(fd, msg->msg_name, , namelen);
if (ret)
goto fail;
- namelen = sizeof(sin);
- msg->msg_namelen = namelen;
+ msg->msg_namelen = sizeof(sin);
}
data_len = ntohs(uh->len) - sizeof(struct udphdr);
diff --git a/kernel/drivers/net/stack/packet/af_packet.c
b/kernel/drivers/net/stack/packet/af_packet.c
index 0d5ecd6a7d..b55235ec19 100644
--- a/kernel/drivers/net/stack/packet/af_packet.c
+++ b/kernel/drivers/net/stack/packet/af_packet.c
@@ -347,15 +347,20 @@ static ssize_t rt_packet_recvmsg(struct rtdm_fd *fd,
struct user_msghdr *msg,
sll.sll_pkttype = rtskb->pkt_type;
sll.sll_ifindex = rtdev->ifindex;
+ if (msg->msg_namelen < 0) {
+ ret = -EINVAL;
+ goto fail;
+ }
+ namelen = min(sizeof(sll), (size_t)msg->msg_namelen);
+
/* Ethernet specific - we rather need some parse handler here */
memcpy(sll.sll_addr, rtskb->mac.ethernet->h_source, ETH_ALEN);
sll.sll_halen = ETH_ALEN;
- ret = rtnet_put_arg(fd, msg->msg_name, , sizeof(sll));
+ ret = rtnet_put_arg(fd, msg->msg_name, , namelen);
if (ret)
goto fail;
- namelen = sizeof(sll);
- msg->msg_namelen = namelen;
+ msg->msg_namelen = sizeof(sll);
}
/* Include the header in raw delivery */
--
2.31.1
[PATCH 1/2] drivers/net: udp, packet: Fix returning of msg_namelen and msg_flags from recvmsg
From: Jan Kiszka
The msg struct passed to the recvmsg handler for udp and packet sockets
is not located in userspace. Therefore, we must not use rtnet_put_arg to
update its content, it may fail on some archs, namely arm and arm64.
Just assign, the syscall entry function will take care of copying it
back.
Fixes: 25a53f5cd352 ("rtnet: udp: Remove duplicate copy_from/to_user")
Signed-off-by: Jan Kiszka
---
kernel/drivers/net/stack/ipv4/udp/udp.c | 12 ++--
kernel/drivers/net/stack/packet/af_packet.c | 13 +++--
2 files changed, 5 insertions(+), 20 deletions(-)
diff --git a/kernel/drivers/net/stack/ipv4/udp/udp.c
b/kernel/drivers/net/stack/ipv4/udp/udp.c
index 6fe1aeb12e..bceb6b5132 100644
--- a/kernel/drivers/net/stack/ipv4/udp/udp.c
+++ b/kernel/drivers/net/stack/ipv4/udp/udp.c
@@ -446,10 +446,7 @@ ssize_t rt_udp_recvmsg(struct rtdm_fd *fd, struct
user_msghdr *msg,
goto fail;
namelen = sizeof(sin);
- ret = rtnet_put_arg(fd, >msg_namelen, ,
- sizeof(namelen));
- if (ret)
- goto fail;
+ msg->msg_namelen = namelen;
}
data_len = ntohs(uh->len) - sizeof(struct udphdr);
@@ -489,12 +486,7 @@ ssize_t rt_udp_recvmsg(struct rtdm_fd *fd, struct
user_msghdr *msg,
if (data_len > 0)
flags |= MSG_TRUNC;
- if (flags != msg->msg_flags) {
- ret = rtnet_put_arg(fd, >msg_flags, ,
- sizeof(flags));
- if (ret)
- goto fail;
- }
+ msg->msg_flags = flags;
out:
if ((msg_flags & MSG_PEEK) == 0)
kfree_rtskb(first_skb);
diff --git a/kernel/drivers/net/stack/packet/af_packet.c
b/kernel/drivers/net/stack/packet/af_packet.c
index 8a8072c640..0d5ecd6a7d 100644
--- a/kernel/drivers/net/stack/packet/af_packet.c
+++ b/kernel/drivers/net/stack/packet/af_packet.c
@@ -302,7 +302,7 @@ static ssize_t rt_packet_recvmsg(struct rtdm_fd *fd, struct
user_msghdr *msg,
size_t copy_len;
struct rtskb *rtskb;
struct sockaddr_ll sll;
- int ret, flags;
+ int ret;
nanosecs_rel_t timeout = sock->timeout;
socklen_t namelen;
struct iovec iov_fast[RTDM_IOV_FASTMAX], *iov;
@@ -355,10 +355,7 @@ static ssize_t rt_packet_recvmsg(struct rtdm_fd *fd,
struct user_msghdr *msg,
goto fail;
namelen = sizeof(sll);
- ret = rtnet_put_arg(fd, >msg_namelen, ,
- sizeof(namelen));
- if (ret)
- goto fail;
+ msg->msg_namelen = namelen;
}
/* Include the header in raw delivery */
@@ -375,11 +372,7 @@ static ssize_t rt_packet_recvmsg(struct rtdm_fd *fd,
struct user_msghdr *msg,
if (copy_len > len) {
copy_len = len;
- flags = msg->msg_flags | MSG_TRUNC;
- ret = rtnet_put_arg(fd, >msg_flags, ,
- sizeof(flags));
- if (ret)
- goto fail;
+ msg->msg_flags |= MSG_TRUNC;
}
copy_len = rtnet_write_to_iov(fd, iov, msg->msg_iovlen, rtskb->data,
--
2.31.1
Re: [PATCH v3] cobalt: Sort out virtual vs. real pids
On 02.08.21 18:56, Jan Kiszka via Xenomai wrote:
> From: Jan Kiszka
>
> Make sure that we consider all pids taken from or sent to userspace via
> syscalls as virtual. That means converting them to global pids before
> processing them or converting them back to virtual pids in the caller's
> namespace before reporting them. We also need to switch thread hashing
> from vpids to real pids.
>
> Not converted is the procfs interface as this one continues to provide
> only a global view on cobalt objects and associated pids.
>
> A few syscall tracepoints that report the vpid as passed down from
> userspace get adjusted in their output so that it is clear that no
> global pid is shown.
>
> Signed-off-by: Jan Kiszka
> ---
>
> Changes in v3:
> - handle process-local thread lookups correctly (hopefully)
>
> This is in next for a while and ran several test cycles. Even if we
> should have remaining issues under pid namespaces, we should not have
> regressions in the normal cases.
>
> include/cobalt/kernel/thread.h | 2 ++
> kernel/cobalt/posix/event.c| 2 +-
> kernel/cobalt/posix/mqueue.c | 2 +-
> kernel/cobalt/posix/process.c | 14 ++
> kernel/cobalt/posix/process.h | 2 ++
> kernel/cobalt/posix/sched.c| 10 ++
> kernel/cobalt/posix/sem.c | 2 +-
> kernel/cobalt/posix/signal.c | 10 ++
> kernel/cobalt/posix/thread.c | 18 ++
> kernel/cobalt/posix/thread.h | 2 +-
> kernel/cobalt/thread.c | 10 ++
> kernel/cobalt/trace/cobalt-posix.h | 4 ++--
> 12 files changed, 56 insertions(+), 22 deletions(-)
>
> diff --git a/include/cobalt/kernel/thread.h b/include/cobalt/kernel/thread.h
> index b79cb84296..4c8a0b9f2a 100644
> --- a/include/cobalt/kernel/thread.h
> +++ b/include/cobalt/kernel/thread.h
> @@ -450,6 +450,8 @@ char *xnthread_format_status(unsigned long status,
>
> pid_t xnthread_host_pid(struct xnthread *thread);
>
> +pid_t xnthread_host_vpid(struct xnthread *thread);
> +
> int xnthread_set_clock(struct xnthread *thread,
> struct xnclock *newclock);
>
> diff --git a/kernel/cobalt/posix/event.c b/kernel/cobalt/posix/event.c
> index 3712154f53..5871106301 100644
> --- a/kernel/cobalt/posix/event.c
> +++ b/kernel/cobalt/posix/event.c
> @@ -352,7 +352,7 @@ COBALT_SYSCALL(event_inquire, current,
> xnsynch_for_each_sleeper(thread, >synch) {
> if (nrwait >= nrpids)
> break;
> - t[nrwait++] = xnthread_host_pid(thread);
> + t[nrwait++] = xnthread_host_vpid(thread);
> }
> }
>
> diff --git a/kernel/cobalt/posix/mqueue.c b/kernel/cobalt/posix/mqueue.c
> index dd8acd55b0..fcde87a077 100644
> --- a/kernel/cobalt/posix/mqueue.c
> +++ b/kernel/cobalt/posix/mqueue.c
> @@ -720,7 +720,7 @@ mq_notify(struct cobalt_mqd *mqd, unsigned index, const
> struct sigevent *evp)
>* receiver's namespaces. We pass the receiver's creds
>* into the init namespace instead.
>*/
> - mq->si.si_pid = task_pid_nr(current);
> + mq->si.si_pid = task_pid_vnr(current);
> mq->si.si_uid = get_current_uuid();
> }
>
> diff --git a/kernel/cobalt/posix/process.c b/kernel/cobalt/posix/process.c
> index 1f059ad830..98b7df33fb 100644
> --- a/kernel/cobalt/posix/process.c
> +++ b/kernel/cobalt/posix/process.c
> @@ -975,6 +975,20 @@ int cobalt_handle_cleanup_event(struct mm_struct *mm)
> return KEVENT_PROPAGATE;
> }
>
> +pid_t cobalt_vpid2pid_nr(pid_t vpid)
> +{
> + struct pid *pid;
> + pid_t nr = -1;
> +
> + rcu_read_lock();
This is not a good idea, at least for I-pipe which is not RCU-compatible
(Dovetail just gained that).
I think we need to rest this approach for now, either under I-pipe
gained support for RCU read-side access or we switched to Dovetail
completely. Pulling it from next.
Jan
> + pid = find_vpid(vpid);
> + if (pid)
> + nr = pid_nr(pid);
> + rcu_read_unlock();
> +
> + return nr;
> +}
> +
> static int attach_process(struct cobalt_process *process)
> {
> struct cobalt_ppd *p = >sys_ppd;
> diff --git a/kernel/cobalt/posix/process.h b/kernel/cobalt/posix/process.h
> index 279707a680..46dff43b7a 100644
> --- a/kernel/cobalt/posix/process.h
> +++ b/kernel/cobalt/posix/process.h
> @@ -175,4 +175,6 @@ int cobalt_handle_cleanup_event(struct mm_struct *mm);
>
> int cobalt_handle_user_return(struct task_struct *task);
>
> +pid_t cobalt_vpid2pid_nr(
Re: Arm userland not building with gcc-9 and later
On 07.08.21 19:00, Philippe Gerum wrote: > > Jan Kiszka writes: > >> Hi all, >> >> just wanted to debug the RTnet issues we now see in CI on arm and arm64. >> I picked arm as first target, but that apparently starts to break with >> gcc-9 or newer (tried 9.2 and 10.2): >> >> make[5]: Entering directory '/xenomai/lib/cobalt/arch/arm' >> CC libarch_la-features.lo >> features.c: In function 'cobalt_arch_check_features': >> features.c:82:1: error: r7 cannot be used in 'asm' here >>82 | } >> | ^ >> >> That seems to be related to passing the syscall number via r7 on ARM. Is >> our ABI soon no longer compilable, or can we fix this? >> > > Just tried to reproduce this issue with the latest stable (10.3-2021.07) > from ARM [1], and a fairly recent linaro snapshot (11.0.1-2021.03) [2], > to no avail. I tried with --enable-debug=symbols, --disable-debug, > --enable-debug=full, no issue so far. > > Can you please share you configure settings? I'm on ARM gcc 10.3-2021.07 as well. Debian's gcc from bullseye show this, too. ./configure --host=arm-none-linux-gnueabihf --enable-debug=full on master. And that results in CC libarch_la-features.lo ../../../../../lib/cobalt/arch/arm/features.c: In function ‘cobalt_arch_check_features’: ../../../../../lib/cobalt/arch/arm/features.c:82:1: error: r7 cannot be used in ‘asm’ here 82 | } | ^ Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
[PATCH] cobalt/arch/arm: arith: Avoid r7 usage in helpers
From: Jan Kiszka
Since gcc-9, direct usage of r7 is in conflict with compiler
allocations. Skip it.
Signed-off-by: Jan Kiszka
---
.../arch/arm/include/asm/xenomai/uapi/arith.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/kernel/cobalt/arch/arm/include/asm/xenomai/uapi/arith.h
b/kernel/cobalt/arch/arm/include/asm/xenomai/uapi/arith.h
index cf897b44fa..4d3ae65411 100644
--- a/kernel/cobalt/arch/arm/include/asm/xenomai/uapi/arith.h
+++ b/kernel/cobalt/arch/arm/include/asm/xenomai/uapi/arith.h
@@ -79,9 +79,9 @@ mach_arm_nodiv_ullimd(const unsigned long long op,
register unsigned frach __asm__ ("r3");
register unsigned integ __asm__("r4") = rhs_integ;
register unsigned opl __asm__ ("r6");
- register unsigned oph __asm__ ("r7");
- register unsigned tl __asm__("r8");
- register unsigned th __asm__("r9");
+ register unsigned oph __asm__ ("r8");
+ register unsigned tl __asm__("r9");
+ register unsigned th __asm__("r10");
xnarch_u64tou32(op, oph, opl);
xnarch_u64tou32(frac, frach, fracl);
@@ -109,10 +109,10 @@ mach_arm_nodiv_llimd(const long long op,
register unsigned frach __asm__ ("r3");
register unsigned integ __asm__("r4") = rhs_integ;
register unsigned opl __asm__ ("r6");
- register unsigned oph __asm__ ("r7");
- register unsigned tl __asm__("r8");
- register unsigned th __asm__("r9");
- register unsigned s __asm__("r10");
+ register unsigned oph __asm__ ("r8");
+ register unsigned tl __asm__("r9");
+ register unsigned th __asm__("r10");
+ register unsigned s __asm__("r11");
xnarch_u64tou32(op, oph, opl);
xnarch_u64tou32(frac, frach, fracl);
--
2.31.1
Re: cannot link 32 bit app
On 07.08.21 09:43, C Smith via Xenomai wrote: > I can compile but not link my xenomai app. I get: > /usr/bin/ld: skipping incompatible /usr/xenomai/lib/libtrank.so when > searching for -ltrank > /usr/bin/ld: skipping incompatible /usr/xenomai/lib/libcobalt.so when > searching for -lcobalt > etc. > > I am testing xenomai 3.1 with x86-64 bit kernel 4.19.89 (I am porting my > xenomai 2.6 codebase to xeno 3.1). I have compiled the kernel OK with 32 > bit emulation support (CONFIG_IA32_EMULATION=y), as I must run my very > large legacy xenomai 2.6 codebase as 32 bit. The xenomai testsuite > latency, clocktest, switchtest apps run fine, BTW. > > Is the problem that the xenomai libs like cobalt are 64 bit only? Did I > omit some xenomai configure option to support 32 bit xenomai apps ? > > Here is an example of the kind of gcc command line my Makefile puts out: > gcc -g3 -m32 -I/usr/xenomai/include/trank -D__XENO_COMPAT__ > -I/usr/xenomai/include/cobalt -I/usr/xenomai/include -D_GNU_SOURCE > -D_REENTRANT -fasynchronous-unwind-tables -D__COBALT__ > -I/usr/xenomai/include/alchemy -I/usr/include/libxml2 > -I/usr/xenomai/include/rtdm -I"../include/nanopb"-Xlinker -rpath > -Xlinker /usr/xenomai/lib testapp.c ../modules/rtdinsync.h > -Wl,--no-as-needed -ltrank -Wl,@/usr/xenomai/lib/modechk.wrappers -lalchemy > -lcopperplate /usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main > -Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -L/usr/xenomai/lib -lcobalt > -lmodechk -lpthread -lrt-lfuse -pthread -Wl,--no-as-needed > -Wl,@/usr/xenomai/lib/cobalt.wrappers > -Wl,@/usr/xenomai/lib/modechk.wrappers > /usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main > -Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -L/usr/xenomai/lib -lcobalt > -lmodechk -lpthread -lrt-lfuse -pthread -Wl,--no-as-needed > -Wl,@/usr/xenomai/lib/cobalt.wrappers > -Wl,@/usr/xenomai/lib/modechk.wrappers > /usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main > -Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -L/usr/xenomai/lib -lcobalt > -lmodechk -lpthread -lrt-lfuse -pthread -lz -llzma -lm -ldl > -Wl,--start-group -loshw -losal -Wl,--end-group -lm -o testapp > Xenomai userland works fine in 32-bit mode on x86, we do the same in production. This is how I configure for 32-bit on my 64-bit machine: /configure --host=i686-linux CFLAGS="-m32 -D_FILE_OFFSET_BITS=64" \ LDFLAGS=-m32 host_alias=i686-linux Then you should be able to build just using the output of "xeno-config --skin=... --cflags --ldflags". That said, things are not nicely tested in upstream yet, see [1]. Jan [1] https://gitlab.com/Xenomai/xenomai-hacker-space/-/issues/21 -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
[PATCH] build: Disable -Wformat-truncation
From: Jan Kiszka This is default-on in Debian 11 and triggers in heapobj_pkg_init_shared or heapobj_bind_session without adding value - we truncate for good reasons. Signed-off-by: Jan Kiszka --- configure.ac | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index bd5fd5ba9a..b6742c4b92 100644 --- a/configure.ac +++ b/configure.ac @@ -692,7 +692,8 @@ fi dnl Internal CFLAGS and LDFLAGS, may be enhanced per-arch below XENO_USER_CFLAGS="$XENO_USER_APP_CFLAGS -pipe -fstrict-aliasing \ -Wall -Wstrict-prototypes -Wmissing-prototypes -Wno-long-long \ --Wno-unused-parameter -Werror -Wformat-security -D__XENO__ -D__IN_XENO__" +-Wno-unused-parameter -Wno-format-truncation -Werror -Wformat-security \ +-D__XENO__ -D__IN_XENO__" if test x$want_fortify = xyes -a x$debug_mode != xfull; then XENO_USER_CFLAGS="$XENO_USER_CFLAGS -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2" fi -- 2.31.1
Re: Arm userland not building with gcc-9 and later
On 06.08.21 18:16, Jan Kiszka wrote:
> On 06.08.21 15:34, Philippe Gerum wrote:
>>
>> Jan Kiszka writes:
>>
>>> On 06.08.21 15:09, Philippe Gerum wrote:
Jan Kiszka writes:
> Hi all,
>
> just wanted to debug the RTnet issues we now see in CI on arm and arm64.
> I picked arm as first target, but that apparently starts to break with
> gcc-9 or newer (tried 9.2 and 10.2):
>
> make[5]: Entering directory '/xenomai/lib/cobalt/arch/arm'
> CC libarch_la-features.lo
> features.c: In function 'cobalt_arch_check_features':
> features.c:82:1: error: r7 cannot be used in 'asm' here
>82 | }
> | ^
>
> That seems to be related to passing the syscall number via r7 on ARM. Is
> our ABI soon no longer compilable, or can we fix this?
>
> Jan
r7 may be used as a scratch register by gcc in some
cases. -fomit-frame-pointer for debug builds may help (i.e. when the
optimizer is switched off).
>>>
>>> Good hint. I had --enable-debug=full set, and it builds without it (and
>>> now reports other issues that Debian's gcc-10 sees).
>>>
>>> But how to resolve this properly?
>>>
>>> Jan
>>
>> XENOMAI_SYSCALL2(sc_cobalt_archcall) in features.c is likely the issue.
>>
>> Either move those bits into some new syscall wrapper which would live in
>> lib/cobalt/internal.c, where there is no register allocation conflict so
>> far. Or discourage gcc from using r7 as a scratch register in
>> arm/features.c entirely? e.g.:
>>
>> diff --git a/lib/cobalt/arch/arm/Makefile.am
>> b/lib/cobalt/arch/arm/Makefile.am
>> index a5095be3d..d5e542ebe 100644
>> --- a/lib/cobalt/arch/arm/Makefile.am
>> +++ b/lib/cobalt/arch/arm/Makefile.am
>> @@ -6,6 +6,7 @@ libarch_la_SOURCES = features.c
>>
>> libarch_la_CPPFLAGS = \
>> @XENO_COBALT_CFLAGS@\
>> +-fomit-frame-pointer\
>> -I$(srcdir)/../.. \
>> -I$(top_srcdir)/include/cobalt \
>> -I$(top_srcdir)/include
>>
>
> -fomit-frame-pointer does not help with -O0. It even keeps the problem
> alive with -O2.
>
> Looks like arm needs a non-unlined helper function for syscalls, to be safe.
>
What might be cheaper, a call-out to a helper or some push/pop around
the syscall like below? But I suspect the helper will do push/pop as well...
#define __SYS_CALLOP "push {r7}; mov %%r7,%[__r7]; swi\t0; pop {r7}"
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: Arm userland not building with gcc-9 and later
On 06.08.21 15:34, Philippe Gerum wrote: > > Jan Kiszka writes: > >> On 06.08.21 15:09, Philippe Gerum wrote: >>> >>> Jan Kiszka writes: >>> Hi all, just wanted to debug the RTnet issues we now see in CI on arm and arm64. I picked arm as first target, but that apparently starts to break with gcc-9 or newer (tried 9.2 and 10.2): make[5]: Entering directory '/xenomai/lib/cobalt/arch/arm' CC libarch_la-features.lo features.c: In function 'cobalt_arch_check_features': features.c:82:1: error: r7 cannot be used in 'asm' here 82 | } | ^ That seems to be related to passing the syscall number via r7 on ARM. Is our ABI soon no longer compilable, or can we fix this? Jan >>> >>> r7 may be used as a scratch register by gcc in some >>> cases. -fomit-frame-pointer for debug builds may help (i.e. when the >>> optimizer is switched off). >>> >> >> Good hint. I had --enable-debug=full set, and it builds without it (and >> now reports other issues that Debian's gcc-10 sees). >> >> But how to resolve this properly? >> >> Jan > > XENOMAI_SYSCALL2(sc_cobalt_archcall) in features.c is likely the issue. > > Either move those bits into some new syscall wrapper which would live in > lib/cobalt/internal.c, where there is no register allocation conflict so > far. Or discourage gcc from using r7 as a scratch register in > arm/features.c entirely? e.g.: > > diff --git a/lib/cobalt/arch/arm/Makefile.am b/lib/cobalt/arch/arm/Makefile.am > index a5095be3d..d5e542ebe 100644 > --- a/lib/cobalt/arch/arm/Makefile.am > +++ b/lib/cobalt/arch/arm/Makefile.am > @@ -6,6 +6,7 @@ libarch_la_SOURCES = features.c > > libarch_la_CPPFLAGS =\ > @XENO_COBALT_CFLAGS@\ > + -fomit-frame-pointer\ > -I$(srcdir)/../.. \ > -I$(top_srcdir)/include/cobalt \ > -I$(top_srcdir)/include > -fomit-frame-pointer does not help with -O0. It even keeps the problem alive with -O2. Looks like arm needs a non-unlined helper function for syscalls, to be safe. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: Arm userland not building with gcc-9 and later
On 06.08.21 15:09, Philippe Gerum wrote: > > Jan Kiszka writes: > >> Hi all, >> >> just wanted to debug the RTnet issues we now see in CI on arm and arm64. >> I picked arm as first target, but that apparently starts to break with >> gcc-9 or newer (tried 9.2 and 10.2): >> >> make[5]: Entering directory '/xenomai/lib/cobalt/arch/arm' >> CC libarch_la-features.lo >> features.c: In function 'cobalt_arch_check_features': >> features.c:82:1: error: r7 cannot be used in 'asm' here >>82 | } >> | ^ >> >> That seems to be related to passing the syscall number via r7 on ARM. Is >> our ABI soon no longer compilable, or can we fix this? >> >> Jan > > r7 may be used as a scratch register by gcc in some > cases. -fomit-frame-pointer for debug builds may help (i.e. when the > optimizer is switched off). > Good hint. I had --enable-debug=full set, and it builds without it (and now reports other issues that Debian's gcc-10 sees). But how to resolve this properly? Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Arm userland not building with gcc-9 and later
Hi all, just wanted to debug the RTnet issues we now see in CI on arm and arm64. I picked arm as first target, but that apparently starts to break with gcc-9 or newer (tried 9.2 and 10.2): make[5]: Entering directory '/xenomai/lib/cobalt/arch/arm' CC libarch_la-features.lo features.c: In function 'cobalt_arch_check_features': features.c:82:1: error: r7 cannot be used in 'asm' here 82 | } | ^ That seems to be related to passing the syscall number via r7 on ARM. Is our ABI soon no longer compilable, or can we fix this? Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [xenomai-images][PATCH v2] linux-xenomai_4.4: Add machine specific config for beagle bone black
On 05.08.21 16:41, Jan Kiszka via Xenomai wrote:
> On 05.08.21 14:29, Q. Gylstorff wrote:
>> From: Quirin Gylstorff
>>
>> The beagle bone black does most[1] of the time not boot ipipe 4.4 + xenomai
>> 3.0.x if
>> the following kernel configuration elements are active:
>> - CONFIG_RAW_PRINTK
>> - CONFIG_DEBUG_LL
>> - CONFIG_IPIPE_DEBUG
>> - CONFIG_XENO_OPT_DEBUG
>>
>> Last message in U-boot is:
>> ```
>> Starting kernel ...
>> ```
>>
>> 4.19 and newer are not impacted.
>>
>> [1]: The CI build boots around 1 out 4. See
>> https://source.denx.de/Xenomai/xenomai-images/-/jobs/303430
>>
>> Signed-off-by: Quirin Gylstorff
>> ---
>> Changes V2:
>> - replace defconfig with partial config
>> - adapt commit message for sporatic CI boots
>>
>> recipes-kernel/linux/files/bbb_4.4.cfg| 4
>> recipes-kernel/linux/linux-xenomai_4.4.bb | 1 +
>> 2 files changed, 5 insertions(+)
>> create mode 100644 recipes-kernel/linux/files/bbb_4.4.cfg
>>
>> diff --git a/recipes-kernel/linux/files/bbb_4.4.cfg
>> b/recipes-kernel/linux/files/bbb_4.4.cfg
>> new file mode 100644
>> index 000..4628f44
>> --- /dev/null
>> +++ b/recipes-kernel/linux/files/bbb_4.4.cfg
>> @@ -0,0 +1,4 @@
>> +# CONFIG_RAW_PRINTK is not set
>> +# CONFIG_DEBUG_LL is not set
>> +# CONFIG_IPIPE_DEBUG is not set
>> +# CONFIG_XENO_OPT_DEBUG is not set
>> diff --git a/recipes-kernel/linux/linux-xenomai_4.4.bb
>> b/recipes-kernel/linux/linux-xenomai_4.4.bb
>> index 2a1137c..42c6d83 100644
>> --- a/recipes-kernel/linux/linux-xenomai_4.4.bb
>> +++ b/recipes-kernel/linux/linux-xenomai_4.4.bb
>> @@ -16,6 +16,7 @@ SRCREV_amd64 ?= "ipipe-core-4.4.268-cip57-x86-28"
>> PV_amd64 = "4.4.268+"
>>
>> SRC_URI_append_armhf = "
>> git://github.com/xenomai-ci/ipipe.git;protocol=https;nobranch=1"
>> +SRC_URI_append_armhf = " ${@ 'file://bbb_4.4.cfg' if d.getVar('MACHINE') ==
>> 'beagle-bone-black' else '' }"
>> SRCREV_armhf ?= "ipipe-core-4.4.268-cip57-arm-13"
>> PV_armhf = "4.4.268+"
>>
>>
>
> Thanks, applied.
>
Bad news: https://source.denx.de/Xenomai/xenomai-images/-/jobs/304747
Possibly, non-debug only lowers the probability of a regression on armhf
or bbb.
Where you able to grab any early boot messages in the failing cases?
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [xenomai-images][RFC][PATCH] ci: Switch to Google nameserver
On 02.08.21 17:43, Jan Kiszka via Xenomai wrote:
> From: Jan Kiszka
>
> This is a temporary hack: Our AWS runners see a lot of DNS errors for
> deb.debian.org. Let's see if they are less with this server.
>
> Signed-off-by: Jan Kiszka
> ---
>
> Seems to work, though only one run passed so far. Go this way for now?
>
> ci/gitlab-ci-base.yml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/ci/gitlab-ci-base.yml b/ci/gitlab-ci-base.yml
> index 2638dec..ce9c800 100644
> --- a/ci/gitlab-ci-base.yml
> +++ b/ci/gitlab-ci-base.yml
> @@ -39,6 +39,7 @@ default:
>extends: .add-proxy-config
>stage: build
>script:
> +- sudo sh -c "echo 'nameserver 8.8.8.8' > /etc/resolv.conf"
> - echo "Building
> kas.yml:board-${TARGET}.yml${XENOMAI_BUILD_OPTION}${LINUX_BUILD_OPTION}${BUILD_OPTIONS}:opt-debug.yml"
> - kas build
> kas.yml:board-${TARGET}.yml${XENOMAI_BUILD_OPTION}${LINUX_BUILD_OPTION}${BUILD_OPTIONS}:opt-debug.yml
> - if [ -n "${USE_S3_BUCKET}" ]; then scripts/deploy_to_aws.sh ${TARGET};
> fi
>
Seems you found the reason in our AWS setup. I'm dropping this from next
again to confirm that we are safe.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH] testsuite/smokey: net: Load rtnet module if missing
On 06.08.21 10:23, Chen, Hongzhan wrote:
>
>
> -Original Message-
>> From: Jan Kiszka
>> Sent: Friday, August 6, 2021 4:12 PM
>> To: Chen, Hongzhan ; Xenomai
>> Subject: Re: [PATCH] testsuite/smokey: net: Load rtnet module if missing
>>
>> On 06.08.21 09:48, Chen, Hongzhan wrote:
>>>
>>>
-Original Message-
From: Jan Kiszka
Sent: Friday, August 6, 2021 3:38 PM
To: Xenomai
Cc: Chen, Hongzhan
Subject: [PATCH] testsuite/smokey: net: Load rtnet module if missing
From: Jan Kiszka
This allows to run RTnet tests if the core is built as module but not
yet loaded at the start of the test.
For that, silence error reports of 'modprobe rtnet'.
Signed-off-by: Jan Kiszka
---
This should do the trick as well, just a bit simpler.
testsuite/smokey/net_common/setup.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/testsuite/smokey/net_common/setup.c
b/testsuite/smokey/net_common/setup.c
index 1badabdfb4..44a0cb24b9 100644
--- a/testsuite/smokey/net_common/setup.c
+++ b/testsuite/smokey/net_common/setup.c
@@ -138,7 +138,7 @@ static int do_down(const char *intf)
return 0;
}
-static int smokey_net_modprobe(int modid)
+static int smokey_net_modprobe(int modid, bool silent)
{
struct module *m = modules + modid;
char buffer[128];
@@ -168,7 +168,8 @@ static int smokey_net_modprobe(int modid)
smokey_trace("%s module not there: modprobing", m->name);
err = smokey_check_errno(
- snprintf(buffer, sizeof(buffer), "modprobe %s", m->name));
+ snprintf(buffer, sizeof(buffer), "modprobe %s %s", m->name,
+ silent ? "2>/dev/null" : ""));
if (err < 0)
return err;
@@ -177,7 +178,8 @@ static int smokey_net_modprobe(int modid)
return err;
if (!WIFEXITED(err) || WEXITSTATUS(err) != 0) {
- smokey_warning("%s: abnormal exit", buffer);
+ if (!silent)
+ smokey_warning("%s: abnormal exit", buffer);
return -EINVAL;
}
@@ -224,7 +226,7 @@ static int smokey_net_setup_rtcfg_client(const char
*intf, int net_config)
if ((net_config & _CC_COBALT_NET_CFG) == 0)
return -ENOSYS;
- err = smokey_net_modprobe(MODID_CFG);
+ err = smokey_net_modprobe(MODID_CFG, false);
if (err < 0)
return err;
@@ -408,6 +410,12 @@ int smokey_net_setup(const char *driver, const char
*intf, int tested_config,
struct sockaddr_in *in_peer = vpeer;
struct sockaddr *peer = vpeer;
+ /*
+ * Main module needs to be loaded in order to use
+ * _CC_COBALT_GET_NET_CONFIG.
+ */
+ smokey_net_modprobe(MODID_RTNET, true);
>>>
>>> no need to check return value?
>>>
>>
>> Theoretically, we could miss the case that RTnet was configured but the
>
> What about RTnet is not configured? New modinfo checking patch as we
> discussed to protect this?
If RTnet is not configured, the test will fail silently ("no kernel
support"). If we don't want that case for our CI/CT setup, we need to
check the output for such messages and fail the test run at lava level.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH] testsuite/smokey: net: Load rtnet module if missing
On 06.08.21 09:48, Chen, Hongzhan wrote:
>
>
>> -Original Message-
>> From: Jan Kiszka
>> Sent: Friday, August 6, 2021 3:38 PM
>> To: Xenomai
>> Cc: Chen, Hongzhan
>> Subject: [PATCH] testsuite/smokey: net: Load rtnet module if missing
>>
>> From: Jan Kiszka
>>
>> This allows to run RTnet tests if the core is built as module but not
>> yet loaded at the start of the test.
>>
>> For that, silence error reports of 'modprobe rtnet'.
>>
>> Signed-off-by: Jan Kiszka
>> ---
>>
>> This should do the trick as well, just a bit simpler.
>>
>> testsuite/smokey/net_common/setup.c | 22 +++---
>> 1 file changed, 15 insertions(+), 7 deletions(-)
>>
>> diff --git a/testsuite/smokey/net_common/setup.c
>> b/testsuite/smokey/net_common/setup.c
>> index 1badabdfb4..44a0cb24b9 100644
>> --- a/testsuite/smokey/net_common/setup.c
>> +++ b/testsuite/smokey/net_common/setup.c
>> @@ -138,7 +138,7 @@ static int do_down(const char *intf)
>> return 0;
>> }
>>
>> -static int smokey_net_modprobe(int modid)
>> +static int smokey_net_modprobe(int modid, bool silent)
>> {
>> struct module *m = modules + modid;
>> char buffer[128];
>> @@ -168,7 +168,8 @@ static int smokey_net_modprobe(int modid)
>> smokey_trace("%s module not there: modprobing", m->name);
>>
>> err = smokey_check_errno(
>> -snprintf(buffer, sizeof(buffer), "modprobe %s", m->name));
>> +snprintf(buffer, sizeof(buffer), "modprobe %s %s", m->name,
>> + silent ? "2>/dev/null" : ""));
>> if (err < 0)
>> return err;
>>
>> @@ -177,7 +178,8 @@ static int smokey_net_modprobe(int modid)
>> return err;
>>
>> if (!WIFEXITED(err) || WEXITSTATUS(err) != 0) {
>> -smokey_warning("%s: abnormal exit", buffer);
>> +if (!silent)
>> +smokey_warning("%s: abnormal exit", buffer);
>> return -EINVAL;
>> }
>>
>> @@ -224,7 +226,7 @@ static int smokey_net_setup_rtcfg_client(const char
>> *intf, int net_config)
>> if ((net_config & _CC_COBALT_NET_CFG) == 0)
>> return -ENOSYS;
>>
>> -err = smokey_net_modprobe(MODID_CFG);
>> +err = smokey_net_modprobe(MODID_CFG, false);
>> if (err < 0)
>> return err;
>>
>> @@ -408,6 +410,12 @@ int smokey_net_setup(const char *driver, const char
>> *intf, int tested_config,
>> struct sockaddr_in *in_peer = vpeer;
>> struct sockaddr *peer = vpeer;
>>
>> +/*
>> + * Main module needs to be loaded in order to use
>> + * _CC_COBALT_GET_NET_CONFIG.
>> + */
>> +smokey_net_modprobe(MODID_RTNET, true);
>
> no need to check return value?
>
Theoretically, we could miss the case that RTnet was configured but the
module cannot be loaded. But I think this is negligible, and the
alternative is rather complex.
We could rather add a "no kernel support" test to our lava jobs when all
features are enabled. Will also ensure that we do not degrade on that again.
Jan
> Regards
> Hongzhan Chen
>> +
>> err = cobalt_corectl(_CC_COBALT_GET_NET_CONFIG,
>> _config, sizeof(net_config));
>> if (err == -EINVAL)
>> @@ -423,15 +431,15 @@ int smokey_net_setup(const char *driver, const char
>> *intf, int tested_config,
>> return -ENOSYS;
>>
>> modules[MODID_DRIVER].name = driver;
>> -err = smokey_net_modprobe(MODID_DRIVER);
>> +err = smokey_net_modprobe(MODID_DRIVER, false);
>> if (err < 0)
>> return err;
>>
>> -err = smokey_net_modprobe(MODID_IPV4);
>> +err = smokey_net_modprobe(MODID_IPV4, false);
>> if (err < 0)
>> return err;
>>
>> -err = smokey_net_modprobe(option_to_modid(tested_config));
>> +err = smokey_net_modprobe(option_to_modid(tested_config), false);
>> if (err < 0)
>> return err;
>>
>> --
>> 2.31.1
>
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH 2/2] testsuite/smokey: net_client: skip late packet error in vm mode
On 05.08.21 07:01, Jan Kiszka via Xenomai wrote:
> On 05.08.21 02:39, Chen, Hongzhan wrote:
>>
>>
>>> -Original Message-
>>> From: Jan Kiszka
>>> Sent: Wednesday, August 4, 2021 6:20 PM
>>> To: Chen, Hongzhan ; xenomai@xenomai.org
>>> Subject: Re: [PATCH 2/2] testsuite/smokey: net_client: skip late packet
>>> error in vm mode
>>>
>>> On 04.08.21 04:47, Hongzhan Chen via Xenomai wrote:
>>>> In vm mode, skip late packet error in functional test to avoid
>>>> test failure.
>>>>
>>>> Signed-off-by: Hongzhan Chen
>>>>
>>>> diff --git a/testsuite/smokey/net_common/client.c
>>>> b/testsuite/smokey/net_common/client.c
>>>> index d13d72918..752ea55ed 100644
>>>> --- a/testsuite/smokey/net_common/client.c
>>>> +++ b/testsuite/smokey/net_common/client.c
>>>> @@ -204,7 +204,7 @@ static int smokey_net_client_loop(struct
>>>> smokey_net_client *client)
>>>>} while (err != -ETIMEDOUT);
>>>>}
>>>>
>>>> - if (glost || glate)
>>>> + if (glost || (!smokey_on_vm && glate))
>>>>fprintf(stderr, "RTnet %s test failed", client->name);
>>>>if (glost) {
>>>>if (glost == limit)
>>>> @@ -214,11 +214,11 @@ static int smokey_net_client_loop(struct
>>>> smokey_net_client *client)
>>>>fprintf(stderr, ", %Lu packets lost (%g %%)",
>>>>glost, 100.0 * glost / limit);
>>>>}
>>>> - if (glate)
>>>> + if (!smokey_on_vm && glate)
>>>>fprintf(stderr, ", %Lu overruns", glate);
>>>
>>> I think we can keep this report, just not mark the test failed in case
>>> of smokey_on_vm.
>>
>> But this string printed out here looks like ugly in case of smokey_on_vm.,
>> do we need to change something ?
>> How about :
>>
>> if (!smokey_on_vm && glate)
>> fprintf(stderr, "there is %Lu overruns", glate);
>> else if (glate)
>> fprintf(stderr, ", %Lu overruns", glate);
>>
>
> Hmm, what is the difference?
>
OK, sorry, now I see the relevance. Applied this one.
Thanks,
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
[PATCH] testsuite/smokey: net: Load rtnet module if missing
From: Jan Kiszka
This allows to run RTnet tests if the core is built as module but not
yet loaded at the start of the test.
For that, silence error reports of 'modprobe rtnet'.
Signed-off-by: Jan Kiszka
---
This should do the trick as well, just a bit simpler.
testsuite/smokey/net_common/setup.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/testsuite/smokey/net_common/setup.c
b/testsuite/smokey/net_common/setup.c
index 1badabdfb4..44a0cb24b9 100644
--- a/testsuite/smokey/net_common/setup.c
+++ b/testsuite/smokey/net_common/setup.c
@@ -138,7 +138,7 @@ static int do_down(const char *intf)
return 0;
}
-static int smokey_net_modprobe(int modid)
+static int smokey_net_modprobe(int modid, bool silent)
{
struct module *m = modules + modid;
char buffer[128];
@@ -168,7 +168,8 @@ static int smokey_net_modprobe(int modid)
smokey_trace("%s module not there: modprobing", m->name);
err = smokey_check_errno(
- snprintf(buffer, sizeof(buffer), "modprobe %s", m->name));
+ snprintf(buffer, sizeof(buffer), "modprobe %s %s", m->name,
+silent ? "2>/dev/null" : ""));
if (err < 0)
return err;
@@ -177,7 +178,8 @@ static int smokey_net_modprobe(int modid)
return err;
if (!WIFEXITED(err) || WEXITSTATUS(err) != 0) {
- smokey_warning("%s: abnormal exit", buffer);
+ if (!silent)
+ smokey_warning("%s: abnormal exit", buffer);
return -EINVAL;
}
@@ -224,7 +226,7 @@ static int smokey_net_setup_rtcfg_client(const char *intf,
int net_config)
if ((net_config & _CC_COBALT_NET_CFG) == 0)
return -ENOSYS;
- err = smokey_net_modprobe(MODID_CFG);
+ err = smokey_net_modprobe(MODID_CFG, false);
if (err < 0)
return err;
@@ -408,6 +410,12 @@ int smokey_net_setup(const char *driver, const char *intf,
int tested_config,
struct sockaddr_in *in_peer = vpeer;
struct sockaddr *peer = vpeer;
+ /*
+* Main module needs to be loaded in order to use
+* _CC_COBALT_GET_NET_CONFIG.
+*/
+ smokey_net_modprobe(MODID_RTNET, true);
+
err = cobalt_corectl(_CC_COBALT_GET_NET_CONFIG,
_config, sizeof(net_config));
if (err == -EINVAL)
@@ -423,15 +431,15 @@ int smokey_net_setup(const char *driver, const char
*intf, int tested_config,
return -ENOSYS;
modules[MODID_DRIVER].name = driver;
- err = smokey_net_modprobe(MODID_DRIVER);
+ err = smokey_net_modprobe(MODID_DRIVER, false);
if (err < 0)
return err;
- err = smokey_net_modprobe(MODID_IPV4);
+ err = smokey_net_modprobe(MODID_IPV4, false);
if (err < 0)
return err;
- err = smokey_net_modprobe(option_to_modid(tested_config));
+ err = smokey_net_modprobe(option_to_modid(tested_config), false);
if (err < 0)
return err;
--
2.31.1
Re: [Patch] Allow selection of timestamp source for GPIO timestamps
Please tag the patch with the subsystem, in this case "drivers/gpio:".
On 05.08.21 17:15, François Legal via Xenomai wrote:
> This patch allows to select which time source (monotonic/realtime) is used to
> timestamp GPIO events.
> The time source used to be monotonic which is the opposite of what other
> drivers do. Now default changed to realtime, plus new API added to go back to
> monotonic.
>
>
> Signed-off-by: François LEGAL
> ---
>
> diff --git a/include/rtdm/uapi/gpio.h b/include/rtdm/uapi/gpio.h
> index 2839f7d51..f8a93b7f7 100644
> --- a/include/rtdm/uapi/gpio.h
> +++ b/include/rtdm/uapi/gpio.h
> @@ -30,6 +30,8 @@ struct rtdm_gpio_readout {
> #define GPIO_RTIOC_REQS _IO(RTDM_CLASS_GPIO, 4)
> #define GPIO_RTIOC_RELS _IO(RTDM_CLASS_GPIO, 5)
> #define GPIO_RTIOC_TS_IOR(RTDM_CLASS_GPIO, 7, int)
> +#define GPIO_RTIOC_TS_REAL _IOR(RTDM_CLASS_GPIO, 8, int)
> +#define GPIO_RTIOC_TS_MONO _IOR(RTDM_CLASS_GPIO, 9, int)
Only one of them needs to be a new define, the other can be an alias (or
GPIO_RTIOC_TS can be that).
>
> #define GPIO_TRIGGER_NONE0x0 /* unspecified */
> #define GPIO_TRIGGER_EDGE_RISING 0x1
> diff --git a/kernel/drivers/gpio/gpio-core.c b/kernel/drivers/gpio/gpio-core.c
> index bc283064b..3eaf425c6 100644
> --- a/kernel/drivers/gpio/gpio-core.c
> +++ b/kernel/drivers/gpio/gpio-core.c
> @@ -36,13 +36,15 @@ static LIST_HEAD(rtdm_gpio_chips);
>
> static DEFINE_MUTEX(chip_lock);
>
> +static nanosecs_abs_t (*timestamp_get_func_ptr)(void) = rtdm_clock_read;
> +
This must be controlled per device instance, not globally for all GPIO
devices.
> static int gpio_pin_interrupt(rtdm_irq_t *irqh)
> {
> struct rtdm_gpio_pin *pin;
>
> pin = rtdm_irq_get_arg(irqh, struct rtdm_gpio_pin);
>
> - pin->timestamp = rtdm_clock_read_monotonic();
> + pin->timestamp = timestamp_get_func_ptr();
> rtdm_event_signal(>event);
>
> return RTDM_IRQ_HANDLED;
> @@ -192,9 +194,18 @@ static int gpio_pin_ioctl_nrt(struct rtdm_fd *fd,
> chan->requested = false;
> break;
> case GPIO_RTIOC_TS:
> + case GPIO_RTIOC_TS_REAL:
This changes the default of GPIO_RTIOC_TS in way that does not allow to
back-port the patch to stable.
> + ret = rtdm_safe_copy_from_user(fd, , arg, sizeof(val));
> + if (ret)
> + return ret;
> + timestamp_get_func_ptr = rtdm_clock_read;
> + chan->want_timestamp = !!val;
> + break;
> + case GPIO_RTIOC_TS_MONO:
> ret = rtdm_safe_copy_from_user(fd, , arg, sizeof(val));
> if (ret)
> return ret;
> + timestamp_get_func_ptr = rtdm_clock_read_monotonic;
> chan->want_timestamp = !!val;
> break;
> default:
>
>
Thanks for the patch, but some bits still need tuning.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [xenomai-images][PATCH v2] linux-xenomai_4.4: Add machine specific config for beagle bone black
On 05.08.21 14:29, Q. Gylstorff wrote:
> From: Quirin Gylstorff
>
> The beagle bone black does most[1] of the time not boot ipipe 4.4 + xenomai
> 3.0.x if
> the following kernel configuration elements are active:
> - CONFIG_RAW_PRINTK
> - CONFIG_DEBUG_LL
> - CONFIG_IPIPE_DEBUG
> - CONFIG_XENO_OPT_DEBUG
>
> Last message in U-boot is:
> ```
> Starting kernel ...
> ```
>
> 4.19 and newer are not impacted.
>
> [1]: The CI build boots around 1 out 4. See
> https://source.denx.de/Xenomai/xenomai-images/-/jobs/303430
>
> Signed-off-by: Quirin Gylstorff
> ---
> Changes V2:
> - replace defconfig with partial config
> - adapt commit message for sporatic CI boots
>
> recipes-kernel/linux/files/bbb_4.4.cfg| 4
> recipes-kernel/linux/linux-xenomai_4.4.bb | 1 +
> 2 files changed, 5 insertions(+)
> create mode 100644 recipes-kernel/linux/files/bbb_4.4.cfg
>
> diff --git a/recipes-kernel/linux/files/bbb_4.4.cfg
> b/recipes-kernel/linux/files/bbb_4.4.cfg
> new file mode 100644
> index 000..4628f44
> --- /dev/null
> +++ b/recipes-kernel/linux/files/bbb_4.4.cfg
> @@ -0,0 +1,4 @@
> +# CONFIG_RAW_PRINTK is not set
> +# CONFIG_DEBUG_LL is not set
> +# CONFIG_IPIPE_DEBUG is not set
> +# CONFIG_XENO_OPT_DEBUG is not set
> diff --git a/recipes-kernel/linux/linux-xenomai_4.4.bb
> b/recipes-kernel/linux/linux-xenomai_4.4.bb
> index 2a1137c..42c6d83 100644
> --- a/recipes-kernel/linux/linux-xenomai_4.4.bb
> +++ b/recipes-kernel/linux/linux-xenomai_4.4.bb
> @@ -16,6 +16,7 @@ SRCREV_amd64 ?= "ipipe-core-4.4.268-cip57-x86-28"
> PV_amd64 = "4.4.268+"
>
> SRC_URI_append_armhf = "
> git://github.com/xenomai-ci/ipipe.git;protocol=https;nobranch=1"
> +SRC_URI_append_armhf = " ${@ 'file://bbb_4.4.cfg' if d.getVar('MACHINE') ==
> 'beagle-bone-black' else '' }"
> SRCREV_armhf ?= "ipipe-core-4.4.268-cip57-arm-13"
> PV_armhf = "4.4.268+"
>
>
Thanks, applied.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH v2 1/1] license: summarize the licensing terms
On 05.08.21 09:23, Philippe Gerum wrote: > > Jan Kiszka writes: > >> On 04.08.21 09:35, Philippe Gerum via Xenomai wrote: >>> From: Philippe Gerum >>> >>> Signed-off-by: Philippe Gerum >>> --- >>> COPYING | 45 + >>> 1 file changed, 45 insertions(+) >>> create mode 100644 COPYING >>> >>> diff --git a/COPYING b/COPYING >>> new file mode 100644 >>> index 0..839938c62 >>> --- /dev/null >>> +++ b/COPYING >>> @@ -0,0 +1,45 @@ >>> + >>> +Xenomai 3 Licensing terms >>> += >>> + >>> +Xenomai 3 is composed of a number of libraries, user-space application >>> +programs, and kernel code. This file summarizes the licenses used for >>> +the libraries and kernel code (aka 'Cobalt core'). Please refer to the >>> +COPYING file in the corresponding directory for details. The licensing >>> +terms of each application program shipped with Xenomai 3 is stated in >>> +the corresponding source code. >>> + >>> + >>> + User space interface|SPDX identifier [1] >>> + >>> + | >>> + alchemy | LGPL-2.1-or-later >>> + boilerplate | LGPL-2.1-or-later, some MIT portions >>> + boilerplate/iniparser | MIT >>> + cobalt | LGPL-2.1-or-later >>> + copperplate | LGPL-2.1-or-later >>> + psos| LGPL-2.1-or-later >>> + smokey | LGPL-2.1-or-later >> >> smokey has "some MIT portions" as well (network tests). >> > > Granted, however this summary exclusively refers to the libraries in > this case, i.e. libsmokey. I published that one under > LGPLv2.1-or-later. The smokey-based tests are referred to as > "application programs", which are not covered in detail by the summary > since they are not part of any application interface. > >From that perspective, you are right. Maybe add a general disclaimer, not only regrading [2], that files may contain further license information, and this is not a 100% complete listing. > >>> + trank | LGPL-2.1-or-later >>> + vxworks | LGPL-2.1-or-later >>> + include | LGPL-2.1-or-later with exception [2] >>> +--- >>> + >>> +== >>> + Cobalt core |SPDX identifier >>> +== >>> + | >>> + kernel/cobalt | GPL-2.0-or-later >>> + kernel/cobalt/posix | GPL-2.0-or-later >>> + kernel/cobalt/rtdm | GPL-2.0-or-later >>> + include/cobalt/kernel | GPL-2.0-or-later with exception [2] >> >> Analogously to that, we have a few RTnet header under a similar >> exceptions: include/rtdm/net.h, include/rtdm/uapi/net.h, >> kernel/drivers/net/stack/include/rtmac.h. >> > > Also, the project name mentioned is RTnet in these files, Xenomai should > at least be referred to as well. > > - the clause in include/rtdm/net.h seems in line with the general > exception clause applicable to all other user interface headers. Yeah, we should change the project reference, explain in the commit log that the RTnet project was merged into the Xenomai one. That reduces exception variations, even if just by name. > > - kernel/drivers/net/stack/include/rtmac.h should probably move to > include/rtdm/uapi, so that it appears clearly as covered by the > Xenomai and Linux-syscall exceptions. Agreed. I don't recall anymore what happened with any applications that were using those IOCTLs. They once existed, as demos at least, but possibly they weren't carried over when RTnet was merged. Those would have complained about the strange header location and missing deployment of rtmac.h... > >>> +-- >>> + >>> +Please note that the Linux licensing rules apply to the Xenomai kernel >>> +code once compiled in the Linux kernel. These rules can be found at: >>> +https://www.kernel.org/doc/html/latest/process/license-rules.html#kernel-licensing >>> + >>> +[1] See https://spdx.org/licenses >>> + >>> +[2] The exception grants additional permission to use the header files >>> +in user-space application programs. See include/COPYING. >>> >> >> I just browsed a report from a commercial license scanner for Xenomai >> 3.0.11. Only those minor deviations above, rest is in line (minus a few >> mis-classifications the scanner and/or the operators produced...). >> > > Ok. > Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH V2] testsuite/smokey: net: load rtnet module if it has not been loaded
On 05.08.21 08:12, Chen, Hongzhan wrote: > > > > >> -Original Message- >> >> From: Jan Kiszka >> >> Sent: Thursday, August 5, 2021 1:50 PM >> >> To: Chen, Hongzhan ; xenomai@xenomai.org >> >> Subject: Re: [PATCH V2] testsuite/smokey: net: load rtnet module if it has >> not been loaded >> >> >> On 05.08.21 07:32, Chen, Hongzhan wrote: >> >>> >>> >>> >>> -Original Message- From: Jan Kiszka Sent: Thursday, August 5, 2021 1:26 PM To: Chen, Hongzhan ; xenomai@xenomai.org Subject: Re: [PATCH V2] testsuite/smokey: net: load rtnet module if it has not been loaded On 05.08.21 07:21, Chen, Hongzhan wrote: > > > > >> -Original Message- >> >> From: Jan Kiszka >> >> Sent: Thursday, August 5, 2021 1:01 PM >> >> To: Chen, Hongzhan ; xenomai@xenomai.org >> >> Subject: Re: [PATCH V2] testsuite/smokey: net: load rtnet module if it >> has not been loaded >> >> >> On 05.08.21 05:13, Hongzhan Chen via Xenomai wrote: >> >>> Before checking net config, rtnet should be ready. >>> >>> >>> >>> Signed-off-by: Hongzhan Chen >>> >>> >>> >>> diff --git a/testsuite/smokey/net_common/setup.c >>> b/testsuite/smokey/net_common/setup.c >>> >>> index 1badabdfb..a0512b00d 100644 >>>
Re: [PATCH V2] testsuite/smokey: net: load rtnet module if it has not been loaded
On 05.08.21 07:32, Chen, Hongzhan wrote:
>
>
>> -Original Message-
>> From: Jan Kiszka
>> Sent: Thursday, August 5, 2021 1:26 PM
>> To: Chen, Hongzhan ; xenomai@xenomai.org
>> Subject: Re: [PATCH V2] testsuite/smokey: net: load rtnet module if it has
>> not been loaded
>>
>> On 05.08.21 07:21, Chen, Hongzhan wrote:
>>>
>>>
-Original Message-
From: Jan Kiszka
Sent: Thursday, August 5, 2021 1:01 PM
To: Chen, Hongzhan ; xenomai@xenomai.org
Subject: Re: [PATCH V2] testsuite/smokey: net: load rtnet module if it has
not been loaded
On 05.08.21 05:13, Hongzhan Chen via Xenomai wrote:
> Before checking net config, rtnet should be ready.
>
> Signed-off-by: Hongzhan Chen
>
> diff --git a/testsuite/smokey/net_common/setup.c
> b/testsuite/smokey/net_common/setup.c
> index 1badabdfb..a0512b00d 100644
> --- a/testsuite/smokey/net_common/setup.c
> +++ b/testsuite/smokey/net_common/setup.c
> @@ -408,6 +408,10 @@ int smokey_net_setup(const char *driver, const char
> *intf, int tested_config,
> struct sockaddr_in *in_peer = vpeer;
> struct sockaddr *peer = vpeer;
>
> + err = smokey_net_modprobe(MODID_RTNET);
> + if (err < 0)
> + return err;
> +
> err = cobalt_corectl(_CC_COBALT_GET_NET_CONFIG,
> _config, sizeof(net_config));
> if (err == -EINVAL)
>
Sorry, only realized now: The checks that come right after this should
not be affected by rtnet being loaded or not yet. I think they check
>>>
>>> No. Actually, it would be affected. If rtnet is not loaded and inited
>>> before cobalt_corectl is called, it would
>>> not call rtnet_corectl_register to cobalt_add_config_chain and
>>> config_notifier_list would
>>> be empty. And then cobalt_corectl ->do_conf_option would return -EINVAL
>>> because blocking_notifier_call_chain return NOTIFY_DONE.
>>> In smokey_net_setup, it would return -ENOSYS because cobalt_corectl return
>>> -EINVAL.
>>>
>>
>> OK, catch22. But we must not fail the test if RTnet is not configured
>
> I do not know what RTnet config you are talking about. Actually
> cobalt_corectl(_CC_COBALT_GET_NET_CONFIG is just checking xenomai kernel
> config.
>
> static int rtnet_corectl_call(struct notifier_block *self, unsigned long arg,
> void *cookie)
>
> {
> struct cobalt_config_vector *vec = cookie;
> int ret = 0;
>
> if (arg != _CC_COBALT_GET_NET_CONFIG)
> return NOTIFY_DONE;
>
> if (vec->u_bufsz < sizeof(ret))
> return notifier_from_errno(-EINVAL);
>
> if (IS_ENABLED(CONFIG_XENO_DRIVERS_NET))
> ret |= _CC_COBALT_NET;
> if (IS_ENABLED(CONFIG_XENO_DRIVERS_NET_ETH_P_ALL))
> ret |= _CC_COBALT_NET_ETH_P_ALL;
> if (IS_ENABLED(CONFIG_XENO_DRIVERS_NET_RTIPV4))
> ret |= _CC_COBALT_NET_IPV4;
> if (IS_ENABLED(CONFIG_XENO_DRIVERS_NET_RTIPV4_ICMP))
> ret |= _CC_COBALT_NET_ICMP;
> if (IS_ENABLED(CONFIG_XENO_DRIVERS_NET_RTIPV4_NETROUTING))
> ret |= _CC_COBALT_NET_NETROUTING;
> if (IS_ENABLED(CONFIG_XENO_DRIVERS_NET_RTIPV4_ROUTE))
> ret |= _CC_COBALT_NET_ROUTER;
> if (IS_ENABLED(CONFIG_XENO_DRIVERS_NET_RTIPV4_UDP))
> ret |= _CC_COBALT_NET_UDP;
> if (IS_ENABLED(CONFIG_XENO_DRIVERS_NET_RTPACKET))
> ret |= _CC_COBALT_NET_AF_PACKET;
> if (IS_ENABLED(CONFIG_XENO_DRIVERS_NET_TDMA))
> ret |= _CC_COBALT_NET_TDMA;
> if (IS_ENABLED(CONFIG_XENO_DRIVERS_NET_NOMAC))
> ret |= _CC_COBALT_NET_NOMAC;
> if (IS_ENABLED(CONFIG_XENO_DRIVERS_NET_RTCFG))
> ret |= _CC_COBALT_NET_CFG;
> if (IS_ENABLED(CONFIG_XENO_DRIVERS_NET_ADDON_RTCAP))
> ret |= _CC_COBALT_NET_CAP;
> if (IS_ENABLED(CONFIG_XENO_DRIVERS_NET_ADDON_PROXY))
> ret |= _CC_COBALT_NET_PROXY;
>
> ret = cobalt_copy_to_user(vec->u_buf, , sizeof(ret));
>
>> and, thus, cannot be loaded.
>>
>> Jan
>
CONFIG_XENO_DRIVERS_NET=n, smokey --run= => skipped (no
kernel support). That would be the expected result. I'm afraid that the
new modprobe will fail with something != ENOSYS, thus will not give us
such a result. Please check.
Thanks,
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH V2] testsuite/smokey: net: load rtnet module if it has not been loaded
On 05.08.21 07:21, Chen, Hongzhan wrote: > > >> -Original Message- >> From: Jan Kiszka >> Sent: Thursday, August 5, 2021 1:01 PM >> To: Chen, Hongzhan ; xenomai@xenomai.org >> Subject: Re: [PATCH V2] testsuite/smokey: net: load rtnet module if it has >> not been loaded >> >> On 05.08.21 05:13, Hongzhan Chen via Xenomai wrote: >>> Before checking net config, rtnet should be ready. >>> >>> Signed-off-by: Hongzhan Chen >>> >>> diff --git a/testsuite/smokey/net_common/setup.c >>> b/testsuite/smokey/net_common/setup.c >>> index 1badabdfb..a0512b00d 100644 >>> --- a/testsuite/smokey/net_common/setup.c >>> +++ b/testsuite/smokey/net_common/setup.c >>> @@ -408,6 +408,10 @@ int smokey_net_setup(const char *driver, const char >>> *intf, int tested_config, >>> struct sockaddr_in *in_peer = vpeer; >>> struct sockaddr *peer = vpeer; >>> >>> + err = smokey_net_modprobe(MODID_RTNET); >>> + if (err < 0) >>> + return err; >>> + >>> err = cobalt_corectl(_CC_COBALT_GET_NET_CONFIG, >>> _config, sizeof(net_config)); >>> if (err == -EINVAL) >>> >> >> Sorry, only realized now: The checks that come right after this should >> not be affected by rtnet being loaded or not yet. I think they check > > No. Actually, it would be affected. If rtnet is not loaded and inited before > cobalt_corectl is called, it would > not call rtnet_corectl_register to cobalt_add_config_chain and > config_notifier_list would > be empty. And then cobalt_corectl ->do_conf_option would return -EINVAL > because blocking_notifier_call_chain return NOTIFY_DONE. > In smokey_net_setup, it would return -ENOSYS because cobalt_corectl return > -EINVAL. > OK, catch22. But we must not fail the test if RTnet is not configured and, thus, cannot be loaded. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH 2/2] testsuite/smokey: net_client: skip late packet error in vm mode
On 05.08.21 02:39, Chen, Hongzhan wrote:
>
>
>> -Original Message-
>> From: Jan Kiszka
>> Sent: Wednesday, August 4, 2021 6:20 PM
>> To: Chen, Hongzhan ; xenomai@xenomai.org
>> Subject: Re: [PATCH 2/2] testsuite/smokey: net_client: skip late packet
>> error in vm mode
>>
>> On 04.08.21 04:47, Hongzhan Chen via Xenomai wrote:
>>> In vm mode, skip late packet error in functional test to avoid
>>> test failure.
>>>
>>> Signed-off-by: Hongzhan Chen
>>>
>>> diff --git a/testsuite/smokey/net_common/client.c
>>> b/testsuite/smokey/net_common/client.c
>>> index d13d72918..752ea55ed 100644
>>> --- a/testsuite/smokey/net_common/client.c
>>> +++ b/testsuite/smokey/net_common/client.c
>>> @@ -204,7 +204,7 @@ static int smokey_net_client_loop(struct
>>> smokey_net_client *client)
>>> } while (err != -ETIMEDOUT);
>>> }
>>>
>>> - if (glost || glate)
>>> + if (glost || (!smokey_on_vm && glate))
>>> fprintf(stderr, "RTnet %s test failed", client->name);
>>> if (glost) {
>>> if (glost == limit)
>>> @@ -214,11 +214,11 @@ static int smokey_net_client_loop(struct
>>> smokey_net_client *client)
>>> fprintf(stderr, ", %Lu packets lost (%g %%)",
>>> glost, 100.0 * glost / limit);
>>> }
>>> - if (glate)
>>> + if (!smokey_on_vm && glate)
>>> fprintf(stderr, ", %Lu overruns", glate);
>>
>> I think we can keep this report, just not mark the test failed in case
>> of smokey_on_vm.
>
> But this string printed out here looks like ugly in case of smokey_on_vm.,
> do we need to change something ?
> How about :
>
> if (!smokey_on_vm && glate)
> fprintf(stderr, "there is %Lu overruns", glate);
> else if (glate)
> fprintf(stderr, ", %Lu overruns", glate);
>
Hmm, what is the difference?
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH V2] testsuite/smokey: net: load rtnet module if it has not been loaded
On 05.08.21 05:13, Hongzhan Chen via Xenomai wrote: > Before checking net config, rtnet should be ready. > > Signed-off-by: Hongzhan Chen > > diff --git a/testsuite/smokey/net_common/setup.c > b/testsuite/smokey/net_common/setup.c > index 1badabdfb..a0512b00d 100644 > --- a/testsuite/smokey/net_common/setup.c > +++ b/testsuite/smokey/net_common/setup.c > @@ -408,6 +408,10 @@ int smokey_net_setup(const char *driver, const char > *intf, int tested_config, > struct sockaddr_in *in_peer = vpeer; > struct sockaddr *peer = vpeer; > > + err = smokey_net_modprobe(MODID_RTNET); > + if (err < 0) > + return err; > + > err = cobalt_corectl(_CC_COBALT_GET_NET_CONFIG, > _config, sizeof(net_config)); > if (err == -EINVAL) > Sorry, only realized now: The checks that come right after this should not be affected by rtnet being loaded or not yet. I think they check whether it is configured and could be loaded. If we try to load when it is not configured, the test case will fail rather than be skipped. Please check and reorder the modprobe accordingly. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH v2 1/1] license: summarize the licensing terms
On 04.08.21 09:35, Philippe Gerum via Xenomai wrote: > From: Philippe Gerum > > Signed-off-by: Philippe Gerum > --- > COPYING | 45 + > 1 file changed, 45 insertions(+) > create mode 100644 COPYING > > diff --git a/COPYING b/COPYING > new file mode 100644 > index 0..839938c62 > --- /dev/null > +++ b/COPYING > @@ -0,0 +1,45 @@ > + > +Xenomai 3 Licensing terms > += > + > +Xenomai 3 is composed of a number of libraries, user-space application > +programs, and kernel code. This file summarizes the licenses used for > +the libraries and kernel code (aka 'Cobalt core'). Please refer to the > +COPYING file in the corresponding directory for details. The licensing > +terms of each application program shipped with Xenomai 3 is stated in > +the corresponding source code. > + > + > + User space interface|SPDX identifier [1] > + > + | > + alchemy | LGPL-2.1-or-later > + boilerplate | LGPL-2.1-or-later, some MIT portions > + boilerplate/iniparser | MIT > + cobalt | LGPL-2.1-or-later > + copperplate | LGPL-2.1-or-later > + psos| LGPL-2.1-or-later > + smokey | LGPL-2.1-or-later smokey has "some MIT portions" as well (network tests). > + trank | LGPL-2.1-or-later > + vxworks | LGPL-2.1-or-later > + include | LGPL-2.1-or-later with exception [2] > +--- > + > +== > + Cobalt core |SPDX identifier > +== > + | > + kernel/cobalt | GPL-2.0-or-later > + kernel/cobalt/posix | GPL-2.0-or-later > + kernel/cobalt/rtdm | GPL-2.0-or-later > + include/cobalt/kernel | GPL-2.0-or-later with exception [2] Analogously to that, we have a few RTnet header under a similar exceptions: include/rtdm/net.h, include/rtdm/uapi/net.h, kernel/drivers/net/stack/include/rtmac.h. > +-- > + > +Please note that the Linux licensing rules apply to the Xenomai kernel > +code once compiled in the Linux kernel. These rules can be found at: > +https://www.kernel.org/doc/html/latest/process/license-rules.html#kernel-licensing > + > +[1] See https://spdx.org/licenses > + > +[2] The exception grants additional permission to use the header files > +in user-space application programs. See include/COPYING. > I just browsed a report from a commercial license scanner for Xenomai 3.0.11. Only those minor deviations above, rest is in line (minus a few mis-classifications the scanner and/or the operators produced...). Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [xenomai-images][PATCH] linux-xenomai_4.4: Add machine specific config for beagle bone black
On 04.08.21 16:29, Gylstorff Quirin wrote: >> But thanks for debugging this. Maybe also clarify that the board >> generally does not boot, but sometimes it still does. > > My target never boots with xenomai-images > b06f6eeef11500b6bce55a1a1e1e27e43fc3fd77. > This one, e.g., did so: https://source.denx.de/Xenomai/xenomai-images/-/jobs/303430 Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH 2/2] testsuite/smokey: net_client: skip late packet error in vm mode
On 04.08.21 04:47, Hongzhan Chen via Xenomai wrote:
> In vm mode, skip late packet error in functional test to avoid
> test failure.
>
> Signed-off-by: Hongzhan Chen
>
> diff --git a/testsuite/smokey/net_common/client.c
> b/testsuite/smokey/net_common/client.c
> index d13d72918..752ea55ed 100644
> --- a/testsuite/smokey/net_common/client.c
> +++ b/testsuite/smokey/net_common/client.c
> @@ -204,7 +204,7 @@ static int smokey_net_client_loop(struct
> smokey_net_client *client)
> } while (err != -ETIMEDOUT);
> }
>
> - if (glost || glate)
> + if (glost || (!smokey_on_vm && glate))
> fprintf(stderr, "RTnet %s test failed", client->name);
> if (glost) {
> if (glost == limit)
> @@ -214,11 +214,11 @@ static int smokey_net_client_loop(struct
> smokey_net_client *client)
> fprintf(stderr, ", %Lu packets lost (%g %%)",
> glost, 100.0 * glost / limit);
> }
> - if (glate)
> + if (!smokey_on_vm && glate)
> fprintf(stderr, ", %Lu overruns", glate);
I think we can keep this report, just not mark the test failed in case
of smokey_on_vm.
> if (glost || glate)
> fputc('\n', stderr);
> - err = glost || glate ? -EPROTO : 0;
> + err = glost || (!smokey_on_vm && glate) ? -EPROTO : 0;
>
>err:
> sock = smokey_check_errno(__RT(close(sock)));
>
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH 1/2] testsuite/smokey: net: load rtnet module if it has not been loaded
On 04.08.21 04:47, Hongzhan Chen via Xenomai wrote:
> Before checking net config, rtnet should be ready.
>
> Signed-off-by: Hongzhan Chen
>
> diff --git a/testsuite/smokey/net_common/setup.c
> b/testsuite/smokey/net_common/setup.c
> index 1badabdfb..719d8175f 100644
> --- a/testsuite/smokey/net_common/setup.c
> +++ b/testsuite/smokey/net_common/setup.c
> @@ -408,6 +408,14 @@ int smokey_net_setup(const char *driver, const char
> *intf, int tested_config,
> struct sockaddr_in *in_peer = vpeer;
> struct sockaddr *peer = vpeer;
>
> + err = access("/dev/rtnet", F_OK);
Not needed. smokey_net_modprobe() checks /proc/modules and loads only if
the module is missing.
> + if (err) {
> + /* device does not exist and load rtnet*/
> + err = smokey_net_modprobe(MODID_RTNET);
> + if (err < 0)
> + return err;
> + }
> +
> err = cobalt_corectl(_CC_COBALT_GET_NET_CONFIG,
> _config, sizeof(net_config));
> if (err == -EINVAL)
>
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: xenomai warning after upgrade to linux 5.4.115
On 04.08.21 02:32, Chen, Hongzhan wrote: > > >> -Original Message- >> From: Jan Kiszka >> Sent: Tuesday, August 3, 2021 5:37 PM >> To: Chen, Hongzhan ; xenomai@xenomai.org >> Subject: Re: xenomai warning after upgrade to linux 5.4.115 >> >> On 29.07.21 10:02, Jan Kiszka via Xenomai wrote: >>> On 29.07.21 08:43, Chen, Hongzhan wrote: >>>> After we upgraded our linux to 5.4.115 from 5.4.76 and rebased IPIPE >>>> patchset for xenomai 3.1.X, there is xenomai warning >>>> printed as in attached xenomai_warning_on_linux5.4.115 on some specific >>>> boards according to our validation. >>> >>> From a first inspection: Linux considers its interrupts to be off around >>> >>> xenomai_init >>> xntimer_grab_hardware >>> ipipe_timer_start >>> smp_call_function_single >>> >>> But that should not be the case. The call path is valid and used for a >>> long time. The issue should come from somewhere else. >>> >>> You you try to debug where interrupts are turned off from Linux >>> perspective? Compare that to boot ups where Linux does not complain. >>> >>>> But I cannot reproduce the issue on same type of board like Maxtang that I >>>> have. In addition, >>>> on one specific board, we found that there is similar warning happened in >>>> smp_call_function_single when ACPI init >>>> ahead of warning happened in xenomai init as in attached >>>> ACPI_warning_and_xenomai_warning_on_linux5.4.115. >>>> When we set acpi=off in cmdline for all problematic boards , warning >>>> totally disappear. Since I cannot get the problematic board >>>> to further debug, would you mind help check attached logs and kernel >>>> config and find the root cause out? >>>> Thanks for your help in advance. >>> >>> >>> Does that other case only occur when CONFIG_IPIPE is enabled? If it also >>> happens with plain Linux, we may see a mainline issue. Or firmware bugs. >>> >>> Jan >>> >> >> Any news on this issue? > > Finally , we found there is missing code in our split patches. > Means, your kernel was missing something that the official I-pipe patches have? Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: kernel bug if rtnet device is accesses during unbind
On 03.08.21 13:18, Lange Norbert via Xenomai wrote: > Hello, > > There is some bigger kernel oops when an rtnet device is unbound from > linux but still accessible via ioctl. > Effect and backtrace depends on timing, usually the rt_igb module will not > decrease its reference count, and a following soft reboot might hang. > > To repoduce, for example with rt_igb (doubt its driver specific): > > echo ":01:00.0" > /sys/bus/pci/drivers/rt_igb/bind > # rtifconfig has to run in background > echo ":01:00.0" > /sys/bus/pci/drivers/rt_igb/unbind & rtifconfig rteth0 > up > So, running one after the other (rtifconfig up first) will not trigger this? Then it would sounds like a race between rtnet or the driver preventing the unbind and the ongoing ifup. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: xenomai warning after upgrade to linux 5.4.115
On 29.07.21 10:02, Jan Kiszka via Xenomai wrote: > On 29.07.21 08:43, Chen, Hongzhan wrote: >> After we upgraded our linux to 5.4.115 from 5.4.76 and rebased IPIPE >> patchset for xenomai 3.1.X, there is xenomai warning >> printed as in attached xenomai_warning_on_linux5.4.115 on some specific >> boards according to our validation. > > From a first inspection: Linux considers its interrupts to be off around > > xenomai_init > xntimer_grab_hardware > ipipe_timer_start > smp_call_function_single > > But that should not be the case. The call path is valid and used for a > long time. The issue should come from somewhere else. > > You you try to debug where interrupts are turned off from Linux > perspective? Compare that to boot ups where Linux does not complain. > >> But I cannot reproduce the issue on same type of board like Maxtang that I >> have. In addition, >> on one specific board, we found that there is similar warning happened in >> smp_call_function_single when ACPI init >> ahead of warning happened in xenomai init as in attached >> ACPI_warning_and_xenomai_warning_on_linux5.4.115. >> When we set acpi=off in cmdline for all problematic boards , warning totally >> disappear. Since I cannot get the problematic board >> to further debug, would you mind help check attached logs and kernel config >> and find the root cause out? >> Thanks for your help in advance. >> > > Does that other case only occur when CONFIG_IPIPE is enabled? If it also > happens with plain Linux, we may see a mainline issue. Or firmware bugs. > > Jan > Any news on this issue? Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: about RTnet* smokey test skipped issue on Qemu
On 03.08.21 09:53, Chen, Hongzhan wrote: > > >> -Original Message- >> From: Jan Kiszka >> Sent: Tuesday, August 3, 2021 3:40 PM >> To: Chen, Hongzhan ; xenomai@xenomai.org >> Subject: Re: about RTnet* smokey test skipped issue on Qemu >> >> On 03.08.21 08:46, Chen, Hongzhan wrote: >>> >>> -Original Message- From: Jan Kiszka Sent: Tuesday, August 3, 2021 12:59 PM To: Chen, Hongzhan ; xenomai@xenomai.org Subject: Re: about RTnet* smokey test skipped issue on Qemu On 03.08.21 06:31, Chen, Hongzhan wrote: > Firstly, I found that all smokey tests including RTnet* pass on bare > metal x86 platform > but three RTnet* related test items are skipped on Qemu. After further > debug, actually there is > no supported rtnet device found on Qemu with current network setting > when xenomai image > is running over even we already enable all supported rtnet devices on > xenomai so that > the test is skipped on qemu. > > After I replace virtio-net-pci with e1000 device like [1] patch , > rt_e1000 and rtnet modules > would be automatically loaded by udevd so that rtnet* test item can go > on without test skipped issue. By default, we are only doing loopback tests in smokey, nothing that requires a real NIC driver to be loaded. These are the modules loaded during a test with udp: Module Size Used by rtudp 24576 0 rtipv4 49152 1 rtudp rt_loopback16384 1 rtnet 81920 3 rtipv4,rtudp,rt_loopback You can set the rtnet_driver and rtnet_interface parameters to switch to real NICs, but that is not happening during a default xeno-test run. >>> > > The problem is that rtnet module is not loaded individually by current > system but because >> RT NIC device driver module depend on it and then rtnet module will be >> loaded when specific >> RT NIC device driver module is modprobed after triggered by udev service. >> That means >> We have to add and modify something to explicitly load rtnet module by >> default when system bootup >> if we do not want to depends on real NIC in our case. For example we may add >> corresponding *.conf >> like [3] to make rtnet load automatically when system bootup in our case? >> >> >> RTnet and udp/rtpacket/loopback etc. modules are loaded by the test >> cases. See testsuite/smokey/net_common/setup.c. > > Actually ,rtnet should be loaded before smokey_net_setup run or else err = > cobalt_corectl(_CC_COBALT_GET_NET_CONFIG, > _config, sizeof(net_config)); would return > -EINVAL directly in smokey_net_setup and there is no chance to go ahead > because no cobalt_add_config_chain was called at that time if rtnet module > was not loaded but it is only called by rtnet_corectl_register per my > understanding. OK, now I understand (and was able reproduce). Two options to solve that: - add loading of the rtnet module to setup.c - make the rtnet core a built-in I'm leaning towards the first option. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: about RTnet* smokey test skipped issue on Qemu
On 03.08.21 08:46, Chen, Hongzhan wrote: > > >> -Original Message- >> From: Jan Kiszka >> Sent: Tuesday, August 3, 2021 12:59 PM >> To: Chen, Hongzhan ; xenomai@xenomai.org >> Subject: Re: about RTnet* smokey test skipped issue on Qemu >> >> On 03.08.21 06:31, Chen, Hongzhan wrote: >>> Firstly, I found that all smokey tests including RTnet* pass on bare >>> metal x86 platform >>> but three RTnet* related test items are skipped on Qemu. After further >>> debug, actually there is >>> no supported rtnet device found on Qemu with current network setting >>> when xenomai image >>> is running over even we already enable all supported rtnet devices on >>> xenomai so that >>> the test is skipped on qemu. >>> >>> After I replace virtio-net-pci with e1000 device like [1] patch , >>> rt_e1000 and rtnet modules >>> would be automatically loaded by udevd so that rtnet* test item can go >>> on without test skipped issue. >> >> By default, we are only doing loopback tests in smokey, nothing that >> requires a real NIC driver to be loaded. These are the modules loaded >> during a test with udp: >> >> Module Size Used by >> rtudp 24576 0 >> rtipv4 49152 1 rtudp >> rt_loopback16384 1 >> rtnet 81920 3 rtipv4,rtudp,rt_loopback >> >> You can set the rtnet_driver and rtnet_interface parameters to switch to >> real NICs, but that is not happening during a default xeno-test run. > > The problem is that rtnet module is not loaded individually by current system > but because > RT NIC device driver module depend on it and then rtnet module will be loaded > when specific > RT NIC device driver module is modprobed after triggered by udev service. > That means > We have to add and modify something to explicitly load rtnet module by > default when system bootup > if we do not want to depends on real NIC in our case. For example we may add > corresponding *.conf > like [3] to make rtnet load automatically when system bootup in our case? > RTnet and udp/rtpacket/loopback etc. modules are loaded by the test cases. See testsuite/smokey/net_common/setup.c. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: about RTnet* smokey test skipped issue on Qemu
On 03.08.21 06:31, Chen, Hongzhan wrote: > Firstly, I found that all smokey tests including RTnet* pass on bare > metal x86 platform > but three RTnet* related test items are skipped on Qemu. After further > debug, actually there is > no supported rtnet device found on Qemu with current network setting > when xenomai image > is running over even we already enable all supported rtnet devices on > xenomai so that > the test is skipped on qemu. > > After I replace virtio-net-pci with e1000 device like [1] patch , > rt_e1000 and rtnet modules > would be automatically loaded by udevd so that rtnet* test item can go > on without test skipped issue. By default, we are only doing loopback tests in smokey, nothing that requires a real NIC driver to be loaded. These are the modules loaded during a test with udp: Module Size Used by rtudp 24576 0 rtipv4 49152 1 rtudp rt_loopback16384 1 rtnet 81920 3 rtipv4,rtudp,rt_loopback You can set the rtnet_driver and rtnet_interface parameters to switch to real NICs, but that is not happening during a default xeno-test run. > But system report error like [2] because there is late packet. It > seems that bad rtnet performance > with virtual network on Qemu may block our RTnet smokey test? Any > Suggestions? > There is open issue https://gitlab.com/Xenomai/xenomai-hacker-space/-/issues/13 on that. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
[PATCH v3] cobalt: Sort out virtual vs. real pids
From: Jan Kiszka
Make sure that we consider all pids taken from or sent to userspace via
syscalls as virtual. That means converting them to global pids before
processing them or converting them back to virtual pids in the caller's
namespace before reporting them. We also need to switch thread hashing
from vpids to real pids.
Not converted is the procfs interface as this one continues to provide
only a global view on cobalt objects and associated pids.
A few syscall tracepoints that report the vpid as passed down from
userspace get adjusted in their output so that it is clear that no
global pid is shown.
Signed-off-by: Jan Kiszka
---
Changes in v3:
- handle process-local thread lookups correctly (hopefully)
This is in next for a while and ran several test cycles. Even if we
should have remaining issues under pid namespaces, we should not have
regressions in the normal cases.
include/cobalt/kernel/thread.h | 2 ++
kernel/cobalt/posix/event.c| 2 +-
kernel/cobalt/posix/mqueue.c | 2 +-
kernel/cobalt/posix/process.c | 14 ++
kernel/cobalt/posix/process.h | 2 ++
kernel/cobalt/posix/sched.c| 10 ++
kernel/cobalt/posix/sem.c | 2 +-
kernel/cobalt/posix/signal.c | 10 ++
kernel/cobalt/posix/thread.c | 18 ++
kernel/cobalt/posix/thread.h | 2 +-
kernel/cobalt/thread.c | 10 ++
kernel/cobalt/trace/cobalt-posix.h | 4 ++--
12 files changed, 56 insertions(+), 22 deletions(-)
diff --git a/include/cobalt/kernel/thread.h b/include/cobalt/kernel/thread.h
index b79cb84296..4c8a0b9f2a 100644
--- a/include/cobalt/kernel/thread.h
+++ b/include/cobalt/kernel/thread.h
@@ -450,6 +450,8 @@ char *xnthread_format_status(unsigned long status,
pid_t xnthread_host_pid(struct xnthread *thread);
+pid_t xnthread_host_vpid(struct xnthread *thread);
+
int xnthread_set_clock(struct xnthread *thread,
struct xnclock *newclock);
diff --git a/kernel/cobalt/posix/event.c b/kernel/cobalt/posix/event.c
index 3712154f53..5871106301 100644
--- a/kernel/cobalt/posix/event.c
+++ b/kernel/cobalt/posix/event.c
@@ -352,7 +352,7 @@ COBALT_SYSCALL(event_inquire, current,
xnsynch_for_each_sleeper(thread, >synch) {
if (nrwait >= nrpids)
break;
- t[nrwait++] = xnthread_host_pid(thread);
+ t[nrwait++] = xnthread_host_vpid(thread);
}
}
diff --git a/kernel/cobalt/posix/mqueue.c b/kernel/cobalt/posix/mqueue.c
index dd8acd55b0..fcde87a077 100644
--- a/kernel/cobalt/posix/mqueue.c
+++ b/kernel/cobalt/posix/mqueue.c
@@ -720,7 +720,7 @@ mq_notify(struct cobalt_mqd *mqd, unsigned index, const
struct sigevent *evp)
* receiver's namespaces. We pass the receiver's creds
* into the init namespace instead.
*/
- mq->si.si_pid = task_pid_nr(current);
+ mq->si.si_pid = task_pid_vnr(current);
mq->si.si_uid = get_current_uuid();
}
diff --git a/kernel/cobalt/posix/process.c b/kernel/cobalt/posix/process.c
index 1f059ad830..98b7df33fb 100644
--- a/kernel/cobalt/posix/process.c
+++ b/kernel/cobalt/posix/process.c
@@ -975,6 +975,20 @@ int cobalt_handle_cleanup_event(struct mm_struct *mm)
return KEVENT_PROPAGATE;
}
+pid_t cobalt_vpid2pid_nr(pid_t vpid)
+{
+ struct pid *pid;
+ pid_t nr = -1;
+
+ rcu_read_lock();
+ pid = find_vpid(vpid);
+ if (pid)
+ nr = pid_nr(pid);
+ rcu_read_unlock();
+
+ return nr;
+}
+
static int attach_process(struct cobalt_process *process)
{
struct cobalt_ppd *p = >sys_ppd;
diff --git a/kernel/cobalt/posix/process.h b/kernel/cobalt/posix/process.h
index 279707a680..46dff43b7a 100644
--- a/kernel/cobalt/posix/process.h
+++ b/kernel/cobalt/posix/process.h
@@ -175,4 +175,6 @@ int cobalt_handle_cleanup_event(struct mm_struct *mm);
int cobalt_handle_user_return(struct task_struct *task);
+pid_t cobalt_vpid2pid_nr(pid_t vpid);
+
#endif /* !_COBALT_POSIX_PROCESS_H */
diff --git a/kernel/cobalt/posix/sched.c b/kernel/cobalt/posix/sched.c
index 4fd9c2b46e..26259fbd3f 100644
--- a/kernel/cobalt/posix/sched.c
+++ b/kernel/cobalt/posix/sched.c
@@ -736,7 +736,7 @@ COBALT_SYSCALL(sched_weightprio, current,
return __cobalt_sched_weightprio(policy, _ex);
}
-int cobalt_sched_setscheduler_ex(pid_t pid,
+int cobalt_sched_setscheduler_ex(pid_t vpid,
int policy,
const struct sched_param_ex *param_ex,
__u32 __user *u_winoff,
@@ -747,9 +747,11 @@ int cobalt_sched_setscheduler_ex(pid_t pid,
int ret, promoted = 0;
spl_t s;
- trace_cobalt_sched_setscheduler(pid, policy, param_ex);
+ trace_cobalt_sched_setscheduler(vpid, policy, param_ex);
+
+
Re: [PATCH v2] cobalt: Sort out virtual vs. real pids
On 22.07.21 16:15, Jan Kiszka via Xenomai wrote:
> On 22.07.21 14:07, MONTET Julien wrote:
>> Hi,
>>
>> I tested all of your patches last week, and it did not change anything.
>> Compiling the Xenomai libraries directly on Docker didn't solve the issue.
>>
>> The Xenomai timer seems to work, I can loop on it and print the time
>> (but it was also working before).
>>
>> Unfortunately I am still stuck on rt_task_wait_period(...).
>>
>
> That might be becaues I was looking at Marco's test case so as he shared
> his...
>
> I starred at the code again, and this on top may help (and also fix
> signaling by udd):
>
> diff --git a/kernel/cobalt/posix/thread.c b/kernel/cobalt/posix/thread.c
> index 2f3ea1dec4..6a79fecb5c 100644
> --- a/kernel/cobalt/posix/thread.c
> +++ b/kernel/cobalt/posix/thread.c
> @@ -176,11 +176,11 @@ struct cobalt_thread *cobalt_thread_find(pid_t pid) /*
> nklocked, IRQs off */
> }
> EXPORT_SYMBOL_GPL(cobalt_thread_find);
>
> -struct cobalt_thread *cobalt_thread_find_local(pid_t pid) /* nklocked, IRQs
> off */
> +struct cobalt_thread *cobalt_thread_find_local(pid_t vpid) /* nklocked, IRQs
> off */
> {
> struct cobalt_thread *thread;
>
> - thread = cobalt_thread_find(pid);
> + thread = cobalt_thread_find(cobalt_vpid2pid_nr(vpid));
> if (thread == NULL || thread->hkey.mm != current->mm)
> return NULL;
>
> diff --git a/kernel/cobalt/posix/thread.h b/kernel/cobalt/posix/thread.h
> index 51be372a7a..66e3a88223 100644
> --- a/kernel/cobalt/posix/thread.h
> +++ b/kernel/cobalt/posix/thread.h
> @@ -146,7 +146,7 @@ int cobalt_thread_setschedprio(unsigned long pth,
>
> struct cobalt_thread *cobalt_thread_find(pid_t pid);
>
> -struct cobalt_thread *cobalt_thread_find_local(pid_t pid);
> +struct cobalt_thread *cobalt_thread_find_local(pid_t vpid);
>
> struct cobalt_thread *cobalt_thread_lookup(unsigned long pth);
>
Did you have a chance to test this? It's now also part of next. I'll
send out v3 for reference as well.
>
>> In any case, I will keep you informed if I achieve to implement this or
>> find my issue.
>> Do not hesitate to suggest debugging tools/methods, I will be pleased to
>> give you feedback on the results.
>>
>
> BTW, there is the bad news that threadobj_stat() uses /proc to retrieve
> thread statistics. That will remain broken over pid namespaces until we
> virtualize /proc as well. That affects rt_task_inquire and the registry
> service /wrt tasks.
>
Checked again: threadobj_stat really only uses regular /proc//stat,
and that is virtualized by the kernel. However, the registry daemon does
use /proc/xenomai/sched/threads.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH 0/7] Update fec driver for xenomai 3 and linux kernel 5.4 and add I.MX8 support
On 02.08.21 10:14, Jan Kiszka via Xenomai wrote: > On 28.07.21 09:27, Jean-Baptiste Trédez via Xenomai wrote: >> Current fec driver does not build on xenomai 3 and on recent kernel (ex : >> 5.4). This driver was completely rewritten on mainline kernel. >> This work uses previous work from Gilles Chanteperdrix and Philippe Gerum >> (rebase over original driver from kernel 4.14.85 for xenomai 3) (patch 1 to >> 3), update the driver to 5.4 kernel and i.MX8Q (patch 4 and 5), fix buffer >> free issue (patch 6) and reduce latency (patch 7). >> This set was tested on i.MX8Q target >> >> Arnaud Bouvet (1): >> net/drivers: fec: remove 1ms latency on frames reception >> >> Gilles Chanteperdrix (2): >> utils/net: rtifconfig: display device name untruncated >> net/stack: rtskb: increase buffer size >> >> Jean-Baptiste Trédez (3): >> net/drivers: fec: update from linux kernel 5.4 and NXP I.MX8 >> Kconfig : enable fec for ARM64 build >> net/drivers: fec: fix dev_kfree_rtskb on wrong buffer >> >> Philippe Gerum (1): >> net/drivers: fec: rebase over original driver from kernel 4.14.85 >> >> kernel/drivers/net/drivers/Kconfig| 11 +- >> kernel/drivers/net/drivers/Makefile |6 +- >> kernel/drivers/net/drivers/fec.c | 1859 --- >> kernel/drivers/net/drivers/freescale/Makefile |5 + >> kernel/drivers/net/drivers/freescale/fec.h| 642 +++ >> .../drivers/net/drivers/freescale/fec_main.c | 4676 + >> .../drivers/net/drivers/freescale/fec_ptp.c | 638 +++ >> kernel/drivers/net/drivers/rt_fec.h | 153 - >> kernel/drivers/net/stack/include/rtskb.h |2 +- >> utils/net/rtifconfig.c|2 +- >> 10 files changed, 5975 insertions(+), 2019 deletions(-) >> delete mode 100644 kernel/drivers/net/drivers/fec.c >> create mode 100644 kernel/drivers/net/drivers/freescale/Makefile >> create mode 100644 kernel/drivers/net/drivers/freescale/fec.h >> create mode 100644 kernel/drivers/net/drivers/freescale/fec_main.c >> create mode 100644 kernel/drivers/net/drivers/freescale/fec_ptp.c >> delete mode 100644 kernel/drivers/net/drivers/rt_fec.h >> > > Thanks, applied to next. > > Patch 3 didn't apply directly, but the conflict was in the to-be-deleted > file. Please always make sure to check if your patches need rebasing. > > In addition, I'll add the driver to CI so that we are building it regularly. > Patch 3-7 have been removed again. CI is left "armed", though the driver is not built because the arm-defconfig does not enable its dependencies (arm64 did). We need a rebase and build fixes for upstream-based I-pipe/Dovetail kernels. 5.4 and 5.10 had problems IIRC. You can find logs under [1][2]. Jan [1] https://gitlab.com/Xenomai/xenomai-hacker-space/-/pipelines/346383552 [2] https://gitlab.com/Xenomai/xenomai-hacker-space/-/pipelines/346415211 -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH v4 5/5] y2038: testsuite/smokey/y2038: Adding test cases for mutex_timedlock64()
On 02.08.21 12:29, Florian Bezdeka wrote:
> On 02.08.21 12:27, Jan Kiszka wrote:
>> On 02.08.21 12:06, Florian Bezdeka wrote:
>>> On 02.08.21 11:45, Jan Kiszka wrote:
On 31.07.21 09:08, Florian Bezdeka wrote:
> This patch was based on the patch sent out by Song and reworked.
> Especially
> - switched from CLOCK_MONOTONIC to CLOCK_REALTIME
> According to POSIX this service is based on CLOCK_REALTIME
>
> - Fixed some mutex leaks / missing pthread_mutex_destroy()
>
> - Removed some magic numbers used for making sure the syscall does
> not return too early
>
> - Fixed several mutex deadlocks. Once mutex_timedlock() was
> successful following calls will deadlock (as long as no special
> DEADLOCK mutex is being used)
>
> Signed-off-by: Florian Bezdeka
> ---
> testsuite/smokey/y2038/syscall-tests.c | 187 +
> 1 file changed, 187 insertions(+)
>
> diff --git a/testsuite/smokey/y2038/syscall-tests.c
> b/testsuite/smokey/y2038/syscall-tests.c
> index 08506d086..2e8add864 100644
> --- a/testsuite/smokey/y2038/syscall-tests.c
> +++ b/testsuite/smokey/y2038/syscall-tests.c
> @@ -115,6 +115,45 @@ static inline bool ts_less(const struct
> xn_timespec64 *a,
> return false;
> }
>
> +/**
> + * Simple helper data structure for holding a thread context
> + */
> +struct thread_context {
> + int sc_nr;
> + pthread_mutex_t *mutex;
> + struct xn_timespec64 *ts;
> + bool timedwait_timecheck;
> +};
> +
> +/**
> + * Start the supplied function inside a separate thread, wait for
> completion
> + * and check the thread return value.
> + *
> + * @param thread The thread entry point
> + * @param arg The thread arguments
> + * @param exp_result The expected return value
> + *
> + * @return 0 if the thread reported @exp_result as return value, the
> thread's
> + * return value otherwise
> + */
> +static int run_thread(void *(*thread)(void *), void *arg, int exp_result)
> +{
> + pthread_t tid;
> + void *status;
> + long res;
> + int ret;
> +
> + if (!__T(ret, pthread_create(, NULL, thread, arg)))
> + return ret;
> +
> + if (!__T(ret, pthread_join(tid, )))
> + return ret;
> +
> + res = *((long *) status);
> +
> + return (res == exp_result) ? 0 : ret;
> +}
> +
> static int test_sc_cobalt_sem_timedwait64(void)
> {
> int ret;
> @@ -404,6 +443,150 @@ static int test_sc_cobalt_clock_adjtime64(void)
> return 0;
> }
>
> +static void *timedlock64_thread(void *arg)
> +{
> + struct thread_context *ctx = (struct thread_context *) arg;
> + struct xn_timespec64 t1, t2;
> + struct timespec ts_nat;
> + int ret;
> +
> + if (ctx->timedwait_timecheck) {
> + if (!__T(ret, clock_gettime(CLOCK_REALTIME, _nat)))
> + return (void *)(long)ret;
> +
> + t1.tv_sec = ts_nat.tv_sec;
> + t1.tv_nsec = ts_nat.tv_nsec;
> + ts_add_ns(, ctx->ts->tv_nsec);
> + ts_add_ns(, ctx->ts->tv_sec * NSEC_PER_SEC);
> + }
> +
> + ret = XENOMAI_SYSCALL2(ctx->sc_nr, ctx->mutex, (void *) ctx->ts);
> + if (ret)
> + return (void *)(long)ret;
> +
> + if (ctx->timedwait_timecheck) {
> + if (!__T(ret, clock_gettime(CLOCK_REALTIME, _nat)))
> + return (void *)(long)ret;
> +
> + t2.tv_sec = ts_nat.tv_sec;
> + t2.tv_nsec = ts_nat.tv_nsec;
> +
> + if (ts_less(, ))
> + smokey_warning("mutex_timedlock64 returned to early!\n"
> +"Expected wakeup at: %lld sec %lld
> nsec\n"
> +"Back at : %lld sec %lld
> nsec\n",
> +t1.tv_sec, t1.tv_nsec, t2.tv_sec,
> +t2.tv_nsec);
> + }
> +
> + return (void *)(long)pthread_mutex_unlock(ctx->mutex);
> +}
> +
> +static int test_sc_cobalt_mutex_timedlock64(void)
> +{
> + int ret;
> + pthread_mutex_t mutex;
> + int sc_nr = sc_cobalt_mutex_timedlock64;
> + struct xn_timespec64 ts64;
> + struct thread_context ctx = {0};
> +
> + ret = pthread_mutex_init(, NULL);
> +
> + /* Make sure we don't crash because of NULL pointers */
> + ret = XENOMAI_SYSCALL2(sc_nr, NULL, NULL);
> + if (ret == -ENOSYS) {
> + smokey_note("mutex_timedlock64: skipped. (no kernel support)");
> + return 0; // Not implemented, nothing to test, success
> + }
> + if (!smokey_assert(ret == -EINVAL))
> + return ret ? ret : -EINVAL;
> +
> + /*
> + * mutex can be taken immediately, no need to
[xenomai-images][RFC][PATCH] ci: Switch to Google nameserver
From: Jan Kiszka
This is a temporary hack: Our AWS runners see a lot of DNS errors for
deb.debian.org. Let's see if they are less with this server.
Signed-off-by: Jan Kiszka
---
Seems to work, though only one run passed so far. Go this way for now?
ci/gitlab-ci-base.yml | 1 +
1 file changed, 1 insertion(+)
diff --git a/ci/gitlab-ci-base.yml b/ci/gitlab-ci-base.yml
index 2638dec..ce9c800 100644
--- a/ci/gitlab-ci-base.yml
+++ b/ci/gitlab-ci-base.yml
@@ -39,6 +39,7 @@ default:
extends: .add-proxy-config
stage: build
script:
+- sudo sh -c "echo 'nameserver 8.8.8.8' > /etc/resolv.conf"
- echo "Building
kas.yml:board-${TARGET}.yml${XENOMAI_BUILD_OPTION}${LINUX_BUILD_OPTION}${BUILD_OPTIONS}:opt-debug.yml"
- kas build
kas.yml:board-${TARGET}.yml${XENOMAI_BUILD_OPTION}${LINUX_BUILD_OPTION}${BUILD_OPTIONS}:opt-debug.yml
- if [ -n "${USE_S3_BUCKET}" ]; then scripts/deploy_to_aws.sh ${TARGET}; fi
--
2.31.1
Re: Large gpio interrupt latency
On 23.07.21 10:04, Philippe Gerum wrote:
>
> François Legal writes:
>
>> Le Mardi, Juin 22, 2021 12:07 CEST, Philippe Gerum a
>> écrit:
>>
>>>
>>> Jan Kiszka writes:
>>>
On 22.06.21 11:31, Philippe Gerum wrote:
>
> Jan Kiszka writes:
>
>> On 22.06.21 10:37, Philippe Gerum wrote:
>>>
>>> Jan Kiszka writes:
>>>
On 22.06.21 09:49, Julien Blanc via Xenomai wrote:
> Le mardi 22 juin 2021 à 09:38 +0200, Philippe Gerum via Xenomai a
> écrit :
>>
>> With this in mind, assuming that we have previously sanitized the
>> clock
>> identifier, doing this:
>>
>> #define get_timestamp(__clock) \
>> ({ (__clock) == CLOCK_MONOTONIC ? rtdm_clock_read_monotonic() :
>> rtdm_clock_read(); })
>>
>> may end up being faster than:
>>
>> xnticks_t (*__get_timestamp)(clockid_t clock);
>> #define get_timestamp(__clock) __get_timestamp(__clock)
>
> Is really a runtime switch necessary ? Since relying on the realtime
> clock is inherently broken, my understanding is that it should be kept
> as compatibility purpose only.
Again: The real-time clock is not a broken clock per se. It is the
basis
of many services (POSIX...) and - if managed properly - it is as sound
clock to build upon. If you need absolute timestamps to calculate
absolute timeouts (like users of the existing code do), this is the
clock to go, also in future versions.
>>>
>>> Definitely correct, for timeout specs.
>>>
Also if you want to use
PTP-sync'ed clocks across systems (TSN...), it is THE way to go. At
that
point, monotonic timestamps will lose relevance in practice.
>>>
>>> We are not there yet. So, let's all agree than we need both clock bases,
>>> and a flexible way to select the current one.
>>>
>>
>> What's still missing with Dovetail and a Linux-operated PTP sync for the
>> main clocksource? Hardending of software-based sync paths? Where it's
>> hw-based, that should already be fine (latest Intel SOCs).
>>
>
> Again, we have two use cases: absolute timeouts based on a common epoch
> which may change, and delays. We do know PTP with hw-based support is an
> efficient way to maintain consistency among users of the former,
> nevertheless we still need to express/measure strict delays in other
> cases. So, we do need both clocks.
>
If you need cross-system event stamping, the unsync'ed monotonic clock
is the wrong choice as well.
>>>
>>> As usual, it's a trade-off, a risk assessment between observing
>>> non-coherent SMP readings and warp jumps. This is a call an application
>>> should be allowed to make, I see no reason to impose a solution
>>> arbitrarily without knowing what the app actually wants to do.
>>>
Again: What is missing to use PTP-sync'ed clock-realtime under Dovetail
today?
>>>
>>> Nothing when it comes to reading timestamps, via the NMI-safe
>>> ktime_get_real_fast_ns() service (updates will be non-preemptible while
>>> holding the seqlock).
>>>
>>
>> Hi there,
>>
>> to move this topic forward, I propose to create a patch to replace the call
>> to rtdm_clock_read_monotonic by rtdm_clock_read in gpio_core.c,
>> plus another one that would introduce the possibility to switch between
>> those 2 different clocks.
>>
>
> There is no timed wait calls in this driver which might benefit from a
> general "clock switch" feature, is it? So what about either of these
> options instead:
>
> - adding GPIO_RTIOC_TS_REAL only for the purpose of retrieving
> timestamps. That would leave the existing client code unaffected, and
> _might_ be backported to the stable tree since this is a mere
> extension of the ABI.
>
> - renaming the current ioctl request to GPIO_RTIOC_GET_TS_MONO, and
> provide GPIO_RTIOC_GET_TS[_REAL] based on rtdm_clock_read() in the
> same move. That would force the existing client code to revisit their
> implementation wrt retrieving a timestamp, providing the desired
> alternative between mono/real too. That sort of change would have to
> wait for 3.2 though.
>
How is the status here? This topic should really be address before the
3.2 release.
Thanks,
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
[PATCH] drivers/serial: rt_imx_uart: Fix compiler warning
From: Jan Kiszka
Addresses "cast from pointer to integer of different size".
Signed-off-by: Jan Kiszka
---
kernel/drivers/serial/rt_imx_uart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/drivers/serial/rt_imx_uart.c
b/kernel/drivers/serial/rt_imx_uart.c
index 6894c1c29c..94efe873a6 100644
--- a/kernel/drivers/serial/rt_imx_uart.c
+++ b/kernel/drivers/serial/rt_imx_uart.c
@@ -1158,7 +1158,7 @@ wait_unlock_out:
case RTSER_RTIOC_BREAK_CTL: {
rtdm_lock_get_irqsave(>lock, lock_ctx);
- rt_imx_uart_break_ctl(ctx, (int)arg);
+ rt_imx_uart_break_ctl(ctx, (unsigned long)arg);
rtdm_lock_put_irqrestore(>lock, lock_ctx);
break;
}
--
2.31.1
Re: [PATCH v4 5/5] y2038: testsuite/smokey/y2038: Adding test cases for mutex_timedlock64()
On 02.08.21 12:06, Florian Bezdeka wrote:
> On 02.08.21 11:45, Jan Kiszka wrote:
>> On 31.07.21 09:08, Florian Bezdeka wrote:
>>> This patch was based on the patch sent out by Song and reworked.
>>> Especially
>>> - switched from CLOCK_MONOTONIC to CLOCK_REALTIME
>>> According to POSIX this service is based on CLOCK_REALTIME
>>>
>>> - Fixed some mutex leaks / missing pthread_mutex_destroy()
>>>
>>> - Removed some magic numbers used for making sure the syscall does
>>> not return too early
>>>
>>> - Fixed several mutex deadlocks. Once mutex_timedlock() was
>>> successful following calls will deadlock (as long as no special
>>> DEADLOCK mutex is being used)
>>>
>>> Signed-off-by: Florian Bezdeka
>>> ---
>>> testsuite/smokey/y2038/syscall-tests.c | 187 +
>>> 1 file changed, 187 insertions(+)
>>>
>>> diff --git a/testsuite/smokey/y2038/syscall-tests.c
>>> b/testsuite/smokey/y2038/syscall-tests.c
>>> index 08506d086..2e8add864 100644
>>> --- a/testsuite/smokey/y2038/syscall-tests.c
>>> +++ b/testsuite/smokey/y2038/syscall-tests.c
>>> @@ -115,6 +115,45 @@ static inline bool ts_less(const struct xn_timespec64
>>> *a,
>>> return false;
>>> }
>>>
>>> +/**
>>> + * Simple helper data structure for holding a thread context
>>> + */
>>> +struct thread_context {
>>> + int sc_nr;
>>> + pthread_mutex_t *mutex;
>>> + struct xn_timespec64 *ts;
>>> + bool timedwait_timecheck;
>>> +};
>>> +
>>> +/**
>>> + * Start the supplied function inside a separate thread, wait for
>>> completion
>>> + * and check the thread return value.
>>> + *
>>> + * @param thread The thread entry point
>>> + * @param arg The thread arguments
>>> + * @param exp_result The expected return value
>>> + *
>>> + * @return 0 if the thread reported @exp_result as return value, the
>>> thread's
>>> + * return value otherwise
>>> + */
>>> +static int run_thread(void *(*thread)(void *), void *arg, int exp_result)
>>> +{
>>> + pthread_t tid;
>>> + void *status;
>>> + long res;
>>> + int ret;
>>> +
>>> + if (!__T(ret, pthread_create(, NULL, thread, arg)))
>>> + return ret;
>>> +
>>> + if (!__T(ret, pthread_join(tid, )))
>>> + return ret;
>>> +
>>> + res = *((long *) status);
>>> +
>>> + return (res == exp_result) ? 0 : ret;
>>> +}
>>> +
>>> static int test_sc_cobalt_sem_timedwait64(void)
>>> {
>>> int ret;
>>> @@ -404,6 +443,150 @@ static int test_sc_cobalt_clock_adjtime64(void)
>>> return 0;
>>> }
>>>
>>> +static void *timedlock64_thread(void *arg)
>>> +{
>>> + struct thread_context *ctx = (struct thread_context *) arg;
>>> + struct xn_timespec64 t1, t2;
>>> + struct timespec ts_nat;
>>> + int ret;
>>> +
>>> + if (ctx->timedwait_timecheck) {
>>> + if (!__T(ret, clock_gettime(CLOCK_REALTIME, _nat)))
>>> + return (void *)(long)ret;
>>> +
>>> + t1.tv_sec = ts_nat.tv_sec;
>>> + t1.tv_nsec = ts_nat.tv_nsec;
>>> + ts_add_ns(, ctx->ts->tv_nsec);
>>> + ts_add_ns(, ctx->ts->tv_sec * NSEC_PER_SEC);
>>> + }
>>> +
>>> + ret = XENOMAI_SYSCALL2(ctx->sc_nr, ctx->mutex, (void *) ctx->ts);
>>> + if (ret)
>>> + return (void *)(long)ret;
>>> +
>>> + if (ctx->timedwait_timecheck) {
>>> + if (!__T(ret, clock_gettime(CLOCK_REALTIME, _nat)))
>>> + return (void *)(long)ret;
>>> +
>>> + t2.tv_sec = ts_nat.tv_sec;
>>> + t2.tv_nsec = ts_nat.tv_nsec;
>>> +
>>> + if (ts_less(, ))
>>> + smokey_warning("mutex_timedlock64 returned to early!\n"
>>> + "Expected wakeup at: %lld sec %lld
>>> nsec\n"
>>> + "Back at : %lld sec %lld
>>> nsec\n",
>>> + t1.tv_sec, t1.tv_nsec, t2.tv_sec,
>>> + t2.tv_nsec);
>>> + }
>>> +
>>> + return (void *)(long)pthread_mutex_unlock(ctx->mutex);
>>> +}
>>> +
>>> +static int test_sc_cobalt_mutex_timedlock64(void)
>>> +{
>>> + int ret;
>>> + pthread_mutex_t mutex;
>>> + int sc_nr = sc_cobalt_mutex_timedlock64;
>>> + struct xn_timespec64 ts64;
>>> + struct thread_context ctx = {0};
>>> +
>>> + ret = pthread_mutex_init(, NULL);
>>> +
>>> + /* Make sure we don't crash because of NULL pointers */
>>> + ret = XENOMAI_SYSCALL2(sc_nr, NULL, NULL);
>>> + if (ret == -ENOSYS) {
>>> + smokey_note("mutex_timedlock64: skipped. (no kernel support)");
>>> + return 0; // Not implemented, nothing to test, success
>>> + }
>>> + if (!smokey_assert(ret == -EINVAL))
>>> + return ret ? ret : -EINVAL;
>>> +
>>> + /*
>>> +* mutex can be taken immediately, no need to validate
>>> +* NULL should be allowed
>>> +*/
>>> + ret = XENOMAI_SYSCALL2(sc_nr, , NULL);
>>> + if (!smokey_assert(!ret))
>>> + return ret;
>>> +
>>> + if (!__T(ret, pthread_mutex_unlock()))
>>> + return ret;
Re: [PATCH 4/7] net/drivers: fec: update from linux kernel 5.4 and NXP I.MX8
On 02.08.21 11:09, Jan Kiszka via Xenomai wrote:
> On 28.07.21 09:27, Jean-Baptiste Trédez via Xenomai wrote:
>> Signed-off-by: Jean-Baptiste Trédez
>>
>>
>> Content :
>>
>> net: fec: add phy_reset_after_clk_enable() support
>>
>> Some PHYs (for example the SMSC LAN8710/LAN8720) doesn't allow turning
>> the refclk on and off again during operation (according to their
>> datasheet). Nonetheless exactly this behaviour was introduced for power
>> saving reasons by commit e8fcfcd5684a ("net: fec: optimize the clock
>> management to save power").
>> Therefore add support for the phy_reset_after_clk_enable function from
>> phylib to mitigate this issue.
>>
>> Generally speaking this issue is only relevant if the ref clk for the
>> PHY is generated by the SoC and therefore the PHY is configured to
>> "REF_CLK In Mode". In our specific case (PCB) this problem does occur at
>> about every 10th to 50th POR of an LAN8710 connected to an i.MX6SOLO
>> SoC. The typical symptom of this problem is a "swinging" ethernet link.
>> Similar issues were reported by users of the NXP forum:
>> https://community.nxp.com/thread/389902
>> https://community.nxp.com/message/309354
>> With this patch applied the issue didn't occur for at least a few
>> hundret PORs of our board.
>>
>> Fixes: e8fcfcd5684a ("net: fec: optimize the clock management to save power")
>> Signed-off-by: Richard Leitner
>> Signed-off-by: David S. Miller
>>
>> --
>>
>> net: fec: add necessary defines to work on ARM64
>>
>> The i.MX8 is a ARMv8 based SoC, that uses the same FEC IP as the
>> earlier, ARMv7 based, i.MX SoCs. Allow the driver to work on ARM64.
>>
>> Signed-off-by: Lucas Stach
>> Acked-by: Fugang Duan
>> Signed-off-by: David S. Miller
>>
>> --
>>
>> drivers: net: Remove device_node checks with of_mdiobus_register()
>>
>> A number of drivers have the following pattern:
>>
>> if (np)
>> of_mdiobus_register()
>> else
>> mdiobus_register()
>>
>> which the implementation of of_mdiobus_register() now takes care of.
>> Remove that pattern in drivers that strictly adhere to it.
>>
>> Signed-off-by: Florian Fainelli
>> Reviewed-by: Grygorii Strashko
>> Reviewed-by: Fugang Duan
>> Reviewed-by: Antoine Tenart
>> Reviewed-by: Jose Abreu
>> Signed-off-by: David S. Miller
>>
>> --
>>
>> net: ethernet: freescale: Allow FEC with COMPILE_TEST
>>
>> The Freescale FEC driver builds fine with COMPILE_TEST, so make that
>> possible.
>>
>> Signed-off-by: Florian Fainelli
>> Signed-off-by: David S. Miller
>>
>> --
>>
>> net: fec: Add a SPDX identifier
>>
>> Currently there is no license information in the header of
>> this file.
>>
>> The MODULE_LICENSE field contains ("GPL"), which means
>> GNU Public License v2 or later, so add a corresponding
>> SPDX license identifier.
>>
>> Signed-off-by: Fabio Estevam
>> Acked-by: Fugang Duan
>> Signed-off-by: David S. Miller
>>
>> --
>>
>> net: ethernet: freescale: Use generic CRC32 implementation
>>
>> Use generic kernel CRC32 implementation because it:
>> 1. Should be faster (uses lookup tables),
>> 2. Removes duplicated CRC generation code,
>> 3. Uses well-proven algorithm instead of coding it one more time.
>>
>> Suggested-by: Eric Biggers
>> Signed-off-by: Krzysztof Kozlowski
>> Signed-off-by: David S. Miller
>>
>> --
>>
>> net: fec: check DMA addressing limitations
>>
>> Check DMA addressing limitations as suggested by the DMA API
>> how-to. This does not fix a particular issue seen but is
>> considered good style.
>>
>> Signed-off-by: Stefan Agner
>> Acked-by: Fugang Duan
>> Reviewed-by: Robin Murphy
>> Signed-off-by: David S. Miller
>>
>> --
>>
>> net: ethernet: Use phy_set_max_speed() to limit advertised speed
>>
>> Many Ethernet MAC drivers want to limit the PHY to only advertise a
>> maximum speed of 100Mbs or 1Gbps. Rather than using a mask, make use
>> of the helper function phy_set_max_speed().
>>
>> Signed-off-by: Andrew Lunn
>> Reviewed-by: Florian Fainelli
>> Signed-off-by: David S. Miller
>>
>> --
>>
>> net: ethernet: Add helper to remove a supported link m
Re: [PATCH v4 5/5] y2038: testsuite/smokey/y2038: Adding test cases for mutex_timedlock64()
On 31.07.21 09:08, Florian Bezdeka wrote:
> This patch was based on the patch sent out by Song and reworked.
> Especially
> - switched from CLOCK_MONOTONIC to CLOCK_REALTIME
> According to POSIX this service is based on CLOCK_REALTIME
>
> - Fixed some mutex leaks / missing pthread_mutex_destroy()
>
> - Removed some magic numbers used for making sure the syscall does
> not return too early
>
> - Fixed several mutex deadlocks. Once mutex_timedlock() was
> successful following calls will deadlock (as long as no special
> DEADLOCK mutex is being used)
>
> Signed-off-by: Florian Bezdeka
> ---
> testsuite/smokey/y2038/syscall-tests.c | 187 +
> 1 file changed, 187 insertions(+)
>
> diff --git a/testsuite/smokey/y2038/syscall-tests.c
> b/testsuite/smokey/y2038/syscall-tests.c
> index 08506d086..2e8add864 100644
> --- a/testsuite/smokey/y2038/syscall-tests.c
> +++ b/testsuite/smokey/y2038/syscall-tests.c
> @@ -115,6 +115,45 @@ static inline bool ts_less(const struct xn_timespec64 *a,
> return false;
> }
>
> +/**
> + * Simple helper data structure for holding a thread context
> + */
> +struct thread_context {
> + int sc_nr;
> + pthread_mutex_t *mutex;
> + struct xn_timespec64 *ts;
> + bool timedwait_timecheck;
> +};
> +
> +/**
> + * Start the supplied function inside a separate thread, wait for completion
> + * and check the thread return value.
> + *
> + * @param thread The thread entry point
> + * @param arg The thread arguments
> + * @param exp_result The expected return value
> + *
> + * @return 0 if the thread reported @exp_result as return value, the thread's
> + * return value otherwise
> + */
> +static int run_thread(void *(*thread)(void *), void *arg, int exp_result)
> +{
> + pthread_t tid;
> + void *status;
> + long res;
> + int ret;
> +
> + if (!__T(ret, pthread_create(, NULL, thread, arg)))
> + return ret;
> +
> + if (!__T(ret, pthread_join(tid, )))
> + return ret;
> +
> + res = *((long *) status);
> +
> + return (res == exp_result) ? 0 : ret;
> +}
> +
> static int test_sc_cobalt_sem_timedwait64(void)
> {
> int ret;
> @@ -404,6 +443,150 @@ static int test_sc_cobalt_clock_adjtime64(void)
> return 0;
> }
>
> +static void *timedlock64_thread(void *arg)
> +{
> + struct thread_context *ctx = (struct thread_context *) arg;
> + struct xn_timespec64 t1, t2;
> + struct timespec ts_nat;
> + int ret;
> +
> + if (ctx->timedwait_timecheck) {
> + if (!__T(ret, clock_gettime(CLOCK_REALTIME, _nat)))
> + return (void *)(long)ret;
> +
> + t1.tv_sec = ts_nat.tv_sec;
> + t1.tv_nsec = ts_nat.tv_nsec;
> + ts_add_ns(, ctx->ts->tv_nsec);
> + ts_add_ns(, ctx->ts->tv_sec * NSEC_PER_SEC);
> + }
> +
> + ret = XENOMAI_SYSCALL2(ctx->sc_nr, ctx->mutex, (void *) ctx->ts);
> + if (ret)
> + return (void *)(long)ret;
> +
> + if (ctx->timedwait_timecheck) {
> + if (!__T(ret, clock_gettime(CLOCK_REALTIME, _nat)))
> + return (void *)(long)ret;
> +
> + t2.tv_sec = ts_nat.tv_sec;
> + t2.tv_nsec = ts_nat.tv_nsec;
> +
> + if (ts_less(, ))
> + smokey_warning("mutex_timedlock64 returned to early!\n"
> +"Expected wakeup at: %lld sec %lld
> nsec\n"
> +"Back at : %lld sec %lld
> nsec\n",
> +t1.tv_sec, t1.tv_nsec, t2.tv_sec,
> +t2.tv_nsec);
> + }
> +
> + return (void *)(long)pthread_mutex_unlock(ctx->mutex);
> +}
> +
> +static int test_sc_cobalt_mutex_timedlock64(void)
> +{
> + int ret;
> + pthread_mutex_t mutex;
> + int sc_nr = sc_cobalt_mutex_timedlock64;
> + struct xn_timespec64 ts64;
> + struct thread_context ctx = {0};
> +
> + ret = pthread_mutex_init(, NULL);
> +
> + /* Make sure we don't crash because of NULL pointers */
> + ret = XENOMAI_SYSCALL2(sc_nr, NULL, NULL);
> + if (ret == -ENOSYS) {
> + smokey_note("mutex_timedlock64: skipped. (no kernel support)");
> + return 0; // Not implemented, nothing to test, success
> + }
> + if (!smokey_assert(ret == -EINVAL))
> + return ret ? ret : -EINVAL;
> +
> + /*
> + * mutex can be taken immediately, no need to validate
> + * NULL should be allowed
> + */
> + ret = XENOMAI_SYSCALL2(sc_nr, , NULL);
> + if (!smokey_assert(!ret))
> + return ret;
> +
> + if (!__T(ret, pthread_mutex_unlock()))
> + return ret;
> +
> + /*
> + * mutex can be taken immediately, no need to validate
> + * an invalid address should be allowed
> + */
> + ret = XENOMAI_SYSCALL2(sc_nr, , 0xdeadbeef);
> + if (!smokey_assert(!ret))
> +
Re: [PATCH v2 0/5] y2038: Adding support for mq_timed{send,recv}64
On 31.07.21 09:19, Florian Bezdeka wrote:
> Hi all,
>
> this is kind of a re-send of the patch series originall published by
> Song. There were some things that had to be addressed:
>
> - Code formattings
> - Copy paste errors in the test suite
> - Failing / incomplete tests, missing test cleanups
> - Incorrect compat syscall declerations
>
> @Song: Especially the missing test cleanups and the incorrect compat
> syscall declerations made me unhappy. Did you really test that once?
> Please make sure to send properly tested patches. There are many
> pitfalls in the game which makes the review process time consuming,
> especially when I have to assume that it was not tested till now.
>
> Best regards,
> Florian
>
> Florian Bezdeka (1):
> y2038: testsuite/smokey/y2038: Adding tests for mq_timed{send,recv}64
>
> Song Chen (4):
> y2038: cobalt/posix/mqueue: Adding mq_timedsend64
> y2038: lib/cobalt/mqueue: dispatch mq_timedsend
> y2038: cobalt/posix/muqueue: Adding mq_timedreceive64
> y2038: lib/cobalt/mqueue: dispatch mq_timedreceive
>
> include/cobalt/uapi/syscall.h | 2 +
> kernel/cobalt/posix/mqueue.c | 49 ++-
> kernel/cobalt/posix/mqueue.h | 18 +++
> kernel/cobalt/posix/syscall32.c| 16 +++
> kernel/cobalt/posix/syscall32.h| 10 ++
> kernel/cobalt/trace/cobalt-posix.h | 4 +-
> lib/cobalt/mq.c| 10 ++
> testsuite/smokey/y2038/syscall-tests.c | 177 -
> 8 files changed, 283 insertions(+), 3 deletions(-)
>
Thanks, applied to next.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH 4/7] net/drivers: fec: update from linux kernel 5.4 and NXP I.MX8
On 28.07.21 09:27, Jean-Baptiste Trédez via Xenomai wrote:
> Signed-off-by: Jean-Baptiste Trédez
>
>
> Content :
>
> net: fec: add phy_reset_after_clk_enable() support
>
> Some PHYs (for example the SMSC LAN8710/LAN8720) doesn't allow turning
> the refclk on and off again during operation (according to their
> datasheet). Nonetheless exactly this behaviour was introduced for power
> saving reasons by commit e8fcfcd5684a ("net: fec: optimize the clock
> management to save power").
> Therefore add support for the phy_reset_after_clk_enable function from
> phylib to mitigate this issue.
>
> Generally speaking this issue is only relevant if the ref clk for the
> PHY is generated by the SoC and therefore the PHY is configured to
> "REF_CLK In Mode". In our specific case (PCB) this problem does occur at
> about every 10th to 50th POR of an LAN8710 connected to an i.MX6SOLO
> SoC. The typical symptom of this problem is a "swinging" ethernet link.
> Similar issues were reported by users of the NXP forum:
> https://community.nxp.com/thread/389902
> https://community.nxp.com/message/309354
> With this patch applied the issue didn't occur for at least a few
> hundret PORs of our board.
>
> Fixes: e8fcfcd5684a ("net: fec: optimize the clock management to save power")
> Signed-off-by: Richard Leitner
> Signed-off-by: David S. Miller
>
> --
>
> net: fec: add necessary defines to work on ARM64
>
> The i.MX8 is a ARMv8 based SoC, that uses the same FEC IP as the
> earlier, ARMv7 based, i.MX SoCs. Allow the driver to work on ARM64.
>
> Signed-off-by: Lucas Stach
> Acked-by: Fugang Duan
> Signed-off-by: David S. Miller
>
> --
>
> drivers: net: Remove device_node checks with of_mdiobus_register()
>
> A number of drivers have the following pattern:
>
> if (np)
> of_mdiobus_register()
> else
> mdiobus_register()
>
> which the implementation of of_mdiobus_register() now takes care of.
> Remove that pattern in drivers that strictly adhere to it.
>
> Signed-off-by: Florian Fainelli
> Reviewed-by: Grygorii Strashko
> Reviewed-by: Fugang Duan
> Reviewed-by: Antoine Tenart
> Reviewed-by: Jose Abreu
> Signed-off-by: David S. Miller
>
> --
>
> net: ethernet: freescale: Allow FEC with COMPILE_TEST
>
> The Freescale FEC driver builds fine with COMPILE_TEST, so make that
> possible.
>
> Signed-off-by: Florian Fainelli
> Signed-off-by: David S. Miller
>
> --
>
> net: fec: Add a SPDX identifier
>
> Currently there is no license information in the header of
> this file.
>
> The MODULE_LICENSE field contains ("GPL"), which means
> GNU Public License v2 or later, so add a corresponding
> SPDX license identifier.
>
> Signed-off-by: Fabio Estevam
> Acked-by: Fugang Duan
> Signed-off-by: David S. Miller
>
> --
>
> net: ethernet: freescale: Use generic CRC32 implementation
>
> Use generic kernel CRC32 implementation because it:
> 1. Should be faster (uses lookup tables),
> 2. Removes duplicated CRC generation code,
> 3. Uses well-proven algorithm instead of coding it one more time.
>
> Suggested-by: Eric Biggers
> Signed-off-by: Krzysztof Kozlowski
> Signed-off-by: David S. Miller
>
> --
>
> net: fec: check DMA addressing limitations
>
> Check DMA addressing limitations as suggested by the DMA API
> how-to. This does not fix a particular issue seen but is
> considered good style.
>
> Signed-off-by: Stefan Agner
> Acked-by: Fugang Duan
> Reviewed-by: Robin Murphy
> Signed-off-by: David S. Miller
>
> --
>
> net: ethernet: Use phy_set_max_speed() to limit advertised speed
>
> Many Ethernet MAC drivers want to limit the PHY to only advertise a
> maximum speed of 100Mbs or 1Gbps. Rather than using a mask, make use
> of the helper function phy_set_max_speed().
>
> Signed-off-by: Andrew Lunn
> Reviewed-by: Florian Fainelli
> Signed-off-by: David S. Miller
>
> --
>
> net: ethernet: Add helper to remove a supported link mode
>
> Some MAC hardware cannot support a subset of link modes. e.g. often
> 1Gbps Full duplex is supported, but Half duplex is not. Add a helper
> to remove such a link mode.
>
> Signed-off-by: Andrew Lunn
> Reviewed-by: Florian Fainelli
> Signed-off-by: David S. Miller
>
> --
>
> net: ethernet: Add helper for MACs which support pause
>
> Rather than have the MAC drivers manipulate phydev members, add a
> helper function for MACs supporting Pause, but not Asym Pause.
>
> Signed-off-by: Andrew Lunn
> Reviewed-by: Florian Fainelli
> Signed-off-by: David S. Miller
>
> --
>
> net: ethernet: Add helper for set_pauseparam for Pause
>
> ethtool can be used to enable/disable pause. Add a helper to configure
> the PHY when Pause is supported.
>
> Signed-off-by: Andrew Lunn
> Reviewed-by: Florian Fainelli
> Signed-off-by: David S. Miller
>
> --
>
> net: ethernet: remove redundant null pointer check before
[PATCH] ci: Include FEC Ethernet driver
From: Jan Kiszka Signed-off-by: Jan Kiszka --- .gitlab-ci.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 0d354c04d7..05b226b474 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -135,6 +135,7 @@ variables: - ./scripts/config -m XENO_DRIVERS_NET_DRV_3C59X - ./scripts/config -m XENO_DRIVERS_NET_DRV_E1000_NEW - ./scripts/config -m XENO_DRIVERS_NET_DRV_RT2500 +- ./scripts/config -m XENO_DRIVERS_NET_FEC - ./scripts/config -m XENO_DRIVERS_NET_ADDON_RTCAP - ./scripts/config -m XENO_DRIVERS_NET_ADDON_PROXY - ./scripts/config -e XENO_DRIVERS_NET_ADDON_PROXY_ARP -- 2.31.1
Re: [PATCH 3/7] net/drivers: fec: rebase over original driver from kernel 4.14.85
On 28.07.21 09:27, Jean-Baptiste Trédez via Xenomai wrote: > From: Philippe Gerum > > This driver has three runtime modes: > > - full RTnet mode for all devices (default) > > - partial RTnet. RTnet mode only for devices which do not define/set > the boolean "rtnet-disabled" to true in the dts. The latter are > operated normally, interfacing with the standard network stack > instead of RTnet. > > - full regular operations. RTnet mode disabled for all devices if the > "rtnet_disabled" module parameter is set to non-zero/true. In this > configuration, the driver operates all devices like the original > driver does, via the standard network stack. > > In addition, the PHC device attached to the FEC is still available to > the PTP stack, including when the driver operates devices in RTnet > mode. There is no real-time guarantee though. > > Tested on i.MX6Q. > > Signed-off-by: Philippe Gerum > --- > kernel/drivers/net/drivers/Kconfig|9 + > kernel/drivers/net/drivers/Makefile |6 +- > kernel/drivers/net/drivers/fec.c | 1859 --- > kernel/drivers/net/drivers/freescale/Makefile |5 + > kernel/drivers/net/drivers/freescale/fec.h| 610 +++ > .../drivers/net/drivers/freescale/fec_main.c | 4394 + > .../drivers/net/drivers/freescale/fec_ptp.c | 640 +++ > kernel/drivers/net/drivers/rt_fec.h | 153 - > 8 files changed, 5660 insertions(+), 2016 deletions(-) > delete mode 100644 kernel/drivers/net/drivers/fec.c > create mode 100644 kernel/drivers/net/drivers/freescale/Makefile > create mode 100644 kernel/drivers/net/drivers/freescale/fec.h > create mode 100644 kernel/drivers/net/drivers/freescale/fec_main.c > create mode 100644 kernel/drivers/net/drivers/freescale/fec_ptp.c > delete mode 100644 kernel/drivers/net/drivers/rt_fec.h > > diff --git a/kernel/drivers/net/drivers/Kconfig > b/kernel/drivers/net/drivers/Kconfig > index 6889a500d..c36533479 100644 > --- a/kernel/drivers/net/drivers/Kconfig > +++ b/kernel/drivers/net/drivers/Kconfig > @@ -131,6 +131,15 @@ config XENO_DRIVERS_NET_DRV_MACB > Driver for internal MAC-controller on AT91SAM926x microcontrollers. > Porting by Cristiano Mantovani and Stefano Banzi (Marposs SpA). > > +config XENO_DRIVERS_NET_FEC > +depends on XENO_DRIVERS_NET > +tristate "Freescale FEC" > +depends on ARCH_MXC || SOC_IMX28 > +select PHYLIB > +imply PTP_1588_CLOCK > +---help--- Deprected Kconfig style - again, please rebase patches before sending and test against a /recent/ version. Fixing up in next. Jan > +For built-in 10/100 Fast ethernet controller on Freescale i.MX > +processors. > endif > > source "drivers/xenomai/net/drivers/experimental/Kconfig" -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH] ci/gitlab-ci-base: Switch xenomai debug on for ci build
On 28.07.21 14:35, Hongzhan Chen via Xenomai wrote:
> Some smokey test items depend on xenomai debug and we need to switch
> it on to help smokey test pass.
>
> Signed-off-by: Hongzhan Chen
>
> diff --git a/ci/gitlab-ci-base.yml b/ci/gitlab-ci-base.yml
> index e23849d..2638dec 100644
> --- a/ci/gitlab-ci-base.yml
> +++ b/ci/gitlab-ci-base.yml
> @@ -39,8 +39,8 @@ default:
>extends: .add-proxy-config
>stage: build
>script:
> -- echo "Building
> kas.yml:board-${TARGET}.yml${XENOMAI_BUILD_OPTION}${LINUX_BUILD_OPTION}${BUILD_OPTIONS}"
> -- kas build
> kas.yml:board-${TARGET}.yml${XENOMAI_BUILD_OPTION}${LINUX_BUILD_OPTION}${BUILD_OPTIONS}
> +- echo "Building
> kas.yml:board-${TARGET}.yml${XENOMAI_BUILD_OPTION}${LINUX_BUILD_OPTION}${BUILD_OPTIONS}:opt-debug.yml"
> +- kas build
> kas.yml:board-${TARGET}.yml${XENOMAI_BUILD_OPTION}${LINUX_BUILD_OPTION}${BUILD_OPTIONS}:opt-debug.yml
> - if [ -n "${USE_S3_BUCKET}" ]; then scripts/deploy_to_aws.sh ${TARGET};
> fi
>
> .test:
>
Thanks, applied, just in different order (patch 2, this one, patch 1 -
ensures bisectability).
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH v4 0/5] y2038: Add mutex_timedlock64() support
On 31.07.21 09:08, Florian Bezdeka wrote: > Hi! > > This series is based on the series posted by Song some time ago. The > testing part has been heavily reworked. Details are mentioned in the > description of the last patch. > > @Jan: Patch 1 and 2 are re-sends. They are not directly related to the > y2038 stuff but the testsuite might fail if they are not applied. > > Testing was done on x86 only so far, internal CI is still running but no > problems expected. > > Best regards, > Florian > > Changes in v4: > - Fixed trace integration > (squashed into patch 3 from Song) > > Changes in v3: > - Added the new syscall to the tracing infrastructure > (squashed into patch 3 from Song) > > Florian Bezdeka (3): > smokey: posix_mutex: Fix mutex/smokey_barrier leak > cobalt/posix/mutex: Harmonize pthread_mutex_timedlock() and > sem_timedwait() > y2038: testsuite/smokey/y2038: Adding test cases for > mutex_timedlock64() > > Song Chen (2): > y2038: cobalt/posix/mutex: Adding mutex_timedlock64 > y2038: lib/cobalt/mutex: dispatch mutex_timedlock > > include/cobalt/uapi/syscall.h | 1 + > kernel/cobalt/posix/mutex.c| 28 ++- > kernel/cobalt/posix/mutex.h| 7 + > kernel/cobalt/posix/syscall32.c| 7 + > kernel/cobalt/posix/syscall32.h| 4 + > kernel/cobalt/trace/cobalt-posix.h | 4 +- > lib/cobalt/mutex.c | 4 + > testsuite/smokey/posix-mutex/posix-mutex.c | 62 +++ > testsuite/smokey/y2038/syscall-tests.c | 187 + > 9 files changed, 302 insertions(+), 2 deletions(-) > Thanks, remaing 3 also applied. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH] cobalt/posix/mutex: Harmonize pthread_mutex_timedlock() and sem_timedwait()
On 29.07.21 16:47, Florian Bezdeka wrote:
> According to the POSIX spec the value of the timeout parameter needs
> not to be validated if the mutex/semaphore could be taken immediately.
>
> While the implementation of the semaphore timedwait (sem_timedwait())
> allowed an invalid timeout pthread_mutex_timedlock() was failing with
> -EFAULT in case the mutex could be taken immediately.
>
> Signed-off-by: Florian Bezdeka
> ---
>
> This was detected while preparing y2038 stuff. Not sure if that should
> go into 3.2. Comments welcome...
>
> CCed Philippe because he was already involved some (long) time ago.
>
> Regards,
> Florian
>
>
> kernel/cobalt/posix/mutex.c| 5 ++
> testsuite/smokey/posix-mutex/posix-mutex.c | 60 ++
> 2 files changed, 65 insertions(+)
>
> diff --git a/kernel/cobalt/posix/mutex.c b/kernel/cobalt/posix/mutex.c
> index 70fe7960a..01478978e 100644
> --- a/kernel/cobalt/posix/mutex.c
> +++ b/kernel/cobalt/posix/mutex.c
> @@ -167,6 +167,11 @@ redo:
> xnthread_commit_ceiling(curr);
>
> if (xnsynch_owner_check(>synchbase, curr)) {
> + /* Check if we can take the mutex immediately */
> + ret = xnsynch_try_acquire(>synchbase);
> + if (ret != -EBUSY)
> + goto out;
> +
> if (fetch_timeout) {
> xnlock_put_irqrestore(, s);
> ret = fetch_timeout(, u_ts);
> diff --git a/testsuite/smokey/posix-mutex/posix-mutex.c
> b/testsuite/smokey/posix-mutex/posix-mutex.c
> index e5793c42c..4aad24964 100644
> --- a/testsuite/smokey/posix-mutex/posix-mutex.c
> +++ b/testsuite/smokey/posix-mutex/posix-mutex.c
> @@ -1002,6 +1002,65 @@ static int protect_handover(void)
> return 0;
> }
>
> +static void *mutex_timed_locker_inv_timeout(void *arg)
> +{
> + struct locker_context *p = arg;
> + int ret;
> +
> + if (__F(ret, pthread_mutex_timedlock(p->mutex, (void *) 0xdeadbeef)) &&
> + __Tassert(ret == -EFAULT))
> + return (void *)1;
> +
> + return NULL;
> +}
> +
> +static int check_timedlock_abstime_validation(void)
> +{
> + struct locker_context args;
> + pthread_mutex_t mutex;
> + pthread_t tid;
> + void *status;
> + int ret;
> +
> + if (!__T(ret, pthread_mutex_init(, NULL)))
> + return ret;
> +
> + /*
> + * We don't own the mutex yet, so no need to validate the timeout as
> + * the mutex can be locked immediately.
> + *
> + * The second parameter of phtread_mutex_timedlock() is flagged as
> + * __nonnull so we take an invalid address instead of NULL.
> + */
> + if (!__T(ret, pthread_mutex_timedlock(, (void *) 0xdeadbeef)))
> + return ret;
> +
> + /*
> + * Create a second thread which will have to wait and therefore will
> + * validate the (invalid) timeout
> + */
> + args.mutex =
> + ret = create_thread(, SCHED_FIFO, THREAD_PRIO_LOW,
> + mutex_timed_locker_inv_timeout, );
> +
> + if (ret)
> + return ret;
> +
> + if (!__T(ret, pthread_join(tid, )))
> + return ret;
> +
> + if (!__T(ret, pthread_mutex_unlock()))
> + return ret;
> +
> + if (!__T(ret, pthread_mutex_destroy()))
> + return ret;
> +
> + if (!__Fassert(status == NULL))
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> /* Detect obviously wrong execution times. */
> static int check_time_limit(const struct timespec *start,
> xnticks_t limit_ns)
> @@ -1065,6 +1124,7 @@ static int run_posix_mutex(struct smokey_test *t, int
> argc, char *const argv[])
> do_test(protect_dynamic, MAX_100_MS);
> do_test(protect_trylock, MAX_100_MS);
> do_test(protect_handover, MAX_100_MS);
> + do_test(check_timedlock_abstime_validation, MAX_100_MS);
>
> return 0;
> }
>
Thanks, applied.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
Re: [PATCH] smokey: posix_mutex: Fix mutex/smokey_barrier leak
On 29.07.21 13:29, Florian Bezdeka wrote: > The mutex of the smokey_barrier used inside protect_handover() was > never destroyed. This had side effects when trying to extend the test > suite with an additional function that had a mutex located on the same > address than the never cleaned up smokey_barrier lock. > > Signed-off-by: Florian Bezdeka > --- > testsuite/smokey/posix-mutex/posix-mutex.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/testsuite/smokey/posix-mutex/posix-mutex.c > b/testsuite/smokey/posix-mutex/posix-mutex.c > index 9a55d0973..e5793c42c 100644 > --- a/testsuite/smokey/posix-mutex/posix-mutex.c > +++ b/testsuite/smokey/posix-mutex/posix-mutex.c > @@ -997,6 +997,8 @@ static int protect_handover(void) > if (!__T(ret, pthread_mutex_destroy())) > return ret; > > + smokey_barrier_destroy(); > + > return 0; > } > > Thanks, applied. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH v2] Enable retrieving of RTNET network packet timestamp OOB using recvmsg()
On 29.07.21 09:32, François Legal wrote: > Le Mardi, Juillet 27, 2021 18:44 CEST, Jan Kiszka a > écrit: > >> On 27.07.21 14:13, François Legal wrote: >>> Le Lundi, Juillet 26, 2021 14:01 CEST, Jan Kiszka >>> a écrit: >>> On 17.05.21 11:44, François Legal via Xenomai wrote: > This patch enables retrieving, in realtime application, of RTNET enabled > adapters packet timestamps. > It uses the linux semantic SO_TIMESTAMPNS, and the linux code to put the > timestamp in the control_msg structure. > > I tested this patch with af_packet sockets only. UDP & TCP might be a > little bit trickier as many fragment/segments get reassembled in a single > recvmsg. I believe the linux code I used to put the timestamps in the > control structure should be OK though. One of my question on v1 is still open: How does Linux handle stamping the context of fragmented UDP and TCP packets? And given that you enable it for those protocols as well, we should likely test that too. >>> >>> I thought I already gave an answer to this. Sorry. >>> Linux does not handle time stamping of UDP and TCP as far as I understand. >> >> Does Linux return an error when you try to enable this for UDP or TCP >> sockets? > > Alright so I rechecked everything again. Linux does not return an error when > requesting timestamping for UDP or TCP (or any other kind of socket it seems). > > Despite my previous assertion, timestamping is supported for UDP and if I > understood the code correctly, only one timestamp is returned in any case > (the time stamp of the last received datagram). This is done in reassembly > queues, where the queue always keep the timestamp of the last received > datagram, and when doing the reassembly, this last timestamp is reported to > the re created skb. > > For TCP it is definitely not supported. > > So I should modify the patch to make it comply with what linux does I guess ? > Yes, unless there is any good (RT/Xenomai-specific) reason speaking against alignment, we should do this - least surprise. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH 0/7] Update fec driver for xenomai 3 and linux kernel 5.4 and add I.MX8 support
On 28.07.21 09:27, Jean-Baptiste Trédez via Xenomai wrote: > Current fec driver does not build on xenomai 3 and on recent kernel (ex : > 5.4). This driver was completely rewritten on mainline kernel. > This work uses previous work from Gilles Chanteperdrix and Philippe Gerum > (rebase over original driver from kernel 4.14.85 for xenomai 3) (patch 1 to > 3), update the driver to 5.4 kernel and i.MX8Q (patch 4 and 5), fix buffer > free issue (patch 6) and reduce latency (patch 7). > This set was tested on i.MX8Q target > > Arnaud Bouvet (1): > net/drivers: fec: remove 1ms latency on frames reception > > Gilles Chanteperdrix (2): > utils/net: rtifconfig: display device name untruncated > net/stack: rtskb: increase buffer size > > Jean-Baptiste Trédez (3): > net/drivers: fec: update from linux kernel 5.4 and NXP I.MX8 > Kconfig : enable fec for ARM64 build > net/drivers: fec: fix dev_kfree_rtskb on wrong buffer > > Philippe Gerum (1): > net/drivers: fec: rebase over original driver from kernel 4.14.85 > > kernel/drivers/net/drivers/Kconfig| 11 +- > kernel/drivers/net/drivers/Makefile |6 +- > kernel/drivers/net/drivers/fec.c | 1859 --- > kernel/drivers/net/drivers/freescale/Makefile |5 + > kernel/drivers/net/drivers/freescale/fec.h| 642 +++ > .../drivers/net/drivers/freescale/fec_main.c | 4676 + > .../drivers/net/drivers/freescale/fec_ptp.c | 638 +++ > kernel/drivers/net/drivers/rt_fec.h | 153 - > kernel/drivers/net/stack/include/rtskb.h |2 +- > utils/net/rtifconfig.c|2 +- > 10 files changed, 5975 insertions(+), 2019 deletions(-) > delete mode 100644 kernel/drivers/net/drivers/fec.c > create mode 100644 kernel/drivers/net/drivers/freescale/Makefile > create mode 100644 kernel/drivers/net/drivers/freescale/fec.h > create mode 100644 kernel/drivers/net/drivers/freescale/fec_main.c > create mode 100644 kernel/drivers/net/drivers/freescale/fec_ptp.c > delete mode 100644 kernel/drivers/net/drivers/rt_fec.h > Thanks, applied to next. Patch 3 didn't apply directly, but the conflict was in the to-be-deleted file. Please always make sure to check if your patches need rebasing. In addition, I'll add the driver to CI so that we are building it regularly. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH 5/7] Kconfig : enable fec for ARM64 build
On 28.07.21 09:28, Jean-Baptiste Trédez via Xenomai wrote: > Signed-off-by: Jean-Baptiste Trédez > --- > kernel/drivers/net/drivers/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/drivers/net/drivers/Kconfig > b/kernel/drivers/net/drivers/Kconfig > index c36533479..60889aa70 100644 > --- a/kernel/drivers/net/drivers/Kconfig > +++ b/kernel/drivers/net/drivers/Kconfig > @@ -116,7 +116,7 @@ config XENO_DRIVERS_NET_DRV_SMC9 > depends on XENO_DRIVERS_NET > tristate "SMSC LAN91C111" > > -if ARM > +if ARM || ARM64 > > config XENO_DRIVERS_NET_DRV_AT91_ETHER > depends on XENO_DRIVERS_NET && SOC_AT91RM9200 > This one is overshooting. I've adjusted it to actually target what the subject was aiming at. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: Xenomai and Linux SCHED_FIFO threads Question
On 30.07.21 18:02, Rajesh Venkataraman via Xenomai wrote: > Hello, >We are trying to move our embedded real time application from RTOS to > Linux. So we first ported our RTOS application to a RT-Linux. In RT-Linux > we have cpu isolation and run our main realtime interrupt as a pthread > with highest priority on the isolated core. Rest of the application on > other cores. We are observing that the execution time(Interrupt Service > Routine duration) of the realtime interrupt is longer than running on a > traditional RTOS. So we are trying to put just this real time interrupt > service routine thread into Xenomai. In the RT linux Application we have > set the scheduling policy for a number of threads to SCHED_FIFO(Including > the Realtime Interrupt Service thread). Is it possible to run just the > realtime interrupt service routine thread under Xenomai and run the other > SCHED_FIFO thread under linux? or do we lose the Linux SCHED_FIFO once we > include Xenomai? > Nope, you can always call __STD(pthread_create) etc. if you want to get the normal Linux service. But keep in mind that you will need Xenomai threads in order to synchronize with you interrupt thread via sleeping lock (e.g. pthread-mutexes). If you want to avoid such dependency, you will have to use lock-less synchronization for shared data. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH] cobalt/posix/mutex: Harmonize pthread_mutex_timedlock() and sem_timedwait()
On 30.07.21 09:14, Bezdeka, Florian (T RDA IOT SES-DE) wrote: > On Thu, 2021-07-29 at 19:29 +0200, Jan Kiszka wrote: >> On 29.07.21 18:22, Bezdeka, Florian (T RDA IOT SES-DE) wrote: >>> On Thu, 2021-07-29 at 17:45 +0200, Jan Kiszka wrote: On 29.07.21 17:06, Philippe Gerum wrote: > > Florian Bezdeka writes: > >> According to the POSIX spec the value of the timeout parameter needs >> not to be validated if the mutex/semaphore could be taken immediately. >> >> While the implementation of the semaphore timedwait (sem_timedwait()) >> allowed an invalid timeout pthread_mutex_timedlock() was failing with >> -EFAULT in case the mutex could be taken immediately. >> >> Signed-off-by: Florian Bezdeka >> --- >> >> This was detected while preparing y2038 stuff. Not sure if that should >> go into 3.2. Comments welcome... >> > > upsides: save a few cycles in the non-contended case by not copying in > the timeout from userland uselessly + might help passing some picky > POSIX compliance tests. > > downside: adds an extra atomic op in the contended case. > How do we compare to libc implementations here? >>> >>> I changed the validation done on cobalt side, not libcobalt. So what >>> exactly do you mean? >>> >> >> Indeed, I was looking for the fast or almost fast paths in userspace. >> >> But now I'm confused: The uncontended case is generally not supposed to >> trigger a syscall. That is always the slow path anyway, e.g. because ned >> to migrated first (likely how you were able to trigger the issue?). > > The fast-path was always fine, that is right. But please note that > depending on the kernel configuration (especially with > CONFIG_XENO_OPT_DEBUG_MUTEX_SLEEP enabled) we will always be forced > into the slow-path. > > So we had another imbalance depending on the kernel configuration. > OK, I just wanted to understand whether that single atomic more is an issue - it's not at all, we are slow already at that point. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH] cobalt/posix/mutex: Harmonize pthread_mutex_timedlock() and sem_timedwait()
On 29.07.21 18:22, Bezdeka, Florian (T RDA IOT SES-DE) wrote: > On Thu, 2021-07-29 at 17:45 +0200, Jan Kiszka wrote: >> On 29.07.21 17:06, Philippe Gerum wrote: >>> >>> Florian Bezdeka writes: >>> According to the POSIX spec the value of the timeout parameter needs not to be validated if the mutex/semaphore could be taken immediately. While the implementation of the semaphore timedwait (sem_timedwait()) allowed an invalid timeout pthread_mutex_timedlock() was failing with -EFAULT in case the mutex could be taken immediately. Signed-off-by: Florian Bezdeka --- This was detected while preparing y2038 stuff. Not sure if that should go into 3.2. Comments welcome... >>> >>> upsides: save a few cycles in the non-contended case by not copying in >>> the timeout from userland uselessly + might help passing some picky >>> POSIX compliance tests. >>> >>> downside: adds an extra atomic op in the contended case. >>> >> >> How do we compare to libc implementations here? > > I changed the validation done on cobalt side, not libcobalt. So what > exactly do you mean? > Indeed, I was looking for the fast or almost fast paths in userspace. But now I'm confused: The uncontended case is generally not supposed to trigger a syscall. That is always the slow path anyway, e.g. because ned to migrated first (likely how you were able to trigger the issue?). Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH] cobalt/posix/mutex: Harmonize pthread_mutex_timedlock() and sem_timedwait()
On 29.07.21 17:06, Philippe Gerum wrote:
>
> Florian Bezdeka writes:
>
>> According to the POSIX spec the value of the timeout parameter needs
>> not to be validated if the mutex/semaphore could be taken immediately.
>>
>> While the implementation of the semaphore timedwait (sem_timedwait())
>> allowed an invalid timeout pthread_mutex_timedlock() was failing with
>> -EFAULT in case the mutex could be taken immediately.
>>
>> Signed-off-by: Florian Bezdeka
>> ---
>>
>> This was detected while preparing y2038 stuff. Not sure if that should
>> go into 3.2. Comments welcome...
>>
>
> upsides: save a few cycles in the non-contended case by not copying in
> the timeout from userland uselessly + might help passing some picky
> POSIX compliance tests.
>
> downside: adds an extra atomic op in the contended case.
>
How do we compare to libc implementations here?
Jan
>> CCed Philippe because he was already involved some (long) time ago.
>>
>
> The patch looks good.
>
>> Regards,
>> Florian
>>
>>
>> kernel/cobalt/posix/mutex.c| 5 ++
>> testsuite/smokey/posix-mutex/posix-mutex.c | 60 ++
>> 2 files changed, 65 insertions(+)
>>
>> diff --git a/kernel/cobalt/posix/mutex.c b/kernel/cobalt/posix/mutex.c
>> index 70fe7960a..01478978e 100644
>> --- a/kernel/cobalt/posix/mutex.c
>> +++ b/kernel/cobalt/posix/mutex.c
>> @@ -167,6 +167,11 @@ redo:
>> xnthread_commit_ceiling(curr);
>>
>> if (xnsynch_owner_check(>synchbase, curr)) {
>> +/* Check if we can take the mutex immediately */
>> +ret = xnsynch_try_acquire(>synchbase);
>> +if (ret != -EBUSY)
>> +goto out;
>> +
>> if (fetch_timeout) {
>> xnlock_put_irqrestore(, s);
>> ret = fetch_timeout(, u_ts);
>> diff --git a/testsuite/smokey/posix-mutex/posix-mutex.c
>> b/testsuite/smokey/posix-mutex/posix-mutex.c
>> index e5793c42c..4aad24964 100644
>> --- a/testsuite/smokey/posix-mutex/posix-mutex.c
>> +++ b/testsuite/smokey/posix-mutex/posix-mutex.c
>> @@ -1002,6 +1002,65 @@ static int protect_handover(void)
>> return 0;
>> }
>>
>> +static void *mutex_timed_locker_inv_timeout(void *arg)
>> +{
>> +struct locker_context *p = arg;
>> +int ret;
>> +
>> +if (__F(ret, pthread_mutex_timedlock(p->mutex, (void *) 0xdeadbeef)) &&
>> +__Tassert(ret == -EFAULT))
>> +return (void *)1;
>> +
>> +return NULL;
>> +}
>> +
>> +static int check_timedlock_abstime_validation(void)
>> +{
>> +struct locker_context args;
>> +pthread_mutex_t mutex;
>> +pthread_t tid;
>> +void *status;
>> +int ret;
>> +
>> +if (!__T(ret, pthread_mutex_init(, NULL)))
>> +return ret;
>> +
>> +/*
>> + * We don't own the mutex yet, so no need to validate the timeout as
>> + * the mutex can be locked immediately.
>> + *
>> + * The second parameter of phtread_mutex_timedlock() is flagged as
>> + * __nonnull so we take an invalid address instead of NULL.
>> + */
>> +if (!__T(ret, pthread_mutex_timedlock(, (void *) 0xdeadbeef)))
>> +return ret;
>> +
>> +/*
>> + * Create a second thread which will have to wait and therefore will
>> + * validate the (invalid) timeout
>> + */
>> +args.mutex =
>> +ret = create_thread(, SCHED_FIFO, THREAD_PRIO_LOW,
>> +mutex_timed_locker_inv_timeout, );
>> +
>> +if (ret)
>> +return ret;
>> +
>> +if (!__T(ret, pthread_join(tid, )))
>> +return ret;
>> +
>> +if (!__T(ret, pthread_mutex_unlock()))
>> +return ret;
>> +
>> +if (!__T(ret, pthread_mutex_destroy()))
>> +return ret;
>> +
>> +if (!__Fassert(status == NULL))
>> +return -EINVAL;
>> +
>> +return 0;
>> +}
>> +
>> /* Detect obviously wrong execution times. */
>> static int check_time_limit(const struct timespec *start,
>> xnticks_t limit_ns)
>> @@ -1065,6 +1124,7 @@ static int run_posix_mutex(struct smokey_test *t, int
>> argc, char *const argv[])
>> do_test(protect_dynamic, MAX_100_MS);
>> do_test(protect_trylock, MAX_100_MS);
>> do_test(protect_handover, MAX_100_MS);
>> +do_test(check_timedlock_abstime_validation, MAX_100_MS);
>>
>> return 0;
>> }
>
>
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
