Re: [PATCH v5 0/5] y2038: Add mutex_timedlock64() support

[Jan Kiszka via Xenomai]

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: [xenomai-images][RFC][PATCH] ci: Switch to Google nameserver

[Jan Kiszka via Xenomai]

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 v2 0/3] y2038: sigtimedwait64

[Jan Kiszka via Xenomai]

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 4] Heads up

[Jan Kiszka via Xenomai]

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

[xenomai-images][PATCH] ci: Add default for S3_BUCKET_URL

[Jan Kiszka via Xenomai]

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

[xenomai-images][PATCH] ci: Make default s3 fetch URL zone-independent

[Jan Kiszka via Xenomai]

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

Re: cannot link 32 bit app

[Jan Kiszka via Xenomai]

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

Re: posix_select seems to leak a registry element

[Jan Kiszka via Xenomai]

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: posix_select seems to leak a registry element

[Jan Kiszka via Xenomai]

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: [PATCH v4 3/5] y2038: cobalt/posix/muqueue: Adding mq_timedreceive64

[Jan Kiszka via Xenomai]

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(&ts, u_ts);
>   if (ret)
>   return ERR_PTR(ret);
> - if (ts.tv_nsec >= ONE_BILLION)
> + if (!timespec64_valid(&ts))
>   return ERR_PTR(-EINVAL);
>   to = ts2ns(&ts) + 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(&len, u_len, sizeof(len));
> + if (ret)
> + return ret;
> +
> + ret = __cobalt_mq_timedreceive(uqd, u_buf, &len, u_prio, u_ts,
> +u_ts ? mq_fetch_timeout64 : NULL);
> +
> + return ret ?: cobalt_copy_to_user(u_len, &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, &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, &clen, 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,
> + 

Re: [PATCH] testsuite/smokey: Fixing a registry leak of the posix_select test

[Jan Kiszka via Xenomai]

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 v2 0/3] y2038: Adding monitor_wait64()

[Jan Kiszka via Xenomai]

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 v4 0/3] y2038: Adding event_wait64()

[Jan Kiszka via Xenomai]

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 v4 3/5] y2038: cobalt/posix/muqueue: Adding mq_timedreceive64

[Jan Kiszka via Xenomai]

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(&ts, u_ts);
>>  if (ret)
>>  return ERR_PTR(ret);
>> -if (ts.tv_nsec >= ONE_BILLION)
>> +if (!timespec64_valid(&ts))
>>  return ERR_PTR(-EINVAL);
>>  to = ts2ns(&ts) + 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(&len, u_len, sizeof(len));
>> +if (ret)
>> +return ret;
>> +
>> +ret = __cobalt_mq_timedreceive(uqd, u_buf, &len, u_prio, u_ts,
>> +   u_ts ? mq_fetch_timeout64 : NULL);
>> +
>> +return ret ?: cobalt_copy_to_user(u_len, &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, &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(m

Re: [PATCH] Add --disable-{demo,testsuite} options

[Jan Kiszka via Xenomai]

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

[xenomai-images][PATCH v2] ci: Add default for S3_BUCKET_URL

[Jan Kiszka via Xenomai]

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

[xenomai-images][PATCH] ci: Do not rely on S3_BUCKET_URL being terminated by a slash

[Jan Kiszka via Xenomai]

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

Re: [PATCH] Add --disable-{demo,testsuite} options

[Jan Kiszka via Xenomai]

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

Re: [xenomai-images][PATCH] linux-xenomai: Add tracing support to arm64

[Jan Kiszka via Xenomai]

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 v2] testsuite/smokey: Fixing a registry leak of the posix_select test

[Jan Kiszka via Xenomai]

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

[PATCH] linux-xenomai: Disable I-pipe debugging on bbb also for 4.4-latest

[Jan Kiszka via Xenomai]

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,1/2] fix build on arc and riscv32

[Jan Kiszka via Xenomai]

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|
> %.2ld:%.2ld:%

[PATCH] lib/cobalt: x86: Relax asm constraints for syscall wrapper

[Jan Kiszka via Xenomai]

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

[PATCH] ci: Add 32-bit x86 compat userland build

[Jan Kiszka via Xenomai]

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

Re: [PATCH v2,2/2] Add --disable-{demo,testsuite} options

[Jan Kiszka via Xenomai]

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 2/2] drivers/gpio: Flip default for GPIO_RTIOC_TS to real-time clock

[Jan Kiszka via Xenomai]

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

[PATCH 0/2] Allow GPIO timestamps also via real-time clock

[Jan Kiszka via Xenomai]

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 1/2] drivers/gpio: Add support for selecting real-time clock timestamps

[Jan Kiszka via Xenomai]

From: Jan Kiszka 

This allows to compare timestamps of GPIO pins against other devices and
ensures that the stamps are synchronized cross-systems in case PTP is in
use (dovetail-based kernels). Keep default to monotonic for now.

Signed-off-by: Jan Kiszka 
---
 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(-)

diff --git a/include/cobalt/kernel/rtdm/gpio.h 
b/include/cobalt/kernel/rtdm/gpio.h
index 00055ec0a9..72cc3a0356 100644
--- a/include/cobalt/kernel/rtdm/gpio.h
+++ b/include/cobalt/kernel/rtdm/gpio.h
@@ -34,6 +34,7 @@ struct rtdm_gpio_pin {
char *name;
struct gpio_desc *desc;
nanosecs_abs_t timestamp;
+   bool monotonic_timestamp;
 };
 
 struct rtdm_gpio_chip {
diff --git a/include/rtdm/uapi/gpio.h b/include/rtdm/uapi/gpio.h
index 2839f7d51c..fb84274453 100644
--- a/include/rtdm/uapi/gpio.h
+++ b/include/rtdm/uapi/gpio.h
@@ -29,7 +29,9 @@ struct rtdm_gpio_readout {
 #define GPIO_RTIOC_IRQDIS  _IO(RTDM_CLASS_GPIO, 3)
 #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_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_TRIGGER_NONE  0x0 /* unspecified */
 #define GPIO_TRIGGER_EDGE_RISING   0x1
diff --git a/kernel/drivers/gpio/gpio-core.c b/kernel/drivers/gpio/gpio-core.c
index 600ef9789a..06a19b33a9 100644
--- a/kernel/drivers/gpio/gpio-core.c
+++ b/kernel/drivers/gpio/gpio-core.c
@@ -189,11 +189,13 @@ static int gpio_pin_ioctl_nrt(struct rtdm_fd *fd,
gpio_free(gpio);
chan->requested = false;
break;
-   case GPIO_RTIOC_TS:
+   case GPIO_RTIOC_TS_MONO:
+   case GPIO_RTIOC_TS_REAL:
ret = rtdm_safe_copy_from_user(fd, &val, arg, sizeof(val));
if (ret)
return ret;
chan->want_timestamp = !!val;
+   pin->monotonic_timestamp = request == GPIO_RTIOC_TS_MONO;
break;
default:
return -EINVAL;
@@ -228,8 +230,11 @@ static ssize_t gpio_pin_read_rt(struct rtdm_fd *fd,
if (ret)
return ret;
rdo.timestamp = pin->timestamp;
-   } else
+   } else if (pin->monotonic_timestamp) {
rdo.timestamp = rtdm_clock_read_monotonic();
+   } else {
+   rdo.timestamp = rtdm_clock_read();
+   }
 
len = sizeof(rdo);
rdo.value = gpiod_get_raw_value(pin->desc);
@@ -489,7 +494,10 @@ int rtdm_gpiochip_post_event(struct rtdm_gpio_chip *rgc,
return -EINVAL;
 
pin = rgc->pins + offset;
-   pin->timestamp = rtdm_clock_read_monotonic();
+   if (pin->monotonic_timestamp)
+   pin->timestamp = rtdm_clock_read_monotonic();
+   else
+   pin->timestamp = rtdm_clock_read();
rtdm_event_signal(&pin->event);

return 0;
-- 
2.31.1

Re: [PATCH RFC 1/2] cobalt/registry: Add a new virtual /proc file for dumping registry

[Jan Kiszka via Xenomai]

On 16.08.21 18:12, Florian Bezdeka wrote:
> Introducing /proc/xenomai/registry/dump which could be accessed by
> something like "cat" to dump the current registry. Like the "usage"
> file it is available when CONFIG_XENO_OPT_VFILE is enabled.
> 
> The main purpose of this file is providing some additional help when
> trying to find resource leaks triggered by Xenomai based applications.
> 
> Signed-off-by: Florian Bezdeka 
> ---
>  kernel/cobalt/registry.c | 35 +++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/kernel/cobalt/registry.c b/kernel/cobalt/registry.c
> index 816102f7a..8befa795c 100644
> --- a/kernel/cobalt/registry.c
> +++ b/kernel/cobalt/registry.c
> @@ -80,6 +80,23 @@ static int usage_vfile_show(struct 
> xnvfile_regular_iterator *it, void *data)
>   return 0;
>  }
>  
> +static int dump_vfile_show(struct xnvfile_regular_iterator *it, void *data)
> +{
> + struct xnobject *elem;
> + struct hlist_node *next;
> + int n;
> +
> + xnvfile_printf(it, "nr_object_entries: %d\n", nr_object_entries);
> + xnvfile_printf(it, "obj_idx[0]: \treserved\n");
> +
> + for (n = 0; n < nr_object_entries; n++)
> + hlist_for_each_entry_safe(elem, next, &object_index[n], hlink)
> + xnvfile_printf(it, "obj_idx[%d]:\tobj=%p, key=%s\n", n,
> +elem->objaddr, elem->key ?: "(anon)");
> +
> + return 0;
> +}
> +
>  static struct xnvfile_regular_ops usage_vfile_ops = {
>   .show = usage_vfile_show,
>  };
> @@ -88,6 +105,14 @@ static struct xnvfile_regular usage_vfile = {
>   .ops = &usage_vfile_ops,
>  };
>  
> +static struct xnvfile_regular_ops dump_vfile_ops = {
> + .show = dump_vfile_show,
> +};
> +
> +static struct xnvfile_regular dump_vfile = {
> + .ops = &dump_vfile_ops,
> +};
> +
>  #endif /* CONFIG_XENO_OPT_VFILE */
>  
>  unsigned xnregistry_hash_size(void)
> @@ -124,8 +149,16 @@ int xnregistry_init(void)
>   return ret;
>   }
>  
> + ret = xnvfile_init_regular("dump", &dump_vfile, ®istry_vfroot);
> + if (ret) {
> + xnvfile_destroy_regular(&usage_vfile);
> + xnvfile_destroy_dir(®istry_vfroot);
> + return ret;
> + }
> +
>   proc_virq = pipeline_create_inband_sirq(registry_proc_schedule);
>   if (proc_virq < 0) {
> + xnvfile_destroy_regular(&dump_vfile);
>   xnvfile_destroy_regular(&usage_vfile);
>   xnvfile_destroy_dir(®istry_vfroot);
>   return proc_virq;
> @@ -149,6 +182,7 @@ int xnregistry_init(void)
>  
>   if (object_index == NULL) {
>  #ifdef CONFIG_XENO_OPT_VFILE
> + xnvfile_destroy_regular(&dump_vfile);
>   xnvfile_destroy_regular(&usage_vfile);
>   xnvfile_destroy_dir(®istry_vfroot);
>   pipeline_delete_inband_sirq(proc_virq);
> @@ -199,6 +233,7 @@ void xnregistry_cleanup(void)
>  #ifdef CONFIG_XENO_OPT_VFILE
>   pipeline_delete_inband_sirq(proc_virq);
>   flush_scheduled_work();
> + xnvfile_destroy_regular(&dump_vfile);
>   xnvfile_destroy_regular(&usage_vfile);
>   xnvfile_destroy_dir(®istry_vfroot);
>  #endif /* CONFIG_XENO_OPT_VFILE */
> 

We need something like this, I'm just wondering if we shouldn't make the
missing information available in a similar way like the already
published one (drivers/ipc), also to avoid duplicating things this way.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH RFC 2/2] cobalt/registry: Adding trace events for registry_{enter,unlink,remove}

[Jan Kiszka via Xenomai]

On 16.08.21 18:12, Florian Bezdeka wrote:
> Adding the following trace events to make registry-usage traceable:
>   - registry_enter   (object gets added to the registry)
>   - registry_unlink  (object is made anonymous)
>   - registry_remove  (object is removed from the registry)
> 
> These trace events are helpful if there is a need to track down
> resource leaks triggered by an Xenomai based application.
> 
> Signed-off-by: Florian Bezdeka 
> ---
>  kernel/cobalt/registry.c  |  5 +
>  kernel/cobalt/trace/cobalt-core.h | 33 +++
>  2 files changed, 38 insertions(+)
> 
> diff --git a/kernel/cobalt/registry.c b/kernel/cobalt/registry.c
> index 8befa795c..c20c4cc1a 100644
> --- a/kernel/cobalt/registry.c
> +++ b/kernel/cobalt/registry.c
> @@ -685,6 +685,7 @@ int xnregistry_enter(const char *key, void *objaddr,
>   nr_active_objects++;
>   object->objaddr = objaddr;
>   object->cstamp = ++next_object_stamp;
> + trace_cobalt_registry_enter(key, objaddr);
>  #ifdef CONFIG_XENO_OPT_VFILE
>   object->pnode = NULL;
>  #endif
> @@ -866,6 +867,8 @@ int xnregistry_remove(xnhandle_t handle)
>   goto unlock_and_exit;
>   }
>  
> + trace_cobalt_registry_remove(object->key, object->objaddr);
> +
>   objaddr = object->objaddr;
>   object->objaddr = NULL;
>   object->cstamp = 0;
> @@ -932,6 +935,8 @@ int xnregistry_unlink(const char *key)
>   goto unlock_and_exit;
>   }
>  
> + trace_cobalt_registry_unlink(object->key, object->objaddr);
> +
>   ret = registry_hash_remove(object);
>   if (ret < 0)
>   goto unlock_and_exit;
> diff --git a/kernel/cobalt/trace/cobalt-core.h 
> b/kernel/cobalt/trace/cobalt-core.h
> index 88ed5700d..d98787c5a 100644
> --- a/kernel/cobalt/trace/cobalt-core.h
> +++ b/kernel/cobalt/trace/cobalt-core.h
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  struct xnsched;
> @@ -149,6 +150,23 @@ DECLARE_EVENT_CLASS(timer_event,
>   TP_printk("timer=%p", __entry->timer)
>  );
>  
> +DECLARE_EVENT_CLASS(registry_event,
> + TP_PROTO(const char *key, void *addr),
> + TP_ARGS(key, addr),
> +
> + TP_STRUCT__entry(
> + __string(key, key ?: "(anon)")
> + __field(void *, addr)
> + ),
> +
> + TP_fast_assign(
> + __assign_str(key, key ?: "(anon)");
> + __entry->addr = addr;
> + ),
> +
> + TP_printk("key=%s, addr=%p", __get_str(key), __entry->addr)
> +);
> +
>  TRACE_EVENT(cobalt_schedule,
>   TP_PROTO(struct xnsched *sched),
>   TP_ARGS(sched),
> @@ -778,6 +796,21 @@ DEFINE_EVENT(synch_post_event, cobalt_synch_forget,
>   TP_ARGS(synch)
>  );
>  
> +DEFINE_EVENT(registry_event, cobalt_registry_enter,
> + TP_PROTO(const char *key, void *addr),
> + TP_ARGS(key, addr)
> +);
> +
> +DEFINE_EVENT(registry_event, cobalt_registry_remove,
> + TP_PROTO(const char *key, void *addr),
> + TP_ARGS(key, addr)
> +);
> +
> +DEFINE_EVENT(registry_event, cobalt_registry_unlink,
> + TP_PROTO(const char *key, void *addr),
> + TP_ARGS(key, addr)
> +);
> +
>  TRACE_EVENT(cobalt_tick_shot,
>   TP_PROTO(s64 delta),
>   TP_ARGS(delta),
> 

Thanks, applied to next.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH 0/2] Allow GPIO timestamps also via real-time clock

[Jan Kiszka via Xenomai]

On 16.08.21 12:18, Jan Kiszka via Xenomai wrote:
> 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(-)
> 

BTW, as I do not have a test setup for this in reach, I definitely need
someone to test this and let us know that it works as desired.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH RFC 2/2] cobalt/registry: Adding trace events for registry_{enter,unlink,remove}

[Jan Kiszka via Xenomai]

On 17.08.21 08:09, Jan Kiszka via Xenomai wrote:
> On 16.08.21 18:12, Florian Bezdeka wrote:
>> Adding the following trace events to make registry-usage traceable:
>>   - registry_enter   (object gets added to the registry)
>>   - registry_unlink  (object is made anonymous)
>>   - registry_remove  (object is removed from the registry)
>>
>> These trace events are helpful if there is a need to track down
>> resource leaks triggered by an Xenomai based application.
>>
>> Signed-off-by: Florian Bezdeka 
>> ---
>>  kernel/cobalt/registry.c  |  5 +
>>  kernel/cobalt/trace/cobalt-core.h | 33 +++
>>  2 files changed, 38 insertions(+)
>>
>> diff --git a/kernel/cobalt/registry.c b/kernel/cobalt/registry.c
>> index 8befa795c..c20c4cc1a 100644
>> --- a/kernel/cobalt/registry.c
>> +++ b/kernel/cobalt/registry.c
>> @@ -685,6 +685,7 @@ int xnregistry_enter(const char *key, void *objaddr,
>>  nr_active_objects++;
>>  object->objaddr = objaddr;
>>  object->cstamp = ++next_object_stamp;
>> +trace_cobalt_registry_enter(key, objaddr);
>>  #ifdef CONFIG_XENO_OPT_VFILE
>>  object->pnode = NULL;
>>  #endif
>> @@ -866,6 +867,8 @@ int xnregistry_remove(xnhandle_t handle)
>>  goto unlock_and_exit;
>>  }
>>  
>> +trace_cobalt_registry_remove(object->key, object->objaddr);
>> +
>>  objaddr = object->objaddr;
>>  object->objaddr = NULL;
>>  object->cstamp = 0;
>> @@ -932,6 +935,8 @@ int xnregistry_unlink(const char *key)
>>  goto unlock_and_exit;
>>  }
>>  
>> +trace_cobalt_registry_unlink(object->key, object->objaddr);
>> +
>>  ret = registry_hash_remove(object);
>>  if (ret < 0)
>>  goto unlock_and_exit;
>> diff --git a/kernel/cobalt/trace/cobalt-core.h 
>> b/kernel/cobalt/trace/cobalt-core.h
>> index 88ed5700d..d98787c5a 100644
>> --- a/kernel/cobalt/trace/cobalt-core.h
>> +++ b/kernel/cobalt/trace/cobalt-core.h
>> @@ -26,6 +26,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  
>>  struct xnsched;
>> @@ -149,6 +150,23 @@ DECLARE_EVENT_CLASS(timer_event,
>>  TP_printk("timer=%p", __entry->timer)
>>  );
>>  
>> +DECLARE_EVENT_CLASS(registry_event,
>> +TP_PROTO(const char *key, void *addr),
>> +TP_ARGS(key, addr),
>> +
>> +TP_STRUCT__entry(
>> +__string(key, key ?: "(anon)")
>> +__field(void *, addr)
>> +),
>> +
>> +TP_fast_assign(
>> +__assign_str(key, key ?: "(anon)");
>> +__entry->addr = addr;
>> +),
>> +
>> +TP_printk("key=%s, addr=%p", __get_str(key), __entry->addr)
>> +);
>> +
>>  TRACE_EVENT(cobalt_schedule,
>>  TP_PROTO(struct xnsched *sched),
>>  TP_ARGS(sched),
>> @@ -778,6 +796,21 @@ DEFINE_EVENT(synch_post_event, cobalt_synch_forget,
>>  TP_ARGS(synch)
>>  );
>>  
>> +DEFINE_EVENT(registry_event, cobalt_registry_enter,
>> +TP_PROTO(const char *key, void *addr),
>> +TP_ARGS(key, addr)
>> +);
>> +
>> +DEFINE_EVENT(registry_event, cobalt_registry_remove,
>> +TP_PROTO(const char *key, void *addr),
>> +TP_ARGS(key, addr)
>> +);
>> +
>> +DEFINE_EVENT(registry_event, cobalt_registry_unlink,
>> +TP_PROTO(const char *key, void *addr),
>> +TP_ARGS(key, addr)
>> +);
>> +
>>  TRACE_EVENT(cobalt_tick_shot,
>>  TP_PROTO(s64 delta),
>>  TP_ARGS(delta),
>>
> 
> Thanks, applied to next.
> 
> Jan
> 

Fixed up a missing include in registry.c.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: Question regarding RTnet Ethernet Driver with PCIe MSI interrupts

[Jan Kiszka via Xenomai]

On 17.08.21 22:01, Jeroen Van den Keybus via Xenomai wrote:
> FWIW, in the past I have worked with e1000 NICs in RTnet that registered
> their MSI interrupt with the kernel.
> 
> I do not recall that I had to do anything out of the ordinary.
> 

The main difference was likely that you were on x86 while Scott is
dealing with an i.MX6-based SoC.

I'm not familiar with the details of MSI routing on that target. If I
quickly understand arch/arm/boot/dts/imx6qdl.dtsi correctly, all MSIs
will be folded by the PCI host controller into a single SPI (120), the
only interrupt source that old SoC understands. In that case, you need
to make sure that this SPI is handled by I-pipe and, indeed, it treated
as muxing IRQ. But I have no idea how the demuxing will happen in
details. You likely need to study and then patch the PCI host controller
driver.

Jan

> 
> Op di 17 aug. 2021 om 15:37 schreef Reed, Scott via Xenomai <
> xenomai@xenomai.org>:
> 
>>
>>
>> Scott Reed
>> Senior Software Engineer
>> direct +497031622263
>>
>> Moog Industrial Group
>> Moog GmbH
>> Hanns-Klemm-Strasse 28
>> 71034 Böblingen
>> Deutschland
>> http://www.moog.com/industrial
>>
>>
>> ___
>>
>>
>>
>> Moog GmbH, Hanns-Klemm-Strasse 28, 71034 Böblingen, Deutschland,
>> Handelsregister: Amtsgericht Stuttgart HRB 240301,
>> Geschäftsführer: Thomas Czeppel, Johannes (Pim) van den Dijssel
>>
>>
>>
>>> -Original Message-
>>> From: Xenomai  On Behalf Of Reed, Scott
>>> via Xenomai
>>> Sent: Thursday, August 5, 2021 19:09
>>> To: xenomai@xenomai.org
>>> Subject: [EXTERNAL] Question regarding RTnet Ethernet Driver with PCIe
>> MSI
>>> interrupts
>>>
>>> Hello,
>>>
>>> About a year ago, I ported an Ethernet driver we use to be an RTnet
>>> driver. In general everything is working, but we have run into a
>>> recent problem which looks like it might be being caused by high
>>> Ethernet receive interrupt latencies.
>>>
>>> The Ethernet interrupts come in as PCIe MSI interrupts and I
>>> implemented the potentially creative but bad solution of
>>> modifying the PCIe driver to distribute the MSI interrupts
>>> to i-ipipe be replacing the call to "generic_handle_irq" with
>>> a call to "ipipe_handle_demuxed_irq".
>>>
>>> I am thinking that this was maybe not the best approach and the
>>> correct solution would be to modify the PCIe driver so that the
>>> original MSI interrupt is an RTDM interrupt as if it is not
>>> this could be causing the high interrupt latencies.
>>>
>>> Is my thinking in the right direction or completely off?
>>
>> I did not receive any feedback from the forum (maybe I made
>> a mistake in my post as it was my first post), but in case someone
>> else runs across this thread and has a similar issue...
>>
>> I modified the PCIe driver so that the MSI interrupt is an
>> RTDM interrupt (i.e. registered interrupt with rtdm_irq_request()
>> as opposed to with devm_request_irq()) and this solved my problem
>> of seeing latencies (i.e. delays) in the handling of the Ethernet receive
>> interrupts (which are packaged in the PCIe MSI interrupt).
>>
>> Since my Ethernet receive interrupts (and transmit interrupts) are also
>> registered as RTDM Interrupts, I needed to keep my original PCIe driver
>> modification that MSI interrupts are distributed in dw_handle_msi_irq()
>> using "ipipe_handle_demuxed_irq" instead of "generic_handle_irq".
>>
>> I assume it would probably also work to register the Ethernet interrupts
>> as "normal Linux" interrupts and then the this modification would not
>> be necessary, but I did not verify this and prefer to have the Ethernet
>> interrupts as RTDM interrupts so the driver is correct whether or not
>> it is "behind" an PCIe MSI interrupt or not.
>>
>> If anyone would like more details, I can gladly provide them.
>>
>> Regards,
>>
>> Scott
>>
>>>
>>> Background information
>>> 
>>> Processor: iMx6 Quad
>>> Linux 4.14.62
>>> Xenomai 3.0.7
>>>
>>> Thanks in advance for any advice.
>>>
>>> Regards,
>>>
>>> Scott
>>
>> Hinweis auf Vertraulichkeit: Diese elektronisch übermittelte Nachricht ist
>> nur für die natürliche oder juristische Person bestimmt, die als Empfänger
>> genannt ist; sie kann vertrauliche Informationen oder Betriebsgeheimnisse
>> enthalten, die Eigentum des Absenders sind. Für den Fall, dass Sie nicht
>> der genannte Empfänger sind, ist Ihnen jede Offenlegung, Verwendung,
>> Vervielfältigung oder Weiterleitung des Inhalts dieser Informationen streng
>> untersagt. Dasselbe gilt für alle Handlungen, die sich auf den Inhalt
>> dieser Informationen gründen. Falls Sie diese Nachricht irrtümlicherweise
>> erhalten haben, bitten wir Sie, den Absender umgehend per E-Mail darüber in
>> Kenntnis zu setzen und die ursprüngliche Nachricht zu löschen. Wir danken
>> Ihnen für Ihre Kooperation.
>>
>> Confidentiality Notice: This electronic mail transmission is intended for
>> the use of the individual or 

Re: [RFC PATCH 0/4] Export mqueues to procfs

[Jan Kiszka via Xenomai]

On 18.08.21 13:24, Florian Bezdeka wrote:
> Hi,
> 
> this is another try to make registered mqueues visible. This time by
> exporting them to the procfs, namely to
> /proc/xenomai/registry/mqueue/
> 
> Let me know what you think... 
> 
> I had to rework the existing export machinery a bit to get rid of the so
> called "root" directory which is normally created. See patch
> descriptions for details.
> 
> Best regards,
> Florian
> 
> Florian Bezdeka (4):
>   cobalt/registry: Make the root directory for proc exports optional
>   cobalt/registry: Share xnregistry_vfreg_ops with other compile units
>   cobalt/registry: Initialize refcnt of exported virtual proc files
>   cobalt/mqueue: Export created mqueues to procfs
> 
>  include/cobalt/kernel/registry.h |  2 ++
>  kernel/cobalt/posix/mqueue.c | 35 +++-
>  kernel/cobalt/registry.c | 13 ++--
>  3 files changed, 43 insertions(+), 7 deletions(-)
> 

Will have a look.

We likely then also want the same for pshared semaphores, right?
Anything else that could get a name (which may collide or become orphaned)?

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [EXTERNAL] Re: Question regarding RTnet Ethernet Driver with PCIe MSI interrupts

[Jan Kiszka via Xenomai]

On 18.08.21 12:15, Reed, Scott via Xenomai wrote:
>> -Original Message-
>> From: Jan Kiszka 
>> Sent: Wednesday, August 18, 2021 08:22
>> To: Jeroen Van den Keybus ; Reed,
>> Scott 
>> Cc: xenomai@xenomai.org
>> Subject: [EXTERNAL] Re: Question regarding RTnet Ethernet Driver with PCIe
>> MSI interrupts
>>
>> On 17.08.21 22:01, Jeroen Van den Keybus via Xenomai wrote:
>>> FWIW, in the past I have worked with e1000 NICs in RTnet that
>>> registered their MSI interrupt with the kernel.
>>>
>>> I do not recall that I had to do anything out of the ordinary.
>>>
>>
>> The main difference was likely that you were on x86 while Scott is dealing
>> with an i.MX6-based SoC.
>>
>> I'm not familiar with the details of MSI routing on that target. If I quickly
>> understand arch/arm/boot/dts/imx6qdl.dtsi correctly, all MSIs will be folded
>> by the PCI host controller into a single SPI (120), the only interrupt source
>> that old SoC understands. In that case, you need to make sure that this SPI 
>> is
>> handled by I-pipe and, indeed, it treated as muxing IRQ. But I have no idea
>> how the demuxing will happen in details. You likely need to study and then
>> patch the PCI host controller driver.
>>
>> Jan
> 
> That is correct that I am working with an iMX6-based SoC.
> 
> For anyone who might face similar issues, for information here is my patch to
> the Linux 4.14.62 PCI host controller (Xenomai 3.0.7 patch already applied).
> 

Patch got mangled, as you can see below. Seems your client or server
decided to have tabs for lunch today.

> Regards,
> 
> Scott
> 
> Subject: [PATCH] Modify PCI MSI interrupts for Xenomai RTDM
> 
> Since we have Xenomai RTDM drivers which are "tied" to PCI MSI
> interrupts (e.g. Altera TSE driver), we need to also make the PCI MSI
> interrupt an RTDM interrupt to avoid latency when the PCI MSI interrupt
> is serviced.
> 
> Since we have Xenomai RTDM drivers which are "tied" to PCI MSI
> interrupts (e.g. Altera TSE driver), we need to first pass the MSI
> interrupt to the i-ipipe handler. If there is not an RTDM driver for
> the interrupt, then the i-pipe handler calls generic_handle_irq.
> ---
>  drivers/pci/dwc/pci-imx6.c | 17 ++---
>  drivers/pci/dwc/pcie-designware-host.c |  2 +-
>  2 files changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c
> index b7348353..65eb9ba5 100644
> --- a/drivers/pci/dwc/pci-imx6.c
> +++ b/drivers/pci/dwc/pci-imx6.c
> @@ -33,6 +33,10 @@
> 
>  #include "pcie-designware.h"
> 
> +#include 
> +
> +static rtdm_irq_t pcie_msi_irq_handle;
> +
>  #define to_imx6_pcie(x)dev_get_drvdata((x)->dev)
> 
>  enum imx6_pcie_variants {
> @@ -545,13 +549,14 @@ static int imx6_pcie_wait_for_speed_change(struct 
> imx6_pcie *imx6_pcie)
>  return -EINVAL;
>  }
> 
> -static irqreturn_t imx6_pcie_msi_handler(int irq, void *arg)
> +static int imx6_pcie_msi_handler_rtdm(rtdm_irq_t *irq_handle)
>  {
> -struct imx6_pcie *imx6_pcie = arg;
> +struct imx6_pcie *imx6_pcie = rtdm_irq_get_arg(irq_handle, struct imx6_pcie);
>  struct dw_pcie *pci = imx6_pcie->pci;
>  struct pcie_port *pp = &pci->pp;
> 
> -return dw_handle_msi_irq(pp);
> +dw_handle_msi_irq(pp);
> +return RTDM_IRQ_HANDLED;

Nasty - if dw_handle_msi_irq decides to return UNHANDLED...

>  }
> 
>  static int imx6_pcie_establish_link(struct imx6_pcie *imx6_pcie)
> @@ -678,10 +683,8 @@ static int imx6_add_pcie_port(struct imx6_pcie 
> *imx6_pcie,
>  return -ENODEV;
>  }
> 
> -ret = devm_request_irq(dev, pp->msi_irq,
> -   imx6_pcie_msi_handler,
> -   IRQF_SHARED | IRQF_NO_THREAD,
> -   "mx6-pcie-msi", imx6_pcie);
> +ret = rtdm_irq_request(&pcie_msi_irq_handle, pp->msi_irq, 
> imx6_pcie_msi_handler_rtdm,
> +RTDM_IRQTYPE_SHARED, "mx6-pcie-msi", imx6_pcie);
>  if (ret) {
>  dev_err(dev, "failed to request MSI irq\n");
>  return ret;
> diff --git a/drivers/pci/dwc/pcie-designware-host.c 
> b/drivers/pci/dwc/pcie-designware-host.c
> index a5b8dd07..d0af2cfa 100644
> --- a/drivers/pci/dwc/pcie-designware-host.c
> +++ b/drivers/pci/dwc/pcie-designware-host.c
> @@ -72,7 +72,7 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
>  while ((pos = find_next_bit((unsigned long *) &val, 32,
>  pos)) != 32) {
>  irq = irq_find_mapping(pp->irq_domain, i * 32 + pos);
> -generic_handle_irq(irq);
> +ipipe_handle_demuxed_irq(irq);
>  dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_STATUS + i * 12,
>  4, 1 << pos);
>  pos++;

This function and likely more will no run in primary domain. But, if you
are unlucky, it may still used Linux locking or other incompatible
calls. Did you check, e.g by enabling I-pipe debugging or by careful
code inspection, if there is no such call remaining? It's a classic if
that is a trigger for lockups etc.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [RFC PATCH 1/4] cobalt/registry: Make the root directory for proc exports optional

[Jan Kiszka via Xenomai]

On 18.08.21 16:11, Bezdeka, Florian (T RDA IOT SES-DE) wrote:
> On Wed, 2021-08-18 at 16:02 +0200, Philippe Gerum wrote:
>> Bezdeka, Florian  writes:
>>
>>> On Wed, 2021-08-18 at 15:26 +0200, Philippe Gerum wrote:
 Florian Bezdeka via Xenomai  writes:

> Previously the root directory was mandatory, which means that exports
> to the proc file system were forced to be located in
> /proc/xenomai/registry///.
>
> The  virtual directory is now optional. If not supplied the
> root node of  is set to registry_vfroot, which represents
> /proc/xenomai/registry.

 This is not needed. You may want to try something along these lines
 (excerpt from the Xenomai 2 implementation the registry originates from,
 with a few adaptations for readability, ksrc/skins/native/queue.c):

 static DEFINE_XNPTREE(__queue_ptree, "native");

 static struct xnpnode_snapshot __q_pnode = {
   .node = {
   .dirname = "queues",
   .root = &__queue_ptree,
   .ops = &xnregistry_vfsnap_ops,
   },
   .vfile = {
   .privsz = sizeof(struct vfile_priv),
   .datasz = sizeof(struct vfile_data),
   .ops = &vfile_ops,
   },
 };

 ...

 xnregistry_enter(q->name, q, &q->handle, &__q_pnode.node);

 With this, you would get the /proc/xenomai/registry/queues root
 directory for queues created automatically, the way the registry wants
 it to be done.

>>>
>>> I tried exactly that, but ended up all queues to be visible in
>>> /proc/xenomai/registry/native/queues/ which was not what I wanted
>>> to achieve.
>>>
>>> But if you tell me that there must be an additional subdirectory, I'm
>>> fine with it...
>>>
>>
>> DEFINE_XNPTREE(rtipc_ptree, "rtipc") already exists in the hierarchy,
>> with protocols attached underneath. The current registry still exhibits
>> some Xenomai 2 legacy, which would have one root per interface (native,
>> posix, vxworks etc.)
>>
>> So, you could either graft your mqueue hierarchy directly under the
>> registry root the way your patch does, or reshuffle the whole thing a
>> bit in order to account for a new set of object families, like POSIX
>> (incl. mqueues), rtdm and other namespaces for some drivers if you plan
>> to export more objects in the future.
>>
>> The point being that POSIX and RTDM for instance both implement
>> semaphores and threads. So either living with /proc/registry/posix_sema4
>> _and_ /proc/registry/rtdm_sema4 is ok with you, otherwise you may go for
>> keeping toplevel categories so as to have /proc/registry/posix/sema4 and
>> /proc/registry/rtdm/sema4.
>>
> 
> Thanks a lot for the explanation. I wasn't aware that rtdm is providing
> it's own semaphores. That's no problem for the mqueues in patch 4, but
> as we still would need something similar for semaphores we would have
> some kind of collision.

RTDM does have semaphores but those are not registered, specifically not
by any name.

Jan

> 
> So there is one single question open for me: What is the correct name
> for the "root" directory in this case. "posix"?
> 
> I will resend a v2 which should consist of less patches. At least patch
> 1 (the one we are discussing here) should vanish.
> 
> Thanks!
> 
> Florian
> 

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: cobalt_assert_nrt should use __cobalt_pthread_kill

[Jan Kiszka via Xenomai]

On 19.08.21 11:56, Lange Norbert via Xenomai wrote:
> Hello,
> 
> I have some small slight issue with the cobalt_assert_nrt function,
> incase a violation is detected the thread should get a signal,
> but the implementation will implicitly get a signal during the execution of 
> pthread_kill, see:
> 
> 
> #0  getpid () at ../sysdeps/unix/syscall-template.S:60
> #1  0x7fc1dc4fa0d6 in __pthread_kill (threadid=, signo=24) 
> at ../sysdeps/unix/sysv/linux/pthread_kill.c:53
> #2  0x7fc1dc8b2470 in callAssertFunction () at 
> /home/lano/git/preload_checkers/src/pchecker.h:199
> #3  malloc () at /home/lano/git/preload_checkers/src/pchecker_heap_glibc.c:220
> #4 
> 
> You see, the signal should happen with the pc of #2, not from the 
> implementation of glibc (or whatever c library).
> So the function should be changed to:
> 
> void cobalt_assert_nrt(void)
> {
> if (cobalt_should_warn())
> __cobalt_pthread_kill(pthread_self(), SIGDEBUG);
> }
> 
> (or even replaced with the raw syscall ?)
> 

Hmm, that's similar to an assert causing a lengthy trace, not failing
directly at the place where the assert was raised:

#0  0x77a3918b in raise () from /lib64/libc.so.6
#1  0x77a3a585 in abort () from /lib64/libc.so.6
#2  0x77a3185a in __assert_fail_base () from /lib64/libc.so.6
#3  0x77a318d2 in __assert_fail () from /lib64/libc.so.6
#4  0x00400524 in main () at assert.c:5

What is your practical problem with the current implementation? Do you
expect a specific SIGDEBUG reason?

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: cobalt_assert_nrt should use __cobalt_pthread_kill

[Jan Kiszka via Xenomai]

On 19.08.21 17:24, Lange Norbert wrote:
> 
> 
>> -Original Message-
>> From: Jan Kiszka 
>> Sent: Donnerstag, 19. August 2021 12:54
>> To: Lange Norbert ; Xenomai
>> (xenomai@xenomai.org) 
>> Subject: Re: cobalt_assert_nrt should use __cobalt_pthread_kill
>>
>>
>>
>> CAUTION: External email. Do not click on links or open attachments unless you
>> know the sender and that the content is safe.
>>
>> On 19.08.21 11:56, Lange Norbert via Xenomai wrote:
>>> Hello,
>>>
>>> I have some small slight issue with the cobalt_assert_nrt function,
>>> incase a violation is detected the thread should get a signal, but the
>>> implementation will implicitly get a signal during the execution of
>> pthread_kill, see:
>>>
>>>
>>> #0  getpid () at ../sysdeps/unix/syscall-template.S:60
>>> #1  0x7fc1dc4fa0d6 in __pthread_kill (threadid=,
>>> signo=24) at ../sysdeps/unix/sysv/linux/pthread_kill.c:53
>>> #2  0x7fc1dc8b2470 in callAssertFunction () at
>>> /home/lano/git/preload_checkers/src/pchecker.h:199
>>> #3  malloc () at
>>> /home/lano/git/preload_checkers/src/pchecker_heap_glibc.c:220
>>> #4 
>>>
>>> You see, the signal should happen with the pc of #2, not from the
>> implementation of glibc (or whatever c library).
>>> So the function should be changed to:
>>>
>>> void cobalt_assert_nrt(void)
>>> {
>>> if (cobalt_should_warn())
>>> __cobalt_pthread_kill(pthread_self(),
>>> SIGDEBUG); }
>>>
>>> (or even replaced with the raw syscall ?)
>>>
>>
>> Hmm, that's similar to an assert causing a lengthy trace, not failing 
>> directly at
>> the place where the assert was raised:
>>
>> #0  0x77a3918b in raise () from /lib64/libc.so.6
>> #1  0x77a3a585 in abort () from /lib64/libc.so.6
>> #2  0x77a3185a in __assert_fail_base () from /lib64/libc.so.6
>> #3  0x77a318d2 in __assert_fail () from /lib64/libc.so.6
>> #4  0x00400524 in main () at assert.c:5
>>
>> What is your practical problem with the current implementation? Do you
>> expect a specific SIGDEBUG reason?
> 
> A better stacktrace. (I actually cut the trace in the signal handler in case 
> of hitting an __assert_fail)

The backtrace should still point to the right function that caused the
migration. I miss cobalt_assert_nrt() in your backtrace though, but that
should have nothing to do with how it is implemented. Are you actually
using cobalt_assert_nrt() from libcobalt?

> BTW, __cobalt_pthread_kill(pthread_self(), SIGDEBUG) doesn’t seem to do a 
> thing, doesn’t handle SIGDEBUG?
> 

It only triggers the signal (in one way or another...). Handling is up
to the application. If you don't handle that, the application is
terminated, obviously.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: cobalt_assert_nrt should use __cobalt_pthread_kill

[Jan Kiszka via Xenomai]

On 19.08.21 18:54, Lange Norbert wrote:
> 
> 
>> -Original Message-
>> From: Jan Kiszka 
>> Sent: Donnerstag, 19. August 2021 17:42
>> To: Lange Norbert ; Xenomai
>> (xenomai@xenomai.org) 
>> Subject: Re: cobalt_assert_nrt should use __cobalt_pthread_kill
>>
>>
>>
>> CAUTION: External email. Do not click on links or open attachments unless you
>> know the sender and that the content is safe.
>>
>> On 19.08.21 17:24, Lange Norbert wrote:
>>>
>>>
 -Original Message-
 From: Jan Kiszka 
 Sent: Donnerstag, 19. August 2021 12:54
 To: Lange Norbert ; Xenomai
 (xenomai@xenomai.org) 
 Subject: Re: cobalt_assert_nrt should use __cobalt_pthread_kill



 CAUTION: External email. Do not click on links or open attachments
 unless you know the sender and that the content is safe.

 On 19.08.21 11:56, Lange Norbert via Xenomai wrote:
> Hello,
>
> I have some small slight issue with the cobalt_assert_nrt function,
> incase a violation is detected the thread should get a signal, but
> the implementation will implicitly get a signal during the execution
> of
 pthread_kill, see:
>
>
> #0  getpid () at ../sysdeps/unix/syscall-template.S:60
> #1  0x7fc1dc4fa0d6 in __pthread_kill (threadid=,
> signo=24) at ../sysdeps/unix/sysv/linux/pthread_kill.c:53
> #2  0x7fc1dc8b2470 in callAssertFunction () at
> /home/lano/git/preload_checkers/src/pchecker.h:199
> #3  malloc () at
> /home/lano/git/preload_checkers/src/pchecker_heap_glibc.c:220
> #4 
>
> You see, the signal should happen with the pc of #2, not from the
 implementation of glibc (or whatever c library).
> So the function should be changed to:
>
> void cobalt_assert_nrt(void)
> {
> if (cobalt_should_warn())
> __cobalt_pthread_kill(pthread_self(),
> SIGDEBUG); }
>
> (or even replaced with the raw syscall ?)
>

 Hmm, that's similar to an assert causing a lengthy trace, not failing
 directly at the place where the assert was raised:

 #0  0x77a3918b in raise () from /lib64/libc.so.6
 #1  0x77a3a585 in abort () from /lib64/libc.so.6
 #2  0x77a3185a in __assert_fail_base () from /lib64/libc.so.6
 #3  0x77a318d2 in __assert_fail () from /lib64/libc.so.6
 #4  0x00400524 in main () at assert.c:5

 What is your practical problem with the current implementation? Do
 you expect a specific SIGDEBUG reason?
>>>
>>> A better stacktrace. (I actually cut the trace in the signal handler
>>> in case of hitting an __assert_fail)
>>
>> The backtrace should still point to the right function that caused the 
>> migration.
>> I miss cobalt_assert_nrt() in your backtrace though, but that should have
>> nothing to do with how it is implemented. Are you actually using
>> cobalt_assert_nrt() from libcobalt?
> 
> Yes, but I dlsym it.
> I would prefer if the cobalt_assert_nrt would be the start of the trace.
> 

That it always does under normal constraints - please check your local
setup, this is not a generic problem. It's your pchecker.h:199 which
issues the syscall directly, rather than calling cobalt_assert_nrt().
Maybe that's because of lazy symbol resolution?

>>
>>> BTW, __cobalt_pthread_kill(pthread_self(), SIGDEBUG) doesn’t seem to do a
>> thing, doesn’t handle SIGDEBUG?
>>>
>>
>> It only triggers the signal (in one way or another...). Handling is up to the
>> application. If you don't handle that, the application is terminated, 
>> obviously.
> 
> The application continues running. But I did not try with 
> __cobalt_pthread_kill(pthread_self(), SIGDEBUG)
> but XENOMAI_SYSCALL2(sc_cobalt_thread_kill, thread, sig).
> Means the cobalt syscall is not handling the signal.

A syscall does not handle signals.

By calling the cobalt version of pthread_kill, you queue the signal for
synchronous RT processing (sigwait).

> 
> So for to satisfy my OCD toggling off/on the modeswitch signals would be 
> correct I guess
> 
> pthread_setmode_np(PTHREAD_WARNSW, 0, NULL);
> pthread_kill(pthread_self(), SIGDEBUG);
> pthread_setmode_np(0, PTHREAD_WARNSW, NULL);
> 
> or even just using a linux syscall:
> 
> getpid();

A syscall will remain the source of the signal, no change on the origin
of the backtrace.

> 
> Point being that right now you trap alteast twice

That is a different point. So far, you were complaining about getting a
wrong backtrace which is not caused by triggering a SIGDEBUG twice. If
you want to prevent a duplicate event, triggering a syscall only or
disabling the warning for the syscall itself can be options. But I
consider this really a minor issue.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: cobalt_assert_nrt should use __cobalt_pthread_kill

[Jan Kiszka via Xenomai]

On 20.08.21 10:52, Lange Norbert wrote:
> 
> 
>> -Original Message-
>> From: Jan Kiszka 
>> Sent: Freitag, 20. August 2021 08:37
>> To: Lange Norbert ; Xenomai
>> (xenomai@xenomai.org) 
>> Subject: Re: cobalt_assert_nrt should use __cobalt_pthread_kill
>>
>>
>>
>> CAUTION: External email. Do not click on links or open attachments unless you
>> know the sender and that the content is safe.
>>
>> On 19.08.21 18:54, Lange Norbert wrote:
>>>
>>>
 -Original Message-
 From: Jan Kiszka 
 Sent: Donnerstag, 19. August 2021 17:42
 To: Lange Norbert ; Xenomai
 (xenomai@xenomai.org) 
 Subject: Re: cobalt_assert_nrt should use __cobalt_pthread_kill



 CAUTION: External email. Do not click on links or open attachments
 unless you know the sender and that the content is safe.

 On 19.08.21 17:24, Lange Norbert wrote:
>
>
>> -Original Message-
>> From: Jan Kiszka 
>> Sent: Donnerstag, 19. August 2021 12:54
>> To: Lange Norbert ; Xenomai
>> (xenomai@xenomai.org) 
>> Subject: Re: cobalt_assert_nrt should use __cobalt_pthread_kill
>>
>>
>>
>> CAUTION: External email. Do not click on links or open attachments
>> unless you know the sender and that the content is safe.
>>
>> On 19.08.21 11:56, Lange Norbert via Xenomai wrote:
>>> Hello,
>>>
>>> I have some small slight issue with the cobalt_assert_nrt
>>> function, incase a violation is detected the thread should get a
>>> signal, but the implementation will implicitly get a signal during
>>> the execution of
>> pthread_kill, see:
>>>
>>>
>>> #0  getpid () at ../sysdeps/unix/syscall-template.S:60
>>> #1  0x7fc1dc4fa0d6 in __pthread_kill (threadid=>> out>,
>>> signo=24) at ../sysdeps/unix/sysv/linux/pthread_kill.c:53
>>> #2  0x7fc1dc8b2470 in callAssertFunction () at
>>> /home/lano/git/preload_checkers/src/pchecker.h:199
>>> #3  malloc () at
>>> /home/lano/git/preload_checkers/src/pchecker_heap_glibc.c:220
>>> #4 
>>>
>>> You see, the signal should happen with the pc of #2, not from the
>> implementation of glibc (or whatever c library).
>>> So the function should be changed to:
>>>
>>> void cobalt_assert_nrt(void)
>>> {
>>> if (cobalt_should_warn())
>>> __cobalt_pthread_kill(pthread_self(),
>>> SIGDEBUG); }
>>>
>>> (or even replaced with the raw syscall ?)
>>>
>>
>> Hmm, that's similar to an assert causing a lengthy trace, not
>> failing directly at the place where the assert was raised:
>>
>> #0  0x77a3918b in raise () from /lib64/libc.so.6
>> #1  0x77a3a585 in abort () from /lib64/libc.so.6
>> #2  0x77a3185a in __assert_fail_base () from
>> /lib64/libc.so.6
>> #3  0x77a318d2 in __assert_fail () from /lib64/libc.so.6
>> #4  0x00400524 in main () at assert.c:5
>>
>> What is your practical problem with the current implementation? Do
>> you expect a specific SIGDEBUG reason?
>
> A better stacktrace. (I actually cut the trace in the signal handler
> in case of hitting an __assert_fail)

 The backtrace should still point to the right function that caused the
>> migration.
 I miss cobalt_assert_nrt() in your backtrace though, but that should
 have nothing to do with how it is implemented. Are you actually using
 cobalt_assert_nrt() from libcobalt?
>>>
>>> Yes, but I dlsym it.
>>> I would prefer if the cobalt_assert_nrt would be the start of the trace.
>>>
>>
>> That it always does under normal constraints - please check your local setup,
>> this is not a generic problem. It's your pchecker.h:199 which issues the 
>> syscall
>> directly, rather than calling cobalt_assert_nrt().
>> Maybe that's because of lazy symbol resolution?
> 
> No, the start of the stacktrace is the first linux syscall resulting from the 
> pthread_kill
> Call (getpid() in my case)
> 
> Gdb has problems displaying the frame function, but it is cobalt_assert_nrt.
> I believe this happens if you use '-fno-plt'
> 

But this is a local problem. If your stack frame is not reliable, it
does not matter at all what exactly cobalt_assert_nrt does, you will
only spot the origin by chance, if at all.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: Time flies

[Jan Kiszka via Xenomai]

On 22.08.21 17:03, Philippe Gerum via Xenomai wrote:
> 
> Btw, Xenomai turned 20 two days ago [1]. Still lots of work ahead.
> 
> Cheers,
> 
> [1] https://www.mail-archive.com/rtl@fsmlabs.com/msg01156.html
> 

Wow, indeed - congrats to the project and its farther! Only 10 years
younger than the kernel itself...

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: Big jitter issues every 5 seconds

[Jan Kiszka via Xenomai]

On 20.08.21 19:14, Ivan Jiang via Xenomai wrote:
> Dear xenomai Oners:
> 
>  
> 
>    My name is Ivan and our company use xenomai 3.10 patched on Linux 
> 4.19.94 worked on Daul core Cortex A7 800MHz CPU.
> 
>    We used this solution to build an EtherCAT Master controller.
> 
>    With the isolcpus=1 nohz=on nohz_full=1  rcu_nocbs=1 the user space 
> latency waveforms is like below:
> 
>  
> 
>    Normally jitter is from -10~10uS every 1mS period,
> 
>    With a -30~30uS worst jitter every 200mS which made by our wifi AP 
> enabled on our A7 Core board, this one could be disappeared if we turned off 
> the WIFI.
> 
>    But the most unimaginable jitter is up to -55~55uS every 5S, which 
> could not find any reason,  that we closed all the peripherals on the board 
> except the EtherCAT.
> 
>    Whatever we turn on/off the L2 Cache or change the size of registry 
> slots and size of system heap / private heap / shared heap.
> 
>    Our biggest problems are why WIFI could influent the Jitters and the 
> biggest jitter every 5S is forbidden, we must get rid of them.
> 
>    Could you help us to analysis these questions.
> 

I'm afraid, 55 µs is already quite good for such a low-end system, even
with core isolation measures.

The last-level caches are typically shared (maybe lstopo can visualize
their hierachy), and the RT workload will likely not fit into core-local
L1 caches. So you cannot avoid eventual spikes already from that
perspective.

In addition, there are likely contention points on the I/O path of your
SoC - only the SoC vendor may be able to tell you where. One you
apparently found already (access to wifi vs. access to Ethernet or
something else on the RT I/O path).

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: Question regarding RTnet Ethernet Driver with PCIe MSI interrupts

[Jan Kiszka via Xenomai]

On 23.08.21 10:59, Scott Reed via Xenomai wrote:
>> -Original Message-
>> From: Jan Kiszka 
>>
>> On 18.08.21 12:15, Reed, Scott via Xenomai wrote:
 -Original Message-
 From: Jan Kiszka 

 On 17.08.21 22:01, Jeroen Van den Keybus via Xenomai wrote:
> FWIW, in the past I have worked with e1000 NICs in RTnet that
> registered their MSI interrupt with the kernel.
>
> I do not recall that I had to do anything out of the ordinary.
>

 The main difference was likely that you were on x86 while Scott is dealing
 with an i.MX6-based SoC.

 I'm not familiar with the details of MSI routing on that target. If I 
 quickly
 understand arch/arm/boot/dts/imx6qdl.dtsi correctly, all MSIs will be 
 folded
 by the PCI host controller into a single SPI (120), the only interrupt 
 source
 that old SoC understands. In that case, you need to make sure that this 
 SPI is
 handled by I-pipe and, indeed, it treated as muxing IRQ. But I have no idea
 how the demuxing will happen in details. You likely need to study and then
 patch the PCI host controller driver.

 Jan
>>>
>>> That is correct that I am working with an iMX6-based SoC.
>>>
>>> For anyone who might face similar issues, for information here is my patch 
>>> to
>>> the Linux 4.14.62 PCI host controller (Xenomai 3.0.7 patch already applied).
>>>
>>
>> Patch got mangled, as you can see below. Seems your client or server
>> decided to have tabs for lunch today.
>>
> Sorry about that! I have incorporated your suggestions from below
> and re-posted the patch hopefully this time not mangled.
>>> Regards,
>>>
>>> Scott
>>>
>>> Subject: [PATCH] Modify PCI MSI interrupts for Xenomai RTDM
>>>
>>> Since we have Xenomai RTDM drivers which are "tied" to PCI MSI
>>> interrupts (e.g. Altera TSE driver), we need to also make the PCI MSI
>>> interrupt an RTDM interrupt to avoid latency when the PCI MSI interrupt
>>> is serviced.
>>>
>>> Since we have Xenomai RTDM drivers which are "tied" to PCI MSI
>>> interrupts (e.g. Altera TSE driver), we need to first pass the MSI
>>> interrupt to the i-ipipe handler. If there is not an RTDM driver for
>>> the interrupt, then the i-pipe handler calls generic_handle_irq.
>>> ---
>>>   drivers/pci/dwc/pci-imx6.c | 17 ++---
>>>   drivers/pci/dwc/pcie-designware-host.c |  2 +-
>>>   2 files changed, 11 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c
>>> index b7348353..65eb9ba5 100644
>>> --- a/drivers/pci/dwc/pci-imx6.c
>>> +++ b/drivers/pci/dwc/pci-imx6.c
>>> @@ -33,6 +33,10 @@
>>>
>>>   #include "pcie-designware.h"
>>>
>>> +#include 
>>> +
>>> +static rtdm_irq_t pcie_msi_irq_handle;
>>> +
>>>   #define to_imx6_pcie(x)dev_get_drvdata((x)->dev)
>>>
>>>   enum imx6_pcie_variants {
>>> @@ -545,13 +549,14 @@ static int imx6_pcie_wait_for_speed_change(struct 
>>> imx6_pcie *imx6_pcie)
>>>   return -EINVAL;
>>>   }
>>>
>>> -static irqreturn_t imx6_pcie_msi_handler(int irq, void *arg)
>>> +static int imx6_pcie_msi_handler_rtdm(rtdm_irq_t *irq_handle)
>>>   {
>>> -struct imx6_pcie *imx6_pcie = arg;
>>> +struct imx6_pcie *imx6_pcie = rtdm_irq_get_arg(irq_handle, struct 
>>> imx6_pcie);
>>>   struct dw_pcie *pci = imx6_pcie->pci;
>>>   struct pcie_port *pp = &pci->pp;
>>>
>>> -return dw_handle_msi_irq(pp);
>>> +dw_handle_msi_irq(pp);
>>> +return RTDM_IRQ_HANDLED;
>>
>> Nasty - if dw_handle_msi_irq decides to return UNHANDLED...
>>
> Yes, I was lazy since I (incorrectly) assumed dw_handle_msi_irq always
> returns HANDLED and therefore did not process the return value.
> Is handled in new patch posted below.
>>>   }
>>>
>>>   static int imx6_pcie_establish_link(struct imx6_pcie *imx6_pcie)
>>> @@ -678,10 +683,8 @@ static int imx6_add_pcie_port(struct imx6_pcie 
>>> *imx6_pcie,
>>>   return -ENODEV;
>>>   }
>>>
>>> -ret = devm_request_irq(dev, pp->msi_irq,
>>> -   imx6_pcie_msi_handler,
>>> -   IRQF_SHARED | IRQF_NO_THREAD,
>>> -   "mx6-pcie-msi", imx6_pcie);
>>> +ret = rtdm_irq_request(&pcie_msi_irq_handle, pp->msi_irq, 
>>> imx6_pcie_msi_handler_rtdm,
>>> +RTDM_IRQTYPE_SHARED, "mx6-pcie-msi", imx6_pcie);
>>>   if (ret) {
>>>   dev_err(dev, "failed to request MSI irq\n");
>>>   return ret;
>>> diff --git a/drivers/pci/dwc/pcie-designware-host.c 
>>> b/drivers/pci/dwc/pcie-designware-host.c
>>> index a5b8dd07..d0af2cfa 100644
>>> --- a/drivers/pci/dwc/pcie-designware-host.c
>>> +++ b/drivers/pci/dwc/pcie-designware-host.c
>>> @@ -72,7 +72,7 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
>>>   while ((pos = find_next_bit((unsigned long *) &val, 32,
>>>   pos)) != 32) {
>>>   irq = irq_find_mapping(pp->irq_domain, i * 32 + pos);
>>> -generic_handle_irq(irq);
>>> +ipipe_handle_demuxed_irq(irq);
>>>   dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_STATUS + i * 12,
>>>   4, 1 << pos);
>>>   pos++;
>>
>> This function and likely more will no run in prim

Re: [PATCH 3/6] cobalt/registry: Adding a new xnptree for exporting posix entries

[Jan Kiszka via Xenomai]

On 23.08.21 17:00, Florian Bezdeka wrote:
> Will be used later for exporting named semaphores as well as mqueues
> to /proc/xenomai/registry/posix/{mqueue,sem}
> 
> Signed-off-by: Florian Bezdeka 
> ---
>  kernel/cobalt/registry.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/kernel/cobalt/registry.c b/kernel/cobalt/registry.c
> index 211e0f76f..3c67b64e6 100644
> --- a/kernel/cobalt/registry.c
> +++ b/kernel/cobalt/registry.c
> @@ -73,6 +73,8 @@ static int proc_virq;
>  
>  static struct xnvfile_directory registry_vfroot;
>  
> +DEFINE_XNPTREE(posix_ptree, "posix");
> +
>  static int usage_vfile_show(struct xnvfile_regular_iterator *it, void *data)
>  {
>   xnvfile_printf(it, "%u/%u\n",
> 

Better let kernel/cobalt/posix/process.c carry this.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH 4/6] cobalt/posix/mqueue: Export created mqueues to procfs

[Jan Kiszka via Xenomai]

On 23.08.21 17:00, Florian Bezdeka wrote:
> Exporting created mqueues to /proc/xenomai/registry/posix/mqueue helps
> to identify resource leaks by making mqueues visible. The content of all
> created virtual files is empty. Removal of such files is not possible
> and reports "operation not supported".
> 
> Signed-off-by: Florian Bezdeka 
> ---
>  kernel/cobalt/posix/mqueue.c | 38 +++-
>  1 file changed, 37 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/cobalt/posix/mqueue.c b/kernel/cobalt/posix/mqueue.c
> index ebe7cf7b0..72759e484 100644
> --- a/kernel/cobalt/posix/mqueue.c
> +++ b/kernel/cobalt/posix/mqueue.c
> @@ -87,6 +87,41 @@ static struct mq_attr default_attr = {
>  
>  static LIST_HEAD(cobalt_mqq);
>  
> +#ifdef CONFIG_XENO_OPT_VFILE
> +
> +extern struct xnptree posix_ptree;

kernel/cobalt/posix/internal.h

Jan

> +
> +static int mq_vfile_show(struct xnvfile_regular_iterator *it, void *data)
> +{
> + return 0;
> +}
> +
> +static struct xnvfile_regular_ops mq_vfile_ops = {
> + .show = mq_vfile_show,
> +};
> +
> +static struct xnpnode_regular __mq_pnode = {
> + .node = {
> + .dirname = "mqueue",
> + .root = &posix_ptree,
> + .ops = &xnregistry_vfreg_ops,
> + },
> + .vfile = {
> + .ops = &mq_vfile_ops,
> + },
> +};
> +
> +#else /* !CONFIG_XENO_OPT_VFILE */
> +
> +static struct xnpnode_link __mq_pnode = {
> + .node = {
> + .dirname = "mqueue",
> + }
> +};
> +
> +#endif /* !CONFIG_XENO_OPT_VFILE */
> +
> +
>  static inline struct cobalt_msg *mq_msg_alloc(struct cobalt_mq *mq)
>  {
>   if (list_empty(&mq->avail))
> @@ -352,7 +387,8 @@ static int mq_open(int uqd, const char *name, int oflags,
>   }
>  
>   xnlock_get_irqsave(&nklock, s);
> - err = xnregistry_enter(mq->name, mq, &mq->handle, NULL);
> + err = xnregistry_enter(mq->name, mq, &mq->handle,
> +&__mq_pnode.node);
>   if (err < 0)
>   --mq->refs;
>   else
> 

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH 6/6] testsuite/smokey/leaks: Add export checks for mqueues and named semaphores

[Jan Kiszka via Xenomai]

On 23.08.21 17:00, Florian Bezdeka wrote:
> Make sure mqueues and named semaphores are exported to the procfs if
> the kernel has procfs support activated.
> 
> While at it: The exit code of the child process was never correctly
> reported to the parent process. Hence, the status code check was wrong
> at all. The variable previously named subprocess_status was not shared
> between both processes.

The second part should better be separate.

Jan

> 
> Signed-off-by: Florian Bezdeka 
> ---
>  testsuite/smokey/leaks/leaks.c | 68 ++
>  1 file changed, 45 insertions(+), 23 deletions(-)
> 
> diff --git a/testsuite/smokey/leaks/leaks.c b/testsuite/smokey/leaks/leaks.c
> index d5577d85e..433dfcc17 100644
> --- a/testsuite/smokey/leaks/leaks.c
> +++ b/testsuite/smokey/leaks/leaks.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -71,6 +72,24 @@ const char *memdev[] = {
>  
>  static int memdevfd[3];
>  
> +static int procfs_exists(const char *type, const char *name)
> +{
> + struct stat s;
> + char path[128];
> + int ret;
> +
> + /* Ignore if the kernel seems to be compiled without procfs support */
> + if (stat("/proc/xenomai", &s) || !S_ISDIR(s.st_mode))
> + return 0;
> +
> + ret = snprintf(path, 128, "%s/%s/%s", "/proc/xenomai/registry/posix",
> +type, &name[1]);
> + if (ret < 0)
> + return -EINVAL;
> +
> + return smokey_check_errno(stat(path, &s));
> +}
> +
>  static unsigned long long get_used(void)
>  {
>   struct cobalt_memdev_stat statbuf;
> @@ -91,9 +110,7 @@ static void *empty(void *cookie)
>   return cookie;
>  }
>  
> -static int subprocess_status;
> -
> -static inline void subprocess_leak(void)
> +static inline int subprocess_leak(void)
>  {
>   struct sigevent sevt;
>   pthread_mutex_t mutex;
> @@ -105,36 +122,44 @@ static inline void subprocess_leak(void)
>  
>   ret = smokey_check_status(pthread_create(&thread, NULL, empty, NULL));
>   if (ret)
> - goto fail;
> + return ret;
>   
>   ret = smokey_check_status(pthread_mutex_init(&mutex, NULL));
>   if (ret)
> - goto fail;
> + return ret;
>   
>   ret = smokey_check_status(pthread_cond_init(&cond, NULL));
>   if (ret)
> - goto fail;
> + return ret;
>  
>   ret = smokey_check_errno(sem_init(&sem, 0, 0));
>   if (ret)
> - goto fail;
> + return ret;
>  
>   ret = smokey_check_errno(-!(sem_open(SEM_NAME, O_CREAT, 0644, 1)));
>   if (ret)
> - goto fail;
> + return ret;
> +
> + ret = procfs_exists("sem", SEM_NAME);
> + if (ret)
> + return ret;
>  
>   sevt.sigev_notify = SIGEV_THREAD_ID;
>   sevt.sigev_signo = SIGALRM;
>   sevt.sigev_notify_thread_id = syscall(__NR_gettid);
>   ret = smokey_check_errno(timer_create(CLOCK_MONOTONIC, &sevt, &tm));
>   if (ret)
> - goto fail;
> - 
> + return ret;
> +
>   ret = smokey_check_errno(mq_open(MQ_NAME, O_RDWR | O_CREAT, 0644, 
> NULL));
> - if (ret >= 0)
> - return;
> -fail:
> - subprocess_status = ret;
> + if (ret < 0)
> + return ret;
> +
> + ret = procfs_exists("mqueue", MQ_NAME);
> + if (ret)
> + return ret;
> +
> + return 0;
>  }
>  
>  static int run_leaks(struct smokey_test *t, int argc, char *const argv[])
> @@ -143,7 +168,7 @@ static int run_leaks(struct smokey_test *t, int argc, 
> char *const argv[])
>   struct sigevent sevt;
>   pthread_mutex_t mutex;
>   pthread_cond_t cond;
> - int fd, failed = 0, i, ret;
> + int fd, failed = 0, i, ret, child_ret;
>   pthread_t thread;
>   sem_t sem, *psem;
>   timer_t tm;
> @@ -235,11 +260,9 @@ static int run_leaks(struct smokey_test *t, int argc, 
> char *const argv[])
>   child = smokey_check_errno(fork());
>   if (child < 0)
>   return child;
> - if (!child) {
> - subprocess_leak();
> - exit(EXIT_SUCCESS);
> - }
> - while (waitpid(child, NULL, 0) == -1 && errno == EINTR);
> + if (!child)
> + exit(subprocess_leak());
> + while (waitpid(child, &child_ret, 0) == -1 && errno == EINTR);
>   sleep(1);
>  
>   ret = smokey_check_errno(sem_unlink(SEM_NAME));
> @@ -248,9 +271,8 @@ static int run_leaks(struct smokey_test *t, int argc, 
> char *const argv[])
>   ret = smokey_check_errno(mq_unlink(MQ_NAME));
>   if (ret)
>   return ret;
> - if (subprocess_status)
> - return subprocess_status;
> - 
> + if (WIFEXITED(child_ret) && WEXITSTATUS(child_ret))
> + return -WEXITSTATUS(child_ret);
>   check_used("fork", before, failed);
>  #endif
>  
> 

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: Can I use ftrace to analysis cobalt kernel

[Jan Kiszka via Xenomai]

On 24.08.21 14:48, Ivan Jiang via Xenomai wrote:
> Dear guys:
> 
>  
> 
>    Can I use ftrace to analysis the kernel with patch of ipipe.
> 
>    I find if use function_graph whe kernel will crash like below:
> 
>    echo function_graph > current_tracer
> 
> root@smarc-rzg2l:/sys/kernel/debug/tracing# [  377.392724] Kernel panic - not 
> syncing: kernel stack overflow
> 
> [  377.399125] CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 
> 4.19.140-cip33-g6634f0243a91 #3
> 
> [  377.407929] Hardware name: RZG2L Evaluation Board Kit (Discrete Power 
> System Ver.) (Dual Cortex-A55) (DT)
> 

That's ARM64 and I-pipe - might not have been tested / fully enabled in
that combination. Try 5.10 with the dovetail patch, there ftrace is
known to work better. Alternatively: the I-pipe tracer should work on
arm64 (though without a nice function graph).

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: CPU core reservation and Latency setting via config

[Jan Kiszka via Xenomai]

On 25.08.21 10:16, Neeraj Agrawal via Xenomai wrote:
> Hello,
> Seeking advice on two separate issues. One of them may be just the 
> documentation.
> 
> Setup is:
> Building via buildroot
> [Xenomai] Cobalt v3.0.10 is running over qemu with 2 CPUs.
> Linux version 4.14.111.
> bootargs: isolcpus=1 processor.max_cstate=0 
> intel_idle.max_cstate=0 nosoftlockup=0 rcu_nocbs=1 irqaffinity=0 tsc=reliable 
> .

Architecture?

> 
> Issue 1\ Latency setting:
> Referring to 
> https://xenomai.org/documentation/xenomai-3/html/man1/autotune/index.html
> -enabling CONFIG_XENO_OPT_AUTOTUNE does create entry as '/dev/rtdm/autotune' 
> in target.
> -setting XENO_OPT_TIMING_SCHEDLAT does NOT reflect in 
> '/proc/xenomai/clock/coreclk'

There is apparently a translation issue. While the config help says you
should specify in nanoseconds, the value is actually accepted in clock
cycles (TSC in case of x86).

Philippe, all those hard-coded values in
kernel/cobalt/arch/*/*/include/asm/xenomai/calibration.h are actually in
ticks? Or are they also in ns, and we need to convert them to ticks as well?

> -enabling BR2_PACKAGE_XENOMAI_ANALOGY does build autotune application, but 
> running it on target also does NOT reflect XENO_OPT_TIMING_SCHEDLAT setting 
> in '/proc/xenomai/clock/coreclk'

That is likely a buildroot topic. Please address via that community
first (provided you meant BR2_PACKAGE_XENOMAI_AUTOTUNE, not ANALOGY).

> 
> Is my expectation correct that statically defined gravity values should 
> reflect in coreclk?
> -If so, how could it be achieved?
> -If not, then how to verify if the values are set/used correctly?
> 
> 
> Issue 2\ CPU cores distribution:
> If bootargs have both ("isolcpus=1 maxcpus=1"), ie:
> isolcpus=1 maxcpus=1 processor.max_cstate=0 
> intel_idle.max_cstate=0 nosoftlockup=0 rcu_nocbs=1 irqaffinity=0 tsc=reliable 
> .
> Then i get a boot time crash. [Could not collect the log, but crash indicate 
> somewhere in i-pipe]

Indeed, maxcpus=1 crashes on x86 with I-pipe. Not with dovetail (5.10),
though. With maxcpus=1, we start with any core > 0 being offline, and
that is likely not supported by I-pipe. Taking cores offline later on is
supposed to work, though.

> Idea behind this is to force Linux to use 1st CPU, there by leaving 2nd CPU 
> dedicated for Xenomai. Either of the entry alone works (but not together).
> [Also tried xenomai.supported_cpus=0x02 without success].

Try only isolcpus and possibly xenomai.supported_cpus (if you like to
reduce the impact of Xenomai on non-RT CPUs).

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH v2 0/7] Export posix mqueues and named semaphores to procfs

[Jan Kiszka via Xenomai]

On 25.08.21 12:32, Florian Bezdeka wrote:
> Hi all,
> 
> with this series I'm trying to care about all the feedback I got for
> RFCs I sent out some days ago. Exporting mqueues and named semaphores to
> the procfs helps to debug and identify resource leaks.
> 
> mqueues will be exported to 
>   /proc/xenomai/registry/posix/mqueue/
> 
> named semaphores will be exported to 
>   /proc/xenomai/registry/posix/sem/
> 
> While adding the tests I noticed that the exit code of the subprocess
> started in the smokey leak test was not correctly reported to the parent
> process. That is now fixed as well. (See last patch for details)
> 
> All patches compile time tested for all targets by the gitlab
> hackerspace CI pipeline. In addition manually tested on ARM64. My
> internal CI is currently out of order, so tests on real hardware were
> skipped this time.
> 
> Best regards,
> Florian
> 
> Changes in v2:
>   - Implement review comments from Jan:
> - Split test adjustments into two separate patches
> - Move the posix xpntree to process.c/internal.h
> - Remove posix xpntree external declaration from sem.c and mqueue.c
> 
> Florian Bezdeka (7):
>   cobalt/registry: Share xnregistry_vfreg_ops with other compile units
>   cobalt/registry: Initialize refcnt of exported virtual proc files
>   cobalt/posix/process: Adding a xnptree for exporting registry entries
>   cobalt/posix/mqueue: Export created mqueues to procfs
>   cobalt/posix/semaphore: Export named semaphores to procfs
>   testsuite/smokey/leaks: Fix error reporting from child to parent
> process
>   testsuite/smokey/leaks: Adding checks for procfs exports
> 
>  include/cobalt/kernel/registry.h |  2 +
>  kernel/cobalt/posix/internal.h   |  2 +
>  kernel/cobalt/posix/mqueue.c | 36 -
>  kernel/cobalt/posix/process.c|  2 +
>  kernel/cobalt/posix/sem.c| 35 +++-
>  kernel/cobalt/registry.c |  1 +
>  testsuite/smokey/leaks/leaks.c   | 68 +---
>  7 files changed, 121 insertions(+), 25 deletions(-)
> 

Thanks, applied to next.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

[PATCH] pipeline: Fix conversion of preset gravitiy values

[Jan Kiszka via Xenomai]

From: Jan Kiszka 

The values in xnclock_gravity are in ticks, not nanoseconds. Make sure
nanosecond values are converted before storing them.

This was originally broken by bc761d8cf25c, for all architectures except
arm, arm64 and powerpc. During the dovetail port, this also sneaked into
the arm and arm64 headers.

Signed-off-by: Jan Kiszka 
---

The I-pipe part is to be ported to stable as well.

 .../arch/arm/dovetail/include/asm/xenomai/calibration.h| 7 ---
 .../arch/arm64/dovetail/include/asm/xenomai/calibration.h  | 7 ---
 .../arch/x86/dovetail/include/asm/xenomai/calibration.h| 7 ---
 .../arch/x86/ipipe/include/asm/xenomai/calibration.h   | 7 ---
 4 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/kernel/cobalt/arch/arm/dovetail/include/asm/xenomai/calibration.h 
b/kernel/cobalt/arch/arm/dovetail/include/asm/xenomai/calibration.h
index c4724372d5..3cf58259b1 100644
--- a/kernel/cobalt/arch/arm/dovetail/include/asm/xenomai/calibration.h
+++ b/kernel/cobalt/arch/arm/dovetail/include/asm/xenomai/calibration.h
@@ -31,9 +31,10 @@ static inline void xnarch_get_latencies(struct 
xnclock_gravity *p)
 #else
sched_latency = 5000;
 #endif
-   p->user = sched_latency;
-   p->kernel = CONFIG_XENO_OPT_TIMING_KSCHEDLAT;
-   p->irq = CONFIG_XENO_OPT_TIMING_IRQLAT;
+   p->user = xnclock_ns_to_ticks(&nkclock, sched_latency);
+   p->kernel = xnclock_ns_to_ticks(&nkclock,
+   CONFIG_XENO_OPT_TIMING_KSCHEDLAT);
+   p->irq = xnclock_ns_to_ticks(&nkclock, CONFIG_XENO_OPT_TIMING_IRQLAT);
 }
 
 #endif /* !_COBALT_ARM_DOVETAIL_CALIBRATION_H */
diff --git 
a/kernel/cobalt/arch/arm64/dovetail/include/asm/xenomai/calibration.h 
b/kernel/cobalt/arch/arm64/dovetail/include/asm/xenomai/calibration.h
index 05cb6f3a54..cd9496b66c 100644
--- a/kernel/cobalt/arch/arm64/dovetail/include/asm/xenomai/calibration.h
+++ b/kernel/cobalt/arch/arm64/dovetail/include/asm/xenomai/calibration.h
@@ -16,9 +16,10 @@ static inline void xnarch_get_latencies(struct 
xnclock_gravity *p)
 #else
sched_latency = 5000;
 #endif
-   p->user = sched_latency;
-   p->kernel = CONFIG_XENO_OPT_TIMING_KSCHEDLAT;
-   p->irq = CONFIG_XENO_OPT_TIMING_IRQLAT;
+   p->user = xnclock_ns_to_ticks(&nkclock, sched_latency);
+   p->kernel = xnclock_ns_to_ticks(&nkclock,
+   CONFIG_XENO_OPT_TIMING_KSCHEDLAT);
+   p->irq = xnclock_ns_to_ticks(&nkclock, CONFIG_XENO_OPT_TIMING_IRQLAT);
 }
 
 #endif /* !_COBALT_ARM64_DOVETAIL_CALIBRATION_H */
diff --git a/kernel/cobalt/arch/x86/dovetail/include/asm/xenomai/calibration.h 
b/kernel/cobalt/arch/x86/dovetail/include/asm/xenomai/calibration.h
index 29d2924477..7f2dde70ca 100644
--- a/kernel/cobalt/arch/x86/dovetail/include/asm/xenomai/calibration.h
+++ b/kernel/cobalt/arch/x86/dovetail/include/asm/xenomai/calibration.h
@@ -29,9 +29,10 @@ static inline void xnarch_get_latencies(struct 
xnclock_gravity *p)
sched_latency = num_online_cpus() > 1 ? 3350 : 2000;
 #endif /* !CONFIG_XENO_OPT_TIMING_SCHEDLAT */
 
-   p->user = sched_latency;
-   p->kernel = CONFIG_XENO_OPT_TIMING_KSCHEDLAT;
-   p->irq = CONFIG_XENO_OPT_TIMING_IRQLAT;
+   p->user = xnclock_ns_to_ticks(&nkclock, sched_latency);
+   p->kernel = xnclock_ns_to_ticks(&nkclock,
+   CONFIG_XENO_OPT_TIMING_KSCHEDLAT);
+   p->irq = xnclock_ns_to_ticks(&nkclock, CONFIG_XENO_OPT_TIMING_IRQLAT);
 }
 
 #endif /* !_COBALT_X86_ASM_CALIBRATION_H */
diff --git a/kernel/cobalt/arch/x86/ipipe/include/asm/xenomai/calibration.h 
b/kernel/cobalt/arch/x86/ipipe/include/asm/xenomai/calibration.h
index a9190e169c..eaecc48d43 100644
--- a/kernel/cobalt/arch/x86/ipipe/include/asm/xenomai/calibration.h
+++ b/kernel/cobalt/arch/x86/ipipe/include/asm/xenomai/calibration.h
@@ -62,9 +62,10 @@ static inline void xnarch_get_latencies(struct 
xnclock_gravity *p)
}
 #endif /* !CONFIG_XENO_OPT_TIMING_SCHEDLAT */
 
-   p->user = sched_latency;
-   p->kernel = CONFIG_XENO_OPT_TIMING_KSCHEDLAT;
-   p->irq = CONFIG_XENO_OPT_TIMING_IRQLAT;
+   p->user = xnclock_ns_to_ticks(&nkclock, sched_latency);
+   p->kernel = xnclock_ns_to_ticks(&nkclock,
+   CONFIG_XENO_OPT_TIMING_KSCHEDLAT);
+   p->irq = xnclock_ns_to_ticks(&nkclock, CONFIG_XENO_OPT_TIMING_IRQLAT);
 }
 
 #endif /* !_COBALT_X86_ASM_CALIBRATION_H */
-- 
2.31.1

[PATCH] cobalt/posix/sem: Pull xnregistry_remove out of nklock

[Jan Kiszka via Xenomai]

From: Jan Kiszka 

Neither needed nor correct for named semaphores where xnregistry_remove
will trigger a flush_work when running over the secondary domain.

Signed-off-by: Jan Kiszka 
---
 kernel/cobalt/posix/sem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/cobalt/posix/sem.c b/kernel/cobalt/posix/sem.c
index b6709e6927..6fb4dc2c2a 100644
--- a/kernel/cobalt/posix/sem.c
+++ b/kernel/cobalt/posix/sem.c
@@ -94,7 +94,6 @@ int __cobalt_sem_destroy(xnhandle_t handle)
}
 
cobalt_mark_deleted(sem);
-   xnregistry_remove(sem->resnode.handle);
if (!sem->pathname)
cobalt_del_resource(&sem->resnode);
if (xnsynch_destroy(&sem->synchbase) == XNSYNCH_RESCHED) {
@@ -104,6 +103,7 @@ int __cobalt_sem_destroy(xnhandle_t handle)
 
xnlock_put_irqrestore(&nklock, s);
 
+   xnregistry_remove(sem->resnode.handle);
if (sem->pathname)
putname(sem->pathname);
 
-- 
2.31.1

Re: [PATCH] cobalt/posix/sem: Pull xnregistry_remove out of nklock

[Jan Kiszka via Xenomai]

On 25.08.21 14:06, Jan Kiszka via Xenomai wrote:
> From: Jan Kiszka 
> 
> Neither needed nor correct for named semaphores where xnregistry_remove
> will trigger a flush_work when running over the secondary domain.
> 
> Signed-off-by: Jan Kiszka 
> ---
>  kernel/cobalt/posix/sem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/cobalt/posix/sem.c b/kernel/cobalt/posix/sem.c
> index b6709e6927..6fb4dc2c2a 100644
> --- a/kernel/cobalt/posix/sem.c
> +++ b/kernel/cobalt/posix/sem.c
> @@ -94,7 +94,6 @@ int __cobalt_sem_destroy(xnhandle_t handle)
>   }
>  
>   cobalt_mark_deleted(sem);
> - xnregistry_remove(sem->resnode.handle);
>   if (!sem->pathname)
>   cobalt_del_resource(&sem->resnode);
>   if (xnsynch_destroy(&sem->synchbase) == XNSYNCH_RESCHED) {
> @@ -104,6 +103,7 @@ int __cobalt_sem_destroy(xnhandle_t handle)
>  
>   xnlock_put_irqrestore(&nklock, s);
>  
> + xnregistry_remove(sem->resnode.handle);
>   if (sem->pathname)
>   putname(sem->pathname);
>  
> 

Will go in before Florian's registry patches as those surface this
hidden issue. Previously, sems had no entry in proc, thus couldn't
trigger this problem.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH v2 7/7] testsuite/smokey/leaks: Adding checks for procfs exports

[Jan Kiszka via Xenomai]

On 25.08.21 12:32, Florian Bezdeka wrote:
> Make sure that named semaphores as well as mqueues are exported to the
> procfs.
> 
> Signed-off-by: Florian Bezdeka 
> ---
>  testsuite/smokey/leaks/leaks.c | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/testsuite/smokey/leaks/leaks.c b/testsuite/smokey/leaks/leaks.c
> index bbe5fc3ad..b867bc727 100644
> --- a/testsuite/smokey/leaks/leaks.c
> +++ b/testsuite/smokey/leaks/leaks.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -71,6 +72,24 @@ const char *memdev[] = {
>  
>  static int memdevfd[3];
>  
> +static int procfs_exists(const char *type, const char *name)
> +{
> + struct stat s;
> + char path[128];
> + int ret;
> +
> + /* Ignore if the kernel seems to be compiled without procfs support */
> + if (stat("/proc/xenomai", &s) || !S_ISDIR(s.st_mode))
> + return 0;
> +
> + ret = snprintf(path, 128, "%s/%s/%s", "/proc/xenomai/registry/posix",
> +type, &name[1]);
> + if (ret < 0)
> + return -EINVAL;
> +
> + return smokey_check_errno(stat(path, &s));
> +}
> +
>  static unsigned long long get_used(void)
>  {
>   struct cobalt_memdev_stat statbuf;
> @@ -121,6 +140,10 @@ static inline int subprocess_leak(void)
>   if (ret)
>   return ret;
>  
> + ret = procfs_exists("sem", SEM_NAME);
> + if (ret)
> + return ret;
> +

This comes too fast for the registry, see failing tests in CI, e.g.
https://source.denx.de/Xenomai/xenomai-images/-/jobs/313503. The
registration with /proc seems to happen asynchronously. If I add a
usleep(10) to procfs_exists(), the tests seem to pass.

Jan

>   sevt.sigev_notify = SIGEV_THREAD_ID;
>   sevt.sigev_signo = SIGALRM;
>   sevt.sigev_notify_thread_id = syscall(__NR_gettid);
> @@ -132,6 +155,10 @@ static inline int subprocess_leak(void)
>   if (ret < 0)
>   return ret;
>  
> + ret = procfs_exists("mqueue", MQ_NAME);
> + if (ret)
> + return ret;
> +
>   return 0;
>  }
>  
> 

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: autotune inside qemu: early shot and segfault

[Jan Kiszka via Xenomai]

On 27.08.21 11:57, Florian Bezdeka wrote:
> Hi all,
> 
> first issue:
> 
> maybe someone can explain what's going on here. I'm running autotune 
> inside qemu (ARM) on an x86_64 host and get the error below. The 
> kernel in use is 4.19 (ipipe) build with current "next" branch.
> 
> root@demo:~# autotune2 
> == auto-tuning started, period=100 ns (may take a while)
> irq gravity... 0 ns
> kernel gravity... autotune: tuning failed (kernel): Resource temporarily 
> unavailable
> 
> dmesg tells me
> 
> [   92.800781] [Xenomai] autotune(irqhand) started
> [  102.499494] [Xenomai] autotune(kthread) started
> [  108.623898] [Xenomai] autotune(kthread) failed with early shot (827251 ns)
> [  108.646795] [Xenomai] autotune finished [0i/5000k/5000u]
> 
> 
> Any idea why / how this early shot can happen? I'm unable to 
> reproduce it on a real hardware like the beagle bone black. 
> I wonder why it seems to work in the CI setup...
> 
> 
> 
> Second issue: From time to time autotune produces a segfault:
> 
> root@demo:~# autotune 
> == auto-tuning started, period=100 ns (may take a while)
> irq gravity... 1984 ns
> kernel gravity... 10912ns
> user gravity... Segmentation fault
> 
> I haven't seen the segfault with a dovetail enabled kernel yet.
> So it might be ipipe related...
> 
> I was able to reproduce once with gdb attached. We seem to crash 
> in rtmd.c line 170 (do_ioctl, XENOMAI_SYSCALL3()). GDB was 
> unable to present a backtrace. ("previous frame identical to this 
> frame (corrupt stack?")
> 

Does corectl provide some hints? Is the kernel reporting a userspace or
a kernel space fault?

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: autotune inside qemu: early shot and segfault

[Jan Kiszka via Xenomai]

On 27.08.21 12:22, Bezdeka, Florian (T RDA IOT SES-DE) wrote:
> On Fri, 2021-08-27 at 12:03 +0200, Jan Kiszka wrote:
>> On 27.08.21 11:57, Florian Bezdeka wrote:
>>> Hi all,
>>>
>>> first issue:
>>>
>>> maybe someone can explain what's going on here. I'm running autotune
>>> inside qemu (ARM) on an x86_64 host and get the error below. The
>>> kernel in use is 4.19 (ipipe) build with current "next" branch.
>>>
>>> root@demo:~# autotune2
>>> == auto-tuning started, period=100 ns (may take a while)
>>> irq gravity... 0 ns
>>> kernel gravity... autotune: tuning failed (kernel): Resource temporarily 
>>> unavailable
>>>
>>> dmesg tells me
>>>
>>> [   92.800781] [Xenomai] autotune(irqhand) started
>>> [  102.499494] [Xenomai] autotune(kthread) started
>>> [  108.623898] [Xenomai] autotune(kthread) failed with early shot (827251 
>>> ns)
>>> [  108.646795] [Xenomai] autotune finished [0i/5000k/5000u]
>>>
>>>
>>> Any idea why / how this early shot can happen? I'm unable to
>>> reproduce it on a real hardware like the beagle bone black.
>>> I wonder why it seems to work in the CI setup...
>>>
>>>
>>>
>>> Second issue: From time to time autotune produces a segfault:
>>>
>>> root@demo:~# autotune
>>> == auto-tuning started, period=100 ns (may take a while)
>>> irq gravity... 1984 ns
>>> kernel gravity... 10912ns
>>> user gravity... Segmentation fault
>>>
>>> I haven't seen the segfault with a dovetail enabled kernel yet.
>>> So it might be ipipe related...
>>>
>>> I was able to reproduce once with gdb attached. We seem to crash
>>> in rtmd.c line 170 (do_ioctl, XENOMAI_SYSCALL3()). GDB was
>>> unable to present a backtrace. ("previous frame identical to this
>>> frame (corrupt stack?")
>>>
>>
>> Does corectl provide some hints? Is the kernel reporting a userspace or
>> a kernel space fault?
> 
> dmesg doesn't list a segfault at all... Wrong routed signal? I'm going
> to play with corectl, but there was nothing interesting so far.
> 

I meant coredumpctl btw., just to be clear.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: autotune inside qemu: early shot and segfault

[Jan Kiszka via Xenomai]

On 27.08.21 13:39, Bezdeka, Florian (T RDA IOT SES-DE) wrote:
> On Fri, 2021-08-27 at 12:23 +0200, Jan Kiszka wrote:
>> On 27.08.21 12:22, Bezdeka, Florian (T RDA IOT SES-DE) wrote:
>>> On Fri, 2021-08-27 at 12:03 +0200, Jan Kiszka wrote:
 On 27.08.21 11:57, Florian Bezdeka wrote:
> Hi all,
>
> first issue:
>
> maybe someone can explain what's going on here. I'm running autotune
> inside qemu (ARM) on an x86_64 host and get the error below. The
> kernel in use is 4.19 (ipipe) build with current "next" branch.
>
> root@demo:~# autotune2
> == auto-tuning started, period=100 ns (may take a while)
> irq gravity... 0 ns
> kernel gravity... autotune: tuning failed (kernel): Resource temporarily 
> unavailable
>
> dmesg tells me
>
> [   92.800781] [Xenomai] autotune(irqhand) started
> [  102.499494] [Xenomai] autotune(kthread) started
> [  108.623898] [Xenomai] autotune(kthread) failed with early shot (827251 
> ns)
> [  108.646795] [Xenomai] autotune finished [0i/5000k/5000u]
>
>
> Any idea why / how this early shot can happen? I'm unable to
> reproduce it on a real hardware like the beagle bone black.
> I wonder why it seems to work in the CI setup...
>
>
>
> Second issue: From time to time autotune produces a segfault:
>
> root@demo:~# autotune
> == auto-tuning started, period=100 ns (may take a while)
> irq gravity... 1984 ns
> kernel gravity... 10912ns
> user gravity... Segmentation fault
>
> I haven't seen the segfault with a dovetail enabled kernel yet.
> So it might be ipipe related...
>
> I was able to reproduce once with gdb attached. We seem to crash
> in rtmd.c line 170 (do_ioctl, XENOMAI_SYSCALL3()). GDB was
> unable to present a backtrace. ("previous frame identical to this
> frame (corrupt stack?")
>

 Does corectl provide some hints? Is the kernel reporting a userspace or
 a kernel space fault?
>>>
>>> dmesg doesn't list a segfault at all... Wrong routed signal? I'm going
>>> to play with corectl, but there was nothing interesting so far.
>>>
>>
>> I meant coredumpctl btw., just to be clear.
> 
> Wow, once coredumpctl was installed I got:
> 
> Stack trace of thread 312:
> #0  0xb6f50daa _Unwind_VRS_Pop (libgcc_s.so.1)
> 
> Compiler issue? I'm currently using
> gcc version 10.2.1 20210110 (Debian 10.2.1-6)
> 

Wait: You have a Debian 10 where (gcc is gcc-8), but for this test you
built autotune (only that?) with gcc-10?

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: pthread_getcpuclockid() and clock_gettime() with Xenomai pthread

[Jan Kiszka via Xenomai]

On 27.08.21 03:15, Rajesh Venkataraman via Xenomai wrote:
> Hi,
>For the linux pthreads we have used pthread_getcpuclockid() to get the
> threads cpu time clock. Then periodically we do a clock_gettime() on this
> timer to get all threads run time. Then do clock_gettime( CLOCK_MONOTONIC,
> &ts ) to get the total system. Using the individual thread run time and
> total run time, we calculate the percentage of CPU utilization for each
> thread. Now we have moved the realtime thread to xenomai user space.
> The clock_gettime() on a xenomai user thread returns an error.   How do we
> calculate what percentage of the CPU is utilized by the xenomai thread in
> our Application?
> 
>   We also get the idle time of the CPU from the /proc/stat and calculate
> the reserve percentage based on the total system time. Does linux idle time
> also include xenomai run time?
> 
>   Is this correct method for calculating the CPU utilization percentage per
> thread in a system/application with xenomai and linux pthreads running in a
> single process?
> 

Xenomai does not support pthread_getcpuclockid for reading the consumed
time of a thread. There are stats under /proc/xenomai/sched/acct, rtps
uses them, but reading those require switching to Linux (if that is an
issue for your use case). And there is an internal cobalt_thread_stat()
syscall already, used only by some non-posix skins so far.

I'm sitting on non-upstream changes to export the CPU usage of thread to
userland without leaving RT, actually even without issuing a syscall.
But those need rework in order to attach to some posix interface.

What are your requirements on a statistic interface? Who is going to
monitor who, and under which constraints?

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH] y2038: testsuite/smokey/y2038: Run tests on y2038 safe kernels only

[Jan Kiszka via Xenomai]

On 27.08.21 12:02, Florian Bezdeka wrote:
> Especially 4.19 is not 2038 safe and 32 bit kernels do not have
> CONFIG_64BIT_TIME set, which ends up in __kernel_timespec being defined
> in a non y2038 safe way.
> 
> cobalt_get_timespec64 will copy the upper bytes of the sec field into
> the nsec field, which is always zero.
> 
> Testing y2038 syscalls on a non y2038 safe kernel doesn't make sense,
> hence limiting the test runs to kernels with 2038 support.
> 
> Signed-off-by: Florian Bezdeka 
> ---
>  testsuite/smokey/y2038/syscall-tests.c | 27 ++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/testsuite/smokey/y2038/syscall-tests.c 
> b/testsuite/smokey/y2038/syscall-tests.c
> index 8afedd7d1..c23a54f5d 100644
> --- a/testsuite/smokey/y2038/syscall-tests.c
> +++ b/testsuite/smokey/y2038/syscall-tests.c
> @@ -11,6 +11,7 @@
>   */
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  smokey_test_plugin(y2038, SMOKEY_NOARGS, "Validate correct y2038 support");
> @@ -989,10 +990,36 @@ static int test_sc_cobalt_event_wait64(void)
>   return 0;
>  }
>  
> +static int check_kernel_version(void)
> +{
> + int ret, major, minor;
> + struct utsname uts;
> +
> + ret = smokey_check_errno(uname(&uts));
> + if (ret)
> + return ret;
> +
> + ret = sscanf(uts.release, "%d.%d", &major, &minor);
> + if (!smokey_assert(ret == 2))
> + return -EINVAL;
> +
> + /* We need a kernel with y2038 support, 5.4 onwards */
> + if (!(major > 5 || (major == 5 && minor >= 4))) {
> + smokey_note("y2038: skipped. (no y2038 safe kernel)");
> + return 1;
> + }
> +
> + return 0;
> +}
> +
>  static int run_y2038(struct smokey_test *t, int argc, char *const argv[])
>  {
>   int ret;
>  
> + ret = check_kernel_version();
> + if (ret)
> + return (ret < 0) ? ret : 0; /* skip if no y2038 safe kernel */
> +
>   ret = test_sc_cobalt_sem_timedwait64();
>   if (ret)
>   return ret;
> 

OK, will apply. But I'm also expected a patch that makes the test case
fail in cases of early shots. We only noticed this issue because you
read the logs of successful runs.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: Doing DMA from peripheral to userland memory

[Jan Kiszka via Xenomai]

On 27.08.21 11:29, François Legal via Xenomai wrote:
> Hello,
> 
> working on a zynq7000 target (arm cortex a9), we have a peripheral that 
> generates loads of data (many kbytes per ms).
> 
> We would like to move that data, directly from the peripheral memory (the OCM 
> of the SoC) directly to our RT application user memory using DMA.
> 
> For one part of the data, we would like the DMA to de interlace that data 
> while moving it. We figured out, the PL330 peripheral on the SoC should be 
> able to do it, however, we would like, as much as possible, to retain the use 
> of one or two channels of the PL330 to plain linux non RT use (via dmaengine).
> 
> My first attempt would be to enhance the dmaengine API to add RT API, then 
> implement the RT API calls in the PL330 driver.
> 
> What do you think of this approach, and is it achievable at all (DMA directly 
> to user land memory and/or having DMA channels exploited by xenomai and other 
> by linux) ?
> 

IIRC, the topic of DMA also popped up in the context of SPI support in
the past. In any case, you likely want to check how Dovetail and EVL /
Xenomai 4 is possibly already addressing, to get an idea of potential
solution patterns.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: Trouble building the testsuite for Xenomai-3.0.3

[Jan Kiszka via Xenomai]

On 27.08.21 21:46, Jackson Jones via Xenomai wrote:
> I am trying to build Xenomai-3.0.3 on antiX-17.4.1_386-full. The processor
> is a Geode. The kernel version 4.4.43 (with the x86 ipipe for that
> version). It builds the libraries, but it fails on the building of the
> testsuite. The version of gcc is 6.3.0.
> 
> Below is a listing of the build and the contents of the xenoconfig.sh.
> I'd appreciate any help in getting around this problem. We cannot
> swith to a new xenomai since this running on a medical device.
> 
> devel@antix1:~/xenomai_build/xenomai-3.0.3$ ./xenoconfig.sh
> checking whether we build for Cobalt or Mercury core... cobalt
> checking build system type... i686-pc-linux-gnu
> checking host system type... i686-pc-linux-gnu
> checking for a BSD-compatible install... /usr/bin/install -c
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking whether gcc understands -c and -o together... yes
> checking how to run the C preprocessor... gcc -E
> checking target system type... i686-pc-linux-gnu
> checking for gcc... gcc
> checking whether we are using the GNU C compiler... (cached) yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... (cached) none needed
> checking whether gcc understands -c and -o together... (cached) yes
> checking how to run the C preprocessor... gcc -E
> checking for grep that handles long lines and -e... /bin/grep
> checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
> checking the name lister (/usr/bin/nm -B) interface... BSD nm
> checking for gawk... gawk
> checking for a sed that does not truncate output... /bin/sed
> checking for egrep... /bin/grep -E
> checking for fgrep... /bin/grep -F
> checking how to print strings... printf
> checking for ld used by gcc... /usr/bin/ld
> checking if the linker (/usr/bin/ld) is GNU ld... yes
> checking command to parse /usr/bin/nm -B output from gcc object... ok
> checking for _ prefix in compiled symbols... no
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> checking whether make sets $(MAKE)... yes
> checking for style of include used by make... GNU
> checking whether make supports nested variables... yes
> checking whether UID '1000' is supported by ustar format... yes
> checking whether GID '1000' is supported by ustar format... yes
> checking how to create a ustar tar archive... gnutar
> checking dependency style of gcc... gcc3
> checking whether make supports nested variables... (cached) yes
> checking whether to enable maintainer-specific portions of Makefiles... no
> checking dependency style of gcc... gcc3
> checking for flex... flex
> checking lex output file root... lex.yy
> checking lex library... none needed
> checking whether yytext is a pointer... no
> checking for target architecture... x86
> checking whether ln -s works... yes
> checking the maximum length of command line arguments... 1572864
> checking whether the shell understands some XSI constructs... yes
> checking whether the shell understands "+="... yes
> checking how to convert i686-pc-linux-gnu file names to i686-pc-linux-gnu
> format... func_convert_file_noop
> checking how to convert i686-pc-linux-gnu file names to toolchain format...
> func_convert_file_noop
> checking for /usr/bin/ld option to reload object files... -r
> checking for objdump... objdump
> checking how to recognize dependent libraries... pass_all
> checking for dlltool... no
> checking how to associate runtime and link libraries... printf %s\n
> checking for ar... ar
> checking for archiver @FILE support... @
> checking for strip... strip
> checking for ranlib... ranlib
> checking for sysroot... no
> checking for mt... mt
> checking if mt is a manifest tool... no
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking for dlfcn.h... yes
> checking for objdir... .libs
> checking if gcc supports -fno-rtti -fno-exceptions... no
> checking for gcc option to produce PIC... -fPIC -DPIC
> checking if gcc PIC flag -fPIC -DPIC works... yes
> checking if gcc static flag -static works... yes
> checking if gcc supports -c -o file.o... yes
> checking if gcc supports -c -o file.o... (cached) yes
> checking whether the gcc linker (/usr/bin/ld) supports shared libraries...
> yes
> checking whether -lc should be explicitly linked in... no
> 

Re: [PATCH 1/3] drivers/gpio: core: move out of OF config conditional compilation

[Jan Kiszka via Xenomai]

On 30.08.21 08:45, Hongzhan Chen via Xenomai wrote:
> The api would be called by both non-OF and OF platform to remove rtdm
> gpiochip device.
> 
> Signed-off-by: Hongzhan Chen 
> ---
>  include/cobalt/kernel/rtdm/gpio.h | 3 +--
>  kernel/drivers/gpio/gpio-core.c   | 4 ++--
>  2 files changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/include/cobalt/kernel/rtdm/gpio.h 
> b/include/cobalt/kernel/rtdm/gpio.h
> index 72cc3a035..c307b1572 100644
> --- a/include/cobalt/kernel/rtdm/gpio.h
> +++ b/include/cobalt/kernel/rtdm/gpio.h
> @@ -70,9 +70,8 @@ int rtdm_gpiochip_scan_of(struct device_node *from,
>  int rtdm_gpiochip_scan_array_of(struct device_node *from,
>   const char *compat[],
>   int nentries, int type);
> +#endif
>  
>  void rtdm_gpiochip_remove_of(int type);
>  

But, when we call this for ACPI platforms as well, is _of still the
right name?

> -#endif
> -
>  #endif /* !_COBALT_RTDM_GPIO_H */
> diff --git a/kernel/drivers/gpio/gpio-core.c b/kernel/drivers/gpio/gpio-core.c
> index 06a19b33a..ddda62b24 100644
> --- a/kernel/drivers/gpio/gpio-core.c
> +++ b/kernel/drivers/gpio/gpio-core.c
> @@ -626,6 +626,8 @@ int rtdm_gpiochip_scan_array_of(struct device_node *from,
>  }
>  EXPORT_SYMBOL_GPL(rtdm_gpiochip_scan_array_of);
>  
> +#endif /* CONFIG_OF */
> +
>  void rtdm_gpiochip_remove_of(int type)
>  {
>   struct rtdm_gpio_chip *rgc, *n;
> @@ -644,5 +646,3 @@ void rtdm_gpiochip_remove_of(int type)
>   mutex_unlock(&chip_lock);
>  }
>  EXPORT_SYMBOL_GPL(rtdm_gpiochip_remove_of);
> -
> -#endif /* CONFIG_OF */
> 

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH 0/3] add support for cherryview gpio controller driver

[Jan Kiszka via Xenomai]

On 30.08.21 08:45, Hongzhan Chen via Xenomai wrote:
> 1. move out of OF config conditional compilation so that non-OF platform
>   call same API to remove rtdm gpio chip device.
> 2. Introduce helper to find gpiochip as referring to pair of 
>rtdm_gpiochip_scan_of and rtdm_gpiochip_scan_array_of. 
> 3. Add Intel Cherryview pinctrl driver based on on 1 and 2.
> 

Looks good, except for that naming issue.

> I also did following tests with this patchset:
> 1. run /usr/lib/xenomai/testsuite/gpiobench -i 334 -i 335 -c INT33FF:02
>to validate patch 9afea5ff2d7ba97db96b22a005a9a7fcf5f2d892 when
>setting GPIO_RTIOC_TS
> 2. apply following patch, and rerun 1.
> 
> index f83d7689f..50afbd418 100644
> --- a/testsuite/gpiobench/gpiobench.c
> +++ b/testsuite/gpiobench/gpiobench.c
> @@ -619,7 +619,7 @@ int main(int argc, char **argv)
> goto out;
> }
> 
> -   ret = ioctl(ti.fd_dev_intr, GPIO_RTIOC_TS, &value);
> +   ret = ioctl(ti.fd_dev_intr, GPIO_RTIOC_TS_MONO, &value);
> if (ret) {
> printf("ioctl gpio port ts, failed\n");
> goto out;
> 
> Hardware env:
> 1. Rock PI X V1.4.
> 2. GPIO loopback connection between GPIO 334 and 335.
>  

Did you check if timestamps are as expected (different)?

Thanks,
Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH 0/3] add support for cherryview gpio controller driver

[Jan Kiszka via Xenomai]

On 31.08.21 03:35, Chen, Hongzhan wrote:
>>
>>
>> -Original Message-
>> From: Jan Kiszka  
>> Sent: Monday, August 30, 2021 3:37 PM
>> To: Chen, Hongzhan ; xenomai@xenomai.org
>> Subject: Re: [PATCH 0/3] add support for cherryview gpio controller driver
>>
>> On 30.08.21 08:45, Hongzhan Chen via Xenomai wrote:
>>> 1. move out of OF config conditional compilation so that non-OF platform
>>>   call same API to remove rtdm gpio chip device.
>>> 2. Introduce helper to find gpiochip as referring to pair of 
>>>rtdm_gpiochip_scan_of and rtdm_gpiochip_scan_array_of. 
>>> 3. Add Intel Cherryview pinctrl driver based on on 1 and 2.
>>>
>>
>> Looks good, except for that naming issue.
>>
>>> I also did following tests with this patchset:
>>> 1. run /usr/lib/xenomai/testsuite/gpiobench -i 334 -i 335 -c INT33FF:02
>>>to validate patch 9afea5ff2d7ba97db96b22a005a9a7fcf5f2d892 when
>>>setting GPIO_RTIOC_TS
>>> 2. apply following patch, and rerun 1.
>>>
>>> index f83d7689f..50afbd418 100644
>>> --- a/testsuite/gpiobench/gpiobench.c
>>> +++ b/testsuite/gpiobench/gpiobench.c
>>> @@ -619,7 +619,7 @@ int main(int argc, char **argv)
>>> goto out;
>>> }
>>>
>>> -   ret = ioctl(ti.fd_dev_intr, GPIO_RTIOC_TS, &value);
>>> +   ret = ioctl(ti.fd_dev_intr, GPIO_RTIOC_TS_MONO, &value);
>>> if (ret) {
>>> printf("ioctl gpio port ts, failed\n");
>>> goto out;
>>>
>>> Hardware env:
>>> 1. Rock PI X V1.4.
>>> 2. GPIO loopback connection between GPIO 334 and 335.
>>>  
>>
>> Did you check if timestamps are as expected (different)?
> 
> According to output of gpiobench, the inner Avg Latency would be vary large 
> like ( 2814377.0) after switch to MONO.
> But it is only about  16.879997 when we set REALTIME. 
> 

gpiobench takes timestamps from CLOCK_MONOTONIC (see clock_gettime
calls)). If you compare them to REALTIME, that will give an offset. But
you report just the opposite, this confuses me now...

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH 0/3] add support for cherryview gpio controller driver

[Jan Kiszka via Xenomai]

On 31.08.21 08:14, Chen, Hongzhan wrote:
> 
> 
>> -Original Message-
>> From: Jan Kiszka  
>> Sent: Tuesday, August 31, 2021 1:59 PM
>> To: Chen, Hongzhan ; xenomai@xenomai.org
>> Subject: Re: [PATCH 0/3] add support for cherryview gpio controller driver
>>
>> On 31.08.21 03:35, Chen, Hongzhan wrote:


 -Original Message-
 From: Jan Kiszka  
 Sent: Monday, August 30, 2021 3:37 PM
 To: Chen, Hongzhan ; xenomai@xenomai.org
 Subject: Re: [PATCH 0/3] add support for cherryview gpio controller driver

 On 30.08.21 08:45, Hongzhan Chen via Xenomai wrote:
> 1. move out of OF config conditional compilation so that non-OF platform
>   call same API to remove rtdm gpio chip device.
> 2. Introduce helper to find gpiochip as referring to pair of 
>rtdm_gpiochip_scan_of and rtdm_gpiochip_scan_array_of. 
> 3. Add Intel Cherryview pinctrl driver based on on 1 and 2.
>

 Looks good, except for that naming issue.

> I also did following tests with this patchset:
> 1. run /usr/lib/xenomai/testsuite/gpiobench -i 334 -i 335 -c INT33FF:02
>to validate patch 9afea5ff2d7ba97db96b22a005a9a7fcf5f2d892 when
>setting GPIO_RTIOC_TS
> 2. apply following patch, and rerun 1.
>
> index f83d7689f..50afbd418 100644
> --- a/testsuite/gpiobench/gpiobench.c
> +++ b/testsuite/gpiobench/gpiobench.c
> @@ -619,7 +619,7 @@ int main(int argc, char **argv)
> goto out;
> }
>
> -   ret = ioctl(ti.fd_dev_intr, GPIO_RTIOC_TS, &value);
> +   ret = ioctl(ti.fd_dev_intr, GPIO_RTIOC_TS_MONO, &value);
> if (ret) {
> printf("ioctl gpio port ts, failed\n");
> goto out;
>
> Hardware env:
> 1. Rock PI X V1.4.
> 2. GPIO loopback connection between GPIO 334 and 335.
>  

 Did you check if timestamps are as expected (different)?
>>>
>>> According to output of gpiobench, the inner Avg Latency would be vary large 
>>> like ( 2814377.0) after switch to MONO.
>>> But it is only about  16.879997 when we set REALTIME. 
>>>
>>
>> gpiobench takes timestamps from CLOCK_MONOTONIC (see clock_gettime
>> calls)). If you compare them to REALTIME, that will give an offset. But
>> you report just the opposite, this confuses me now...
> 
> The test is running on dovetail based 5.10.
> 

I missed one case in gpio_pin_interrupt where I need to check
monotonic_timestamp - but, again, mono is what should remain fine,
GPIO_RTIOC_TS_REAL (or GPIO_RTIOC_TS, the default) should give a delta.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH 2/3] drivers/gpio: core: Introduce helper to find gpiochip

[Jan Kiszka via Xenomai]

On 31.08.21 07:07, Hongzhan Chen via Xenomai wrote:
> To find gpiochip for non-OF platforms like x86
> 
> Signed-off-by: Hongzhan Chen 
> ---
>  include/cobalt/kernel/rtdm/gpio.h |  7 ++
>  kernel/drivers/gpio/gpio-core.c   | 42 +++
>  2 files changed, 49 insertions(+)
> 
> diff --git a/include/cobalt/kernel/rtdm/gpio.h 
> b/include/cobalt/kernel/rtdm/gpio.h
> index 29f26d6c6..98279e242 100644
> --- a/include/cobalt/kernel/rtdm/gpio.h
> +++ b/include/cobalt/kernel/rtdm/gpio.h
> @@ -62,6 +62,13 @@ int rtdm_gpiochip_add_by_name(struct rtdm_gpio_chip *rgc,
>  int rtdm_gpiochip_post_event(struct rtdm_gpio_chip *rgc,
>unsigned int offset);
>  
> +int rtdm_gpiochip_find(struct device_node *from,
> +   const char *label, int type);
> +
> +int rtdm_gpiochip_array_find(struct device_node *from,
> + const char *compat[],
> + int nentries, int type);
> +
>  #ifdef CONFIG_OF
>  
>  int rtdm_gpiochip_scan_of(struct device_node *from,
> diff --git a/kernel/drivers/gpio/gpio-core.c b/kernel/drivers/gpio/gpio-core.c
> index ccda67bd1..ce80e8d73 100644
> --- a/kernel/drivers/gpio/gpio-core.c
> +++ b/kernel/drivers/gpio/gpio-core.c
> @@ -528,6 +528,48 @@ int rtdm_gpiochip_add_by_name(struct rtdm_gpio_chip *rgc,
>  }
>  EXPORT_SYMBOL_GPL(rtdm_gpiochip_add_by_name);
>  
> +int rtdm_gpiochip_find(struct device_node *from, const char *label,
> +   int type)
> +{
> + struct rtdm_gpio_chip *rgc;
> + struct gpio_chip *chip;
> + int ret = -ENODEV;
> +
> + if (!rtdm_available())
> + return -ENOSYS;
> +
> + chip = find_chip_by_name(label);
> + if (chip == NULL)
> + return ret;
> +
> + ret = 0;
> + rgc = rtdm_gpiochip_alloc(chip, type);
> + if (IS_ERR(rgc))
> + ret = PTR_ERR(rgc);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(rtdm_gpiochip_find);
> +
> +int rtdm_gpiochip_array_find(struct device_node *from,
> + const char *compat[],

Is "compat" the right argument name here? We are searching by name
(label), no?

Jan

> + int nentries, int type)
> +{
> + int ret = -ENODEV, _ret, n;
> +
> + for (n = 0; n < nentries; n++) {
> + _ret = rtdm_gpiochip_find(from, compat[n], type);
> + if (_ret) {
> + if (_ret != -ENODEV)
> + return _ret;
> + } else
> + ret = 0;
> + }
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(rtdm_gpiochip_array_find);
> +
>  #ifdef CONFIG_OF
>  
>  #include 
> 

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH 3/3] driver/gpio: Add Intel Cherryview pinctrl driver

[Jan Kiszka via Xenomai]

On 31.08.21 07:07, Hongzhan Chen via Xenomai wrote:
> Add support for Intel Cherryview pin controller driver
> 
> Signed-off-by: Hongzhan Chen 
> ---
>  kernel/drivers/gpio/Kconfig   |  7 +
>  kernel/drivers/gpio/Makefile  |  2 ++
>  kernel/drivers/gpio/gpio-cherryview.c | 42 +++
>  3 files changed, 51 insertions(+)
>  create mode 100644 kernel/drivers/gpio/gpio-cherryview.c
> 
> diff --git a/kernel/drivers/gpio/Kconfig b/kernel/drivers/gpio/Kconfig
> index 44f41688c..c257444f0 100644
> --- a/kernel/drivers/gpio/Kconfig
> +++ b/kernel/drivers/gpio/Kconfig
> @@ -57,6 +57,13 @@ config XENO_DRIVERS_GPIO_OMAP
>   Enables support for the GPIO controller available from
>   OMAP family SOC.
>  
> +config XENO_DRIVERS_GPIO_CHERRYVIEW
> + depends on PINCTRL_CHERRYVIEW
> + tristate "Support for Cherryview GPIOs"
> + help
> +
> + Enables support for the Intel Cherryview GPIO controller
> +
>  config XENO_DRIVERS_GPIO_DEBUG
> bool "Enable GPIO core debugging features"
>  
> diff --git a/kernel/drivers/gpio/Makefile b/kernel/drivers/gpio/Makefile
> index 7bcf59949..e534eab93 100644
> --- a/kernel/drivers/gpio/Makefile
> +++ b/kernel/drivers/gpio/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_XENO_DRIVERS_GPIO_SUN8I_H3) += 
> xeno-gpio-sun8i-h3.o
>  obj-$(CONFIG_XENO_DRIVERS_GPIO_ZYNQ7000) += xeno-gpio-zynq7000.o
>  obj-$(CONFIG_XENO_DRIVERS_GPIO_XILINX) += xeno-gpio-xilinx.o
>  obj-$(CONFIG_XENO_DRIVERS_GPIO_OMAP) += xeno-gpio-omap.o
> +obj-$(CONFIG_XENO_DRIVERS_GPIO_CHERRYVIEW) += xeno-gpio-cherryview.o
>  obj-$(CONFIG_XENO_DRIVERS_GPIO) += gpio-core.o
>  
>  xeno-gpio-bcm2835-y := gpio-bcm2835.o
> @@ -14,3 +15,4 @@ xeno-gpio-sun8i-h3-y := gpio-sun8i-h3.o
>  xeno-gpio-zynq7000-y := gpio-zynq7000.o
>  xeno-gpio-xilinx-y := gpio-xilinx.o
>  xeno-gpio-omap-y := gpio-omap.o
> +xeno-gpio-cherryview-y := gpio-cherryview.o
> diff --git a/kernel/drivers/gpio/gpio-cherryview.c 
> b/kernel/drivers/gpio/gpio-cherryview.c
> new file mode 100644
> index 0..524199fe9
> --- /dev/null
> +++ b/kernel/drivers/gpio/gpio-cherryview.c
> @@ -0,0 +1,42 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * @note Copyright (C) 2021 Hongzhan Chen 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +#include 
> +#include 
> +
> +#define RTDM_SUBCLASS_CHERRYVIEW  7
> +
> +static const char *compat_array[] = {

Again naming: 'compat'? Or rather 'label'?

> + "INT33FF:00",
> + "INT33FF:01",
> + "INT33FF:02",
> + "INT33FF:03",
> +};
> +
> +static int __init cherryview_gpio_init(void)
> +{
> + return rtdm_gpiochip_array_find(NULL, compat_array,
> + ARRAY_SIZE(compat_array),
> + RTDM_SUBCLASS_CHERRYVIEW);
> +}
> +module_init(cherryview_gpio_init);
> +
> +static void __exit cherryview_gpio_exit(void)
> +{
> + rtdm_gpiochip_remove(RTDM_SUBCLASS_CHERRYVIEW);
> +}
> +module_exit(cherryview_gpio_exit);
> +
> +MODULE_LICENSE("GPL");
> 

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH 2/3] drivers/gpio: core: Introduce helper to find gpiochip

[Jan Kiszka via Xenomai]

On 31.08.21 09:07, Chen, Hongzhan wrote:
> 
> 
>  -Original Message-
>> From: Jan Kiszka  
>> Sent: Tuesday, August 31, 2021 2:48 PM
>> To: Chen, Hongzhan ; xenomai@xenomai.org
>> Subject: Re: [PATCH 2/3] drivers/gpio: core: Introduce helper to find 
>> gpiochip
>>
>> On 31.08.21 07:07, Hongzhan Chen via Xenomai wrote:
>>> To find gpiochip for non-OF platforms like x86
>>>
>>> Signed-off-by: Hongzhan Chen 
>>> ---
>>>  include/cobalt/kernel/rtdm/gpio.h |  7 ++
>>>  kernel/drivers/gpio/gpio-core.c   | 42 +++
>>>  2 files changed, 49 insertions(+)
>>>
>>> diff --git a/include/cobalt/kernel/rtdm/gpio.h 
>>> b/include/cobalt/kernel/rtdm/gpio.h
>>> index 29f26d6c6..98279e242 100644
>>> --- a/include/cobalt/kernel/rtdm/gpio.h
>>> +++ b/include/cobalt/kernel/rtdm/gpio.h
>>> @@ -62,6 +62,13 @@ int rtdm_gpiochip_add_by_name(struct rtdm_gpio_chip *rgc,
>>>  int rtdm_gpiochip_post_event(struct rtdm_gpio_chip *rgc,
>>>  unsigned int offset);
>>>  
>>> +int rtdm_gpiochip_find(struct device_node *from,
>>> + const char *label, int type);
>>> +
>>> +int rtdm_gpiochip_array_find(struct device_node *from,
>>> +   const char *compat[],
>>> +   int nentries, int type);
>>> +
>>>  #ifdef CONFIG_OF
>>>  
>>>  int rtdm_gpiochip_scan_of(struct device_node *from,
>>> diff --git a/kernel/drivers/gpio/gpio-core.c 
>>> b/kernel/drivers/gpio/gpio-core.c
>>> index ccda67bd1..ce80e8d73 100644
>>> --- a/kernel/drivers/gpio/gpio-core.c
>>> +++ b/kernel/drivers/gpio/gpio-core.c
>>> @@ -528,6 +528,48 @@ int rtdm_gpiochip_add_by_name(struct rtdm_gpio_chip 
>>> *rgc,
>>>  }
>>>  EXPORT_SYMBOL_GPL(rtdm_gpiochip_add_by_name);
>>>  
>>> +int rtdm_gpiochip_find(struct device_node *from, const char *label,
>>> + int type)
>>> +{
>>> +   struct rtdm_gpio_chip *rgc;
>>> +   struct gpio_chip *chip;
>>> +   int ret = -ENODEV;
>>> +
>>> +   if (!rtdm_available())
>>> +   return -ENOSYS;
>>> +
>>> +   chip = find_chip_by_name(label);
>>> +   if (chip == NULL)
>>> +   return ret;
>>> +
>>> +   ret = 0;
>>> +   rgc = rtdm_gpiochip_alloc(chip, type);
>>> +   if (IS_ERR(rgc))
>>> +   ret = PTR_ERR(rgc);
>>> +
>>> +   return ret;
>>> +}
>>> +EXPORT_SYMBOL_GPL(rtdm_gpiochip_find);
>>> +
>>> +int rtdm_gpiochip_array_find(struct device_node *from,
>>> +   const char *compat[],
>>
>> Is "compat" the right argument name here? We are searching by name
>> (label), no?
> 
> Yes , it is label. Let me modify it. So patch 1/3 is accepted ?
> 

Already done that locally while merging. Also just renamed compat_array
to label_array in patch 3. Let me push this then.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

[PATCH v2 0/3] Allow GPIO timestamps also via real-time clock

[Jan Kiszka via Xenomai]

Changes in v2:
 - respect selected mode also in gpio_pin_interrupt
 - select timestamp mode explicitly in gpiobench

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 3 aligns the default to the rest of
Xenomai, using real-time from now on. That's 3.2 material.

Jan

Jan Kiszka (3):
  drivers/gpio: Add support for selecting real-time clock timestamps
  testsuite/gpiobench: Explicitly request monotonic 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   | 19 +++
 testsuite/gpiobench/gpiobench.c   |  2 +-
 4 files changed, 20 insertions(+), 6 deletions(-)

-- 
2.31.1

[PATCH v2 1/3] drivers/gpio: Add support for selecting real-time clock timestamps

[Jan Kiszka via Xenomai]

From: Jan Kiszka 

This allows to compare timestamps of GPIO pins against other devices and
ensures that the stamps are synchronized cross-systems in case PTP is in
use (dovetail-based kernels). Keep default to monotonic for now.

Signed-off-by: Jan Kiszka 
---
 include/cobalt/kernel/rtdm/gpio.h |  1 +
 include/rtdm/uapi/gpio.h  |  4 +++-
 kernel/drivers/gpio/gpio-core.c   | 19 +++
 3 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/include/cobalt/kernel/rtdm/gpio.h 
b/include/cobalt/kernel/rtdm/gpio.h
index 00055ec0a9..72cc3a0356 100644
--- a/include/cobalt/kernel/rtdm/gpio.h
+++ b/include/cobalt/kernel/rtdm/gpio.h
@@ -34,6 +34,7 @@ struct rtdm_gpio_pin {
char *name;
struct gpio_desc *desc;
nanosecs_abs_t timestamp;
+   bool monotonic_timestamp;
 };
 
 struct rtdm_gpio_chip {
diff --git a/include/rtdm/uapi/gpio.h b/include/rtdm/uapi/gpio.h
index 2839f7d51c..fb84274453 100644
--- a/include/rtdm/uapi/gpio.h
+++ b/include/rtdm/uapi/gpio.h
@@ -29,7 +29,9 @@ struct rtdm_gpio_readout {
 #define GPIO_RTIOC_IRQDIS  _IO(RTDM_CLASS_GPIO, 3)
 #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_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_TRIGGER_NONE  0x0 /* unspecified */
 #define GPIO_TRIGGER_EDGE_RISING   0x1
diff --git a/kernel/drivers/gpio/gpio-core.c b/kernel/drivers/gpio/gpio-core.c
index 600ef9789a..5f5ee3d0f7 100644
--- a/kernel/drivers/gpio/gpio-core.c
+++ b/kernel/drivers/gpio/gpio-core.c
@@ -42,7 +42,10 @@ static int gpio_pin_interrupt(rtdm_irq_t *irqh)
 
pin = rtdm_irq_get_arg(irqh, struct rtdm_gpio_pin);
 
-   pin->timestamp = rtdm_clock_read_monotonic();
+   if (pin->monotonic_timestamp)
+   pin->timestamp = rtdm_clock_read_monotonic();
+   else
+   pin->timestamp = rtdm_clock_read();
rtdm_event_signal(&pin->event);
 
return RTDM_IRQ_HANDLED;
@@ -189,11 +192,13 @@ static int gpio_pin_ioctl_nrt(struct rtdm_fd *fd,
gpio_free(gpio);
chan->requested = false;
break;
-   case GPIO_RTIOC_TS:
+   case GPIO_RTIOC_TS_MONO:
+   case GPIO_RTIOC_TS_REAL:
ret = rtdm_safe_copy_from_user(fd, &val, arg, sizeof(val));
if (ret)
return ret;
chan->want_timestamp = !!val;
+   pin->monotonic_timestamp = request == GPIO_RTIOC_TS_MONO;
break;
default:
return -EINVAL;
@@ -228,8 +233,11 @@ static ssize_t gpio_pin_read_rt(struct rtdm_fd *fd,
if (ret)
return ret;
rdo.timestamp = pin->timestamp;
-   } else
+   } else if (pin->monotonic_timestamp) {
rdo.timestamp = rtdm_clock_read_monotonic();
+   } else {
+   rdo.timestamp = rtdm_clock_read();
+   }
 
len = sizeof(rdo);
rdo.value = gpiod_get_raw_value(pin->desc);
@@ -489,7 +497,10 @@ int rtdm_gpiochip_post_event(struct rtdm_gpio_chip *rgc,
return -EINVAL;
 
pin = rgc->pins + offset;
-   pin->timestamp = rtdm_clock_read_monotonic();
+   if (pin->monotonic_timestamp)
+   pin->timestamp = rtdm_clock_read_monotonic();
+   else
+   pin->timestamp = rtdm_clock_read();
rtdm_event_signal(&pin->event);

return 0;
-- 
2.31.1

[PATCH v2 3/3] drivers/gpio: Flip default for GPIO_RTIOC_TS to real-time clock

[Jan Kiszka via Xenomai]

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

[PATCH v2 2/3] testsuite/gpiobench: Explicitly request monotonic timestamps

[Jan Kiszka via Xenomai]

From: Jan Kiszka 

The API's default will change, so select monotonic explicitly.

Signed-off-by: Jan Kiszka 
---
 testsuite/gpiobench/gpiobench.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/testsuite/gpiobench/gpiobench.c b/testsuite/gpiobench/gpiobench.c
index f83d7689f4..50afbd418a 100644
--- a/testsuite/gpiobench/gpiobench.c
+++ b/testsuite/gpiobench/gpiobench.c
@@ -619,7 +619,7 @@ int main(int argc, char **argv)
goto out;
}
 
-   ret = ioctl(ti.fd_dev_intr, GPIO_RTIOC_TS, &value);
+   ret = ioctl(ti.fd_dev_intr, GPIO_RTIOC_TS_MONO, &value);
if (ret) {
printf("ioctl gpio port ts, failed\n");
goto out;
-- 
2.31.1

Re: [PATCH V2 0/3] add support for cherryview gpio controller driver

[Jan Kiszka via Xenomai]

On 31.08.21 07:07, Hongzhan Chen via Xenomai wrote:
> 1. move out of OF config conditional compilation so that non-OF platform
>   call same API to remove rtdm gpio chip device and remove _of for api
>   name.
> 2. Introduce helper to find gpiochip as referring to pair of 
>rtdm_gpiochip_scan_of and rtdm_gpiochip_scan_array_of. 
> 3. Add Intel Cherryview pinctrl driver based on on 1 and 2.
> 
> I also did following tests with this patchset:
> 1. run /usr/lib/xenomai/testsuite/gpiobench -i 334 -i 335 -c INT33FF:02
>to validate patch 9afea5ff2d7ba97db96b22a005a9a7fcf5f2d892 when
>setting GPIO_RTIOC_TS
> 2. apply following patch, and rerun 1.
> 
> index f83d7689f..50afbd418 100644
> --- a/testsuite/gpiobench/gpiobench.c
> +++ b/testsuite/gpiobench/gpiobench.c
> @@ -619,7 +619,7 @@ int main(int argc, char **argv)
> goto out;
> }
> 
> -   ret = ioctl(ti.fd_dev_intr, GPIO_RTIOC_TS, &value);
> +   ret = ioctl(ti.fd_dev_intr, GPIO_RTIOC_TS_MONO, &value);
> if (ret) {
> printf("ioctl gpio port ts, failed\n");
> goto out;
> 
> 3. test result for inner related output:
>REALTIME clock:
>   # Total: 00099
>   # Min Latencies: 00013
>   # Avg Latencies: 16.879997
>   # Max Latencies: 00043
> 
>MONO clock:
>   # Total: 83988
>   # Min Latencies: 00012
>   # Avg Latencies: 2814377.00
>   # Max Latencies: 00041
> 
> Hardware env:
> 1. Rock PI X V1.4.
> 2. GPIO loopback connection between GPIO 334 and 335.
> 
> Hongzhan Chen (3):
>   drivers/gpio: core: Move out of OF config conditional compilation
>   drivers/gpio: core: Introduce helper to find gpiochip
>   driver/gpio: Add Intel Cherryview pinctrl driver
> 
>  include/cobalt/kernel/rtdm/gpio.h | 12 +--
>  kernel/drivers/gpio/Kconfig   |  7 
>  kernel/drivers/gpio/Makefile  |  2 ++
>  kernel/drivers/gpio/gpio-bcm2835.c|  2 +-
>  kernel/drivers/gpio/gpio-cherryview.c | 42 ++
>  kernel/drivers/gpio/gpio-core.c   | 50 ---
>  kernel/drivers/gpio/gpio-mxc.c|  2 +-
>  kernel/drivers/gpio/gpio-omap.c   |  2 +-
>  kernel/drivers/gpio/gpio-sun8i-h3.c   |  2 +-
>  kernel/drivers/gpio/gpio-xilinx.c |  2 +-
>  kernel/drivers/gpio/gpio-zynq7000.c   |  2 +-
>  11 files changed, 112 insertions(+), 13 deletions(-)
>  create mode 100644 kernel/drivers/gpio/gpio-cherryview.c
> 

All three merged, with slight modifications as discussed.

Thanks,
Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH 1/3] drivers/gpio: core: Move out of OF config conditional compilation

[Jan Kiszka via Xenomai]

On 31.08.21 07:07, Hongzhan Chen via Xenomai wrote:
> Rename interface name because it is undependent of OF platform and
> non-OF platform would also call it to remove rtdm gpio chip device.
> 
> Signed-off-by: Hongzhan Chen 
> ---
>  include/cobalt/kernel/rtdm/gpio.h   | 5 ++---
>  kernel/drivers/gpio/gpio-bcm2835.c  | 2 +-
>  kernel/drivers/gpio/gpio-core.c | 8 
>  kernel/drivers/gpio/gpio-mxc.c  | 2 +-
>  kernel/drivers/gpio/gpio-omap.c | 2 +-
>  kernel/drivers/gpio/gpio-sun8i-h3.c | 2 +-
>  kernel/drivers/gpio/gpio-xilinx.c   | 2 +-
>  kernel/drivers/gpio/gpio-zynq7000.c | 2 +-
>  8 files changed, 12 insertions(+), 13 deletions(-)
> 
> diff --git a/include/cobalt/kernel/rtdm/gpio.h 
> b/include/cobalt/kernel/rtdm/gpio.h
> index 72cc3a035..29f26d6c6 100644
> --- a/include/cobalt/kernel/rtdm/gpio.h
> +++ b/include/cobalt/kernel/rtdm/gpio.h
> @@ -70,9 +70,8 @@ int rtdm_gpiochip_scan_of(struct device_node *from,
>  int rtdm_gpiochip_scan_array_of(struct device_node *from,
>   const char *compat[],
>   int nentries, int type);
> -
> -void rtdm_gpiochip_remove_of(int type);
> -
>  #endif
>  
> +void rtdm_gpiochip_remove(int type);
> +
>  #endif /* !_COBALT_RTDM_GPIO_H */
> diff --git a/kernel/drivers/gpio/gpio-bcm2835.c 
> b/kernel/drivers/gpio/gpio-bcm2835.c
> index f30d6b591..a0c17f875 100644
> --- a/kernel/drivers/gpio/gpio-bcm2835.c
> +++ b/kernel/drivers/gpio/gpio-bcm2835.c
> @@ -29,7 +29,7 @@ module_init(bcm2835_gpio_init);
>  
>  static void __exit bcm2835_gpio_exit(void)
>  {
> - rtdm_gpiochip_remove_of(RTDM_SUBCLASS_BCM2835);
> + rtdm_gpiochip_remove(RTDM_SUBCLASS_BCM2835);
>  }
>  module_exit(bcm2835_gpio_exit);
>  
> diff --git a/kernel/drivers/gpio/gpio-core.c b/kernel/drivers/gpio/gpio-core.c
> index 06a19b33a..ccda67bd1 100644
> --- a/kernel/drivers/gpio/gpio-core.c
> +++ b/kernel/drivers/gpio/gpio-core.c
> @@ -626,7 +626,9 @@ int rtdm_gpiochip_scan_array_of(struct device_node *from,
>  }
>  EXPORT_SYMBOL_GPL(rtdm_gpiochip_scan_array_of);
>  
> -void rtdm_gpiochip_remove_of(int type)
> +#endif /* CONFIG_OF */
> +
> +void rtdm_gpiochip_remove(int type)
>  {
>   struct rtdm_gpio_chip *rgc, *n;
>  
> @@ -643,6 +645,4 @@ void rtdm_gpiochip_remove_of(int type)
>  
>   mutex_unlock(&chip_lock);
>  }
> -EXPORT_SYMBOL_GPL(rtdm_gpiochip_remove_of);
> -
> -#endif /* CONFIG_OF */
> +EXPORT_SYMBOL_GPL(rtdm_gpiochip_remove);
> diff --git a/kernel/drivers/gpio/gpio-mxc.c b/kernel/drivers/gpio/gpio-mxc.c
> index 7b28111f6..99162e5f8 100644
> --- a/kernel/drivers/gpio/gpio-mxc.c
> +++ b/kernel/drivers/gpio/gpio-mxc.c
> @@ -35,7 +35,7 @@ module_init(mxc_gpio_init);
>  
>  static void __exit mxc_gpio_exit(void)
>  {
> - rtdm_gpiochip_remove_of(RTDM_SUBCLASS_MXC);
> + rtdm_gpiochip_remove(RTDM_SUBCLASS_MXC);
>  }
>  module_exit(mxc_gpio_exit);
>  
> diff --git a/kernel/drivers/gpio/gpio-omap.c b/kernel/drivers/gpio/gpio-omap.c
> index 5f10278f3..848d84694 100644
> --- a/kernel/drivers/gpio/gpio-omap.c
> +++ b/kernel/drivers/gpio/gpio-omap.c
> @@ -36,7 +36,7 @@ module_init(omap_gpio_init);
>  
>  static void __exit omap_gpio_exit(void)
>  {
> - rtdm_gpiochip_remove_of(RTDM_SUBCLASS_OMAP);
> + rtdm_gpiochip_remove(RTDM_SUBCLASS_OMAP);
>  }
>  module_exit(omap_gpio_exit);
>  
> diff --git a/kernel/drivers/gpio/gpio-sun8i-h3.c 
> b/kernel/drivers/gpio/gpio-sun8i-h3.c
> index 94303dd00..0dcfe8c00 100644
> --- a/kernel/drivers/gpio/gpio-sun8i-h3.c
> +++ b/kernel/drivers/gpio/gpio-sun8i-h3.c
> @@ -36,7 +36,7 @@ module_init(h3_gpio_init);
>  
>  static void __exit h3_gpio_exit(void)
>  {
> - rtdm_gpiochip_remove_of(RTDM_SUBCLASS_H3);
> + rtdm_gpiochip_remove(RTDM_SUBCLASS_H3);
>  }
>  module_exit(h3_gpio_exit);
>  
> diff --git a/kernel/drivers/gpio/gpio-xilinx.c 
> b/kernel/drivers/gpio/gpio-xilinx.c
> index e982f5fa4..05bf870df 100644
> --- a/kernel/drivers/gpio/gpio-xilinx.c
> +++ b/kernel/drivers/gpio/gpio-xilinx.c
> @@ -32,7 +32,7 @@ module_init(xilinx_gpio_init);
>  
>  static void __exit xilinx_gpio_exit(void)
>  {
> - rtdm_gpiochip_remove_of(RTDM_SUBCLASS_XILINX);
> + rtdm_gpiochip_remove(RTDM_SUBCLASS_XILINX);
>  }
>  module_exit(xilinx_gpio_exit);
>  
> diff --git a/kernel/drivers/gpio/gpio-zynq7000.c 
> b/kernel/drivers/gpio/gpio-zynq7000.c
> index 070db3fe4..5a6f2b83d 100644
> --- a/kernel/drivers/gpio/gpio-zynq7000.c
> +++ b/kernel/drivers/gpio/gpio-zynq7000.c
> @@ -32,7 +32,7 @@ module_init(zynq7000_gpio_init);
>  
>  static void __exit zynq7000_gpio_exit(void)
>  {
> - rtdm_gpiochip_remove_of(RTDM_SUBCLASS_ZYNQ7000);
> + rtdm_gpiochip_remove(RTDM_SUBCLASS_ZYNQ7000);
>  }
>  module_exit(zynq7000_gpio_exit);
>  
> 

Oops, we already had a rtdm_gpiochip_remove. Renaming this one to
rtdm_gpiochip_remove_by_type".

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [Dovetail] v5.10.61-rebase released

[Jan Kiszka via Xenomai]

On 31.08.21 10:39, Philippe Gerum via Xenomai wrote:
> 
> At g...@source.denx.de:Xenomai/linux-dovetail.git, branch v5.10.y-rebase
> 

While I appreciate the update push: This is on first sight not really a
release, rather a rebase + new patches.

Philippe, are you still tagging as well, just forgetting to push? Or
should I tag on the merging branch automatically (after a test run passed)?

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH] driver/gpio: gpio-cherryview: call correct api to remove gpio device

[Jan Kiszka via Xenomai]

On 01.09.21 07:21, Hongzhan Chen via Xenomai wrote:
> call correct api to remove gpio device.
> 
> Signed-off-by: Hongzhan Chen 
> 
> diff --git a/kernel/drivers/gpio/gpio-cherryview.c 
> b/kernel/drivers/gpio/gpio-cherryview.c
> index 826faff3a..1234a3e12 100644
> --- a/kernel/drivers/gpio/gpio-cherryview.c
> +++ b/kernel/drivers/gpio/gpio-cherryview.c
> @@ -35,7 +35,7 @@ module_init(cherryview_gpio_init);
>  
>  static void __exit cherryview_gpio_exit(void)
>  {
> - rtdm_gpiochip_remove(RTDM_SUBCLASS_CHERRYVIEW);
> + rtdm_gpiochip_remove_by_type(RTDM_SUBCLASS_CHERRYVIEW);
>  }
>  module_exit(cherryview_gpio_exit);
>  
> 

Oh, indeed. Please send a new version of the affected commit (top of
next right now anyway). And please also update the kernel configs for CI
(xenomai/.gitlab-ci.yml) at this chance so that this new driver is built
whenever possible.

We may also want to enable it in xenomai-images eventually.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH] driver/gpio: Add Intel Cherryview pinctrl driver

[Jan Kiszka via Xenomai]

On 01.09.21 08:46, Hongzhan Chen wrote:
> Add support for Intel Cherryview pin controller driver
> 
> Signed-off-by: Hongzhan Chen 
> [Jan: renamed 'compat_array' to 'label_array']
> Signed-off-by: Jan Kiszka 
> 
> diff --git a/kernel/drivers/gpio/Kconfig b/kernel/drivers/gpio/Kconfig
> index 44f41688c..c257444f0 100644
> --- a/kernel/drivers/gpio/Kconfig
> +++ b/kernel/drivers/gpio/Kconfig
> @@ -57,6 +57,13 @@ config XENO_DRIVERS_GPIO_OMAP
>   Enables support for the GPIO controller available from
>   OMAP family SOC.
>  
> +config XENO_DRIVERS_GPIO_CHERRYVIEW
> + depends on PINCTRL_CHERRYVIEW
> + tristate "Support for Cherryview GPIOs"
> + help
> +
> + Enables support for the Intel Cherryview GPIO controller
> +
>  config XENO_DRIVERS_GPIO_DEBUG
> bool "Enable GPIO core debugging features"
>  
> diff --git a/kernel/drivers/gpio/Makefile b/kernel/drivers/gpio/Makefile
> index 7bcf59949..e534eab93 100644
> --- a/kernel/drivers/gpio/Makefile
> +++ b/kernel/drivers/gpio/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_XENO_DRIVERS_GPIO_SUN8I_H3) += 
> xeno-gpio-sun8i-h3.o
>  obj-$(CONFIG_XENO_DRIVERS_GPIO_ZYNQ7000) += xeno-gpio-zynq7000.o
>  obj-$(CONFIG_XENO_DRIVERS_GPIO_XILINX) += xeno-gpio-xilinx.o
>  obj-$(CONFIG_XENO_DRIVERS_GPIO_OMAP) += xeno-gpio-omap.o
> +obj-$(CONFIG_XENO_DRIVERS_GPIO_CHERRYVIEW) += xeno-gpio-cherryview.o
>  obj-$(CONFIG_XENO_DRIVERS_GPIO) += gpio-core.o
>  
>  xeno-gpio-bcm2835-y := gpio-bcm2835.o
> @@ -14,3 +15,4 @@ xeno-gpio-sun8i-h3-y := gpio-sun8i-h3.o
>  xeno-gpio-zynq7000-y := gpio-zynq7000.o
>  xeno-gpio-xilinx-y := gpio-xilinx.o
>  xeno-gpio-omap-y := gpio-omap.o
> +xeno-gpio-cherryview-y := gpio-cherryview.o
> diff --git a/kernel/drivers/gpio/gpio-cherryview.c 
> b/kernel/drivers/gpio/gpio-cherryview.c
> new file mode 100644
> index 0..1234a3e12
> --- /dev/null
> +++ b/kernel/drivers/gpio/gpio-cherryview.c
> @@ -0,0 +1,42 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * @note Copyright (C) 2021 Hongzhan Chen 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +#include 
> +#include 
> +
> +#define RTDM_SUBCLASS_CHERRYVIEW  7
> +
> +static const char *label_array[] = {
> + "INT33FF:00",
> + "INT33FF:01",
> + "INT33FF:02",
> + "INT33FF:03",
> +};
> +
> +static int __init cherryview_gpio_init(void)
> +{
> + return rtdm_gpiochip_array_find(NULL, label_array,
> + ARRAY_SIZE(label_array),
> + RTDM_SUBCLASS_CHERRYVIEW);
> +}
> +module_init(cherryview_gpio_init);
> +
> +static void __exit cherryview_gpio_exit(void)
> +{
> + rtdm_gpiochip_remove_by_type(RTDM_SUBCLASS_CHERRYVIEW);
> +}
> +module_exit(cherryview_gpio_exit);
> +
> +MODULE_LICENSE("GPL");
> 

Thanks, integrated. Will send the CI update patch separately.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

[PATCH] ci: Add new GPIO Cherryview driver

[Jan Kiszka via Xenomai]

From: Jan Kiszka 

Ensures build-testing.

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 68785f657c..5932dec876 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -160,6 +160,7 @@ variables:
 - ./scripts/config -e XENO_DRIVERS_GPIO_ZYNQ7000
 - ./scripts/config -e XENO_DRIVERS_GPIO_XILINX
 - ./scripts/config -e XENO_DRIVERS_GPIO_OMAP
+- ./scripts/config -e XENO_DRIVERS_GPIO_CHERRYVIEW
 - ./scripts/config -e XENO_DRIVERS_GPIO_DEBUG
 - ./scripts/config -e XENO_DRIVERS_GPIOPWM
 - ./scripts/config -e XENO_DRIVERS_SPI_BCM2835
-- 
2.31.1

[PATCH] ci: Enable gpiolib

[Jan Kiszka via Xenomai]

From: Jan Kiszka 

This ensures that Xenomai GPIO drivers are built. It's a dependency of
XENO_DRIVERS_GPIO that is not automatically enabled.

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 68785f657c..88c4c37ba8 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -153,6 +153,7 @@ variables:
 - ./scripts/config -e XENO_DRIVERS_ANALOGY_S526
 - ./scripts/config -e XENO_DRIVERS_RTIPC
 - ./scripts/config -e XENO_DRIVERS_UDD
+- ./scripts/config -e GPIOLIB
 - ./scripts/config -e XENO_DRIVERS_GPIO
 - ./scripts/config -e XENO_DRIVERS_GPIO_BCM2835
 - ./scripts/config -e XENO_DRIVERS_GPIO_MXC
-- 
2.31.1

[PATCH v2] ci: Add new GPIO Cherryview driver

[Jan Kiszka via Xenomai]

From: Jan Kiszka 

Ensures build-testing. We need to enable a couple of dependencies of the
driver for that.

Signed-off-by: Jan Kiszka 
---

Changes in v2:
 - enable dependencies

 .gitlab-ci.yml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 88c4c37ba8..602a7682ac 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -161,6 +161,9 @@ variables:
 - ./scripts/config -e XENO_DRIVERS_GPIO_ZYNQ7000
 - ./scripts/config -e XENO_DRIVERS_GPIO_XILINX
 - ./scripts/config -e XENO_DRIVERS_GPIO_OMAP
+- ./scripts/config -e PINCTRL
+- ./scripts/config -e PINCTRL_CHERRYVIEW
+- ./scripts/config -e XENO_DRIVERS_GPIO_CHERRYVIEW
 - ./scripts/config -e XENO_DRIVERS_GPIO_DEBUG
 - ./scripts/config -e XENO_DRIVERS_GPIOPWM
 - ./scripts/config -e XENO_DRIVERS_SPI_BCM2835
-- 
2.31.1

Re: [PATCH 0/3] add support for cherryview gpio controller driver

[Jan Kiszka via Xenomai]

On 31.08.21 08:36, Chen, Hongzhan wrote:
>>> -Original Message-
 From: Jan Kiszka  
 Sent: Tuesday, August 31, 2021 1:59 PM
 To: Chen, Hongzhan ; xenomai@xenomai.org
 Subject: Re: [PATCH 0/3] add support for cherryview gpio controller driver

 On 31.08.21 03:35, Chen, Hongzhan wrote:
>>
>>
>> -Original Message-
>> From: Jan Kiszka  
>> Sent: Monday, August 30, 2021 3:37 PM
>> To: Chen, Hongzhan ; xenomai@xenomai.org
>> Subject: Re: [PATCH 0/3] add support for cherryview gpio controller 
>> driver
>>
>> On 30.08.21 08:45, Hongzhan Chen via Xenomai wrote:
>>> 1. move out of OF config conditional compilation so that non-OF platform
>>>   call same API to remove rtdm gpio chip device.
>>> 2. Introduce helper to find gpiochip as referring to pair of 
>>>rtdm_gpiochip_scan_of and rtdm_gpiochip_scan_array_of. 
>>> 3. Add Intel Cherryview pinctrl driver based on on 1 and 2.
>>>
>>
>> Looks good, except for that naming issue.
>>
>>> I also did following tests with this patchset:
>>> 1. run /usr/lib/xenomai/testsuite/gpiobench -i 334 -i 335 -c INT33FF:02
>>>to validate patch 9afea5ff2d7ba97db96b22a005a9a7fcf5f2d892 when
>>>setting GPIO_RTIOC_TS
>>> 2. apply following patch, and rerun 1.
>>>
>>> index f83d7689f..50afbd418 100644
>>> --- a/testsuite/gpiobench/gpiobench.c
>>> +++ b/testsuite/gpiobench/gpiobench.c
>>> @@ -619,7 +619,7 @@ int main(int argc, char **argv)
>>> goto out;
>>> }
>>>
>>> -   ret = ioctl(ti.fd_dev_intr, GPIO_RTIOC_TS, &value);
>>> +   ret = ioctl(ti.fd_dev_intr, GPIO_RTIOC_TS_MONO, &value);
>>> if (ret) {
>>> printf("ioctl gpio port ts, failed\n");
>>> goto out;
>>>
>>> Hardware env:
>>> 1. Rock PI X V1.4.
>>> 2. GPIO loopback connection between GPIO 334 and 335.
>>>  
>>
>> Did you check if timestamps are as expected (different)?
>
> According to output of gpiobench, the inner Avg Latency would be vary 
> large like ( 2814377.0) after switch to MONO.
> But it is only about  16.879997 when we set REALTIME. 
>

 gpiobench takes timestamps from CLOCK_MONOTONIC (see clock_gettime
 calls)). If you compare them to REALTIME, that will give an offset. But
 you report just the opposite, this confuses me now...
>>>
>>> The test is running on dovetail based 5.10.
>>>
>>
>> I missed one case in gpio_pin_interrupt where I need to check
>> monotonic_timestamp - but, again, mono is what should remain fine,
>> GPIO_RTIOC_TS_REAL (or GPIO_RTIOC_TS, the default) should give a delta.
> 
> I found there is one obvious gap for my comparison test.
> 
> For REALTEIM , it totally run 99 like [1] till test normally exit. But 
> for MONO, I force to quit during running
> because it may take several hours to finish and I can not wait like [2]. Let 
> me rerun test and wait till it normally exit and 
> get result to check.
> 
> [1]:
> # Total: 00099
> # Min Latencies: 00013
> # Avg Latencies: 16.879997
> # Max Latencies: 00043
> [2]:
> # Total: 83988
> # Min Latencies: 00012
> # Avg Latencies: 2814377.00
> # Max Latencies: 00041
> 

Were you able to resolve this mystery over latest next?

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH 0/3] add support for cherryview gpio controller driver

[Jan Kiszka via Xenomai]

On 02.09.21 02:42, Chen, Hongzhan wrote:
> 
> 
>> -Original Message-
>> From: Jan Kiszka  
>> Sent: Wednesday, September 1, 2021 10:27 PM
>> To: Chen, Hongzhan ; xenomai@xenomai.org
>> Subject: Re: [PATCH 0/3] add support for cherryview gpio controller driver
>>
>> On 31.08.21 08:36, Chen, Hongzhan wrote:
> -Original Message-
>> From: Jan Kiszka  
>> Sent: Tuesday, August 31, 2021 1:59 PM
>> To: Chen, Hongzhan ; xenomai@xenomai.org
>> Subject: Re: [PATCH 0/3] add support for cherryview gpio controller 
>> driver
>>
>> On 31.08.21 03:35, Chen, Hongzhan wrote:


 -Original Message-
 From: Jan Kiszka  
 Sent: Monday, August 30, 2021 3:37 PM
 To: Chen, Hongzhan ; xenomai@xenomai.org
 Subject: Re: [PATCH 0/3] add support for cherryview gpio controller 
 driver

 On 30.08.21 08:45, Hongzhan Chen via Xenomai wrote:
> 1. move out of OF config conditional compilation so that non-OF 
> platform
>   call same API to remove rtdm gpio chip device.
> 2. Introduce helper to find gpiochip as referring to pair of 
>rtdm_gpiochip_scan_of and rtdm_gpiochip_scan_array_of. 
> 3. Add Intel Cherryview pinctrl driver based on on 1 and 2.
>

 Looks good, except for that naming issue.

> I also did following tests with this patchset:
> 1. run /usr/lib/xenomai/testsuite/gpiobench -i 334 -i 335 -c 
> INT33FF:02
>to validate patch 9afea5ff2d7ba97db96b22a005a9a7fcf5f2d892 when
>setting GPIO_RTIOC_TS
> 2. apply following patch, and rerun 1.
>
> index f83d7689f..50afbd418 100644
> --- a/testsuite/gpiobench/gpiobench.c
> +++ b/testsuite/gpiobench/gpiobench.c
> @@ -619,7 +619,7 @@ int main(int argc, char **argv)
> goto out;
> }
>
> -   ret = ioctl(ti.fd_dev_intr, GPIO_RTIOC_TS, &value);
> +   ret = ioctl(ti.fd_dev_intr, GPIO_RTIOC_TS_MONO, 
> &value);
> if (ret) {
> printf("ioctl gpio port ts, failed\n");
> goto out;
>
> Hardware env:
> 1. Rock PI X V1.4.
> 2. GPIO loopback connection between GPIO 334 and 335.
>  

 Did you check if timestamps are as expected (different)?
>>>
>>> According to output of gpiobench, the inner Avg Latency would be vary 
>>> large like ( 2814377.0) after switch to MONO.
>>> But it is only about  16.879997 when we set REALTIME. 
>>>
>>
>> gpiobench takes timestamps from CLOCK_MONOTONIC (see clock_gettime
>> calls)). If you compare them to REALTIME, that will give an offset. But
>> you report just the opposite, this confuses me now...
>
> The test is running on dovetail based 5.10.
>

 I missed one case in gpio_pin_interrupt where I need to check
 monotonic_timestamp - but, again, mono is what should remain fine,
 GPIO_RTIOC_TS_REAL (or GPIO_RTIOC_TS, the default) should give a delta.
>>>
>>> I found there is one obvious gap for my comparison test.
>>>
>>> For REALTEIM , it totally run 99 like [1] till test normally exit. But 
>>> for MONO, I force to quit during running
>>> because it may take several hours to finish and I can not wait like [2]. 
>>> Let me rerun test and wait till it normally exit and 
>>> get result to check.
>>>
>>> [1]:
>>> # Total: 00099
>>> # Min Latencies: 00013
>>> # Avg Latencies: 16.879997
>>> # Max Latencies: 00043
>>> [2]:
>>> # Total: 83988
>>> # Min Latencies: 00012
>>> # Avg Latencies: 2814377.00
>>> # Max Latencies: 00041
>>>
>>
>> Were you able to resolve this mystery over latest next?
> 
> Yes. Firstly , I am doing complete test with passing MONO or REALTIME to 
> check if this mystery large AVG latency 
> still happen till gpiobench normally exit and do comparison test based on 
> updated next code. And then figure out 
> why it happen when gpiobench is interrupted during running and fix it if it 
> is problem caused by timestamp.
> 

So, you WILL do this, right? I'm asking because this is blocking -rc1,
and I can't test here.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH 0/3] add support for cherryview gpio controller driver

[Jan Kiszka via Xenomai]

On 02.09.21 08:24, Chen, Hongzhan wrote:
> 
> 
>> -Original Message-
>> From: Jan Kiszka  
>> Sent: Thursday, September 2, 2021 2:11 PM
>> To: Chen, Hongzhan ; xenomai@xenomai.org
>> Subject: Re: [PATCH 0/3] add support for cherryview gpio controller driver
>>
>> On 02.09.21 02:42, Chen, Hongzhan wrote:
>>>
>>>
 -Original Message-
 From: Jan Kiszka  
 Sent: Wednesday, September 1, 2021 10:27 PM
 To: Chen, Hongzhan ; xenomai@xenomai.org
 Subject: Re: [PATCH 0/3] add support for cherryview gpio controller driver

 On 31.08.21 08:36, Chen, Hongzhan wrote:
>>> -Original Message-
 From: Jan Kiszka  
 Sent: Tuesday, August 31, 2021 1:59 PM
 To: Chen, Hongzhan ; xenomai@xenomai.org
 Subject: Re: [PATCH 0/3] add support for cherryview gpio controller 
 driver

 On 31.08.21 03:35, Chen, Hongzhan wrote:
>>
>>
>> -Original Message-
>> From: Jan Kiszka  
>> Sent: Monday, August 30, 2021 3:37 PM
>> To: Chen, Hongzhan ; xenomai@xenomai.org
>> Subject: Re: [PATCH 0/3] add support for cherryview gpio controller 
>> driver
>>
>> On 30.08.21 08:45, Hongzhan Chen via Xenomai wrote:
>>> 1. move out of OF config conditional compilation so that non-OF 
>>> platform
>>>   call same API to remove rtdm gpio chip device.
>>> 2. Introduce helper to find gpiochip as referring to pair of 
>>>rtdm_gpiochip_scan_of and rtdm_gpiochip_scan_array_of. 
>>> 3. Add Intel Cherryview pinctrl driver based on on 1 and 2.
>>>
>>
>> Looks good, except for that naming issue.
>>
>>> I also did following tests with this patchset:
>>> 1. run /usr/lib/xenomai/testsuite/gpiobench -i 334 -i 335 -c 
>>> INT33FF:02
>>>to validate patch 9afea5ff2d7ba97db96b22a005a9a7fcf5f2d892 when
>>>setting GPIO_RTIOC_TS
>>> 2. apply following patch, and rerun 1.
>>>
>>> index f83d7689f..50afbd418 100644
>>> --- a/testsuite/gpiobench/gpiobench.c
>>> +++ b/testsuite/gpiobench/gpiobench.c
>>> @@ -619,7 +619,7 @@ int main(int argc, char **argv)
>>> goto out;
>>> }
>>>
>>> -   ret = ioctl(ti.fd_dev_intr, GPIO_RTIOC_TS, &value);
>>> +   ret = ioctl(ti.fd_dev_intr, GPIO_RTIOC_TS_MONO, 
>>> &value);
>>> if (ret) {
>>> printf("ioctl gpio port ts, failed\n");
>>> goto out;
>>>
>>> Hardware env:
>>> 1. Rock PI X V1.4.
>>> 2. GPIO loopback connection between GPIO 334 and 335.
>>>  
>>
>> Did you check if timestamps are as expected (different)?
>
> According to output of gpiobench, the inner Avg Latency would be vary 
> large like ( 2814377.0) after switch to MONO.
> But it is only about  16.879997 when we set REALTIME. 
>

 gpiobench takes timestamps from CLOCK_MONOTONIC (see clock_gettime
 calls)). If you compare them to REALTIME, that will give an offset. But
 you report just the opposite, this confuses me now...
>>>
>>> The test is running on dovetail based 5.10.
>>>
>>
>> I missed one case in gpio_pin_interrupt where I need to check
>> monotonic_timestamp - but, again, mono is what should remain fine,
>> GPIO_RTIOC_TS_REAL (or GPIO_RTIOC_TS, the default) should give a delta.
>
> I found there is one obvious gap for my comparison test.
>
> For REALTEIM , it totally run 99 like [1] till test normally exit. 
> But for MONO, I force to quit during running
> because it may take several hours to finish and I can not wait like [2]. 
> Let me rerun test and wait till it normally exit and 
> get result to check.
>
> [1]:
> # Total: 00099
> # Min Latencies: 00013
> # Avg Latencies: 16.879997
> # Max Latencies: 00043
> [2]:
> # Total: 83988
> # Min Latencies: 00012
> # Avg Latencies: 2814377.00
> # Max Latencies: 00041
>

 Were you able to resolve this mystery over latest next?
>>>
>>> Yes. Firstly , I am doing complete test with passing MONO or REALTIME to 
>>> check if this mystery large AVG latency 
>>> still happen till gpiobench normally exit and do comparison test based on 
>>> updated next code. And then figure out 
>>> why it happen when gpiobench is interrupted during running and fix it if it 
>>> is problem caused by timestamp.
>>>
>>
>> So, you WILL do this, right? I'm asking because this is blocking -rc1,
>> and I can't test here.
> 
> Yes. I already found the root cause. It is caused by gpiobench itself. 
> Because 
> It do not execute "ti.ts.inner_a

Re: [PATCH] testsuite/gpiobench: Do calculate avg latency once when test is interrupted

[Jan Kiszka via Xenomai]

On 02.09.21 09:27, Hongzhan Chen via Xenomai wrote:
> When test is interrupted, avg latency need to be calcuated once
> to avoid large latency showing even though it may not be quite
> accurate.
> 
> Signed-off-by: Hongzhan Chen 
> 
> diff --git a/testsuite/gpiobench/gpiobench.c b/testsuite/gpiobench/gpiobench.c
> index 50afbd418..50dc7aef7 100644
> --- a/testsuite/gpiobench/gpiobench.c
> +++ b/testsuite/gpiobench/gpiobench.c
> @@ -482,6 +482,18 @@ static void print_hist(void)
>  {
>   int i;
>  
> + if (ti.total_cycles < (ti.max_cycles - 1)) {
> + /* test is interrupted and force to calculate
> +  * even though it is not accurate but to avoid
> +  * large latency surprising us.
> +  */
> + printf("test is interrupted and exit exceptionally\n");
> + printf("Please run again till it exit normally\n");
> +
> + ti.ts.inner_avg /= (ti.total_cycles * 2);
> + ti.ts.outer_avg /= (ti.total_cycles * 2);
> +
> + }
>   printf("\n");
>   printf("# Inner Loop Histogram\n");
>   printf("# Inner Loop latency is the latency in kernel space\n"
> 

Thanks, applied.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH] testsuite/gpiobench: Do calculate avg latency once when test is interrupted

[Jan Kiszka via Xenomai]

On 02.09.21 10:33, Jan Kiszka wrote:
> On 02.09.21 09:27, Hongzhan Chen via Xenomai wrote:
>> When test is interrupted, avg latency need to be calcuated once
>> to avoid large latency showing even though it may not be quite
>> accurate.
>>
>> Signed-off-by: Hongzhan Chen 
>>
>> diff --git a/testsuite/gpiobench/gpiobench.c 
>> b/testsuite/gpiobench/gpiobench.c
>> index 50afbd418..50dc7aef7 100644
>> --- a/testsuite/gpiobench/gpiobench.c
>> +++ b/testsuite/gpiobench/gpiobench.c
>> @@ -482,6 +482,18 @@ static void print_hist(void)
>>  {
>>  int i;
>>  
>> +if (ti.total_cycles < (ti.max_cycles - 1)) {
>> +/* test is interrupted and force to calculate
>> + * even though it is not accurate but to avoid
>> + * large latency surprising us.
>> + */
>> +printf("test is interrupted and exit exceptionally\n");
>> +printf("Please run again till it exit normally\n");
>> +
>> +ti.ts.inner_avg /= (ti.total_cycles * 2);
>> +ti.ts.outer_avg /= (ti.total_cycles * 2);
>> +
>> +}
>>  printf("\n");
>>  printf("# Inner Loop Histogram\n");
>>  printf("# Inner Loop latency is the latency in kernel space\n"
>>
> 
> Thanks, applied.
> 
> Jan
> 

...with some tuning of the wording and the newline. See next.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH] testsuite/gpiobench: Provide choice to switch clock for getting timestamp

[Jan Kiszka via Xenomai]

On 03.09.21 06:33, Hongzhan Chen via Xenomai wrote:
> Provide choices to switch clock between MONO and REALTIME for getting
> different timestamp since gpio driver already provide choosable service.
> 
> Signed-off-by: Hongzhan Chen 
> 
> diff --git a/testsuite/gpiobench/gpiobench.c b/testsuite/gpiobench/gpiobench.c
> index 0f099b0e8..04c694639 100644
> --- a/testsuite/gpiobench/gpiobench.c
> +++ b/testsuite/gpiobench/gpiobench.c
> @@ -85,6 +85,7 @@ struct test_info {
>   unsigned long total_cycles;
>   unsigned long max_histogram;
>   int mode;
> + int clockid;
>   int prio;
>   int quiet;
>   int tracelimit;
> @@ -121,7 +122,10 @@ static void display_help(void)
>  "must be specified\n"
>  "-m   --testmode 0 is loopback mode\n"
>  "1 is react mode which works with a 
> latency box,\n"
> -"default=0\n\n"
> +"default=0\n"
> +"-k   --clockid  0 is CLOCK_REALTIME\n"
> +"1 is CLOCK_MONOTONIC,\n"
> +"default=1\n\n"
>  
>  "e.g. gpiobench -o 20 -i 21 -c pinctrl-bcm2835\n"
>   );
> @@ -130,7 +134,7 @@ static void display_help(void)
>  static void process_options(int argc, char *argv[])
>  {
>   int c = 0;
> - static const char optstring[] = "h:p:m:l:c:b:i:o:q";
> + static const char optstring[] = "h:p:m:l:c:b:i:o:k:q";
>  
>   struct option long_options[] = {
>   { "bracetrace", required_argument, 0, 'b'},
> @@ -142,6 +146,7 @@ static void process_options(int argc, char *argv[])
>   { "intr", required_argument, 0, 'i'},
>   { "pinctrl", required_argument, 0, 'c'},
>   { "testmode", required_argument, 0, 'm'},
> + { "clockid", required_argument, 0, 'k'},
>   { 0, 0, 0, 0},
>   };
>  
> @@ -185,6 +190,11 @@ static void process_options(int argc, char *argv[])
>   MODE_REACT ? MODE_REACT : MODE_LOOPBACK;
>   break;
>  
> + case 'k':
> + ti.clockid = atoi(optarg) >= CLOCK_MONOTONIC ?
> + CLOCK_MONOTONIC : CLOCK_REALTIME;
> + break;
> +
>   default:
>   display_help();
>   exit(2);
> @@ -291,7 +301,7 @@ static int rw_gpio(int value, int index)
>   struct rtdm_gpio_readout rdo;
>   long long gpio_write, gpio_read, inner_diff, outer_diff;
>  
> - clock_gettime(CLOCK_MONOTONIC, ×tamp);
> + clock_gettime(ti.clockid, ×tamp);
>   gpio_write = calc_us(timestamp);
>  
>   ret = write(ti.fd_dev_out, &value, sizeof(value));
> @@ -306,7 +316,7 @@ static int rw_gpio(int value, int index)
>   return ret;
>   }
>  
> - clock_gettime(CLOCK_MONOTONIC, ×tamp);
> + clock_gettime(ti.clockid, ×tamp);
>   gpio_read = calc_us(timestamp);
>  
>   inner_diff = (rdo.timestamp - gpio_write) / 1000;
> @@ -472,6 +482,7 @@ static void init_ti(void)
>   ti.gpio_out = -1;
>   ti.gpio_intr = -1;
>   ti.mode = MODE_LOOPBACK;
> + ti.clockid = CLOCK_MONOTONIC;
>  
>   ti.ts.inner_min = ti.ts.outer_min = DEFAULT_LIMIT;
>   ti.ts.inner_max = ti.ts.outer_max = 0;
> @@ -632,7 +643,9 @@ int main(int argc, char **argv)
>   goto out;
>   }
>  
> - ret = ioctl(ti.fd_dev_intr, GPIO_RTIOC_TS_MONO, &value);
> + ret = ioctl(ti.fd_dev_intr,
> + ti.clockid == CLOCK_MONOTONIC ?
> + GPIO_RTIOC_TS_MONO : GPIO_RTIOC_TS_REAL, &value);
>   if (ret) {
>   printf("ioctl gpio port ts, failed\n");
>   goto out;
> 

Merged to next, thanks.

May I assume that both modes work fine now?

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: irq pipeline: Netdev watchdog triggered

[Jan Kiszka via Xenomai]

On 06.09.21 14:58, Bezdeka, Florian (T RDA IOT SES-DE) wrote:
> Hi,
> 
> here is another IRQ_PIPELINE problem we're facing on on of our quite
> big Xenomai machines:
> 
> Platform:
> Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz
> 2 Sockets, 6 cores per socket, 2 threads per core
> (2 NUMA nodes)
> 
> As soon as we enable CONFIG_IRQ_PIPELINE the netdev watchdog triggers.
> There is no specific load on the system. In most cases the watchdog
> triggers right after booting up. There is no xenomai task running when
> the crash happens.
> 
> The problem was detected during reboot tests. Disabling
> CONFIG_IRQ_PIPELINE helped. We didn't run into a problem for >400
> reboots.
> 
> Any advise how to debug that? Dovetail torture tests have already been
> run and there was no error reported. CONFIG_DEBUG_IRQ_PIPELINE is
> enabled as well and did not help so far.
> 
> The stacktrace follows but I guess it's not really helpful:
> 
> [ cut here ]
> [   42.114151] NETDEV WATCHDOG: enp7s0f0 (igb): transmit queue 5 timed out
> [   42.114173] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:467 
> dev_watchdog+0x205/0x210
> [   42.163593] Modules linked in: overlay x86_pkg_temp_thermal 
> intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul mei_me iTCO_wdt 
> iTCO_vendor_support mei hed ipmi_si ipmi_devintf ipmi_msghandler msr fuse 
> configfs ip_tables x_tables ipv6 autofs4 raid10 raid456 async_raid6_recov 
> async_memcpy async_pq async_xor xor async_tx hid_generic usbhid hid raid6_pq 
> libcrc32c raid1 raid0 multipath linear lpc_ich ahci i2c_i801 xhci_pci 
> i2c_smbus mfd_core libahci mpt3sas igb i2c_algo_bit raid_class xhci_hcd 
> scsi_transport_sas
> [   42.435191] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
> 5.10.61-dovetaildbg-noxeno-pipedbg-0 #1
> [   42.486198] Hardware name: Siemens <...snip...>, BIOS s2.0a_M1 08/02/2016
> [   42.546050] IRQ stage: Linux
> [   42.563263] RIP: 0010:dev_watchdog+0x205/0x210
> [   42.589837] Code: 91 26 fe ff eb b1 4c 89 ef c6 05 9e 1d b7 00 01 e8 90 86 
> fb ff 44 89 e1 4c 89 ee 48 c7 c7 48 41 de b7 48 89 c2 e8 8a c1 0a 00 <0f> 0b 
> eb 92 0f 1f 80 00 00 00 00 0f 1f 44 00 00 f0 80 a7 d8 00 00
> [   42.702205] RSP: 0018:9ff4c0003ec0 EFLAGS: 00010282
> [   42.733459] RAX:  RBX: 930cc42438c0 RCX: 
> 4002
> [   42.776148] RDX: 4004 RSI:  RDI: 
> b70cb824
> [   42.818841] RBP: 930cc7e903b8 R08: 0007daee R09: 
> 9ff4c0003cc8
> [   42.861531] R10: e000 R11: 3fff R12: 
> 0006
> [   42.904224] R13: 930cc7e9 R14: b7686860 R15: 
> 9ff4c0003f18
> [   42.946916] FS:  () GS:931bff80() 
> knlGS:
> [   42.995328] CS:  0010 DS:  ES:  CR0: 80050033
> [   43.029700] CR2: 00c000e5 CR3: 0001057ca001 CR4: 
> 001706f0
> [   43.072391] DR0:  DR1:  DR2: 
> 
> [   43.115082] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [   43.157774] Call Trace:
> [   43.172388]  
> [   43.184400]  ? pfifo_fast_dequeue+0x1e0/0x1e0
> [   43.210453]  call_timer_fn+0x2b/0x100
> [   43.232344]  __run_timers.part.0+0x1d9/0x250
> [   43.257879]  ? ktime_get+0x35/0x90
> [   43.278205]  run_timer_softirq+0x26/0x50
> [   43.301661]  __do_softirq+0x105/0x30b
> [   43.323550]  asm_call_irq_on_stack+0xf/0x20
> [   43.348562]  
> [   43.361099]  do_softirq_own_stack+0x37/0x40
> [   43.386108]  irq_exit_rcu+0xaa/0xe0
> [   43.406960]  arch_do_IRQ_pipelined+0x78/0x130
> [   43.433012]  sync_current_irq_stage+0x177/0x250
> [   43.460100]  __inband_irq_enable+0x4c/0x50
> [   43.484593]  cpuidle_enter_state+0x100/0x3a0
> [   43.510125]  cpuidle_enter+0x29/0x40
> [   43.531498]  do_idle+0x1eb/0x230
> [   43.550787]  cpu_startup_entry+0x19/0x20
> [   43.574241]  start_kernel+0x56d/0x590
> [   43.596134]  secondary_startup_64_no_verify+0xb0/0xbb
> [   43.626343] ---[ end trace b219258fce8dc761 ]---
> [   43.654095] igb :07:00.0 enp7s0f0: Reset adapter
> [   46.090948] igb :07:00.0: exceed max 2 second
> 

This is just the warning from the NIC watchdog handler. What we still
need to find out is the health of other NIC interrupts around this
event. Also if other interrupts are possibly affected as well or just
one or more of the device.

BTW, can we recover the device by ifdown/up? Or by driver unbind/bind?

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

[ANNOUNCE] Xenomai v3.2-rc1 available

[Jan Kiszka via Xenomai]

Hi all,

we are heading for a new major release, Xenomai 3.1-rc1 is now 
available:

https://gitlab.denx.de/Xenomai/xenomai/-/archive/v3.2-rc1/xenomai-v3.2-rc1.tar.bz2
https://gitlab.denx.de/Xenomai/xenomai/commits/v3.2-rc1

Please test it intensively, specifically in combination with the new 
Dovetail patches and kernel 5.10. But also the combination with 4.19-
ipipe should still work.

Thanks a lot to all the contributors to this release!

Jan

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

Re: An error occures when installing Xenomai libraries and tools

[Jan Kiszka via Xenomai]

On 09.09.21 08:55, Bezdeka, Florian via Xenomai wrote:
> On Thu, 2021-09-09 at 11:43 +0800, rany97 via Xenomai wrote:
>> Hi,
>>
>>
>> When I run "sudo make install" to install Xenomai libraries and tools, gcc 
>> reports an error posted below:
>> 
>> /home/rany/build_rtos/xenomai/src/xenomai-3.1/lib/boilerplate/iniparser/iniparser.c:
>>  In function ‘iniparser_load’:
>> /home/rany/build_rtos/xenomai/src/xenomai-3.1/lib/boilerplate/iniparser/iniparser.c:616:13:
>>  error: ‘sprintf’ arguments 3, 4 may overlap destination object ‘buf’ 
>> [-Werror=restrict]
>>   616 |             sprintf(tmp, 
>> "%s:%s", section, key);
>>       |            
>>  ^~~
>> cc1: all warnings being treated as errors
>>
>> ---
>> Shall I ignore it?
>>
>> ---
>> Some info lost in last mail:
>> gcc 10.2.1
>> Linux debian 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64 
>> GNU/Linux
>> Xenomai 3.1
>> ---
> 
> I have the same setup here, and there is no such warning. There is no
> sprintf in iniparser.c:616. Are you sure it's Xenomai 3.1 you're
> looking at?
> 
> Some time ago I had to update the iniparser (from its upstream source)
> to get rid of such compiler warnings.
> 

That fix was merged into master and stable/v3.1.x long ago. You just
need to use the latest stable release.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: An error occures when installing Xenomai libraries and tools

[Jan Kiszka via Xenomai]

On 09.09.21 16:47, Bezdeka, Florian (T RDA IOT SES-DE) wrote:
> On Thu, 2021-09-09 at 09:00 +0200, Jan Kiszka wrote:
>> On 09.09.21 08:55, Bezdeka, Florian via Xenomai wrote:
>>> On Thu, 2021-09-09 at 11:43 +0800, rany97 via Xenomai wrote:
 Hi,


 When I run "sudo make install" to install Xenomai libraries and tools, gcc 
 reports an error posted below:
 
 /home/rany/build_rtos/xenomai/src/xenomai-3.1/lib/boilerplate/iniparser/iniparser.c:
  In function ‘iniparser_load’:
 /home/rany/build_rtos/xenomai/src/xenomai-3.1/lib/boilerplate/iniparser/iniparser.c:616:13:
  error: ‘sprintf’ arguments 3, 4 may overlap destination object ‘buf’ 
 [-Werror=restrict]
   616 |             sprintf(tmp, 
 "%s:%s", section, key);
       |            
  ^~~
 cc1: all warnings being treated as errors

 ---
 Shall I ignore it?

 ---
 Some info lost in last mail:
 gcc 10.2.1
 Linux debian 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64 
 GNU/Linux
 Xenomai 3.1
 ---
>>>
>>> I have the same setup here, and there is no such warning. There is no
>>> sprintf in iniparser.c:616. Are you sure it's Xenomai 3.1 you're
>>> looking at?
>>>
>>> Some time ago I had to update the iniparser (from its upstream source)
>>> to get rid of such compiler warnings.
>>>
>>
>> That fix was merged into master and stable/v3.1.x long ago. You just
>> need to use the latest stable release.
> 
> Just noticed that the stable/3.0 branch still has this issue. So maybe
> it was about 3.0 and not 3.1?
> 
> @Jan
> I noticed that 3.0 is broken when trying to update xenomai images to
> Debian 11. IOW: 3.0 is not buildable with Debian 11. Should we apply
> 
> 8acdbd718b78 ("lib/boilerplate/iniparser: Allow building with GCC 10.2 
> 2020101")
> 
> to stable/3.0 as well? It applies cleanly.

Done, thanks.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

[xenomai-images][PATCH 1/3] linux-xenomai: Add recipe to build 5.10 dovetail release

[Jan Kiszka via Xenomai]

From: Jan Kiszka 

Provides an option for a stable 5.10 revision, analogously to I-pipe
releases.

Signed-off-by: Jan Kiszka 
---
 recipes-kernel/linux/linux-xenomai_5.10.bb | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 recipes-kernel/linux/linux-xenomai_5.10.bb

diff --git a/recipes-kernel/linux/linux-xenomai_5.10.bb 
b/recipes-kernel/linux/linux-xenomai_5.10.bb
new file mode 100644
index 000..afc129c
--- /dev/null
+++ b/recipes-kernel/linux/linux-xenomai_5.10.bb
@@ -0,0 +1,18 @@
+#
+# Xenomai Real-Time System
+#
+# Copyright (c) Siemens AG, 2021
+#
+# Authors:
+#  Jan Kiszka 
+#
+# SPDX-License-Identifier: MIT
+#
+
+require recipes-kernel/linux/linux-xenomai.inc
+
+SRC_URI += 
"git://source.denx.de/xenomai/linux-dovetail.git;protocol=https;nobranch=1"
+SRCREV = "v5.10.61-dovetail"
+PV = "5.10.61+"
+
+S = "${WORKDIR}/git"
-- 
2.31.1

[xenomai-images][PATCH 0/3] Improve consistency of kernel version selection

[Jan Kiszka via Xenomai]

Will also help adding a kas menu later on (prototype is working already).

Jan

Jan Kiszka (3):
  linux-xenomai: Add recipe to build 5.10 dovetail release
  Rename local_conf_header section for kernel version
  Provide consistent kas files for selecting kernels

 ci/gitlab-ci-base.yml  |  1 -
 ci/kernel_4_19_xenomai_next.yml|  6 ++
 ci/xenomai_3_0_x.yml   |  2 ++
 ci/xenomai_3_1_x.yml   |  6 ++
 opt-linux-4.19.yml |  4 ++--
 opt-linux-4.4.yml  |  4 ++--
 ...linux-latest-5.10.yml => opt-linux-5.10.yml |  5 ++---
 opt-linux-latest-5.10.yml => opt-linux-5.4.yml |  5 ++---
 ...nux-latest.yml => opt-linux-latest-4.19.yml |  0
 ...latest-5.10.yml => opt-linux-latest-4.4.yml |  2 +-
 opt-linux-latest-5.10.yml  |  2 +-
 opt-linux-latest-5.4.yml   |  2 +-
 recipes-kernel/linux/linux-xenomai_5.10.bb | 18 ++
 13 files changed, 43 insertions(+), 14 deletions(-)
 copy opt-linux-latest-5.10.yml => opt-linux-5.10.yml (65%)
 copy opt-linux-latest-5.10.yml => opt-linux-5.4.yml (65%)
 rename opt-linux-latest.yml => opt-linux-latest-4.19.yml (100%)
 copy opt-linux-latest-5.10.yml => opt-linux-latest-4.4.yml (89%)
 create mode 100644 recipes-kernel/linux/linux-xenomai_5.10.bb

-- 
2.31.1

[xenomai-images][PATCH 3/3] Provide consistent kas files for selecting kernels

[Jan Kiszka via Xenomai]

From: Jan Kiszka 

Add the missing 5.4 and 5.10 release files, provide clearly named latest
options for 4.4 and 4.19.

CI needs some refactoring as opt-linux-latest.yml is renamed. Use that
chance to make kernel selection more explicit. That should also help
moving forward.

Signed-off-by: Jan Kiszka 
---
 ci/gitlab-ci-base.yml   |  1 -
 ci/kernel_4_19_xenomai_next.yml |  6 ++
 ci/xenomai_3_0_x.yml|  2 ++
 ci/xenomai_3_1_x.yml|  6 ++
 opt-linux-5.10.yml  | 17 +
 opt-linux-5.4.yml   | 17 +
 ...inux-latest.yml => opt-linux-latest-4.19.yml |  0
 ...linux-latest.yml => opt-linux-latest-4.4.yml |  6 +++---
 8 files changed, 51 insertions(+), 4 deletions(-)
 create mode 100644 opt-linux-5.10.yml
 create mode 100644 opt-linux-5.4.yml
 copy opt-linux-latest.yml => opt-linux-latest-4.19.yml (100%)
 rename opt-linux-latest.yml => opt-linux-latest-4.4.yml (62%)

diff --git a/ci/gitlab-ci-base.yml b/ci/gitlab-ci-base.yml
index ce9c800..13d37b0 100644
--- a/ci/gitlab-ci-base.yml
+++ b/ci/gitlab-ci-base.yml
@@ -19,7 +19,6 @@ variables:
   ftp_proxy: "$FTP_PROXY"
   no_proxy: "$NO_PROXY"
   XENOMAI_BUILD_OPTION: ":opt-xenomai-next.yml"
-  LINUX_BUILD_OPTION: ":opt-linux-latest.yml"
   ISAR_IMAGE: demo-image
   ISAR_DISTRIBUTION: xenomai-demo
   LAVA_TESTS_ENABLED: "true"
diff --git a/ci/kernel_4_19_xenomai_next.yml b/ci/kernel_4_19_xenomai_next.yml
index 765a805..6ae2c35 100644
--- a/ci/kernel_4_19_xenomai_next.yml
+++ b/ci/kernel_4_19_xenomai_next.yml
@@ -12,6 +12,7 @@
 build-4.19:qemu-amd64:
   extends: .build:qemu-amd64
   variables:
+LINUX_BUILD_OPTION: ":opt-linux-latest-4.19.yml"
 DEPLOY_DIR_EXTENSION: "4.19"
 
 lava-test-4.19:qemu-amd64:
@@ -24,6 +25,7 @@ lava-test-4.19:qemu-amd64:
 build-4.19:qemu-armhf:
   extends: .build:qemu-armhf
   variables:
+LINUX_BUILD_OPTION: ":opt-linux-latest-4.19.yml"
 DEPLOY_DIR_EXTENSION: "4.19"
 
 lava-test-4.19:qemu-armhf:
@@ -36,6 +38,7 @@ lava-test-4.19:qemu-armhf:
 build-4.19:qemu-arm64:
   extends: .build:qemu-arm64
   variables:
+LINUX_BUILD_OPTION: ":opt-linux-latest-4.19.yml"
 DEPLOY_DIR_EXTENSION: "4.19"
 
 lava-test-4.19:qemu-arm64:
@@ -48,6 +51,7 @@ lava-test-4.19:qemu-arm64:
 build-4.19:hikey:
   extends: .build:hikey
   variables:
+LINUX_BUILD_OPTION: ":opt-linux-latest-4.19.yml"
 DEPLOY_DIR_EXTENSION: "4.19"
 
 lava-test-4.19:hikey:
@@ -60,6 +64,7 @@ lava-test-4.19:hikey:
 build-4.19:beagle-bone-black:
   extends: .build:beagle-bone-black
   variables:
+LINUX_BUILD_OPTION: ":opt-linux-latest-4.19.yml"
 DEPLOY_DIR_EXTENSION: "4.19"
 
 lava-test-4.19:beagle-bone-black:
@@ -72,6 +77,7 @@ lava-test-4.19:beagle-bone-black:
 build-4.19:x86-64-efi:
   extends: .build:x86-64-efi
   variables:
+LINUX_BUILD_OPTION: ":opt-linux-latest-4.19.yml"
 DEPLOY_DIR_EXTENSION: "4.19"
 
 lava-test-4.19:x86-64-efi:
diff --git a/ci/xenomai_3_0_x.yml b/ci/xenomai_3_0_x.yml
index 9b8c31e..cedd2e0 100644
--- a/ci/xenomai_3_0_x.yml
+++ b/ci/xenomai_3_0_x.yml
@@ -15,6 +15,7 @@ build-4.4:beagle-bone-black:
   extends: .build:beagle-bone-black
   variables:
 XENOMAI_BUILD_OPTION: ":opt-xenomai-3.0.x.yml"
+LINUX_BUILD_OPTION: ":opt-linux-latest-4.4.yml"
 DEPLOY_DIR_EXTENSION: "xenomai-3.0.x"
 
 lava-test-4.4:beagle-bone-black:
@@ -28,6 +29,7 @@ build-4.4:x86-64-efi:
   extends: .build:x86-64-efi
   variables:
 XENOMAI_BUILD_OPTION: ":opt-xenomai-3.0.x.yml"
+LINUX_BUILD_OPTION: ":opt-linux-latest-4.4.yml"
 DEPLOY_DIR_EXTENSION: "xenomai-3.0.x"
 
 lava-test-4.4:x86-64-efi:
diff --git a/ci/xenomai_3_1_x.yml b/ci/xenomai_3_1_x.yml
index 11f3640..1e0961f 100644
--- a/ci/xenomai_3_1_x.yml
+++ b/ci/xenomai_3_1_x.yml
@@ -17,6 +17,7 @@ build-4.19:qemu-amd64:
   variables:
 DEPLOY_DIR_EXTENSION: "xenomai-3.1.x"
 XENOMAI_BUILD_OPTION: ":opt-xenomai-3.1.x.yml"
+LINUX_BUILD_OPTION: ":opt-linux-latest-4.19.yml"
 
 lava-test-4.19:qemu-amd64:
   needs: [ "build-4.19:qemu-amd64" ]
@@ -30,6 +31,7 @@ build-4.19:qemu-armhf:
   variables:
 DEPLOY_DIR_EXTENSION: "xenomai-3.1.x"
 XENOMAI_BUILD_OPTION: ":opt-xenomai-3.1.x.yml"
+LINUX_BUILD_OPTION: ":opt-linux-latest-4.19.yml"
 
 lava-test-4.19:qemu-armhf:
   needs: [ "build-4.19:qemu-armhf" ]
@@ -43,6 +45,7 @@ build-4.19:qemu-arm64:
   variables:
 DEPLOY_DIR_EXTENSION: "xenomai-3.1.x"
 XENOMAI_BUILD_OPTION: ":opt-xenomai-3.1.x.yml"
+LINUX_BUILD_OPTION: ":opt-linux-latest-4.19.yml"
 
 lava-test-4.19:qemu-arm64:
   needs: [ "build-4.19:qemu-arm64" ]
@@ -56,6 +59,7 @@ build-4.19:hikey:
   variables:
 DEPLOY_DIR_EXTENSION: "xenomai-3.1.x"
 XENOMAI_BUILD_OPTION: ":opt-xenomai-3.1.x.yml"
+LINUX_BUILD_OPTION: ":opt-linux-latest-4.19.yml"
 
 lava-test-4.19:hikey:
   needs: [ "build-4.19:hikey" ]
@@ -69,6 +73,7 @@ build-4.19:beagle-bone-black:
   variables:
 DEPLOY_DIR_EX

[xenomai-images][PATCH 2/3] Rename local_conf_header section for kernel version

[Jan Kiszka via Xenomai]

From: Jan Kiszka 

Use a more intuitive name. No functional changes.

Signed-off-by: Jan Kiszka 
---
 opt-linux-4.19.yml| 4 ++--
 opt-linux-4.4.yml | 4 ++--
 opt-linux-latest-5.10.yml | 2 +-
 opt-linux-latest-5.4.yml  | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/opt-linux-4.19.yml b/opt-linux-4.19.yml
index fb3657f..d5fa5ef 100644
--- a/opt-linux-4.19.yml
+++ b/opt-linux-4.19.yml
@@ -1,7 +1,7 @@
 #
 # Xenomai Real-Time System
 #
-# Copyright (c) Siemens AG, 2020
+# Copyright (c) Siemens AG, 2020-2021
 #
 # Authors:
 #  Quirin Gylstorff 
@@ -13,5 +13,5 @@ header:
   version: 10
 
 local_conf_header:
-  linux-xenomai-latest: |
+  linux-xenomai-version: |
 PREFERRED_VERSION_linux-xenomai = "4.19%"
diff --git a/opt-linux-4.4.yml b/opt-linux-4.4.yml
index c4afa68..2b9dd14 100644
--- a/opt-linux-4.4.yml
+++ b/opt-linux-4.4.yml
@@ -1,7 +1,7 @@
 #
 # Xenomai Real-Time System
 #
-# Copyright (c) Siemens AG, 2020
+# Copyright (c) Siemens AG, 2020-2021
 #
 # Authors:
 #  Quirin Gylstorff 
@@ -13,5 +13,5 @@ header:
   version: 10
 
 local_conf_header:
-  linux-xenomai-latest: |
+  linux-xenomai-version: |
 PREFERRED_VERSION_linux-xenomai = "4.4%"
diff --git a/opt-linux-latest-5.10.yml b/opt-linux-latest-5.10.yml
index 89530b8..a6bb221 100644
--- a/opt-linux-latest-5.10.yml
+++ b/opt-linux-latest-5.10.yml
@@ -13,6 +13,6 @@ header:
   version: 10
 
 local_conf_header:
-  linux-xenomai-latest: |
+  linux-xenomai-version: |
 PREFERRED_VERSION_linux-xenomai = "-%"
 LATEST_GIT_BRANCH = "5.10"
diff --git a/opt-linux-latest-5.4.yml b/opt-linux-latest-5.4.yml
index 7767be4..d3164e3 100644
--- a/opt-linux-latest-5.4.yml
+++ b/opt-linux-latest-5.4.yml
@@ -13,6 +13,6 @@ header:
   version: 10
 
 local_conf_header:
-  linux-xenomai-latest: |
+  linux-xenomai-version: |
 PREFERRED_VERSION_linux-xenomai = "-%"
 LATEST_GIT_BRANCH = "5.4"
-- 
2.31.1

Re: (rt_)printf and virtual memory

[Jan Kiszka via Xenomai]

On 07.09.21 11:21, Mauro S. via Xenomai wrote:
> Hi all,
> 
> consider the simple code attached.
> 
> I'm using Xenomai 3.1 on a x86_64 CPU, 2GB RAM.
> 
> I compile and link the code using "xeno-config --skin=alchemy --cflags"
> and "xeno-config --skin=alchemy --ldflags"
> 
> * Scenario 1)
>   #define printf rt_printf commented out (use printf for prints)
> 
>   Changing the NUM_TASKS value, in top command I see these results:
> 
>   - NUM_TASKS 2
> 
>     PID  PPID USER STAT   VSZ %VSZ %CPU COMMAND
>     496   480 root S    80068   4%   0% ./test
> 
>   - NUM_TASKS 4
> 
>     PID  PPID USER STAT   VSZ %VSZ %CPU COMMAND
>     496   480 root S    80204   4%   0% ./test
> 
>   - NUM_TASKS 5
> 
>     PID  PPID USER STAT   VSZ %VSZ %CPU COMMAND
>     496   480 root S    80272   4%   0% ./test
> 
>   - NUM_TASKS 6
> 
>     PID  PPID USER STAT   VSZ %VSZ %CPU COMMAND
>     496   480 root S    80340   4%   0% ./test
> 
> Virtual memory size increases in a linear way.
> 
> 
> * Scenario 2)
>   #define printf rt_printf not commented (use rt_printf for prints)
> 
>   Changing the NUM_TASKS value, in top command I see these results:
> 
>   - NUM_TASKS 2
> 
>     PID  PPID USER STAT   VSZ %VSZ %CPU COMMAND
>     496   480 root S    80068   4%   0% ./test
> 
>   - NUM_TASKS 4
> 
>     PID  PPID USER STAT   VSZ %VSZ %CPU COMMAND
>     496   480 root S    80204   4%   0% ./test
> 
>   - NUM_TASKS 5
> 
>     PID  PPID USER STAT   VSZ %VSZ %CPU COMMAND
>     496   480 root S 142M   4%   0% ./test
> 
>   - NUM_TASKS 6
> 
>     PID  PPID USER STAT   VSZ %VSZ %CPU COMMAND
>     496   480 root S 206M   4%   0% ./test
> 
> 
> Starting from a number of tasks > 4, the VMEM got a jump and then
> increases very rapidly.
> 
> Is it normal? Or I'm misusing the rt_printf?

No, that's related to glibc's internal memory allocation strategy. I
didn't dig into details, but you can easily trigger enormous virtual
memory reservations (which are not real memory, as we know) by adding a
pre-thread malloc(1) to your program - without using rt_printf.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: 回复： An error occures when installing Xenomai libraries and tools

[Jan Kiszka via Xenomai]

On 10.09.21 03:08, rany97 wrote:
> Sorry for not replying properly.
> I got Xenomai
> from?0?2https://xenomai.org/downloads/xenomai/stable/xenomai-3.1.tar.bz2.
> 
> The problem have been solved by using xenomai-stable-3.1.x got
> from?0?2https://source.denx.de/Xenomai/xenomai/-/tree/stable/v3.1.x
> 
> But new errors happened, they seems similar:
> -
> /home/rany/build_rtos/xenomai/src/xenomai-stable-v3.1.x/lib/copperplate/heapobj-pshared.c:
> In function ??heapobj_pkg_init_shared??:
> /home/rany/build_rtos/xenomai/src/xenomai-stable-v3.1.x/lib/copperplate/heapobj-pshared.c:859:11:
> error: ??%s?? directive output may be truncated writing up to 287 bytes
> into a region of size 250 [-Werror=format-truncation=]
> ?0?2 859 |?0?2 ?0?2 "/xeno:%s", hobj->name);
> ?0?2 ?0?2 ?0?2 |?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ?0?2^~
> ..
> ..
> /home/rany/build_rtos/xenomai/src/xenomai-stable-v3.1.x/lib/copperplate/heapobj-pshared.c:
> In function ??heapobj_bind_session??:
> /home/rany/build_rtos/xenomai/src/xenomai-stable-v3.1.x/lib/copperplate/heapobj-pshared.c:987:11:
> error: ??%s?? directive output may be truncated writing up to 287 bytes
> into a region of size 250 [-Werror=format-truncation=]
> ?0?2 987 |?0?2 ?0?2 "/xeno:%s", hobj->name);
> ?0?2 ?0?2 ?0?2 |?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ?0?2^~
> 
> 

Good point , Florian should have seen that as well already:
We need to merge
https://source.denx.de/Xenomai/xenomai/-/commit/6fff5236239a752ea0328e6bfee1b
into stable 3.1 as well. Will do,

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

[PATCH stable/v3.1.x] ci: Drop 4.14 from target list

[Jan Kiszka via Xenomai]

From: Jan Kiszka 

This kernel is no longer maintained and will not survive the switch to
gcc-10.

Signed-off-by: Jan Kiszka 
---
 .gitlab-ci.yml | 8 
 1 file changed, 8 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 6b77c4ee64..7b99547cdc 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -233,14 +233,6 @@ x86-4.19-cip-release:
 IPIPE_KERNEL: ${IPIPE_MIRROR_URL}/ipipe-x86.git
 KERNEL_DEFCONFIG: x86_64_defconfig
 
-x86-4.14-release:
-  extends: .build
-  variables:
-ARCH: x86
-IPIPE_REV: ipipe-core-4.14..*-x86-.*
-IPIPE_KERNEL: ${IPIPE_MIRROR_URL}/ipipe-x86.git
-KERNEL_DEFCONFIG: x86_64_defconfig
-
 x86-4.4-cip-head:
   extends: .build
   variables:
-- 
2.31.1

Re: setup RTnet

[Jan Kiszka via Xenomai]

On 11.09.21 19:46, Marco Barletta via Xenomai wrote:
> Hi everyone;
> I was trying to setup RTnet but I found some problems. After removing
> non-rt e1000e module and loading rt one, when I run rtnet start I got the
> same output as
> https://www.mail-archive.com/xenomai@xenomai.org/msg18342.html. I know this
> is a known issue since the rt_e1000e doesn't work very well with i219-V
> Intel ethernet controller, and I checked out patches in
> https://www.mail-archive.com/xenomai@xenomai.org/msg16000.html. Anyway I
> experienced some compile time issues with Xenomai 3.1, Linux 5.4.77. Do you
> have an updated version tested toward this kernel version? On gitlab I see
> the driver still doesn't support the controller.
> Thank you very much for the effort.
> 

Nothing recent is known to me.

As we know build up to 5.10, someone would have to set down again and
refresh / rebase the update. Best would be to split it into a vanilla
import of a specific mainline version + a patch on top that does the
needed adjustments. This time, I'll promise to look at things quicker.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: Mercury 32bit VxWorks skin

[Jan Kiszka via Xenomai]

On 13.09.21 15:21, Enrico Buffoli via Xenomai wrote:
> Hello,
> 
> I've a question regarding the execution of the Mercury 32bit VxWorks skin
> on an 64 bit patch rt Linux 4.14.78-rt47 on aarch64.
> Is this setup possible? or there are some known issues/limits?
> 

We have no recent feedback on the usage of Mercury. Right now, no one is
working on its QA. Conceptually, this may work, but we can't tell
upfront if there will be issues.

In addition, all porting of VxWorks apps always involve the untangling
of drivers from the application code. Only the latter is covered by the
skin, the former often requires architectural porting to Linux.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

[PATCH] cobalt/posix/io: Privatize some select helpers

[Jan Kiszka via Xenomai]

From: Jan Kiszka 

This was missed in c4c2fc21a32d.

Signed-off-by: Jan Kiszka 
---
 kernel/cobalt/posix/io.c | 6 +++---
 kernel/cobalt/posix/io.h | 5 -
 2 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/kernel/cobalt/posix/io.c b/kernel/cobalt/posix/io.c
index 0c17f55bf3..be8a2d3f0f 100644
--- a/kernel/cobalt/posix/io.c
+++ b/kernel/cobalt/posix/io.c
@@ -167,7 +167,7 @@ COBALT_SYSCALL(mmap, lostage,
return cobalt_copy_to_user(u_addrp, &u_addr, sizeof(u_addr));
 }
 
-int __cobalt_first_fd_valid_p(fd_set *fds[XNSELECT_MAX_TYPES], int nfds)
+static int __cobalt_first_fd_valid_p(fd_set *fds[XNSELECT_MAX_TYPES], int nfds)
 {
int i, fd;
 
@@ -181,8 +181,8 @@ int __cobalt_first_fd_valid_p(fd_set 
*fds[XNSELECT_MAX_TYPES], int nfds)
return 1;
 }
 
-int __cobalt_select_bind_all(struct xnselector *selector,
-fd_set *fds[XNSELECT_MAX_TYPES], int nfds)
+static int __cobalt_select_bind_all(struct xnselector *selector,
+   fd_set *fds[XNSELECT_MAX_TYPES], int nfds)
 {
bool first_fd = true;
unsigned fd, type;
diff --git a/kernel/cobalt/posix/io.h b/kernel/cobalt/posix/io.h
index d9f29fa595..c02595b4f3 100644
--- a/kernel/cobalt/posix/io.h
+++ b/kernel/cobalt/posix/io.h
@@ -23,11 +23,6 @@
 #include 
 #include 
 
-int __cobalt_first_fd_valid_p(fd_set *fds[XNSELECT_MAX_TYPES], int nfds);
-
-int __cobalt_select_bind_all(struct xnselector *selector,
-fd_set *fds[XNSELECT_MAX_TYPES], int nfds);
-
 int __cobalt_select(int nfds, void __user *u_rfds, void __user *u_wfds,
void __user *u_xfds, void __user *u_tv, bool compat);
 
-- 
2.31.1

[PATCH] ci: Drop resource_group from qemu targets

[Jan Kiszka via Xenomai]

From: Jan Kiszka 

We now have 4 available, so the risk having to wait for a free one is
significantly reduced.

Signed-off-by: Jan Kiszka 
---

Thanks for making this possible, Hongzhan!

 ci/gitlab-ci-base.yml | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/ci/gitlab-ci-base.yml b/ci/gitlab-ci-base.yml
index 13d37b0..8a1dbfb 100644
--- a/ci/gitlab-ci-base.yml
+++ b/ci/gitlab-ci-base.yml
@@ -68,7 +68,6 @@ default:
 
 .lava-test:qemu-amd64:
   extends: .test
-  resource_group: board-qemu
   variables:
 TARGET: qemu-amd64
 
@@ -80,7 +79,6 @@ default:
 
 .lava-test:qemu-armhf:
   extends: .test
-  resource_group: board-qemu
   variables:
 TARGET: qemu-armhf
 
@@ -92,7 +90,6 @@ default:
 
 .lava-test:qemu-arm64:
   extends: .test
-  resource_group: board-qemu
   variables:
 TARGET: qemu-arm64
 
-- 
2.31.1