RE: smokey's fork tests hangs?

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Freitag, 8. März 2019 16:23
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Subject: Re: smokey's fork tests hangs?
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 08.03.19 15:05, Lange Norbert wrote:
> >
> >
> >> -Original Message-
> >> From: Jan Kiszka 
> >> Sent: Freitag, 8. März 2019 14:59
> >> To: Lange Norbert ; Xenomai
> >> (xenomai@xenomai.org) 
> >> Subject: Re: smokey's fork tests hangs?
> >>
> >> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE,
> PLEASE
> >> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
> >>
> >>
> >> On 08.03.19 14:47, Lange Norbert wrote:
> >>>
> >>>>
> >>>> Not reproducible here with stable/3.0.x or next, and with
> >>>> ipipe-x86-
> >> 4.14.y.
> >>>> What are your parameters?
> >>>
> >>> Not entirely upstream, but based on ipipe-core-4.14.89-x86-2 and
> >>> xenomai master, the difference is contained in the rt_igb driver,
> >>> which is
> >> not even loaded.
> >>> Defconfig is attached.
> >>>
> >>> I mostly suspect glibc as the relevant difference, I am using
> >>> glibc-2.28-69-g1e5c5303a522764d7e9d2302a60e4a32cdb902f1.
> >>>
> >>> Looking at the strace the child process 1039 is stuck at
> >>> FUTEX_WAIT_PRIVATE, Don’t really know how to tackle this.
> >>
> >> Is this a regression? Then try bisecting the causing commit.
> >
> > Not really, I haven't ran the smokey suite often (and only for specific 
> > tests).
> > I use buildroot for my rootfs, so I have no easy way of swapping around
> glibc versions.
> > I have not encountered other issues outside of those tests.
> >
> > Which version of glibc is running on your end?
> >
>
> Mine is in fact old: 2.19. Colleagues are on Debian 9 with 2.24 where this 
> used
> to work but was not tested recently against master.
>
> I haven't tried buildroot with Xenomai yet - is there a working 3.x recipe, 
> and
> everything is out-of-the-box?

Yes, and thats both a blessing(easy to start with) and a curse(by defaults 
builds everything inc. toolchain, packages mostly available in 1 version).
It has a configuration system similar to the Kernel, getting to a xenomai 
userspace would take the following steps:

make O=/tmp/c defconfig
make O=/tmp/c menuconfig
make O=/tmp/c

You would have to change in menuconfig:
Target options: x86_64
Toolchain -> C library: glibc
Target packages -> Real-Time: xenomai (set cobalt + test utils, set version to 
3.0.8)

(or you drop the attached file into configs/xenomai_defconfig and run 'make 
O=/tmp/c xenomai_defconfig')

And you would need to remove the patch in package/xenomai as it won't apply 
with 3.0.8.

> Regarding how to possibly debug this: If one thread is stuck, you could check
> if there are other threads in that application that may hold the lock. Or if 
> the
> lock content is actually invalid and therefore blocking the caller (memoryC
> corruption). You should be able to read out the thread ID of the owner from
> a valid lock structure.

I don’t know what the fork+exec sequence should do. I only know libc waits 
forever for a private futex,
potentially synchronizing with a thread that has not been created yet.
As said, I haven’t encountered any other issues and I am not able to sink a lot 
time into something
that’s not a problem right now. I would still like to narrow down the cause.

Norbert


This message and any attachments are solely for the use of the intended 
recipients. They may contain privileged and/or confidential information or 
other information protected from disclosure. If you are not an intended 
recipient, you are hereby notified that you received this email in error and 
that any review, dissemination, distribution or copying of this email and any 
attachment is strictly prohibited. If you have received this email in error, 
please contact the sender and delete the message and any attachment from your 
system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

-- next part --
A non-text attachment was scrubbed...
Name: xenomai_defconfig
Type: application/octet-stream
Size: 242 bytes
Desc: xenomai_defconfig
URL: 
<http://xenomai.org/pipermail/xenomai/attachments/20190311/22a1cbff/attachment.obj>

RE: smokey's fork tests hangs with glibc 2.28+ ?

[Lange Norbert via Xenomai]

Well, swapping out glibc with 2.27 removes the issue, so it has been introduced 
afterwards,
the current buildroot will use 2.28 so you should be able to build yourself a 
reproducer that way.
I will also attach a prebuilt rootfs once the clean rebuild is done.

Unfortunately the smokey suite is not available with the Mercury core, might be 
easier to isolate that way.

In the future, maybe some battletested glibc versions could be recommended for 
xenomai?

> -Original Message-
> From: Jan Kiszka 
> Sent: Freitag, 8. März 2019 16:23
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Subject: Re: smokey's fork tests hangs?
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 08.03.19 15:05, Lange Norbert wrote:
> >
> >
> >> -Original Message-
> >> From: Jan Kiszka 
> >> Sent: Freitag, 8. März 2019 14:59
> >> To: Lange Norbert ; Xenomai
> >> (xenomai@xenomai.org) 
> >> Subject: Re: smokey's fork tests hangs?
> >>
> >> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE,
> PLEASE
> >> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
> >>
> >>
> >> On 08.03.19 14:47, Lange Norbert wrote:
> >>>
> 
>  Not reproducible here with stable/3.0.x or next, and with
>  ipipe-x86-
> >> 4.14.y.
>  What are your parameters?
> >>>
> >>> Not entirely upstream, but based on ipipe-core-4.14.89-x86-2 and
> >>> xenomai master, the difference is contained in the rt_igb driver,
> >>> which is
> >> not even loaded.
> >>> Defconfig is attached.
> >>>
> >>> I mostly suspect glibc as the relevant difference, I am using
> >>> glibc-2.28-69-g1e5c5303a522764d7e9d2302a60e4a32cdb902f1.
> >>>
> >>> Looking at the strace the child process 1039 is stuck at
> >>> FUTEX_WAIT_PRIVATE, Don’t really know how to tackle this.
> >>
> >> Is this a regression? Then try bisecting the causing commit.
> >
> > Not really, I haven't ran the smokey suite often (and only for specific 
> > tests).
> > I use buildroot for my rootfs, so I have no easy way of swapping around
> glibc versions.
> > I have not encountered other issues outside of those tests.
> >
> > Which version of glibc is running on your end?
> >
>
> Mine is in fact old: 2.19. Colleagues are on Debian 9 with 2.24 where this 
> used
> to work but was not tested recently against master.
>
> I haven't tried buildroot with Xenomai yet - is there a working 3.x recipe, 
> and
> everything is out-of-the-box?
>
> Regarding how to possibly debug this: If one thread is stuck, you could check
> if there are other threads in that application that may hold the lock. Or if 
> the
> lock content is actually invalid and therefore blocking the caller (memory
> corruption). You should be able to read out the thread ID of the owner from
> a valid lock structure.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate
> Competence Center Embedded Linux


This message and any attachments are solely for the use of the intended 
recipients. They may contain privileged and/or confidential information or 
other information protected from disclosure. If you are not an intended 
recipient, you are hereby notified that you received this email in error and 
that any review, dissemination, distribution or copying of this email and any 
attachment is strictly prohibited. If you have received this email in error, 
please contact the sender and delete the message and any attachment from your 
system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

Re: smokey's fork tests hangs with glibc 2.28+ ?

[Jan Kiszka via Xenomai]

On 11.03.19 14:40, Lange Norbert wrote:

Well, swapping out glibc with 2.27 removes the issue, so it has been introduced 
afterwards,
the current buildroot will use 2.28 so you should be able to build yourself a 
reproducer that way.
I will also attach a prebuilt rootfs once the clean rebuild is done.


Ok, thanks for narrowing that further down.

I just realized that buster (Debian 10) will use 2.28 as well. Will try that 
baseline as well.




Unfortunately the smokey suite is not available with the Mercury core, might be 
easier to isolate that way.

In the future, maybe some battletested glibc versions could be recommended for 
xenomai?


Maintained distributions are generally a good choice. My plan is to define and 
test reference images via https://gitlab.denx.de/Xenomai/xenomai-images, but we 
are not there yet.


Jan

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

RE: smokey's fork tests hangs with glibc 2.28+ ?

[Lange Norbert via Xenomai]

Thats a rootfs which reproduces the issue. Identical setup, but glibc 2.27 will 
not reproduce.

> -Original Message-
> From: Jan Kiszka 
> Sent: Montag, 11. März 2019 14:50
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Subject: Re: smokey's fork tests hangs with glibc 2.28+ ?
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 11.03.19 14:40, Lange Norbert wrote:
> > Well, swapping out glibc with 2.27 removes the issue, so it has been
> > introduced afterwards, the current buildroot will use 2.28 so you should be
> able to build yourself a reproducer that way.
> > I will also attach a prebuilt rootfs once the clean rebuild is done.
>
> Ok, thanks for narrowing that further down.
>
> I just realized that buster (Debian 10) will use 2.28 as well. Will try that
> baseline as well.
>
> >
> > Unfortunately the smokey suite is not available with the Mercury core,
> might be easier to isolate that way.
> >
> > In the future, maybe some battletested glibc versions could be
> recommended for xenomai?
>
> Maintained distributions are generally a good choice. My plan is to define and
> test reference images via https://gitlab.denx.de/Xenomai/xenomai-images,
> but we are not there yet.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate
> Competence Center Embedded Linux


This message and any attachments are solely for the use of the intended 
recipients. They may contain privileged and/or confidential information or 
other information protected from disclosure. If you are not an intended 
recipient, you are hereby notified that you received this email in error and 
that any review, dissemination, distribution or copying of this email and any 
attachment is strictly prohibited. If you have received this email in error, 
please contact the sender and delete the message and any attachment from your 
system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

-- next part --
A non-text attachment was scrubbed...
Name: rootfs.tar.xz
Type: application/octet-stream
Size: 1893344 bytes
Desc: rootfs.tar.xz
URL: 
<http://xenomai.org/pipermail/xenomai/attachments/20190311/aec534ed/attachment.obj>

Re: smokey's fork tests hangs with glibc 2.28+ ?

[Philippe Gerum via Xenomai]

On 3/11/19 3:08 PM, Lange Norbert via Xenomai wrote:
> Thats a rootfs which reproduces the issue. Identical setup, but glibc 2.27 
> will not reproduce.

The issue was introduced by [1], which already triggered a bug in the
glibc test suite [2]. In short, calling pthread_atfork() like
__cobalt_init() does over the context of a fork handler is now invalid,
because the glibc now holds the internal atfork_lock while running the
fork handlers. The cobalt fork handler needs to be registered earlier,
outside of such context.

This change was introduced between glibc-2.27.9000 and glibc-2.28.

[1] git://sourceware.org/git/glibc.git, 27761a104
[2] git://sourceware.org/git/glibc.git, 669ff911e

-- 
Philippe.

Re: kvm fpu warning on 4.14.89

[cagnulein via Xenomai]

Hi Jan, did you get any chance to look at my issue?
Thanks

Il ven 1 mar 2019, 15:58 Jan Kiszka  ha scritto:

> On 01.03.19 15:21, cagnulein wrote:
> > Hi, with the last git the warning disappear, thanks.
> > Now I would like to submit a new issue : with the last git and with the
> 4.14.89
> > also, if I run latency-test without the kvm guest on, everything works
> fine.
> > If I run latency-test with the kvm guest on the system hangs! The entire
> system
> > not only the guest.
> > This doesn't happen with the 4.9.146.
> > Any hints to debug it?
>
> Hmm, this will be more complicated in fact. I need to try reproducing that
> in
> KVM (nested setup) because that allows insights to be obtained more easily.
>
> Jan
>
> > Thanks in advance
> >
> > Il ven 1 mar 2019, 11:30 cagnulein  > > ha scritto:
> >
> > Yes qemu on a xenomai kernel (host device). My guest is a windows 10
> 2019.
> >
> > I'm already compiling the last git. I will let you know.
> > Thanks
> >
> > Il ven 1 mar 2019, 11:24 Jan Kiszka  > > ha scritto:
> >
> > On 01.03.19 10:35, cagnulein via Xenomai wrote:
> >  > I’m testing the 4.14.89 ipipe (i was usually using 4.9.146)
> and i’ve
> > got a
> >  > deterministic warning every time i start qemu. Is it already
> known?
> >  >
> >
> > Thanks for reporting. I suppose this wasn't tested in a while.
> >
> > Just to be sure: You are starting QEMU/KVM *on* a Xenomai
> kernel, and *not*
> > Xenomai as KVM guest, right?
> >
> > Could you also give latest
> https://gitlab.denx.de/Xenomai/ipipe-x86/ a
> > try, if
> > something happened to have changed?
> >
> > I will try to reproduce ASAP.
> >
> > Jan
> >
> >  > Thanks
> >  >
> >  > R.
> >  >
> >  >
> >  >
> >  > Mar  1 01:14:05 debiankvm kernel: [   96.078798] WARNING:
> CPU: 0 PID:
> > 1154
> >  > at ./arch/x86/include/asm/fpu/internal.h:617
> __kernel_fpu_end+0x8b/0xa0
> >  >
> >  > Mar  1 01:14:05 debiankvm kernel: [   96.078802] Modules
> linked in:
> >  > hid_generic usbhid hid xt_CHECKSUM iptable_mangle
> ipt_MASQUERADE
> >  > nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat
> nf_conntrack_ipv4
> >  > nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT
> nf_reject_ipv4
> >  > xt_tcpudp tun ebtable_filter ebtables ip6table_filter
> ip6_tables
> >  > iptable_filter bridge stp llc intel_rapl x86_pkg_temp_thermal
> coretemp
> >  > kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul
> ghash_clmulni_intel
> >  > pcbc i2c_designware_platform i2c_designware_core nls_ascii
> nls_cp437 vfat
> >  > fat aesni_intel aes_x86_64 crypto_simd glue_helper cryptd
> intel_cstate
> >  > intel_rapl_perf pcspkr i915 prime_numbers lpc_ich
> drm_kms_helper drm
> > idma64
> >  > fb_sys_fops mei_me syscopyarea intel_lpss_pci sysfillrect
> intel_lpss
> >  > sysimgblt mfd_core mei shpchp sg evdev video ip_tables
> x_tables autofs4
> >  >
> >  > Mar  1 01:14:05 debiankvm kernel: [   96.078913]  ext4 crc16
> mbcache jbd2
> >  > fscrypto btrfs zstd_decompress zstd_compress xxhash raid10
> raid456
> >  > async_raid6_recov async_memcpy async_pq async_xor async_tx
> xor raid6_pq
> >  > libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod
> sd_mod
> >  > mmc_block igb i2c_algo_bit dca ahci sdhci_pci sdhci xhci_pci
> libahci ptp
> >  > crc32c_intel i2c_i801 xhci_hcd mmc_core pps_core libata
> usbcore scsi_mod
> >  >
> >  > Mar  1 01:14:05 debiankvm kernel: [   96.078982] CPU: 0 PID:
> 1154 Comm:
> >  > qemu-system-x86 Not tainted 4.14.89 #1
> >  >
> >  > Mar  1 01:14:05 debiankvm kernel: [   96.078985] I-pipe
> domain: Linux
> >  >
> >  > Mar  1 01:14:05 debiankvm kernel: [   96.078988] task:
> 94aff6f49c80
> >  > task.stack: b5be80a58000
> >  >
> >  > Mar  1 01:14:05 debiankvm kernel: [   96.078991] RIP:
> >  > 0010:__kernel_fpu_end+0x8b/0xa0
> >  >
> >  > Mar  1 01:14:05 debiankvm kernel: [   96.078994] RSP:
> > 0018:b5be80a5bcf8
> >  > EFLAGS: 00010246
> >  >
> >  > Mar  1 01:14:05 debiankvm kernel: [   96.078999] RAX:
> > ff00 RBX:
> >  > 94aff6e88000 RCX: 94aff6f49c80
> >  >
> >  > Mar  1 01:14:05 debiankvm kernel: [   96.079002] RDX:
> >  RSI:
> >  > 0246 RDI: 94aff6f4a800
> >  >
> >  > Mar  1 01:14:05 debiankvm kernel: [   96.079005] RBP:
> > b5be80a5bdd0 R08:
> >  > c0c1c060 R09: 94aff6f8f000
> >  >
> >  > Mar  1 01:14:05 debiankvm kernel: [

[PATCH] kernel: cobalt: replace access_ok with corresponding wrappers

[roman.stratiienko--- via Xenomai]

From: Roman Stratiienko 

Use access_wok / access_rok wrappers to enable support for kernel v5.0

Signed-off-by: Roman Stratiienko 
---

This patch is also required to support v5.0

 kernel/cobalt/pipe.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/cobalt/pipe.c b/kernel/cobalt/pipe.c
index 0b8f8cbf8..16e85125c 100644
--- a/kernel/cobalt/pipe.c
+++ b/kernel/cobalt/pipe.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -795,7 +796,7 @@ static ssize_t xnpipe_read(struct file *file,
ssize_t ret;
spl_t s;
 
-   if (!access_ok(VERIFY_WRITE, buf, count))
+   if (!access_wok(buf, count))
return -EFAULT;
 
xnlock_get_irqsave(&nklock, s);
@@ -903,7 +904,7 @@ static ssize_t xnpipe_write(struct file *file,
if (count == 0)
return 0;
 
-   if (!access_ok(VERIFY_READ, buf, count))
+   if (!access_rok(buf, count))
return -EFAULT;
 
xnlock_get_irqsave(&nklock, s);
-- 
2.17.1

[PATCH v3] travis: add basic CI support

[roman.stratiienko--- via Xenomai]

From: Roman Stratiienko 

Signed-off-by: Roman Stratiienko 
---

Changes since v2

Removed redundand "CONFIG_" prefix
Added building of the drivers

Currently CAN bus driver build fails on v4.20 and v5.0,
(https://travis-ci.org/devel-opi/xenomai-fork/builds/504429157)

Please suggest which configs should be also enabled in
CI to cover as much as possible code lines

 .travis.yml | 99 +
 1 file changed, 99 insertions(+)
 create mode 100644 .travis.yml

diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 0..8d3eba2c3
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,99 @@
+language: c
+dist: xenial
+
+addons:
+  apt:
+packages:
+  - gcc-aarch64-linux-gnu
+  - gcc-arm-linux-gnueabihf
+  - patch
+  - quilt
+  - wget
+
+env:
+  global:
+- KDIR=/tmp/kernel
+
+install:
+  - if [[ "${KERNEL_VERSION}" == *-rc* ]]; then
+  
KERNEL_URL=https://git.kernel.org/torvalds/t/linux-${KERNEL_VERSION}.tar.gz;
+else
+  
KERNEL_URL=https://www.kernel.org/pub/linux/kernel/v${KERNEL_VERSION::1}.x/linux-${KERNEL_VERSION}.tar.xz;
+fi
+  - wget -O kernel.tar.xz ${KERNEL_URL} && mkdir ${KDIR} && tar -C ${KDIR} 
--strip=1 -xf kernel.tar.xz
+  - wget -O /tmp/ipipe.patch ${IPIPE_URL}
+
+before_script:
+  - case "${ARCH}" in
+  "arm64") export CROSS_COMPILE=aarch64-linux-gnu-
+  ;;
+  "arm"  ) export CROSS_COMPILE=arm-linux-gnueabihf-
+  ;;
+  "x86"  ) export CROSS_COMPILE=
+  ;;
+esac
+  - pushd ${KDIR}
+  - make -j $(nproc) ${KERNEL_DEFCONFIG}
+  - ./scripts/config -e IPIPE
+  - ./scripts/config -e XENOMAI
+  - ./scripts/config -e XENO_DRIVERS_ANALOGY
+  - ./scripts/config -e XENO_DRIVERS_ANALOGY_DEBUG
+  - ./scripts/config -e XENO_DRIVERS_ANALOGY_DEBUG_FTRACE
+  - ./scripts/config -e XENO_DRIVERS_ANALOGY_8255
+  - ./scripts/config -e XENO_DRIVERS_ANALOGY_PARPORT
+  - ./scripts/config -e XENO_DRIVERS_ANALOGY_NI_MITE
+  - ./scripts/config -e XENO_DRIVERS_ANALOGY_NI_TIO
+  - ./scripts/config -e XENO_DRIVERS_ANALOGY_NI_MIO
+  - ./scripts/config -e XENO_DRIVERS_ANALOGY_NI_PCIMIO
+  - ./scripts/config -e XENO_DRIVERS_ANALOGY_NI_670x
+  - ./scripts/config -e XENO_DRIVERS_ANALOGY_NI_660x
+  - ./scripts/config -e XENO_DRIVERS_ANALOGY_S526
+  - ./scripts/config -e XENO_DRIVERS_ANALOGY_FAKE
+  - ./scripts/config -e XENO_DRIVERS_AUTOTUNE
+  - ./scripts/config -e XENO_DRIVERS_CAN
+  - ./scripts/config -e XENO_DRIVERS_CAN_DEBUG
+  - ./scripts/config -e XENO_DRIVERS_CAN_LOOPBACK
+  - ./scripts/config -e XENO_DRIVERS_CAN_BUS_ERR
+  - ./scripts/config -e XENO_DRIVERS_CAN_VIRT
+  - ./scripts/config -e XENO_DRIVERS_CAN_FLEXCAN
+  - ./scripts/config -e XENO_DRIVERS_GPIO
+  - ./scripts/config -e XENO_DRIVERS_GPIO_SUN8I_H3
+  - ./scripts/config -e XENO_DRIVERS_GPIO_DEBUG
+  - ./scripts/config -e XENO_DRIVERS_GPIOPWM
+  - ./scripts/config -e XENO_DRIVERS_RTIPC
+  - ./scripts/config -e XENO_DRIVERS_NET
+  - ./scripts/config -e XENO_DRIVERS_16550A
+  - ./scripts/config -e XENO_DRIVERS_SPI
+  - ./scripts/config -e XENO_DRIVERS_TIMERBENCH
+  - ./scripts/config -e XENO_DRIVERS_UDD
+
+  - popd
+
+script:
+  - ./scripts/prepare-kernel.sh --ipipe=/tmp/ipipe.patch --arch=${ARCH} 
--linux=${KDIR}
+  - cd ${KDIR}
+  - make -j $(nproc) olddefconfig
+  - make -j $(nproc) all
+
+matrix:
+  include:
+- env:
+  - ARCH: arm
+KERNEL_VERSION: 4.14.85
+KERNEL_DEFCONFIG: multi_v7_defconfig
+IPIPE_URL: 
https://xenomai.org/downloads/ipipe/v4.x/arm/ipipe-core-4.14.85-arm-6.patch
+- env:
+  - ARCH: arm
+KERNEL_VERSION: 4.1.18
+KERNEL_DEFCONFIG: multi_v7_defconfig
+IPIPE_URL: 
https://xenomai.org/downloads/ipipe/v4.x/arm/older/ipipe-core-4.1.18-arm-9.patch
+- env:
+  - ARCH: x86
+KERNEL_VERSION: 4.14.89
+KERNEL_DEFCONFIG: x86_64_defconfig
+IPIPE_URL: 
https://xenomai.org/downloads/ipipe/v4.x/x86/ipipe-core-4.14.89-x86-2.patch
+- env:
+  - ARCH: x86
+KERNEL_VERSION: 4.4.166
+KERNEL_DEFCONFIG: i386_defconfig
+IPIPE_URL: 
https://xenomai.org/downloads/ipipe/v4.x/x86/ipipe-core-4.4.166-x86-12.patch
-- 
2.17.1

RE: smokey's fork tests hangs with glibc 2.28+ ?

[Lange Norbert via Xenomai]

Thanks Phillipe,

assume just for a moment that I know little of the issues,
is there any harm using glibc 2.28 for now, given that I don’t
run into those deadlocks or could there be some more
subtile breakage involved?

Norbert

> -Original Message-
> From: Philippe Gerum 
> Sent: Montag, 11. März 2019 15:19
> To: Lange Norbert ; Jan Kiszka
> ; Xenomai (xenomai@xenomai.org)
> 
> Subject: Re: smokey's fork tests hangs with glibc 2.28+ ?
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 3/11/19 3:08 PM, Lange Norbert via Xenomai wrote:
> > Thats a rootfs which reproduces the issue. Identical setup, but glibc 2.27 
> > will
> not reproduce.
>
> The issue was introduced by [1], which already triggered a bug in the glibc
> test suite [2]. In short, calling pthread_atfork() like
> __cobalt_init() does over the context of a fork handler is now invalid,
> because the glibc now holds the internal atfork_lock while running the fork
> handlers. The cobalt fork handler needs to be registered earlier, outside of
> such context.
>
> This change was introduced between glibc-2.27.9000 and glibc-2.28.
>
> [1] git://sourceware.org/git/glibc.git, 27761a104 [2]
> git://sourceware.org/git/glibc.git, 669ff911e
>
> --
> Philippe.


This message and any attachments are solely for the use of the intended 
recipients. They may contain privileged and/or confidential information or 
other information protected from disclosure. If you are not an intended 
recipient, you are hereby notified that you received this email in error and 
that any review, dissemination, distribution or copying of this email and any 
attachment is strictly prohibited. If you have received this email in error, 
please contact the sender and delete the message and any attachment from your 
system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: smokey's fork tests hangs with glibc 2.28+ ?

[Lange Norbert via Xenomai]

Thanks Phillipe,

assume just for a moment that I know little of the issues,
is there any harm using glibc 2.28 for now, given that I don’t
run into those deadlocks or could there be some more
subtile breakage involved?

Norbert

> -Original Message-
> From: Philippe Gerum 
> Sent: Montag, 11. März 2019 15:19
> To: Lange Norbert ; Jan Kiszka
> ; Xenomai (xenomai@xenomai.org)
> 
> Subject: Re: smokey's fork tests hangs with glibc 2.28+ ?
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 3/11/19 3:08 PM, Lange Norbert via Xenomai wrote:
> > Thats a rootfs which reproduces the issue. Identical setup, but glibc 2.27 
> > will
> not reproduce.
>
> The issue was introduced by [1], which already triggered a bug in the glibc
> test suite [2]. In short, calling pthread_atfork() like
> __cobalt_init() does over the context of a fork handler is now invalid,
> because the glibc now holds the internal atfork_lock while running the fork
> handlers. The cobalt fork handler needs to be registered earlier, outside of
> such context.
>
> This change was introduced between glibc-2.27.9000 and glibc-2.28.
>
> [1] git://sourceware.org/git/glibc.git, 27761a104 [2]
> git://sourceware.org/git/glibc.git, 669ff911e
>
> --
> Philippe.


This message and any attachments are solely for the use of the intended 
recipients. They may contain privileged and/or confidential information or 
other information protected from disclosure. If you are not an intended 
recipient, you are hereby notified that you received this email in error and 
that any review, dissemination, distribution or copying of this email and any 
attachment is strictly prohibited. If you have received this email in error, 
please contact the sender and delete the message and any attachment from your 
system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

Using RTnet to communicate with regular UDP socket

[李冰 via Xenomai]

Hi everyone：
I am using xenomai + RTnet in Ubuntu，Xenomai version 3.0.5 Linux kernal 
version 4.9.38. And the ethernet card is Intel e1000.

I'm going to use RTnet to communicate with regular UDP socket like a socket 
in raw Linux . I need to implement two way communication between Xenomai and 
another device witch is using regular UDP socket.  In other words, RTnet socket 
in Xenomai should sent datagram to the regular UDP socket . If the regular UDP 
protocol can decode the rt-udp datagram and get right data?  Besides, RTnet 
socket in Xenomai should also receive datagram from regular UDP protocol, so if 
the rt-udp in Xenomai can decode the regular UDP datagram?
Thanks for everyone who spend time to give me some help!

Re: kvm fpu warning on 4.14.89

[Jan Kiszka via Xenomai]

On 11.03.19 15:36, cagnulein wrote:

Hi Jan, did you get any chance to look at my issue?


Not yet, sorry. I hope I can do some Xenomai stuff tomorrow, including at least 
a reproduction of this issue.


Jan


Thanks

Il ven 1 mar 2019, 15:58 Jan Kiszka > ha scritto:


On 01.03.19 15:21, cagnulein wrote:
 > Hi, with the last git the warning disappear, thanks.
 > Now I would like to submit a new issue : with the last git and with the
4.14.89
 > also, if I run latency-test without the kvm guest on, everything works 
fine.
 > If I run latency-test with the kvm guest on the system hangs! The entire
system
 > not only the guest.
 > This doesn't happen with the 4.9.146.
 > Any hints to debug it?

Hmm, this will be more complicated in fact. I need to try reproducing that 
in
KVM (nested setup) because that allows insights to be obtained more easily.

Jan

 > Thanks in advance
 >
 > Il ven 1 mar 2019, 11:30 cagnulein mailto:cagnul...@gmail.com>
 > >> ha scritto:
 >
 >     Yes qemu on a xenomai kernel (host device). My guest is a windows 10
2019.
 >
 >     I'm already compiling the last git. I will let you know.
 >     Thanks
 >
 >     Il ven 1 mar 2019, 11:24 Jan Kiszka mailto:jan.kis...@siemens.com>
 >     >> ha
scritto:
 >
 >         On 01.03.19 10:35, cagnulein via Xenomai wrote:
 >          > I’m testing the 4.14.89 ipipe (i was usually using 4.9.146)
and i’ve
 >         got a
 >          > deterministic warning every time i start qemu. Is it already
known?
 >          >
 >
 >         Thanks for reporting. I suppose this wasn't tested in a while.
 >
 >         Just to be sure: You are starting QEMU/KVM *on* a Xenomai kernel,
and *not*
 >         Xenomai as KVM guest, right?
 >
 >         Could you also give latest
https://gitlab.denx.de/Xenomai/ipipe-x86/ a
 >         try, if
 >         something happened to have changed?
 >
 >         I will try to reproduce ASAP.
 >
 >         Jan
 >
 >          > Thanks
 >          >
 >          > R.
 >          >
 >          >
 >          >
 >          > Mar  1 01:14:05 debiankvm kernel: [   96.078798] WARNING: CPU:
0 PID:
 >         1154
 >          > at ./arch/x86/include/asm/fpu/internal.h:617
__kernel_fpu_end+0x8b/0xa0
 >          >
 >          > Mar  1 01:14:05 debiankvm kernel: [   96.078802] Modules
linked in:
 >          > hid_generic usbhid hid xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE
 >          > nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat
nf_conntrack_ipv4
 >          > nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT 
nf_reject_ipv4
 >          > xt_tcpudp tun ebtable_filter ebtables ip6table_filter 
ip6_tables
 >          > iptable_filter bridge stp llc intel_rapl x86_pkg_temp_thermal
coretemp
 >          > kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel
 >          > pcbc i2c_designware_platform i2c_designware_core nls_ascii
nls_cp437 vfat
 >          > fat aesni_intel aes_x86_64 crypto_simd glue_helper cryptd
intel_cstate
 >          > intel_rapl_perf pcspkr i915 prime_numbers lpc_ich
drm_kms_helper drm
 >         idma64
 >          > fb_sys_fops mei_me syscopyarea intel_lpss_pci sysfillrect
intel_lpss
 >          > sysimgblt mfd_core mei shpchp sg evdev video ip_tables
x_tables autofs4
 >          >
 >          > Mar  1 01:14:05 debiankvm kernel: [   96.078913]  ext4 crc16
mbcache jbd2
 >          > fscrypto btrfs zstd_decompress zstd_compress xxhash raid10 
raid456
 >          > async_raid6_recov async_memcpy async_pq async_xor async_tx xor
raid6_pq
 >          > libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod
sd_mod
 >          > mmc_block igb i2c_algo_bit dca ahci sdhci_pci sdhci xhci_pci
libahci ptp
 >          > crc32c_intel i2c_i801 xhci_hcd mmc_core pps_core libata
usbcore scsi_mod
 >          >
 >          > Mar  1 01:14:05 debiankvm kernel: [   96.078982] CPU: 0 PID:
1154 Comm:
 >          > qemu-system-x86 Not tainted 4.14.89 #1
 >          >
 >          > Mar  1 01:14:05 debiankvm kernel: [   96.078985] I-pipe
domain: Linux
 >          >
 >          > Mar  1 01:14:05 debiankvm kernel: [   96.078988] task:
94aff6f49c80
 >          > task.stack: b5be80a58000
 >          >
 >          > Mar  1 01:14:05 debiankvm kernel: [   96.078991] RIP:
 >          > 0010:__kernel_fpu_end+0x8b/0xa0
 >          >
 >          > Mar  1 01:14:05 debiankvm kernel: [   96.078994] RSP:
 >         0018:b5be80a5

Re: Question about real-time networking

[Jan Kiszka via Xenomai]

On 11.03.19 06:59, 김병진 wrote:

 >On 08.03.19 10:05, 김병진 via Xenomai wrote:

 >> HelloI wanna use tcp or udp for real-time network.i found an example from 
/home/kraptor/xenomai-v3.0.8/demo/posix/cobalt/eth_p_allBut it seems like not using 
rtnet.https://gitlab.denx.de/Xenomai/xenomai/wikis/RTnetWiki says that i need to install Rtnet separately.Is it right? I am 
trying to build rtnet tcp example without install.Cause all function I need is in /xenomai/kernel/drivers/net/stack/But what should I 
include or link?(cflags or ldflags)Is there anyone who can help me?Thank you.

 >Something is mangling your emails...

Sorry for messy html. I think My mail editor has a problem:(

 >RTnet is part of Xenomai, no need for a separate installation anymore. Where 
exactly is our wiki suggesting something different?

Several paths in 'Rtnet programming' are based on installing Rtnet.

https://gitlab.denx.de/Xenomai/xenomai/wikis/RTnet

"The second folder of interest is the folder where RTnet was installed into. The 
default location for this would be /usr/local/rtnet."

https://gitlab.denx.de/Xenomai/xenomai/wikis/RTnet_Setup

"Change to directory /usr/local/rtnet/sbin"


Well, that is talking about installing it from the Xenomai sources onto the 
target. That still applies.




 >For rttcp, you need to use the development branch (master).

So if i use master branch xenomai, can i add tcp in "RT_PROTOCOLS" from 
'rtnet.conf'?

I can't add tcp flags on 3.0.8 branch because there is no tcp/rtnet option in 
kernel config.



As I said: use git, master branch.

Jan

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