Re: l2reflect - network-based I/O latency benchmark

[Henning Schild via Xenomai]

Am Wed, 24 Mar 2021 12:11:27 +0100
schrieb Jan Kiszka via Xenomai :

> Hi all,
> 
> as we discussed today in the community call how to use a network link
> to benchmark Xenomai I/O, here is the link to our work for a different
> activity that we shared with the dpdk community:
> 
> http://mails.dpdk.org/archives/dev/2020-September/181035.html
> 
> Being DPDK, this comes without interrupts, but that might be
> extensible. There are minor updates available internally, so let us
> know if interest is concrete, then we can refresh this.

In fact the version posted there has interrupts if one wants. We
started off with polling only but decided to add interrupts for the
mainlining.
We hope to eventually succeed with mainline. More stakeholders asking
for a "cyclictest" for ethernet I/O could help.
There is not much internal stuff we did not yet publish, a bit of
advanced tracing which can be regarded optional for the first round.
And a bit of linux-bridge support which so far did not result in
promising results (low latency) and will need more investigation.

All the internal bits can be shared any time but simply did not yet
work well enough to propose them for mainline.

Henning

> Jan
> 

Re: "switchtest" problem with recent 5.10 dovetail and distro-like kernel config

[Henning Schild via Xenomai]

Am Thu, 7 Oct 2021 10:55:38 +0200
schrieb "Bezdeka, Florian (T RDA IOT SES-DE)"
:

> On Thu, 2021-10-07 at 08:53 +, Bezdeka, Florian via Xenomai wrote:
> > On Thu, 2021-10-07 at 10:37 +0200, Jan Kiszka wrote:  
> > > On 05.10.21 17:18, Henning Schild wrote:  
> > > > Am Tue, 5 Oct 2021 16:38:12 +0200
> > > > schrieb "Bezdeka, Florian (T RDA IOT SES-DE)"
> > > > :
> > > >  
> > > > > On Tue, 2021-10-05 at 16:29 +0200, Jan Kiszka via Xenomai
> > > > > wrote:  
> > > > > > On 24.09.21 15:31, Henning Schild via Xenomai wrote:  
> > > > > > > Am Wed, 22 Sep 2021 16:21:54 +0200
> > > > > > > schrieb Henning Schild via Xenomai :
> > > > > > >  
> > > > > > > > Am Wed, 22 Sep 2021 14:36:49 +0200
> > > > > > > > schrieb Philippe Gerum :
> > > > > > > >  
> > > > > > > > > Henning Schild via Xenomai 
> > > > > > > > > writes: 
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > getting sick of maintaining a "small" kernel config
> > > > > > > > > > i wanted to switch to a config derived from the
> > > > > > > > > > debian11 5.10 kernel. Basically that config plus
> > > > > > > > > > the few switches coming in with dovetail.
> > > > > > > > > >
> > > > > > > > > > That passed all tests in qemu but on a real machine
> > > > > > > > > > (big xeon with raid0) the "switchtest" has an issue.
> > > > > > > > > >
> > > > > > > > > > # /lib/xenomai/testsuite/switchtest
> > > > > > > > > > == Testing FPU check routines...
> > > > > > > > > > r0: 1 != 2
> > > > > > > > > > r1: 1 != 2
> > > > > > > > > > r2: 1 != 2
> > > > > > > > > > r3: 1 != 2
> > > > > > > > > > r4: 1 != 2
> > > > > > > > > > r5: 1 != 2
> > > > > > > > > > r6: 1 != 2
> > > > > > > > > > r7: 1 != 2
> > > > > > > > > > ymm0: 1/1 != 2/2
> > > > > > > > > > ymm1: 1/1 != 2/2
> > > > > > > > > > ymm2: 1/1 != 2/2
> > > > > > > > > > ymm3: 1/1 != 2/2
> > > > > > > > > > ymm4: 1/1 != 2/2
> > > > > > > > > > ymm5: 1/1 != 2/2
> > > > > > > > > > ymm6: 1/1 != 2/2
> > > > > > > > > > ymm7: 1/1 != 2/2
> > > > > > > > > > == FPU check routines: OK.
> > > > > > > > > > == Threads: ... a lot of threads ...
> > > > > > > > > > 30-16 rtuo_ufpp30-17 rtuo_ufpp30-18 rtuo_ufps30-19
> > > > > > > > > > rtuo_ufps30-20 rtuo_ufpp_ufps30-21
> > > > > > > > > > rtuo_ufpp_ufps30-22 sleeper_ufpthread_create:
> > > > > > > > > > Resource temporarily unavailable ps31-0 rtk31-1
> > > > > > > > > > rtk31-2 rtk_fp31-3 rtk_fp31-4 rtk_fp_ufpp31-5
> > > > > > > > > > rtk_fp_ufpp31-6 rtup31-7 rtup31-8 rtup_ufpp31-9
> > > > > > > > > > rtup_ufpp31-10 rtus
> > > > > > > > > >
> > > > > > > > > > followed by only 0s
> > > > > > > > > >
> > > > > > > > > > RTH|-cpu|ctx switches|---total
> > > > > > > > > > RTD|   0|   0|   0
> > > > > > > > > > RTD|   1|   0|   0
> > > > > > > > > > RTD|   2|   0|   0
> > > > > > > > > > RTD|   3|   0|   0
> > > > > > > > > > RTD|   4|   0|   0
> > > > > > > > > > RTD|   5|   0|   0
> > > > > > > > > > RTD|   6|   0|   0
> > > > > > > > > >
> > > > > > > > > >

Re: "switchtest" problem with recent 5.10 dovetail and distro-like kernel config

[Henning Schild via Xenomai]

Am Thu, 7 Oct 2021 10:37:19 +0200
schrieb Jan Kiszka :

> On 05.10.21 17:18, Henning Schild wrote:
> > Am Tue, 5 Oct 2021 16:38:12 +0200
> > schrieb "Bezdeka, Florian (T RDA IOT SES-DE)"
> > :
> >   
> >> On Tue, 2021-10-05 at 16:29 +0200, Jan Kiszka via Xenomai wrote:  
> >>> On 24.09.21 15:31, Henning Schild via Xenomai wrote:
> >>>> Am Wed, 22 Sep 2021 16:21:54 +0200
> >>>> schrieb Henning Schild via Xenomai :
> >>>>
> >>>>> Am Wed, 22 Sep 2021 14:36:49 +0200
> >>>>> schrieb Philippe Gerum :
> >>>>>
> >>>>>> Henning Schild via Xenomai  writes:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> getting sick of maintaining a "small" kernel config i
> >>>>>>> wanted to switch to a config derived from the debian11 5.10
> >>>>>>> kernel. Basically that config plus the few switches coming
> >>>>>>> in with dovetail.
> >>>>>>>
> >>>>>>> That passed all tests in qemu but on a real machine (big
> >>>>>>> xeon with raid0) the "switchtest" has an issue.
> >>>>>>>
> >>>>>>> # /lib/xenomai/testsuite/switchtest
> >>>>>>> == Testing FPU check routines...
> >>>>>>> r0: 1 != 2
> >>>>>>> r1: 1 != 2
> >>>>>>> r2: 1 != 2
> >>>>>>> r3: 1 != 2
> >>>>>>> r4: 1 != 2
> >>>>>>> r5: 1 != 2
> >>>>>>> r6: 1 != 2
> >>>>>>> r7: 1 != 2
> >>>>>>> ymm0: 1/1 != 2/2
> >>>>>>> ymm1: 1/1 != 2/2
> >>>>>>> ymm2: 1/1 != 2/2
> >>>>>>> ymm3: 1/1 != 2/2
> >>>>>>> ymm4: 1/1 != 2/2
> >>>>>>> ymm5: 1/1 != 2/2
> >>>>>>> ymm6: 1/1 != 2/2
> >>>>>>> ymm7: 1/1 != 2/2
> >>>>>>> == FPU check routines: OK.
> >>>>>>> == Threads: ... a lot of threads ...
> >>>>>>> 30-16 rtuo_ufpp30-17 rtuo_ufpp30-18 rtuo_ufps30-19
> >>>>>>> rtuo_ufps30-20 rtuo_ufpp_ufps30-21 rtuo_ufpp_ufps30-22
> >>>>>>> sleeper_ufpthread_create: Resource temporarily unavailable
> >>>>>>> ps31-0 rtk31-1 rtk31-2 rtk_fp31-3 rtk_fp31-4
> >>>>>>> rtk_fp_ufpp31-5 rtk_fp_ufpp31-6 rtup31-7 rtup31-8
> >>>>>>> rtup_ufpp31-9 rtup_ufpp31-10 rtus
> >>>>>>>
> >>>>>>> followed by only 0s
> >>>>>>>
> >>>>>>> RTH|-cpu|ctx switches|---total
> >>>>>>> RTD|   0|   0|   0
> >>>>>>> RTD|   1|   0|   0
> >>>>>>> RTD|   2|   0|   0
> >>>>>>> RTD|   3|   0|   0
> >>>>>>> RTD|   4|   0|   0
> >>>>>>> RTD|   5|   0|   0
> >>>>>>> RTD|   6|   0|   0
> >>>>>>>
> >>>>>>> So it gets a
> >>>>>>>
> >>>>>>> sleeper_ufpthread_create: Resource temporarily unavailable
> >>>>>>>
> >>>>>>> but swallows that and keeps going. I think there might be a
> >>>>>>> first issue with that error return not being dealt with.
> >>>>>>>
> >>>>>>> A second run get the "switchtest" stuck after crtl+c while
> >>>>>>> the kernel starts complaining.
> >>>>>>>
> >>>>>>> [ 1229.072052] list_del corruption. prev->next should be
> >>>>>>> b24e46fb0548, but was 9a7356b0 [ 1229.072053]
> >>>>>>> [ cut here ] [ 1229.072054] kernel
> >>>>>>> BUG at lib/list_debug.c:51! [ 1229.072054] invalid opcode:
> >>>>>>>  [#1] SMP PTI IRQ_PIPELINE [ 1229.072054] CPU: 31 PID:
> >>>>>>> 1857 Comm: switchtest Tainted: GE
> >>>>>>> 5.10.61-xenomai-1 #1 [ 1229.072055] Hardwar

Re: "switchtest" problem with recent 5.10 dovetail and distro-like kernel config

[Henning Schild via Xenomai]

Am Tue, 5 Oct 2021 16:38:12 +0200
schrieb "Bezdeka, Florian (T RDA IOT SES-DE)"
:

> On Tue, 2021-10-05 at 16:29 +0200, Jan Kiszka via Xenomai wrote:
> > On 24.09.21 15:31, Henning Schild via Xenomai wrote:  
> > > Am Wed, 22 Sep 2021 16:21:54 +0200
> > > schrieb Henning Schild via Xenomai :
> > >  
> > > > Am Wed, 22 Sep 2021 14:36:49 +0200
> > > > schrieb Philippe Gerum :
> > > >  
> > > > > Henning Schild via Xenomai  writes:
> > > > >  
> > > > > > Hi,
> > > > > >
> > > > > > getting sick of maintaining a "small" kernel config i
> > > > > > wanted to switch to a config derived from the debian11 5.10
> > > > > > kernel. Basically that config plus the few switches coming
> > > > > > in with dovetail.
> > > > > >
> > > > > > That passed all tests in qemu but on a real machine (big
> > > > > > xeon with raid0) the "switchtest" has an issue.
> > > > > >
> > > > > > # /lib/xenomai/testsuite/switchtest
> > > > > > == Testing FPU check routines...
> > > > > > r0: 1 != 2
> > > > > > r1: 1 != 2
> > > > > > r2: 1 != 2
> > > > > > r3: 1 != 2
> > > > > > r4: 1 != 2
> > > > > > r5: 1 != 2
> > > > > > r6: 1 != 2
> > > > > > r7: 1 != 2
> > > > > > ymm0: 1/1 != 2/2
> > > > > > ymm1: 1/1 != 2/2
> > > > > > ymm2: 1/1 != 2/2
> > > > > > ymm3: 1/1 != 2/2
> > > > > > ymm4: 1/1 != 2/2
> > > > > > ymm5: 1/1 != 2/2
> > > > > > ymm6: 1/1 != 2/2
> > > > > > ymm7: 1/1 != 2/2
> > > > > > == FPU check routines: OK.
> > > > > > == Threads: ... a lot of threads ...
> > > > > > 30-16 rtuo_ufpp30-17 rtuo_ufpp30-18 rtuo_ufps30-19
> > > > > > rtuo_ufps30-20 rtuo_ufpp_ufps30-21 rtuo_ufpp_ufps30-22
> > > > > > sleeper_ufpthread_create: Resource temporarily unavailable
> > > > > > ps31-0 rtk31-1 rtk31-2 rtk_fp31-3 rtk_fp31-4
> > > > > > rtk_fp_ufpp31-5 rtk_fp_ufpp31-6 rtup31-7 rtup31-8
> > > > > > rtup_ufpp31-9 rtup_ufpp31-10 rtus
> > > > > >
> > > > > > followed by only 0s
> > > > > >
> > > > > > RTH|-cpu|ctx switches|---total
> > > > > > RTD|   0|   0|   0
> > > > > > RTD|   1|   0|   0
> > > > > > RTD|   2|   0|   0
> > > > > > RTD|   3|   0|   0
> > > > > > RTD|   4|   0|   0
> > > > > > RTD|   5|   0|   0
> > > > > > RTD|   6|   0|   0
> > > > > >
> > > > > > So it gets a
> > > > > >
> > > > > > sleeper_ufpthread_create: Resource temporarily unavailable
> > > > > >
> > > > > > but swallows that and keeps going. I think there might be a
> > > > > > first issue with that error return not being dealt with.
> > > > > >
> > > > > > A second run get the "switchtest" stuck after crtl+c while
> > > > > > the kernel starts complaining.
> > > > > >
> > > > > > [ 1229.072052] list_del corruption. prev->next should be
> > > > > > b24e46fb0548, but was 9a7356b0 [ 1229.072053]
> > > > > > [ cut here ] [ 1229.072054] kernel
> > > > > > BUG at lib/list_debug.c:51! [ 1229.072054] invalid opcode:
> > > > > >  [#1] SMP PTI IRQ_PIPELINE [ 1229.072054] CPU: 31 PID:
> > > > > > 1857 Comm: switchtest Tainted: GE
> > > > > > 5.10.61-xenomai-1 #1 [ 1229.072055] Hardware name: secret [
> > > > > > 1229.072055] IRQ stage: Linux [ 1229.072055] RIP:
> > > > > > 0010:__list_del_entry_valid.cold+0x31/0x47 [ 1229.072056]
> > > > > > Code: 99 32 9a e8 5f 0d ff ff 0f 0b 48 c7 c7 00 9a 32 9a e8
> > > > > > 51 0d ff ff 0f 0b 48 89 b [ 1229.072057] RSP:
> > > > > > 0018:b24e4b5f7e30 EFLAGS: 00010046 [ 1229.072061] RAX:
> > > > > > 000

Re: "switchtest" problem with recent 5.10 dovetail and distro-like kernel config

[Henning Schild via Xenomai]

Am Wed, 22 Sep 2021 16:21:54 +0200
schrieb Henning Schild via Xenomai :

> Am Wed, 22 Sep 2021 14:36:49 +0200
> schrieb Philippe Gerum :
> 
> > Henning Schild via Xenomai  writes:
> >   
> > > Hi,
> > >
> > > getting sick of maintaining a "small" kernel config i wanted to
> > > switch to a config derived from the debian11 5.10 kernel.
> > > Basically that config plus the few switches coming in with
> > > dovetail.
> > >
> > > That passed all tests in qemu but on a real machine (big xeon with
> > > raid0) the "switchtest" has an issue.
> > >
> > > # /lib/xenomai/testsuite/switchtest 
> > > == Testing FPU check routines...
> > > r0: 1 != 2
> > > r1: 1 != 2
> > > r2: 1 != 2
> > > r3: 1 != 2
> > > r4: 1 != 2
> > > r5: 1 != 2
> > > r6: 1 != 2
> > > r7: 1 != 2
> > > ymm0: 1/1 != 2/2
> > > ymm1: 1/1 != 2/2
> > > ymm2: 1/1 != 2/2
> > > ymm3: 1/1 != 2/2
> > > ymm4: 1/1 != 2/2
> > > ymm5: 1/1 != 2/2
> > > ymm6: 1/1 != 2/2
> > > ymm7: 1/1 != 2/2
> > > == FPU check routines: OK.
> > > == Threads: ... a lot of threads ...
> > > 30-16 rtuo_ufpp30-17 rtuo_ufpp30-18 rtuo_ufps30-19 rtuo_ufps30-20
> > > rtuo_ufpp_ufps30-21 rtuo_ufpp_ufps30-22 sleeper_ufpthread_create:
> > > Resource temporarily unavailable ps31-0 rtk31-1 rtk31-2 rtk_fp31-3
> > > rtk_fp31-4 rtk_fp_ufpp31-5 rtk_fp_ufpp31-6 rtup31-7 rtup31-8
> > > rtup_ufpp31-9 rtup_ufpp31-10 rtus
> > >
> > > followed by only 0s
> > >
> > > RTH|-cpu|ctx switches|---total
> > > RTD|   0|   0|   0
> > > RTD|   1|   0|   0
> > > RTD|   2|   0|   0
> > > RTD|   3|   0|   0
> > > RTD|   4|   0|   0
> > > RTD|   5|   0|   0
> > > RTD|   6|   0|   0
> > >
> > > So it gets a 
> > >
> > > sleeper_ufpthread_create: Resource temporarily unavailable
> > >
> > > but swallows that and keeps going. I think there might be a first
> > > issue with that error return not being dealt with.
> > >
> > > A second run get the "switchtest" stuck after crtl+c while the
> > > kernel starts complaining.
> > >
> > > [ 1229.072052] list_del corruption. prev->next should be
> > > b24e46fb0548, but was 9a7356b0 [ 1229.072053]
> > > [ cut here ] [ 1229.072054] kernel BUG at
> > > lib/list_debug.c:51! [ 1229.072054] invalid opcode:  [#1] SMP
> > > PTI IRQ_PIPELINE [ 1229.072054] CPU: 31 PID: 1857 Comm: switchtest
> > > Tainted: GE 5.10.61-xenomai-1 #1 [ 1229.072055]
> > > Hardware name: secret [ 1229.072055] IRQ stage: Linux
> > > [ 1229.072055] RIP: 0010:__list_del_entry_valid.cold+0x31/0x47
> > > [ 1229.072056] Code: 99 32 9a e8 5f 0d ff ff 0f 0b 48 c7 c7 00 9a
> > > 32 9a e8 51 0d ff ff 0f 0b 48 89 b [ 1229.072057] RSP:
> > > 0018:b24e4b5f7e30 EFLAGS: 00010046 [ 1229.072061] RAX:
> > > 0057 RBX: b24e46fb04b0 RCX:  [
> > > 1229.072062] RDX:  RSI: a10e9fd9bba0 RDI:
> > > a10e9fd97b68 [ 1229.072064] RBP:  R08:
> > > 0001 R09: 000f [ 1229.072066] R10:
> > > 000f R11: a10e9fd97bd6 R12:  [
> > > 1229.072069] R13: a0ff488c7380 R14:  R15:
> > >  [ 1229.072072] FS:  7f57e687bb80()
> > > GS:a10e9fd8() knlGS: [ 1229.072074]
> > > CS: 0010 DS:  ES:  CR0: 80050033 [ 1229.072076]
> > > CR2: 55921bfa921c CR3: 0001062fe002 CR4: 001706e0
> > > [ 1229.072078] Call Trace: [ 1229.072080]
> > > xntimer_destroy+0x81/0x150 [ 1229.072082]
> > > __xnthread_cleanup+0x1e/0x2a0 [ 1229.072084]
> > > cobalt_handle_taskexit_event+0x1d/0x40 [ 1229.072086]
> > > do_exit+0xe1/0xab0 [ 1229.072088]  ?
> > > signal_wake_up_state+0x23/0x40 [ 1229.072090]
> > > do_group_exit+0x33/0xa0 [ 1229.072092]
> > > __x64_sys_exit_group+0x14/0x20 [ 1229.072111]
> > > do_syscall_64+0x3f/0x90 [ 1229.072113]
> > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1229.072115] RIP:
> > > 0033:0x7f57e6948699 [ 1229.072117] Code: 00 4c 8b 05 f9 27 0f 00

Re: "switchtest" problem with recent 5.10 dovetail and distro-like kernel config

[Henning Schild via Xenomai]

Am Wed, 22 Sep 2021 14:36:49 +0200
schrieb Philippe Gerum :

> Henning Schild via Xenomai  writes:
> 
> > Hi,
> >
> > getting sick of maintaining a "small" kernel config i wanted to
> > switch to a config derived from the debian11 5.10 kernel. Basically
> > that config plus the few switches coming in with dovetail.
> >
> > That passed all tests in qemu but on a real machine (big xeon with
> > raid0) the "switchtest" has an issue.
> >
> > # /lib/xenomai/testsuite/switchtest 
> > == Testing FPU check routines...
> > r0: 1 != 2
> > r1: 1 != 2
> > r2: 1 != 2
> > r3: 1 != 2
> > r4: 1 != 2
> > r5: 1 != 2
> > r6: 1 != 2
> > r7: 1 != 2
> > ymm0: 1/1 != 2/2
> > ymm1: 1/1 != 2/2
> > ymm2: 1/1 != 2/2
> > ymm3: 1/1 != 2/2
> > ymm4: 1/1 != 2/2
> > ymm5: 1/1 != 2/2
> > ymm6: 1/1 != 2/2
> > ymm7: 1/1 != 2/2
> > == FPU check routines: OK.
> > == Threads: ... a lot of threads ...
> > 30-16 rtuo_ufpp30-17 rtuo_ufpp30-18 rtuo_ufps30-19 rtuo_ufps30-20
> > rtuo_ufpp_ufps30-21 rtuo_ufpp_ufps30-22 sleeper_ufpthread_create:
> > Resource temporarily unavailable ps31-0 rtk31-1 rtk31-2 rtk_fp31-3
> > rtk_fp31-4 rtk_fp_ufpp31-5 rtk_fp_ufpp31-6 rtup31-7 rtup31-8
> > rtup_ufpp31-9 rtup_ufpp31-10 rtus
> >
> > followed by only 0s
> >
> > RTH|-cpu|ctx switches|---total
> > RTD|   0|   0|   0
> > RTD|   1|   0|   0
> > RTD|   2|   0|   0
> > RTD|   3|   0|   0
> > RTD|   4|   0|   0
> > RTD|   5|   0|   0
> > RTD|   6|   0|   0
> >
> > So it gets a 
> >
> > sleeper_ufpthread_create: Resource temporarily unavailable
> >
> > but swallows that and keeps going. I think there might be a first
> > issue with that error return not being dealt with.
> >
> > A second run get the "switchtest" stuck after crtl+c while the
> > kernel starts complaining.
> >
> > [ 1229.072052] list_del corruption. prev->next should be
> > b24e46fb0548, but was 9a7356b0 [ 1229.072053]
> > [ cut here ] [ 1229.072054] kernel BUG at
> > lib/list_debug.c:51! [ 1229.072054] invalid opcode:  [#1] SMP
> > PTI IRQ_PIPELINE [ 1229.072054] CPU: 31 PID: 1857 Comm: switchtest
> > Tainted: GE 5.10.61-xenomai-1 #1 [ 1229.072055]
> > Hardware name: secret [ 1229.072055] IRQ stage: Linux
> > [ 1229.072055] RIP: 0010:__list_del_entry_valid.cold+0x31/0x47
> > [ 1229.072056] Code: 99 32 9a e8 5f 0d ff ff 0f 0b 48 c7 c7 00 9a
> > 32 9a e8 51 0d ff ff 0f 0b 48 89 b [ 1229.072057] RSP:
> > 0018:b24e4b5f7e30 EFLAGS: 00010046 [ 1229.072061] RAX:
> > 0057 RBX: b24e46fb04b0 RCX:  [
> > 1229.072062] RDX:  RSI: a10e9fd9bba0 RDI:
> > a10e9fd97b68 [ 1229.072064] RBP:  R08:
> > 0001 R09: 000f [ 1229.072066] R10:
> > 000f R11: a10e9fd97bd6 R12:  [
> > 1229.072069] R13: a0ff488c7380 R14:  R15:
> >  [ 1229.072072] FS:  7f57e687bb80()
> > GS:a10e9fd8() knlGS: [ 1229.072074] CS:
> >  0010 DS:  ES:  CR0: 80050033 [ 1229.072076] CR2:
> > 55921bfa921c CR3: 0001062fe002 CR4: 001706e0 [
> > 1229.072078] Call Trace: [ 1229.072080]  xntimer_destroy+0x81/0x150
> > [ 1229.072082]  __xnthread_cleanup+0x1e/0x2a0 [ 1229.072084]
> > cobalt_handle_taskexit_event+0x1d/0x40 [ 1229.072086]
> > do_exit+0xe1/0xab0 [ 1229.072088]  ? signal_wake_up_state+0x23/0x40
> > [ 1229.072090]  do_group_exit+0x33/0xa0 [ 1229.072092]
> > __x64_sys_exit_group+0x14/0x20 [ 1229.072111]
> > do_syscall_64+0x3f/0x90 [ 1229.072113]
> > entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1229.072115] RIP:
> > 0033:0x7f57e6948699 [ 1229.072117] Code: 00 4c 8b 05 f9 27 0f 00 be
> > e7 00 00 00 ba 3c 00 00 00 eb 12 0f 1f 44 00 00 89 0 [ 1229.072119]
> > RSP: 002b:7ffcfbda0078 EFLAGS: 0246 ORIG_RAX:
> > 00e7 [ 1229.072128] RAX: ffda RBX:
> > 7f57e6a3d610 RCX: 7f57e6948699 [ 1229.072130] RDX:
> > 003c RSI: 00e7 RDI: 0001 [
> > 1229.072132] RBP: 0001 R08: ff70 R09:
> > 0001 [ 1229.072134] R10: 0005 R11:
> > 0246 R12: 7f57e6a3d610 [ 1229.072136] R13:
> > 0

"switchtest" problem with recent 5.10 dovetail and distro-like kernel config

[Henning Schild via Xenomai]

Hi,

getting sick of maintaining a "small" kernel config i wanted to switch
to a config derived from the debian11 5.10 kernel. Basically that
config plus the few switches coming in with dovetail.

That passed all tests in qemu but on a real machine (big xeon with
raid0) the "switchtest" has an issue.

# /lib/xenomai/testsuite/switchtest 
== Testing FPU check routines...
r0: 1 != 2
r1: 1 != 2
r2: 1 != 2
r3: 1 != 2
r4: 1 != 2
r5: 1 != 2
r6: 1 != 2
r7: 1 != 2
ymm0: 1/1 != 2/2
ymm1: 1/1 != 2/2
ymm2: 1/1 != 2/2
ymm3: 1/1 != 2/2
ymm4: 1/1 != 2/2
ymm5: 1/1 != 2/2
ymm6: 1/1 != 2/2
ymm7: 1/1 != 2/2
== FPU check routines: OK.
== Threads: ... a lot of threads ...
30-16 rtuo_ufpp30-17 rtuo_ufpp30-18 rtuo_ufps30-19 rtuo_ufps30-20
rtuo_ufpp_ufps30-21 rtuo_ufpp_ufps30-22 sleeper_ufpthread_create:
Resource temporarily unavailable ps31-0 rtk31-1 rtk31-2 rtk_fp31-3
rtk_fp31-4 rtk_fp_ufpp31-5 rtk_fp_ufpp31-6 rtup31-7 rtup31-8
rtup_ufpp31-9 rtup_ufpp31-10 rtus

followed by only 0s

RTH|-cpu|ctx switches|---total
RTD|   0|   0|   0
RTD|   1|   0|   0
RTD|   2|   0|   0
RTD|   3|   0|   0
RTD|   4|   0|   0
RTD|   5|   0|   0
RTD|   6|   0|   0

So it gets a 

sleeper_ufpthread_create: Resource temporarily unavailable

but swallows that and keeps going. I think there might be a first issue
with that error return not being dealt with.

A second run get the "switchtest" stuck after crtl+c while the kernel
starts complaining.

[ 1229.072052] list_del corruption. prev->next should be b24e46fb0548, but 
was 9a7356b0
[ 1229.072053] [ cut here ]
[ 1229.072054] kernel BUG at lib/list_debug.c:51!
[ 1229.072054] invalid opcode:  [#1] SMP PTI IRQ_PIPELINE
[ 1229.072054] CPU: 31 PID: 1857 Comm: switchtest Tainted: GE 
5.10.61-xenomai-1 #1
[ 1229.072055] Hardware name: secret
[ 1229.072055] IRQ stage: Linux
[ 1229.072055] RIP: 0010:__list_del_entry_valid.cold+0x31/0x47
[ 1229.072056] Code: 99 32 9a e8 5f 0d ff ff 0f 0b 48 c7 c7 00 9a 32 9a e8 51 
0d ff ff 0f 0b 48 89 b
[ 1229.072057] RSP: 0018:b24e4b5f7e30 EFLAGS: 00010046
[ 1229.072061] RAX: 0057 RBX: b24e46fb04b0 RCX: 
[ 1229.072062] RDX:  RSI: a10e9fd9bba0 RDI: a10e9fd97b68
[ 1229.072064] RBP:  R08: 0001 R09: 000f
[ 1229.072066] R10: 000f R11: a10e9fd97bd6 R12: 
[ 1229.072069] R13: a0ff488c7380 R14:  R15: 
[ 1229.072072] FS:  7f57e687bb80() GS:a10e9fd8() 
knlGS:
[ 1229.072074] CS:  0010 DS:  ES:  CR0: 80050033
[ 1229.072076] CR2: 55921bfa921c CR3: 0001062fe002 CR4: 001706e0
[ 1229.072078] Call Trace:
[ 1229.072080]  xntimer_destroy+0x81/0x150
[ 1229.072082]  __xnthread_cleanup+0x1e/0x2a0
[ 1229.072084]  cobalt_handle_taskexit_event+0x1d/0x40
[ 1229.072086]  do_exit+0xe1/0xab0
[ 1229.072088]  ? signal_wake_up_state+0x23/0x40
[ 1229.072090]  do_group_exit+0x33/0xa0
[ 1229.072092]  __x64_sys_exit_group+0x14/0x20
[ 1229.072111]  do_syscall_64+0x3f/0x90
[ 1229.072113]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 1229.072115] RIP: 0033:0x7f57e6948699
[ 1229.072117] Code: 00 4c 8b 05 f9 27 0f 00 be e7 00 00 00 ba 3c 00 00 00 eb 
12 0f 1f 44 00 00 89 0
[ 1229.072119] RSP: 002b:7ffcfbda0078 EFLAGS: 0246 ORIG_RAX: 
00e7
[ 1229.072128] RAX: ffda RBX: 7f57e6a3d610 RCX: 7f57e6948699
[ 1229.072130] RDX: 003c RSI: 00e7 RDI: 0001
[ 1229.072132] RBP: 0001 R08: ff70 R09: 0001
[ 1229.072134] R10: 0005 R11: 0246 R12: 7f57e6a3d610
[ 1229.072136] R13: 0002 R14: 7f57e6a3dae8 R15: 
[ 1229.072138] Modules linked in: md4(E) sha512_ssse3(E) sha512_generic(E) 
cmac(E) nls_utf8(E) cifs)
[ 1229.072169]  mei(E) soundcore(E) sysimgblt(E) sg(E) evdev(E) ioatdma(E) 
joydev(E) watchdog(E) ac)
[ 1229.072185] ---[ end trace a1d1ac68468e74f0 ]---
[ 1229.072186] RIP: 0010:__list_del_entry_valid.cold+0x31/0x47
[ 1229.072187] Code: 99 32 9a e8 5f 0d ff ff 0f 0b 48 c7 c7 00 9a 32 9a e8 51 
0d ff ff 0f 0b 48 89 b
[ 1229.072187] RSP: 0018:b24e4b5f7e30 EFLAGS: 00010046
[ 1229.072188] RAX: 0057 RBX: b24e46fb04b0 RCX: 
[ 1229.072188] RDX:  RSI: a10e9fd9bba0 RDI: a10e9fd97b68
[ 1229.072189] RBP:  R08: 0001 R09: 000f
[ 1229.072189] R10: 000f R11: a10e9fd97bd6 R12: 
[ 1229.072190] R13: a0ff488c7380 R14:  R15: 
[ 1229.072190] FS:  7f57e687bb80() GS:a10e9fd8() 
knlGS:
[ 1229.072190] CS:  0010 DS:  ES: 00

Re: sched: Unexpected reschedule of offline CPU#2!

[Henning Schild via Xenomai]

Was this ever resolved and if so can someone please point me to the
patches? I started digging a bit but could not yet find how that
continued.

I am seeing similar or maybe the same problem on 4.19.192 with the
ipipe patch from the xenomai project applied.

regards,
Henning

Am Sat, 17 Aug 2019 22:21:48 +0200
schrieb Thomas Gleixner :

> On Fri, 16 Aug 2019, Guenter Roeck wrote:
> > On Fri, Aug 16, 2019 at 12:22:22PM +0200, Thomas Gleixner wrote:  
> > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> > > index 75fea0d48c0e..625627b1457c 100644
> > > --- a/arch/x86/kernel/process.c
> > > +++ b/arch/x86/kernel/process.c
> > > @@ -601,6 +601,7 @@ void stop_this_cpu(void *dummy)
> > >   /*
> > >* Remove this CPU:
> > >*/
> > > + set_cpu_active(smp_processor_id(), false);
> > >   set_cpu_online(smp_processor_id(), false);
> > >   disable_local_APIC();
> > >   mcheck_cpu_clear(this_cpu_ptr(&cpu_info));
> > >   
> > No luck. The problem is still seen with this patch applied on top of
> > the mainline kernel (commit a69e90512d9def6).  
> 
> Yeah, was a bit too naive 
> 
> We actually need to do the full cpuhotplug dance for a regular
> reboot. In the panic case, there is nothing we can do about. I'll
> have a look tomorrow.
> 
> Thanks,
> 
>   tglx

Re: [RFC] status of [meta-]xenomai for Yocto

[Henning Schild via Xenomai]

Am Wed, 5 May 2021 10:19:50 +0200
schrieb Stefano Babic :

> Hi Philippe, Jan, Henning,
> 
> On 03.05.21 19:30, Jan Kiszka via Xenomai wrote:
> > On 03.05.21 19:16, Henning Schild via Xenomai wrote:  
> >> We have xenomai-images kind of maintained under the umbrella of the
> >> project. But that is Isar and Yocto sure has its place as well. I
> >> have also seen buildroot layers which include xenomai.
> >>
> >> Such integration systems tend to cause a lot of work. A project
> >> like xenomai probably wants to be "very close" to one of them to
> >> allow continous testing. We have that internally based on Isar and
> >> i think Intel might be going the same way.
> >>
> >> Not against the idea, but also not convinced.
> >>  
> > 
> > Was about to express the same concern: Who will test that those
> > preintegrations still work, produce reasonable results? If people
> > stand up and say, "hey, I'm doing that anyway already, will take
> > care of this!", then this could work.
> >   
> 
> I had to integrate a couple of time Xenomai in a Yocto build and I
> had thought about if it is worth to start a "meta-xemnomai". But
> after that, supporting Xenomai in Yocto means two main things:
> 
> - add support for Xenomai libs and tools. Well, this is a single
> recipe (at least in my build).
> - patch the kernel running scripts/prepare-kernel.sh.
> 
> And as we can use just LTS kernel, the second one means to add a new 
> provider for kernel, let's say a linux-xenomai recipe.
> 
> But then, that's all. I do not know if this it is enough to add an
> own meta-xenomai and to maintain it.

If you want to call it maintained you need to have kernel configs for
boards, and test those boards regularly ... at least with smokey. That
is where the real work starts, as pointed out by jan.
Not doing so will just mean a rather disappointing offering that might
in fact harm the project.

Henning

> Could be an alternative path to try to push the required recipes 
> (kernel+libs) to OE-Core, exactly as it was done by Preemp-rt ?
> Recipes are then part of a standard layer, and I see as advantage
> that they can be shown by much more people and could help to
> advertise Xenomai.
> 
> Best regards,
> Stefano
> 
> > And then the next aspect would be how to make generic assets like
> > kernel configurations and integration reusable for xenomai-images,
> > and vice versa.
> > 
> > Jan
> >   
> >> regards,
> >> Henning
> >>
> >> Am Mon, 3 May 2021 18:58:49 +0200
> >> schrieb Philippe Gerum via Xenomai :
> >>  
> >>> I'd like to discuss the current status of what exists, what might
> >>> be planned regarding a meta layer which would/does provide
> >>> support for Xenomai-enabled kernels. This could be a topic raised
> >>> during the next community meeting.
> >>>
> >>> I can see a couple of options floating around on the net, all
> >>> dedicated to specific hardware it seems, some/all extending their
> >>> support up to the rootfs image.
> >>>
> >>> Would it be possible to conceive such support as a meta-bsp layer
> >>> instead, implementing a new kernel type, one that could be
> >>> included in bbconf settings without imposing anything about the
> >>> image to be produced?  Something which could be extended to cover
> >>> Xenomai 4/EVL at some point as well.
> >>>
> >>> It would be nice to discuss ideas around the general topic of
> >>> having a reference meta layer for Xenomai in the most flexible
> >>> way. Whether it already exists, or not.
> >>>  
> >>
> >>  
> >   
> 
> 

Re: [RFC] status of [meta-]xenomai for Yocto

[Henning Schild via Xenomai]

We have xenomai-images kind of maintained under the umbrella of the
project. But that is Isar and Yocto sure has its place as well. I have
also seen buildroot layers which include xenomai.

Such integration systems tend to cause a lot of work. A project like
xenomai probably wants to be "very close" to one of them to allow
continous testing. We have that internally based on Isar and i think
Intel might be going the same way.

Not against the idea, but also not convinced.

regards,
Henning

Am Mon, 3 May 2021 18:58:49 +0200
schrieb Philippe Gerum via Xenomai :

> I'd like to discuss the current status of what exists, what might be
> planned regarding a meta layer which would/does provide support for
> Xenomai-enabled kernels. This could be a topic raised during the next
> community meeting.
> 
> I can see a couple of options floating around on the net, all
> dedicated to specific hardware it seems, some/all extending their
> support up to the rootfs image.
> 
> Would it be possible to conceive such support as a meta-bsp layer
> instead, implementing a new kernel type, one that could be included in
> bbconf settings without imposing anything about the image to be
> produced?  Something which could be extended to cover Xenomai 4/EVL at
> some point as well.
> 
> It would be nice to discuss ideas around the general topic of having a
> reference meta layer for Xenomai in the most flexible way. Whether it
> already exists, or not.
> 

Re: x86 on dovetail: Stress-ng gets my system down

[Henning Schild via Xenomai]

Am Mon, 3 May 2021 11:45:52 +0200
schrieb "Bezdeka, Florian (T RDA IOT SES-DE)"
:

> Hi,
> 
> while trying to debug one of the Xenomai 3.2 issues listed at [1] I
> run into the situation described below on my x86 system. The problem
> (or at least the "system hang" is reproducible on real hardware and on
> qemu/kvm.
> 
> Once the system is frozen, attaching GDB to the qemu process shows me:
> 
> (gdb) info threads
>   Id   Target Id  Frame
> * 1Thread 1 (CPU#0 [running]) csd_lock_wait
> (csd=0x88803e92ea00) at kernel/smp.c:228 2Thread 2 (CPU#1
> [running]) 0x564f0b05d36d in ?? () 3Thread 3 (CPU#2
> [running]) csd_lock_wait (csd=0x88803e82f1e0) at kernel/smp.c:228
> 4Thread 4 (CPU#3 [running]) csd_lock_wait
> (csd=0x88803e82f200) at kernel/smp.c:228
> 
> So three of my CPUs are waiting for other CPUs to complete a function
> call IPI. It looks like CPU1 is not responding anymore. The system is
> completely unusable at this point.
> 
> (gdb) bt
> #0  csd_lock_wait (csd=0x88803e92ea00) at kernel/smp.c:228
> #1  smp_call_function_many_cond (mask=mask@entry=0x88800448c340,
> func=func@entry=0x81055bb0 ,
> info=info@entry=0x8200acc0 ,
> wait=wait@entry=true, cond_func=cond_func@entry=0x810550b0
> ) at kernel/smp.c:693 #2  0x810f56f5 in
> on_each_cpu_cond_mask (cond_func=cond_func@entry=0x810550b0
> , func=func@entry=0x81055bb0
> , info=info@entry=0x8200acc0
> , wait=wait@entry=true,
> mask=mask@entry=0x88800448c340) at kernel/smp.c:904 #3
> 0x81055538 in native_flush_tlb_others
> (cpumask=cpumask@entry=0x88800448c340,
> info=info@entry=0x8200acc0 ) at
> arch/x86/mm/tlb.c:840 #4  0x81055fac in flush_tlb_others
> (info=0x8200acc0 ,
> cpumask=0x88800448c340) at arch/x86/mm/tlb.c:1170 #5
> arch_tlbbatch_flush (batch=batch@entry=0x88800448c340) at
> arch/x86/mm/tlb.c:1170 #6  0x811ae3e1 in try_to_unmap_flush
> () at mm/rmap.c:602 #7  0x8117d9d3 in shrink_page_list
> (page_list=page_list@entry=0xc9000306f910,
> pgdat=pgdat@entry=0x88803ffdb000, sc=sc@entry=0xc9000306fb18,
> stat=stat@entry=0xc9000306f924,
> ignore_references=ignore_references@entry=false) at mm/vmscan.c:1487
> #8  0x8117f79c in shrink_inactive_list (nr_to_scan= out>, lruvec=lruvec@entry=0x88803ffde508,
> out>sc=sc@entry=0xc9000306fb18, lru=lru@entry=LRU_INACTIVE_FILE)
> out>at mm/vmscan.c:1962 #9  0x811800dc in shrink_list
> out>(sc=0xc9000306fb18, lruvec=0x88803ffde508,
> out>nr_to_scan=, lru=) at
> out>mm/vmscan.c:2169 #10 shrink_lruvec
> out>(lruvec=lruvec@entry=0x88803ffde508,
> out>sc=sc@entry=0xc9000306fb18) at mm/vmscan.c:2464 #11
> out>0x81180374 in shrink_node_memcgs (sc=0xc9000306fb18,
> out>pgdat=0x88803ffdb000) at mm/vmscan.c:2652 #12 shrink_node
> out>(pgdat=pgdat@entry=0x88803ffdb000,
> out>sc=sc@entry=0xc9000306fb18) at mm/vmscan.c:2769 #13
> out>0x811806c8 in shrink_zones (sc=0xc9000306fb18,
> out>zonelist=0x88803ffdc400) at mm/vmscan.c:2972 #14
> out>do_try_to_free_pages (zonelist=zonelist@entry=0x88803ffdc400,
> out>sc=sc@entry=0xc9000306fb18) at mm/vmscan.c:3027 #15
> out>0x811817f6 in try_to_free_pages
> out>(zonelist=0x88803ffdc400, order=order@entry=1,
> out>gfp_mask=gfp_mask@entry=4197824, nodemask=) at
> out>mm/vmscan.c:3266 #16 0x811ba411 in __perform_reclaim
> out>(ac=0xc9000306fc90, ac=0xc9000306fc90, order=1,
> out>gfp_mask=4197824) at mm/page_alloc.c:4335 #17
> out>__alloc_pages_direct_reclaim (did_some_progress= out>pointer>, ac=0xc9000306fc90, alloc_flags=2112, order=1,
> out>pointer>gfp_mask=4197824) at mm/page_alloc.c:4356 #18
> out>pointer>__alloc_pages_slowpath (gfp_mask=,
> out>pointer>gfp_mask@entry=4197824, order=order@entry=1,
> out>pointer>ac=ac@entry=0xc9000306fc90) at mm/page_alloc.c:4760
> out>pointer>#19 0x811baf44 in __alloc_pages_nodemask
> out>pointer>(gfp_mask=, gfp_mask@entry=4197824,
> out>pointer>order=order@entry=1, preferred_nid=,
> out>pointer>nodemask=0x0 ) at mm/page_alloc.c:4970
> out>pointer>#20 0x811ce039 in alloc_pages_current
> out>pointer>(gfp=gfp@entry=4197824, order=order@entry=1) at
> out>pointer>./include/linux/topology.h:88 #21 0x811b6248 in
> out>pointer>alloc_pages (order=order@entry=1, gfp_mask=4197824) at
> out>pointer>./include/linux/gfp.h:547 #22 __get_free_pages
> out>pointer>(gfp_mask=gfp_mask@entry=4197824, order=order@entry=1) at
> out>pointer>mm/page_alloc.c:4994 #23 0x8105482c in _pgd_alloc
> out>pointer>() at arch/x86/mm/pgtable.c:430
> #24 pgd_alloc (mm=mm@entry=0x88800315e400) at
> arch/x86/mm/pgtable.c:430 #25 0x8105efae in mm_alloc_pgd
> (mm=0x88800315e400) at kernel/fork.c:1054 #26 mm_init
> (mm=mm@entry=0x88800315e400, user_ns=,
> p=0x888002bbc880) at kernel/fork.c:1054 #27 0x8105f624 in
> dup_

Re: Path to xeno-config - packages vs. scripts

[Henning Schild via Xenomai]

Am Wed, 14 Apr 2021 12:08:13 +0200
schrieb "Bezdeka, Florian (T RDA IOT SES-DE)"
:

> Hi!
> 
> While porting a simple application to Xenomai I had some problems
> related to the xeno-config tool:
> 
> xeno-config is part of the xenomai-runtime package when installing
> xenomai using the debian packages. I guess that's a packaging bug and
> it should be located in libxenomai-dev. Calling xeno-config having
> xenomai-runtime installed but not libxenomai-dev fails because of
> unmet dependencies.

I guess xeno-config should move into libxenomai-dev.

> While preparing a patch for that I noticed that we have documented
> "/usr/xenomai/bin/xeno-config" as path to xeno-config in the project
> wiki while debian packages install to "/usr/bin/xeno-config"
> 
> "/usr/xenomai/bin" is correct in case someone used scripts/maint/test-
> xeno-test.rb. Which path should be documented in the wiki?

Not sure that is a big issue, probably has to do with configure arg
--prefix which is non-default in the debian package. If that script is
part of any of the packages and contains absolute paths, is should
probably take the prefix into consideration.

Henning

> Best regards,
> Florian
> 
> --
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux

Re: [Dovetail] x86 test version available (kernel v5.10)

[Henning Schild via Xenomai]

Am Fri, 12 Mar 2021 20:46:30 +0100
schrieb Henning Schild :

> Am Fri, 12 Mar 2021 19:18:14 +0100
> schrieb Henning Schild via Xenomai :
> 
> > Am Fri, 12 Mar 2021 12:32:54 +0100
> > schrieb Jan Kiszka :
> >   
> > > On 12.03.21 08:22, Jan Kiszka wrote:    
> > > > On 11.03.21 17:35, Henning Schild wrote:  
> > > >> Am Mon, 22 Feb 2021 16:35:30 +0100
> > > >> schrieb Henning Schild via Xenomai :
> > > >>  
> > > >>> Am Sun, 31 Jan 2021 17:06:21 +0100
> > > >>> schrieb Philippe Gerum via Xenomai :
> > > >>>  
> > > >>>> The initial port of the Cobalt core to Dovetail/x86 is
> > > >>>> available from [1]. Ports to Dovetail/ARM and Dovetail/arm64
> > > >>>> should follow within a couple of weeks.
> > > >>>>
> > > >>>> So far, latency and switchtest run flawlessly. Most of the
> > > >>>> smokey test suite passes successfully, except the GDB test at
> > > >>>> the moment.
> > > >>>>
> > > >>>> How to test this:
> > > >>>>
> > > >>>> - clone Xenomai from [1], switch to branch
> > > >>>> for-upstream/dovetail
> > > >>>> - clone the Dovetail tree (v5.10) from [2], switch to branch
> > > >>>> dovetail/master
> > > >>>> - run scripts/prepare-kernel.sh available from [1] into [2]
> > > >>>> (usual procedure) for x86, that would be:
> > > >>>> .../scripts/prepare-kernel.sh --arch=x86
> > > >>>> - build your kernel using the sources from [2]
> > > >>>
> > > >>> I followed this and got
> > > >>>
> > > >>> 0625b829450dab22b2eea860eef4fb94f64af4fd
> > > >>> 61769e49d82a6775f6eb259bdc16c2f84df79505
> > > >>>
> > > >>>  
> > > >>>> There is no user-visible Kconfig change compared to an I-pipe
> > > >>>> based version.
> > > >>>
> > > >>> took a 4.19 x86_64 savedefconfig in via olddefconfig
> > > >>>  
> > > >>>> Alternatively, the Xenomai code base in [1] can also run on
> > > >>>> top of the I-pipe. prepare-kernel.sh detects which pipeline
> > > >>>> flavour is there, and prepares the source tree accordingly.
> > > >>>>
> > > >>>> This code is being gradually merged into Xenomai's -next
> > > >>>> branch, and will be at the core of Xenomai 3.2. Testing and
> > > >>>> feedback appreciated.
> > > >>>
> > > >>> Now i get a BUG pretty early on during boot. Since my config
> > > >>> still seems off i could not yet enter my rootfs, probably some
> > > >>> drivers/filesystems/raid switches got lost ...
> > > >>>
> > > >>> Its a null pointer deref in kmem_cache_alloc, coming somewhere
> > > >>> from mempool_init_node
> > > >>>
> > > >>> First guess was that "numa=off" would hide the problem, seems
> > > >>> it does. So my next guess is that even a qemu with numa could
> > > >>> reproduce this ... probably almost on a random config ... as
> > > >>> long as it has smp+numa  
> > > >>
> > > >> It is not about numa, now also see that on qemu. Jan looks into
> > > >> it at the moment.
> > > >>  
> > > > 
> > > > I'm suspecting an upstream issue. The bug is some freelist
> > > > corruption, possibly only surfaced by dovetail. After digging
> > > > longer, I enabled CONFIG_SLAB_FREELIST_HARDENED, and that gave
> > > > 
> > > > [0.159611] ACPI Error: Could not remove SCI handler
> > > > (20210105/evmisc-251)
> > > > [0.160188] [ cut here ]
> > > > [0.160566] cache_from_obj: Wrong slab cache.
> > > > ftrace_event_field but object is from kmalloc-64
> > > > 
> > > > and more. However: You get those bugs also from running latest
> > > > 5.10.23 and even Linus' master. Will debug that further and then
> > > > possibly report upstream.  
> > > 
> > > This is a corner case of upstream (but still a bug there):
> > > 
> > > Your config lost CONFIG_PCI, likely because it is no longer
> > > default y. That not only generates and unbootable systems, it
> > > also sends the ACPI subsystem into an error path. There it seems
> > > to release objects to the wrong caches, leading to corruptions
> > > later on. Enabling PCI resolves all this.
> > > 
> > > I'll dump the config to upstream ACPI folks, should be their
> > > business.
> > 
> > Thanks Jan!
> >   
> > > Jan
> > > 
> > > PS: Your config has more issues as it does not even boot in QEMU,
> > > even with PCI enabled. You should (re-)derive from
> > > x86_64-defconfig.
> > 
> > Yes that was CI progressing with "olddefconfig" from a 4.19
> > "savedefconfig". No human took a closer look at the result, before
> > you. But hey that might fix an upstream bug so it was a good
> > exercise anyhow.  
> 
> Looking much better with a changed config. AFAIK the gdb test from
> smokey is known to fail at the moment. Should that be marked as "skip"
> mainline to reduce downstream skipping fixups?

Related to that ...

smokey --run --keep-going

does not keep-going on gdb, one needs

smokey --run --exclude gdb --keep-going

Henning

> Henning
> 
> > Henning 
> > 
> >   
> 

Re: [Dovetail] x86 test version available (kernel v5.10)

[Henning Schild via Xenomai]

Am Fri, 12 Mar 2021 19:18:14 +0100
schrieb Henning Schild via Xenomai :

> Am Fri, 12 Mar 2021 12:32:54 +0100
> schrieb Jan Kiszka :
> 
> > On 12.03.21 08:22, Jan Kiszka wrote:  
> > > On 11.03.21 17:35, Henning Schild wrote:
> > >> Am Mon, 22 Feb 2021 16:35:30 +0100
> > >> schrieb Henning Schild via Xenomai :
> > >>
> > >>> Am Sun, 31 Jan 2021 17:06:21 +0100
> > >>> schrieb Philippe Gerum via Xenomai :
> > >>>
> > >>>> The initial port of the Cobalt core to Dovetail/x86 is
> > >>>> available from [1]. Ports to Dovetail/ARM and Dovetail/arm64
> > >>>> should follow within a couple of weeks.
> > >>>>
> > >>>> So far, latency and switchtest run flawlessly. Most of the
> > >>>> smokey test suite passes successfully, except the GDB test at
> > >>>> the moment.
> > >>>>
> > >>>> How to test this:
> > >>>>
> > >>>> - clone Xenomai from [1], switch to branch
> > >>>> for-upstream/dovetail
> > >>>> - clone the Dovetail tree (v5.10) from [2], switch to branch
> > >>>> dovetail/master
> > >>>> - run scripts/prepare-kernel.sh available from [1] into [2]
> > >>>> (usual procedure) for x86, that would be:
> > >>>> .../scripts/prepare-kernel.sh --arch=x86
> > >>>> - build your kernel using the sources from [2]  
> > >>>
> > >>> I followed this and got
> > >>>
> > >>> 0625b829450dab22b2eea860eef4fb94f64af4fd
> > >>> 61769e49d82a6775f6eb259bdc16c2f84df79505
> > >>>
> > >>>
> > >>>> There is no user-visible Kconfig change compared to an I-pipe
> > >>>> based version.  
> > >>>
> > >>> took a 4.19 x86_64 savedefconfig in via olddefconfig
> > >>>
> > >>>> Alternatively, the Xenomai code base in [1] can also run on top
> > >>>> of the I-pipe. prepare-kernel.sh detects which pipeline flavour
> > >>>> is there, and prepares the source tree accordingly.
> > >>>>
> > >>>> This code is being gradually merged into Xenomai's -next
> > >>>> branch, and will be at the core of Xenomai 3.2. Testing and
> > >>>> feedback appreciated.  
> > >>>
> > >>> Now i get a BUG pretty early on during boot. Since my config
> > >>> still seems off i could not yet enter my rootfs, probably some
> > >>> drivers/filesystems/raid switches got lost ...
> > >>>
> > >>> Its a null pointer deref in kmem_cache_alloc, coming somewhere
> > >>> from mempool_init_node
> > >>>
> > >>> First guess was that "numa=off" would hide the problem, seems it
> > >>> does. So my next guess is that even a qemu with numa could
> > >>> reproduce this ... probably almost on a random config ... as
> > >>> long as it has smp+numa
> > >>
> > >> It is not about numa, now also see that on qemu. Jan looks into
> > >> it at the moment.
> > >>
> > > 
> > > I'm suspecting an upstream issue. The bug is some freelist
> > > corruption, possibly only surfaced by dovetail. After digging
> > > longer, I enabled CONFIG_SLAB_FREELIST_HARDENED, and that gave
> > > 
> > > [0.159611] ACPI Error: Could not remove SCI handler
> > > (20210105/evmisc-251)
> > > [0.160188] [ cut here ]
> > > [0.160566] cache_from_obj: Wrong slab cache.
> > > ftrace_event_field but object is from kmalloc-64
> > > 
> > > and more. However: You get those bugs also from running latest
> > > 5.10.23 and even Linus' master. Will debug that further and then
> > > possibly report upstream.
> > 
> > This is a corner case of upstream (but still a bug there):
> > 
> > Your config lost CONFIG_PCI, likely because it is no longer default
> > y. That not only generates and unbootable systems, it also sends
> > the ACPI subsystem into an error path. There it seems to release
> > objects to the wrong caches, leading to corruptions later on.
> > Enabling PCI resolves all this.
> > 
> > I'll dump the config to upstream ACPI folks, should be their
> > business.  
> 
> Thanks Jan!
> 
> > Jan
> > 
> > PS: Your config has more issues as it does not even boot in QEMU,
> > even with PCI enabled. You should (re-)derive from
> > x86_64-defconfig.  
> 
> Yes that was CI progressing with "olddefconfig" from a 4.19
> "savedefconfig". No human took a closer look at the result, before
> you. But hey that might fix an upstream bug so it was a good exercise
> anyhow.

Looking much better with a changed config. AFAIK the gdb test from
smokey is known to fail at the moment. Should that be marked as "skip"
mainline to reduce downstream skipping fixups?

Henning

> Henning 
> 
> 

Re: [Dovetail] x86 test version available (kernel v5.10)

[Henning Schild via Xenomai]

Am Fri, 12 Mar 2021 12:32:54 +0100
schrieb Jan Kiszka :

> On 12.03.21 08:22, Jan Kiszka wrote:
> > On 11.03.21 17:35, Henning Schild wrote:  
> >> Am Mon, 22 Feb 2021 16:35:30 +0100
> >> schrieb Henning Schild via Xenomai :
> >>  
> >>> Am Sun, 31 Jan 2021 17:06:21 +0100
> >>> schrieb Philippe Gerum via Xenomai :
> >>>  
> >>>> The initial port of the Cobalt core to Dovetail/x86 is available
> >>>> from [1]. Ports to Dovetail/ARM and Dovetail/arm64 should follow
> >>>> within a couple of weeks.
> >>>>
> >>>> So far, latency and switchtest run flawlessly. Most of the smokey
> >>>> test suite passes successfully, except the GDB test at the
> >>>> moment.
> >>>>
> >>>> How to test this:
> >>>>
> >>>> - clone Xenomai from [1], switch to branch for-upstream/dovetail
> >>>> - clone the Dovetail tree (v5.10) from [2], switch to branch
> >>>> dovetail/master
> >>>> - run scripts/prepare-kernel.sh available from [1] into [2]
> >>>> (usual procedure) for x86, that would be:
> >>>> .../scripts/prepare-kernel.sh --arch=x86
> >>>> - build your kernel using the sources from [2]
> >>>
> >>> I followed this and got
> >>>
> >>> 0625b829450dab22b2eea860eef4fb94f64af4fd
> >>> 61769e49d82a6775f6eb259bdc16c2f84df79505
> >>>
> >>>  
> >>>> There is no user-visible Kconfig change compared to an I-pipe
> >>>> based version.
> >>>
> >>> took a 4.19 x86_64 savedefconfig in via olddefconfig
> >>>  
> >>>> Alternatively, the Xenomai code base in [1] can also run on top
> >>>> of the I-pipe. prepare-kernel.sh detects which pipeline flavour
> >>>> is there, and prepares the source tree accordingly.
> >>>>
> >>>> This code is being gradually merged into Xenomai's -next branch,
> >>>> and will be at the core of Xenomai 3.2. Testing and feedback
> >>>> appreciated.
> >>>
> >>> Now i get a BUG pretty early on during boot. Since my config still
> >>> seems off i could not yet enter my rootfs, probably some
> >>> drivers/filesystems/raid switches got lost ...
> >>>
> >>> Its a null pointer deref in kmem_cache_alloc, coming somewhere
> >>> from mempool_init_node
> >>>
> >>> First guess was that "numa=off" would hide the problem, seems it
> >>> does. So my next guess is that even a qemu with numa could
> >>> reproduce this ... probably almost on a random config ... as long
> >>> as it has smp+numa  
> >>
> >> It is not about numa, now also see that on qemu. Jan looks into it
> >> at the moment.
> >>  
> > 
> > I'm suspecting an upstream issue. The bug is some freelist
> > corruption, possibly only surfaced by dovetail. After digging
> > longer, I enabled CONFIG_SLAB_FREELIST_HARDENED, and that gave
> > 
> > [0.159611] ACPI Error: Could not remove SCI handler
> > (20210105/evmisc-251)
> > [0.160188] [ cut here ]
> > [0.160566] cache_from_obj: Wrong slab cache. ftrace_event_field
> > but object is from kmalloc-64
> > 
> > and more. However: You get those bugs also from running latest
> > 5.10.23 and even Linus' master. Will debug that further and then
> > possibly report upstream.  
> 
> This is a corner case of upstream (but still a bug there):
> 
> Your config lost CONFIG_PCI, likely because it is no longer default y.
> That not only generates and unbootable systems, it also sends the ACPI
> subsystem into an error path. There it seems to release objects to the
> wrong caches, leading to corruptions later on. Enabling PCI resolves
> all this.
> 
> I'll dump the config to upstream ACPI folks, should be their business.

Thanks Jan!

> Jan
> 
> PS: Your config has more issues as it does not even boot in QEMU, even
> with PCI enabled. You should (re-)derive from x86_64-defconfig.

Yes that was CI progressing with "olddefconfig" from a 4.19
"savedefconfig". No human took a closer look at the result, before you.
But hey that might fix an upstream bug so it was a good exercise
anyhow.

Henning 

Re: [Dovetail] x86 test version available (kernel v5.10)

[Henning Schild via Xenomai]

Am Mon, 22 Feb 2021 16:35:30 +0100
schrieb Henning Schild via Xenomai :

> Am Sun, 31 Jan 2021 17:06:21 +0100
> schrieb Philippe Gerum via Xenomai :
> 
> > The initial port of the Cobalt core to Dovetail/x86 is available
> > from [1]. Ports to Dovetail/ARM and Dovetail/arm64 should follow
> > within a couple of weeks.
> > 
> > So far, latency and switchtest run flawlessly. Most of the smokey
> > test suite passes successfully, except the GDB test at the moment.
> > 
> > How to test this:
> > 
> > - clone Xenomai from [1], switch to branch for-upstream/dovetail
> > - clone the Dovetail tree (v5.10) from [2], switch to branch
> > dovetail/master
> > - run scripts/prepare-kernel.sh available from [1] into [2] (usual
> > procedure) for x86, that would be: .../scripts/prepare-kernel.sh
> > --arch=x86
> > - build your kernel using the sources from [2]  
> 
> I followed this and got
> 
> 0625b829450dab22b2eea860eef4fb94f64af4fd
> 61769e49d82a6775f6eb259bdc16c2f84df79505
> 
> 
> > There is no user-visible Kconfig change compared to an I-pipe based
> > version.  
> 
> took a 4.19 x86_64 savedefconfig in via olddefconfig
> 
> > Alternatively, the Xenomai code base in [1] can also run on top of
> > the I-pipe. prepare-kernel.sh detects which pipeline flavour is
> > there, and prepares the source tree accordingly.
> > 
> > This code is being gradually merged into Xenomai's -next branch, and
> > will be at the core of Xenomai 3.2. Testing and feedback
> > appreciated.  
> 
> Now i get a BUG pretty early on during boot. Since my config still
> seems off i could not yet enter my rootfs, probably some
> drivers/filesystems/raid switches got lost ...
> 
> Its a null pointer deref in kmem_cache_alloc, coming somewhere from
> mempool_init_node
> 
> First guess was that "numa=off" would hide the problem, seems it does.
> So my next guess is that even a qemu with numa could reproduce this
> ... probably almost on a random config ... as long as it has smp+numa

It is not about numa, now also see that on qemu. Jan looks into it at
the moment.

Henning

> I do not have more at the moment, but there seem to be issues around
> NUMA.
> 
> regards,
> Henning
> 
> > Thanks,
> > 
> > [1] https://lab.xenomai.org/xenomai-rpm.git, "for-upstream/dovetail"
> > branch [2] https://git.evlproject.org/linux-evl.git,
> > "dovetail/master" branch
> >   
> 
> 

Re: [IMPORTANT] gitlab relocation / rename

[Henning Schild via Xenomai]

Am Wed, 10 Mar 2021 08:56:48 +0100
schrieb Wolfgang Denk :

> Dear Henning,
> 
> In message <20210308083457.76db0...@md1za8fc.ad001.siemens.net> you
> wrote:
> >
> > I do not understand why this is not just gitlab (proper) or github.
> > I hope this discussion was held with the communities of the affected
> > projects involved. While being disruptive i would suggest for
> > Xenomai to move away from denx. For the git side of the operations.
> > To be more open and welcoming to users/contributers etc.  
> 
> Are you positively sure that moving to any otherhosting environment
> will have any positive effect on how the Xenomai community works?

I am not sure. But i would be willing to give it a try. Sitting on a
platform that is open to everyone means we might see "stars",
"fork-relationships" etc. We might have to close issues and MRs with
ever repeating ... "please use ML". But at that point you are already
talking to someone who used the easy collaboration effects to
drive-by/random interact. And chances are high you get them onto the ML,
we see this in other projects where we keep PRs and issues enabled even
though we do not "use them". 

> We use the very same setup for U-Boot as well, which has a _much_
> bigger and _much_ more active community.  We have regular releases
> every 3 months, and most releases include commits from >200
> developers from >30 employers.  And the CI setup for U-Boot is in no
> respect (number of supported architectures / processors / boards /
> tool chains) less challenging than what you do in Xenomai, on
> contrary.  Not to mention the development rate - U-Boot sees > 20
> commits per day in mainline.

Xenomai does not have such a strong community, a point that needs to
improve. Putting it on a social coding platform (probably in addition),
where people can socialize could help. In a private gitlab social
interaction is pretty limited, especially with a strict bouncer
rejecting people that are invited to the party ;).

CI/CT needs mean a hoster is more than a storage of code, and also
means that more stakeholders need access. Many public hosters give
compute+storage away for free. Plus free code-coverage, style checking
with commercial tools ... Good stuff. Stuff that any project can
benefit from, just put a "mirror fork" on github, no offense to the
main hoster ... they can stay.

> Sorry, but I don't buy your "more open and welcoming to users/contri-
> buters" comment.  THe existing environment has proven to work fine
> for a FOSS community project.

Maybe you know now.

regards,
Henning 

> Best regards,
> 
> Wolfgang Denk
> 

Re: [IMPORTANT] gitlab relocation / rename

[Henning Schild via Xenomai]

Am Sun, 28 Feb 2021 16:14:55 +0100
schrieb Wolfgang Denk via Xenomai :

> Hi all,
> 
> In message <621240.1614155...@gemini.denx.de> I wrote:
> >
> > We have to move all public projects off  gitlab.denx.de  to a new
> > gitlab instance; the new host name is then  source.denx.de .
> > We are fully aware that this will cause inconveniences, and I can
> > only assure you that we try hard to keep these as limited as
> > possible.
> >
> > # Details
> >
> > Around noon on Saturday, 2021-02-27, we will freeze all public
> > repositories on gitlab.denx.de.  They will still be readable/
> > cloneable but any attempt to push new commits after this point will
> > fail.
> >
> > We will then copy them over to the now host, source.denx.de .
> > All custodian accounts will also be transferred, the same login
> > credentials from gitlab.denx.de will work on source.denx.de .
> >
> > The URLs for the repositories will stay the same, except of course
> > for the host name.  So, for example, the U-Boot mainline repository
> > will then be hosted at
> >
> > https://source.denx.de/u-boot/u-boot.git
> >
> > We will install redirects to forward HTTP accesses from the old
> > repository URLs to the new host.  This should make the transition
> > mostly transparent, but does not cover everything.  The following
> > needs to be taken care of manually:
> >
> > - Update the SSH URI for pushing to the repositories.  Just replace
> >   gitlab.denx.de  with  source.denx.de .  We will transfer all the
> >   SSH-keys to the new host so nothing else should be needed.
> >
> > - Make sure you're logging in on  source.denx.de .  Access to
> >   gitlab.denx.de  will no longer work!
> >
> > - CI runners connected to  gitlab.denx.de  need to be re-registered
> >   with  source.denx.de .
> >
> > The new host should hopefully be operational sometime on Sunday,
> > 2021-02-28.  We will send a further announcement once everything is
> > back up and running.  
> 
> As far as we were able to test it, the move has been completed and
> is fully functional again.  All public project are now on the new
> gitlab instance  source.denx.de

One fun side-effect is that pulling via ssh also does not work anymore.
Because it seems account have been fully deleted. This mail did not
make it to my inbox because it was only sent to a list i happen to read
sometimes.
It would have been nice to receive my own copy with me actually in
"To:". Would have saved me a bit of time trying to understand what is
wrong. Luckily i remembered the "New developer accounts on
source.denx.de" mail from last week, where that URL seemed strange when
i first read it.

I do not understand why this is not just gitlab (proper) or github. I
hope this discussion was held with the communities of the affected
projects involved. While being disruptive i would suggest for Xenomai
to move away from denx. For the git side of the operations. To be more
open and welcoming to users/contributers etc.

regards,
Henning

> If you should experience any problems, please do not hesitate to ask 
> Harald Seiler , he will try to help you.
> 
> Thanks for your patience!
> 
> Best regards,
> 
> Wolfgang Denk
> 

Re: [PATCH 4.19] ipipe: mm: Restore unCOW support for copy_pte_range

[Henning Schild via Xenomai]

Am Sat, 6 Mar 2021 14:14:30 +0100
schrieb Jan Kiszka via Xenomai :

> On 05.03.21 12:38, Jan Kiszka via Xenomai wrote:
> > From: Jan Kiszka 
> > 
> > This is still needed to avoid that a real-time parent seems minor
> > faults after forking for shared pages until they are finally
> > unshared.
> > 
> > This missing support became visible in Xenomai when running the
> > complete smokey test suite on certain architectures/config
> > combinations.
> > 
> > Fixes: 0f0b6099c45f ("ipipe: mm: Drop un-COW from copy_pte_range")
> > Signed-off-by: Jan Kiszka 
> > ---
> > 
> > For discussion. If there is a better pattern in reach, I'm happy to
> > go that path as well.
> > 
> > Otherwise, this should go into our 4.19 branches (Greg, your arm64
> > isn't in sync with noarch, you will need manual merging). Possibly,
> > it already applies to 5.4 as well, didn't check yet.
> > 
> >  mm/memory.c | 76
> > - 1 file
> > changed, 69 insertions(+), 7 deletions(-)
> > 
> > diff --git a/mm/memory.c b/mm/memory.c
> > index 4cc7c72a0b7e..f102f4de2213 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -141,6 +141,9 @@ EXPORT_SYMBOL(zero_pfn);
> >  
> >  unsigned long highest_memmap_pfn __read_mostly;
> >  
> > +static bool cow_user_page(struct page *dst, struct page *src,
> > + struct vm_fault *vmf);
> > +
> >  /*
> >   * CONFIG_MMU architectures set up ZERO_PAGE in their paging_init()
> >   */
> > @@ -957,8 +960,9 @@ struct page *vm_normal_page_pmd(struct
> > vm_area_struct *vma, unsigned long addr, 
> >  static inline unsigned long
> >  copy_one_pte(struct mm_struct *dst_mm, struct mm_struct *src_mm,
> > -   pte_t *dst_pte, pte_t *src_pte, struct
> > vm_area_struct *vma,
> > -   unsigned long addr, int *rss)
> > +pte_t *dst_pte, pte_t *src_pte, struct vm_area_struct
> > *vma,
> > +unsigned long addr, int *rss, pmd_t *src_pmd,
> > +struct page *uncow_page)
> >  {
> > unsigned long vm_flags = vma->vm_flags;
> > pte_t pte = *src_pte;
> > @@ -1036,6 +1040,33 @@ copy_one_pte(struct mm_struct *dst_mm,
> > struct mm_struct *src_mm,
> >  * in the parent and the child
> >  */
> > if (is_cow_mapping(vm_flags) && pte_write(pte)) {
> > +#ifdef CONFIG_IPIPE
> > +   if (uncow_page) {
> > +   struct page *old_page =
> > vm_normal_page(vma, addr, pte);
> > +   struct vm_fault vmf;
> > +
> > +   vmf.vma = vma;
> > +   vmf.address = addr;
> > +   vmf.orig_pte = pte;
> > +   vmf.pmd = src_pmd;
> > +
> > +   if (cow_user_page(uncow_page, old_page,
> > &vmf)) {
> > +   pte = mk_pte(uncow_page,
> > vma->vm_page_prot); +
> > +   if (vm_flags & VM_SHARED)
> > +   pte = pte_mkclean(pte);
> > +   pte = pte_mkold(pte);
> > +
> > +   page_add_new_anon_rmap(uncow_page,
> > vma, addr,
> > +  false);
> > +   rss[!!PageAnon(uncow_page)]++;
> > +   goto out_set_pte;
> > +   } else {
> > +   /* unexpected: source page no
> > longer present */
> > +   WARN_ON_ONCE(1);
> > +   }
> > +   }
> > +#endif /* CONFIG_IPIPE */
> > ptep_set_wrprotect(src_mm, addr, src_pte);
> > pte = pte_wrprotect(pte);
> > }
> > @@ -1083,13 +1114,27 @@ static int copy_pte_range(struct mm_struct
> > *dst_mm, struct mm_struct *src_mm, int progress = 0;
> > int rss[NR_MM_COUNTERS];
> > swp_entry_t entry = (swp_entry_t){0};
> > -
> > +   struct page *uncow_page = NULL;
> > +#ifdef CONFIG_IPIPE
> > +   int do_cow_break = 0;
> > +again:
> > +   if (do_cow_break) {
> > +   uncow_page = alloc_page_vma(GFP_HIGHUSER, vma,
> > addr);
> > +   if (uncow_page == NULL)
> > +   return -ENOMEM;
> > +   do_cow_break = 0;
> > +   }
> > +#else
> >  again:
> > +#endif
> > init_rss_vec(rss);
> >  
> > dst_pte = pte_alloc_map_lock(dst_mm, dst_pmd, addr,
> > &dst_ptl);
> > -   if (!dst_pte)
> > +   if (!dst_pte) {
> > +   if (uncow_page)
> > +   put_page(uncow_page);
> > return -ENOMEM;
> > +   }
> > src_pte = pte_offset_map(src_pmd, addr);
> > src_ptl = pte_lockptr(src_mm, src_pmd);
> > spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING);
> > @@ -1112,8 +1157,25 @@ static int copy_pte_range(struct mm_struct
> > *dst_mm, struct mm_struct *src_mm, progress++;
> > continue;
> > }
> > +#ifdef CONFIG_IPIPE
> > +   if (likely(uncow_page == NULL) &&
> > likely(pte_present(*src_pte))) {
> > +   if (is_cow_mapping(vma->vm_flags) &&
> > +   test_bit(MMF_VM_PINN

Re: [I-PIPE] ipipe-core-4.19.165-cip41-arm64-09 released

[Henning Schild via Xenomai]

Am Wed, 24 Feb 2021 11:24:55 +0100
schrieb Henning Schild via Xenomai :

> Am Wed, 10 Feb 2021 12:08:43 +0100
> schrieb Jan Kiszka via Xenomai :
> 
> > On 10.02.21 11:07, Bezdeka, Florian (T RDA IOT SES-DE) wrote:  
> > > On Wed, 2021-02-10 at 09:15 +0100, Jan Kiszka via Xenomai wrote:
> > >   
> > >> On 10.02.21 07:22, xenomai--- via Xenomai wrote:
> > >>> Download URL:
> > >>> https://xenomai.org/downloads/ipipe/v4.x/arm64/ipipe-core-4.19.165-cip41-arm64-09.patch
> > >>>
> > >>> Repository: https://git.xenomai.org/ipipe-arm64
> > >>> Release tag: ipipe-core-4.19.165-cip41-arm64-09
> > >>>
> > >>
> > >> Hmm, now we have the 5.4-arm64 issue also on 4.19:
> > >> https://gitlab.denx.de/Xenomai/xenomai-images/-/jobs/219984
> > >>
> > > 
> > > I don't know much about the things going on here, but found this
> > > line in the log. Maybe a starting point...
> > > 
> > > 2021-02-10T07:51:47 setsched.c:120, assertion failed: stats.msw ==
> > > msw   
> > 
> > Exactly, that is causing the overall failure. And it was first seen
> > with the newly added 5.4 kernel.  
> 
> Seing the same on amd64 when testing on qemu, real HW is fine.
> 
> Managed to bisect it down to 4.19.147-cip (good) 4.19.150-cip (bad)
> 
> Which also means that ipipe-core-4.19.152-cip37-x86-15 is affected.
> 
> https://gitlab.denx.de/Xenomai/xenomai-images/-/jobs/200646
> did not find it, so maybe our config differs

Digging further i found 0f0b6099c45ff3e06d2487816cf1ff30d21835f6 likely
causing the problem.

ipipe-core-4.19.152-cip37-x86-15 <- bad
revert 2b294ac325c7ce3f36854b74d0d1d89dc1d1d8b8
revert 8579a0440381353e0a71dd6a4d4371be8457eac4 <- bad
revert 0f0b6099c45ff3e06d2487816cf1ff30d <- good

I think here Jan or Phillipe should take over.

Henning

> Henning
> 
> > Jan
> >   
> > > 
> > >> Guess we need to understand this next now, specifically as it
> > >> "spreads".
> > >>
> > >> Jan
> > >>
> > > 
> >   
> 
> 

Re: [I-PIPE] ipipe-core-4.19.165-cip41-arm64-09 released

[Henning Schild via Xenomai]

Am Wed, 10 Feb 2021 12:08:43 +0100
schrieb Jan Kiszka via Xenomai :

> On 10.02.21 11:07, Bezdeka, Florian (T RDA IOT SES-DE) wrote:
> > On Wed, 2021-02-10 at 09:15 +0100, Jan Kiszka via Xenomai wrote:  
> >> On 10.02.21 07:22, xenomai--- via Xenomai wrote:  
> >>> Download URL:
> >>> https://xenomai.org/downloads/ipipe/v4.x/arm64/ipipe-core-4.19.165-cip41-arm64-09.patch
> >>>
> >>> Repository: https://git.xenomai.org/ipipe-arm64
> >>> Release tag: ipipe-core-4.19.165-cip41-arm64-09
> >>>  
> >>
> >> Hmm, now we have the 5.4-arm64 issue also on 4.19:
> >> https://gitlab.denx.de/Xenomai/xenomai-images/-/jobs/219984
> >>  
> > 
> > I don't know much about the things going on here, but found this
> > line in the log. Maybe a starting point...
> > 
> > 2021-02-10T07:51:47 setsched.c:120, assertion failed: stats.msw ==
> > msw 
> 
> Exactly, that is causing the overall failure. And it was first seen
> with the newly added 5.4 kernel.

Seing the same on amd64 when testing on qemu, real HW is fine.

Managed to bisect it down to 4.19.147-cip (good) 4.19.150-cip (bad)

Which also means that ipipe-core-4.19.152-cip37-x86-15 is affected.

https://gitlab.denx.de/Xenomai/xenomai-images/-/jobs/200646
did not find it, so maybe our config differs

Henning

> Jan
> 
> >   
> >> Guess we need to understand this next now, specifically as it
> >> "spreads".
> >>
> >> Jan
> >>  
> >   
> 

Re: [Dovetail] x86 test version available (kernel v5.10)

[Henning Schild via Xenomai]

Am Mon, 22 Feb 2021 16:35:30 +0100
schrieb Henning Schild via Xenomai :

> Am Sun, 31 Jan 2021 17:06:21 +0100
> schrieb Philippe Gerum via Xenomai :
> 
> > The initial port of the Cobalt core to Dovetail/x86 is available
> > from [1]. Ports to Dovetail/ARM and Dovetail/arm64 should follow
> > within a couple of weeks.
> > 
> > So far, latency and switchtest run flawlessly. Most of the smokey
> > test suite passes successfully, except the GDB test at the moment.
> > 
> > How to test this:
> > 
> > - clone Xenomai from [1], switch to branch for-upstream/dovetail
> > - clone the Dovetail tree (v5.10) from [2], switch to branch
> > dovetail/master
> > - run scripts/prepare-kernel.sh available from [1] into [2] (usual
> > procedure) for x86, that would be: .../scripts/prepare-kernel.sh
> > --arch=x86
> > - build your kernel using the sources from [2]  
> 
> I followed this and got
> 
> 0625b829450dab22b2eea860eef4fb94f64af4fd
> 61769e49d82a6775f6eb259bdc16c2f84df79505
> 
> 
> > There is no user-visible Kconfig change compared to an I-pipe based
> > version.  
> 
> took a 4.19 x86_64 savedefconfig in via olddefconfig
> 
> > Alternatively, the Xenomai code base in [1] can also run on top of
> > the I-pipe. prepare-kernel.sh detects which pipeline flavour is
> > there, and prepares the source tree accordingly.
> > 
> > This code is being gradually merged into Xenomai's -next branch, and
> > will be at the core of Xenomai 3.2. Testing and feedback
> > appreciated.  
> 
> Now i get a BUG pretty early on during boot. Since my config still
> seems off i could not yet enter my rootfs, probably some
> drivers/filesystems/raid switches got lost ...
> 
> Its a null pointer deref in kmem_cache_alloc, coming somewhere from
> mempool_init_node
> 
> First guess was that "numa=off" would hide the problem, seems it does.
> So my next guess is that even a qemu with numa could reproduce this
> ... probably almost on a random config ... as long as it has smp+numa

Tried that again, it is not 100% reproducible ... "numa=off" does not
solve the issue.

I did try the dovetail bits of xenomai-images 5.10 together with a
numa-qemu ... that works.

qemu-system-x86_64 -drive
file=./build/tmp/deploy/images/qemu-amd64/demo-image-xenomai-demo-qemu-amd64.ext4.img,discard=unmap,if=none,id=disk,format=raw
-serial mon:stdio -netdev user,id=net -kernel
./build/tmp/deploy/images/qemu-amd64/demo-image-xenomai-demo-qemu-amd64-vmlinuz
-append ' root=/dev/sda vga=0x305' -initrd
./build/tmp/deploy/images/qemu-amd64/demo-image-xenomai-demo-qemu-amd64-initrd.img
-cpu host -smp 4 -enable-kvm -machine q35 -device ide-hd,drive=disk
-device virtio-net-pci,netdev=net -object
memory-backend-ram,id=mem0,size=1G -object
memory-backend-ram,id=mem1,size=1G -numa
node,cpus=0-1,nodeid=0,memdev=mem0 -numa
node,cpus=2-3,nodeid=1,memdev=mem1 -m 2G

> I do not have more at the moment, but there seem to be issues around
> NUMA.

So maybe it is not NUMA, will keep digging.

Henning

> regards,
> Henning
> 
> > Thanks,
> > 
> > [1] https://lab.xenomai.org/xenomai-rpm.git, "for-upstream/dovetail"
> > branch [2] https://git.evlproject.org/linux-evl.git,
> > "dovetail/master" branch
> >   
> 
> 

Re: [Dovetail] x86 test version available (kernel v5.10)

[Henning Schild via Xenomai]

Am Sun, 31 Jan 2021 17:06:21 +0100
schrieb Philippe Gerum via Xenomai :

> The initial port of the Cobalt core to Dovetail/x86 is available from
> [1]. Ports to Dovetail/ARM and Dovetail/arm64 should follow within a
> couple of weeks.
> 
> So far, latency and switchtest run flawlessly. Most of the smokey test
> suite passes successfully, except the GDB test at the moment.
> 
> How to test this:
> 
> - clone Xenomai from [1], switch to branch for-upstream/dovetail
> - clone the Dovetail tree (v5.10) from [2], switch to branch
> dovetail/master
> - run scripts/prepare-kernel.sh available from [1] into [2] (usual
> procedure) for x86, that would be: .../scripts/prepare-kernel.sh
> --arch=x86
> - build your kernel using the sources from [2]

I followed this and got

0625b829450dab22b2eea860eef4fb94f64af4fd
61769e49d82a6775f6eb259bdc16c2f84df79505


> There is no user-visible Kconfig change compared to an I-pipe based
> version.

took a 4.19 x86_64 savedefconfig in via olddefconfig

> Alternatively, the Xenomai code base in [1] can also run on top of the
> I-pipe. prepare-kernel.sh detects which pipeline flavour is there, and
> prepares the source tree accordingly.
> 
> This code is being gradually merged into Xenomai's -next branch, and
> will be at the core of Xenomai 3.2. Testing and feedback appreciated.

Now i get a BUG pretty early on during boot. Since my config still
seems off i could not yet enter my rootfs, probably some
drivers/filesystems/raid switches got lost ...

Its a null pointer deref in kmem_cache_alloc, coming somewhere from
mempool_init_node

First guess was that "numa=off" would hide the problem, seems it does.
So my next guess is that even a qemu with numa could reproduce this ...
probably almost on a random config ... as long as it has smp+numa

I do not have more at the moment, but there seem to be issues around
NUMA.

regards,
Henning

> Thanks,
> 
> [1] https://lab.xenomai.org/xenomai-rpm.git, "for-upstream/dovetail"
> branch [2] https://git.evlproject.org/linux-evl.git,
> "dovetail/master" branch
> 

Re: [PATCH][4.19] x86: ipipe: Harden racy path in __fpu__restore_sig

[Henning Schild via Xenomai]

On Tue, 28 Jul 2020 17:53:10 +0200
Jan Kiszka  wrote:

> From: Jan Kiszka 
> 
> This is needed because I-pipe can interrupt at a point where
> fpu->initialized is already set but the (internally hardened)
> fpu__restore() was not run yet. As the context switch uses
> 'initialized' to decide whether to activate the FPU for the target
> thread, we may prematurely activate it.
> 
> Signed-off-by: Jan Kiszka 
> ---
> 
> I'm still struggling to find out what all could go wrong for us. The 
> patch originates from 4.4 where this missing protection triggers a 
> warning, and more was missing (https://lkml.org/lkml/2020/7/24/932).

LGTM, and i am afraid i have no clue what else could go wrong.

Henning

>  arch/x86/kernel/fpu/signal.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/x86/kernel/fpu/signal.c
> b/arch/x86/kernel/fpu/signal.c index d99a8ee9e185..ea846a28300a 100644
> --- a/arch/x86/kernel/fpu/signal.c
> +++ b/arch/x86/kernel/fpu/signal.c
> @@ -315,6 +315,7 @@ static int __fpu__restore_sig(void __user *buf,
> void __user *buf_fx, int size)
>* header. Validate and sanitize the copied state.
>*/
>   struct user_i387_ia32_struct env;
> + unsigned long flags;
>   int err = 0;
>  
>   /*
> @@ -345,8 +346,10 @@ static int __fpu__restore_sig(void __user *buf,
> void __user *buf_fx, int size) }
>  
>   local_bh_disable();
> + flags = hard_cond_local_irq_save();
>   fpu->initialized = 1;
>   fpu__restore(fpu);
> + hard_cond_local_irq_restore(flags);
>   local_bh_enable();
>  
>   return err;

Re: ipipe kernel image compile error

[Henning Schild via Xenomai]

Hi,

i do not know what that timer is or whether it is wise to choose it for
an ipipe kernel.

You can probably work around the issue by not setting CONFIG_APB_TIMER
in your kernel configuration. And my guess is that you will not be
missing any features. In order to reproduce the issue, your config
would be useful.

Henning

On Tue, 31 Mar 2020 14:42:45 -0700
C Smith via Xenomai  wrote:

> Hi,
> 
> I'm having a problem compiling Kernel 4.19.109 with
> ipipe-core-4.19.109-cip22-x86-11.patch using Xenomai-3.1.
> 
> $ scripts/prepare-kernel.sh --linux=../linux/
> --ipipe=../ipipe-core-4.19.109-cip22-x86-11.patch --arch=x86
> 
> I'm compiling with:
> $ m -j4 bzImage
> 
> I'm getting following error:
> 
> arch/x86/kernel/apb_timer.c: In function ‘apbt_set_mapping’:
> arch/x86/kernel/apb_timer.c:122:21: error: too few arguments to
> function ‘dw_apb_clocksource_init’
>   clocksource_apbt = dw_apb_clocksource_init(APBT_CLOCKSOURCE_RATING,
>  ^~~
> In file included from arch/x86/kernel/apb_timer.c:31:
> ./include/linux/dw_apb_timer.h:50:1: note: declared here
>  dw_apb_clocksource_init(unsigned rating, const char *name, void
> __iomem *base,
>  ^~~
> make[2]: *** [scripts/Makefile.build:303: arch/x86/kernel/apb_timer.o]
> Error 1
> make[1]: *** [scripts/Makefile.build:544: arch/x86/kernel] Error 2
> make[1]: *** Waiting for unfinished jobs
> 
> 
>  config_20200331
> 
> 
> 
> Thank you
> -- next part --
> A non-text attachment was scrubbed...
> Name: config_20200331
> Type: application/octet-stream
> Size: 208519 bytes
> Desc: not available
> URL:
> 

Re: [PATCH] libs: Add linking dependencies to libraries

[Henning Schild via Xenomai]

On Tue, 25 Feb 2020 15:33:45 +0100
Jan Kiszka  wrote:

> [adding the list]
> 
> On 25.02.20 15:32, Jan Kiszka wrote:
> > On 25.02.20 15:30, Henning Schild wrote:  
> >> I guess that is related to lds --(no-)as-needed which is different
> >> in the ubuntu toolchain. Back when i looked into it Ubuntu managed
> >> to patch the default behaviour but forgot to patch the man-pages ;)
> >>
> >> See
> >> https://gitlab.denx.de/Xenomai/xenomai/commit/83dea2ad712ee2d2137942c7ab9891da7d4ef841
> >>  
> >>
> >>
> >> Maybe this can actually be reverted after the proposed fix.  
> > 
> > If someone can validate that, I'm happy to do so...

That is why i pulled in Antoine again. He has a ubuntu setup and can
probably check whether applying your fix works, and reverting the other
one still works.

Henning

> > Jan
> >   
> >>
> >> Henning
> >>
> >> On Wed, 19 Feb 2020 13:31:29 +0100
> >> Jan Kiszka via Xenomai  wrote:
> >>  
> >>> From: Jan Kiszka 
> >>>
> >>> This ensures that no optimization will drop dependencies of our
> >>> shared objects, preventing to load them via dlopen without
> >>> explicitly loading those dropped dependencies first. See also
> >>> https://xenomai.org/pipermail/xenomai/2020-February/042449.html
> >>>
> >>> As trank now explicitly depends on alchemy, reorder the build to
> >>> ensure that the latter is available before the former is built
> >>> (analogy is only moved for consistency reasons).
> >>>
> >>> Reported-by: Antoine Hoarau 
> >>> Signed-off-by: Jan Kiszka 
> >>> ---
> >>>   lib/Makefile.am | 11 +++
> >>>   lib/alchemy/Makefile.am |  4 
> >>>   lib/analogy/Makefile.am |  2 ++
> >>>   lib/psos/Makefile.am    |  4 
> >>>   lib/trank/Makefile.am   |  4 
> >>>   lib/vxworks/Makefile.am |  4 
> >>>   6 files changed, 25 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/lib/Makefile.am b/lib/Makefile.am
> >>> index c927a9bd85..e909030564 100644
> >>> --- a/lib/Makefile.am
> >>> +++ b/lib/Makefile.am
> >>> @@ -1,10 +1,7 @@
> >>>   SUBDIRS = boilerplate
> >>>   if XENO_COBALT
> >>> -SUBDIRS +=    \
> >>> -    cobalt    \
> >>> -    analogy    \
> >>> -    trank
> >>> +SUBDIRS += cobalt
> >>>   else
> >>>   SUBDIRS += mercury
> >>>   endif
> >>> @@ -16,6 +13,12 @@ SUBDIRS +=    \
> >>>   vxworks    \
> >>>   psos
> >>> +if XENO_COBALT
> >>> +SUBDIRS += \
> >>> +    analogy    \
> >>> +    trank
> >>> +endif
> >>> +
> >>>   DIST_SUBDIRS = \
> >>>   alchemy    \
> >>>   analogy    \
> >>> diff --git a/lib/alchemy/Makefile.am b/lib/alchemy/Makefile.am
> >>> index 5362695ed2..f97bd69bf8 100644
> >>> --- a/lib/alchemy/Makefile.am
> >>> +++ b/lib/alchemy/Makefile.am
> >>> @@ -2,6 +2,10 @@ lib_LTLIBRARIES = libalchemy.la
> >>>   libalchemy_la_LDFLAGS = @XENO_LIB_LDFLAGS@ -version-info 0:0:0
> >>> +libalchemy_la_LIBADD =
> >>> \
> >>> +    @XENO_CORE_LDADD@    \
> >>> +    $(top_builddir)/lib/copperplate/libcopperplate.la
> >>> +
> >>>   libalchemy_la_SOURCES =    \
> >>>   init.c    \
> >>>   internal.c    \
> >>> diff --git a/lib/analogy/Makefile.am b/lib/analogy/Makefile.am
> >>> index e53d8a11ab..4c6f0de013 100644
> >>> --- a/lib/analogy/Makefile.am
> >>> +++ b/lib/analogy/Makefile.am
> >>> @@ -2,6 +2,8 @@ lib_LTLIBRARIES = libanalogy.la
> >>>   libanalogy_la_LDFLAGS = @XENO_LIB_LDFLAGS@ -version-info 1:0:0
> >>> -lm +libanalogy_la_LIBADD = @XENO_CORE_LDADD@
> >>> +
> >>>   libanalogy_la_SOURCES =    \
> >>>   async.c    \
> >>>   descriptor.c    \
> >>> diff --git a/lib/psos/Makefile.am b/lib/psos/Makefile.am
> >>> index 4eb7ad84ce..6fe50881cc 100644
> >>> --- a/lib/psos/Makefile.am
> >>> +++ b/lib/psos/Makefile.am
> >>> @@ -2,6 +2,10 @@ lib_LTLIBRARIES = libpsos.la
> >>>   libpsos_la_LDFLAGS = @XENO_LIB_LDFLAGS@ -version-info 0:0:0
&

Re: [PATCH] libs: Add linking dependencies to libraries

[Henning Schild via Xenomai]

I guess that is related to lds --(no-)as-needed which is different in
the ubuntu toolchain. Back when i looked into it Ubuntu managed to
patch the default behaviour but forgot to patch the man-pages ;)

See
https://gitlab.denx.de/Xenomai/xenomai/commit/83dea2ad712ee2d2137942c7ab9891da7d4ef841

Maybe this can actually be reverted after the proposed fix.

Henning

On Wed, 19 Feb 2020 13:31:29 +0100
Jan Kiszka via Xenomai  wrote:

> From: Jan Kiszka 
> 
> This ensures that no optimization will drop dependencies of our shared
> objects, preventing to load them via dlopen without explicitly loading
> those dropped dependencies first. See also
> https://xenomai.org/pipermail/xenomai/2020-February/042449.html
> 
> As trank now explicitly depends on alchemy, reorder the build to
> ensure that the latter is available before the former is built
> (analogy is only moved for consistency reasons).
> 
> Reported-by: Antoine Hoarau 
> Signed-off-by: Jan Kiszka 
> ---
>  lib/Makefile.am | 11 +++
>  lib/alchemy/Makefile.am |  4 
>  lib/analogy/Makefile.am |  2 ++
>  lib/psos/Makefile.am|  4 
>  lib/trank/Makefile.am   |  4 
>  lib/vxworks/Makefile.am |  4 
>  6 files changed, 25 insertions(+), 4 deletions(-)
> 
> diff --git a/lib/Makefile.am b/lib/Makefile.am
> index c927a9bd85..e909030564 100644
> --- a/lib/Makefile.am
> +++ b/lib/Makefile.am
> @@ -1,10 +1,7 @@
>  SUBDIRS = boilerplate
>  
>  if XENO_COBALT
> -SUBDIRS +=   \
> - cobalt  \
> - analogy \
> - trank
> +SUBDIRS += cobalt
>  else
>  SUBDIRS += mercury
>  endif
> @@ -16,6 +13,12 @@ SUBDIRS += \
>   vxworks \
>   psos
>  
> +if XENO_COBALT
> +SUBDIRS +=   \
> + analogy \
> + trank
> +endif
> +
>  DIST_SUBDIRS =   \
>   alchemy \
>   analogy \
> diff --git a/lib/alchemy/Makefile.am b/lib/alchemy/Makefile.am
> index 5362695ed2..f97bd69bf8 100644
> --- a/lib/alchemy/Makefile.am
> +++ b/lib/alchemy/Makefile.am
> @@ -2,6 +2,10 @@ lib_LTLIBRARIES = libalchemy.la
>  
>  libalchemy_la_LDFLAGS = @XENO_LIB_LDFLAGS@ -version-info 0:0:0
>  
> +libalchemy_la_LIBADD =
>   \
> + @XENO_CORE_LDADD@   \
> + $(top_builddir)/lib/copperplate/libcopperplate.la
> +
>  libalchemy_la_SOURCES =  \
>   init.c  \
>   internal.c  \
> diff --git a/lib/analogy/Makefile.am b/lib/analogy/Makefile.am
> index e53d8a11ab..4c6f0de013 100644
> --- a/lib/analogy/Makefile.am
> +++ b/lib/analogy/Makefile.am
> @@ -2,6 +2,8 @@ lib_LTLIBRARIES = libanalogy.la
>  
>  libanalogy_la_LDFLAGS = @XENO_LIB_LDFLAGS@ -version-info 1:0:0 -lm
>  
> +libanalogy_la_LIBADD = @XENO_CORE_LDADD@
> +
>  libanalogy_la_SOURCES =  \
>   async.c \
>   descriptor.c\
> diff --git a/lib/psos/Makefile.am b/lib/psos/Makefile.am
> index 4eb7ad84ce..6fe50881cc 100644
> --- a/lib/psos/Makefile.am
> +++ b/lib/psos/Makefile.am
> @@ -2,6 +2,10 @@ lib_LTLIBRARIES = libpsos.la
>  
>  libpsos_la_LDFLAGS = @XENO_LIB_LDFLAGS@ -version-info 0:0:0
>  
> +libpsos_la_LIBADD =  \
> + @XENO_CORE_LDADD@   \
> + $(top_builddir)/lib/copperplate/libcopperplate.la
> +
>  libpsos_la_SOURCES = \
>   init.c  \
>   internal.h  \
> diff --git a/lib/trank/Makefile.am b/lib/trank/Makefile.am
> index 816a1a4047..ee353c6f20 100644
> --- a/lib/trank/Makefile.am
> +++ b/lib/trank/Makefile.am
> @@ -3,6 +3,10 @@ lib_LTLIBRARIES = libtrank.la
>  
>  libtrank_la_LDFLAGS = @XENO_LIB_LDFLAGS@ -version-info 0:0:0
>  
> +libtrank_la_LIBADD = \
> + @XENO_CORE_LDADD@   \
> + $(top_builddir)/lib/alchemy/libalchemy.la
> +
>  libtrank_la_SOURCES =\
>   init.c  \
>   internal.c  \
> diff --git a/lib/vxworks/Makefile.am b/lib/vxworks/Makefile.am
> index a123864079..4217a994b0 100644
> --- a/lib/vxworks/Makefile.am
> +++ b/lib/vxworks/Makefile.am
> @@ -2,6 +2,10 @@ lib_LTLIBRARIES = libvxworks.la
>  
>  libvxworks_la_LDFLAGS = @XENO_LIB_LDFLAGS@ -version-info 0:0:0
>  
> +libvxworks_la_LIBADD =
>   \
> + @XENO_CORE_LDADD@   \
> + $(top_builddir)/lib/copperplate/libcopperplate.la
> +
>  libvxworks_la_SOURCES = \
>   init.c  \
>   errnoLib.c  \

Re: Migrate project from Debian 8 Xenomai 2.x to Debain 9 Xenomai 3.x

[Henning Schild via Xenomai]

Hi Carsten,

the sniplets look like cmake. There are more cmake-xenomai-users
around, i would suggest to dig in the archive of the mailinglist. AFAIK
there have been contributions that did not get merged but will probably
solve your problem.

If that is the case we should keep in mind that xenomai users seem to
like cmake and consider those cmake patches more relevant for the
project.

regards,
Henning

On Mon, 10 Feb 2020 14:20:04 +
Carsten EHRMANN via Xenomai  wrote:

> Hi Jan,
> 
> do I have to include the xeno-config file? I just configured it with
> "xeno-config --skin=native".
> 
> I use a project file where includes are defined, see below:
> 
> unix {
> TEMPLATE = app
> } else {
> TEMPLATE = vcapp
> }
> CONFIG -= qt
> CONFIG += debug_and_release warn_on exceptions rtti 
> Debug {
> TARGET = CSRTDaemon
> CONFIG += console
> OBJECTS_DIR = ../tmp/obj/CSRTDaemon/debug
> DESTDIR = ../lib/CSRTDaemon
> DLLDESTDIR = ../dll/CSRTDaemon
> SCOPE=debug
> unix {
> QMAKE_CXXFLAGS += 
> QMAKE_CFLAGS += 
> QMAKE_LFLAGS +=
> } else {
> QMAKE_POST_LINK = COPY /Y ../lib/CSRTDaemon/*.pdb
> ../dll/CSRTDaemon/ }
> } else {
> TARGET = CSRTDaemon
> OBJECTS_DIR = ../tmp/obj/CSRTDaemon/release
> DESTDIR = ../lib/CSRTDaemon
> DLLDESTDIR = ../dll/CSRTDaemon
> DEFINES += QT_NO_DEBUG_OUTPUT NDEBUG
> SCOPE=release
> }
> 
> 
> QMAKE_LIBDIR += /usr/xenomai/lib
> INCLUDEPATH += /usr/xenomai/include
> 
> 
> 
> 
> _
> Bitte überlegen Sie, ob Sie diese Nachricht wirklich ausdrucken
> müssen/ before printing, think about environmental responsibility.
> Diehl Metering GmbH, Industriestraße 13, 91522 Ansbach Telefon + 49
> 981 1806 0, Telefax +49 981 1806 615 Sitz der Gesellschaft: Ansbach,
> Registergericht: Ansbach HRB 69 Geschäftsführer: Dr. Christof Bosbach
> (Sprecher), Thomas Gastner, Jean-François Marguet Der Inhalt der
> vorstehenden E-Mail ist nicht rechtlich bindend. Diese E-Mail enthält
> vertrauliche und/oder rechtlich geschützte Informationen. Informieren
> Sie uns bitte, wenn Sie diese E-Mail fälschlicherweise erhalten
> haben. Bitte löschen Sie in diesem Fall die Nachricht. Jede
> unerlaubte Form der Reproduktion, Bekanntgabe, Änderung, Verteilung
> und/oder Publikation dieser E-Mail ist strengstens untersagt. The
> contents of the above mentioned e-mail is not legally binding. This
> e-mail contains confidential and/or legally protected information.
> Please inform us if you have received this e-mail by mistake and
> delete it in such a case. Each unauthorized reproduction, disclosure,
> alteration, distribution and/or publication of this e-mail is
> strictly prohibited. Informationen zum Datenschutz finden Sie auf
> unserer Homepage.
> https://www.diehl.com/metering/de/diehl-metering/data-protection
> Information about data protection can be found on our homepage.
> https://www.diehl.com/metering/en/diehl-metering/data-protection
> 
> 
> -Original Message-
> From: Jan Kiszka  
> Sent: Monday, February 10, 2020 2:23 PM
> To: Carsten EHRMANN ; xenomai@xenomai.org
> Subject: Re: Migrate project from Debian 8 Xenomai 2.x to Debain 9
> Xenomai 3.x
> 
> On 10.02.20 13:03, Carsten EHRMANN via Xenomai wrote:
> > Hello,
> > 
> > 
> > Because of new PC hardware I have to use debain 9 and Xenomai 3. 
> > Xenomai is running on the system, I run the testsuite scripts. I
> > found a migration document on xenomai.org and changed the
> > includepaths and so on in my sourcecode. But now when I want to
> > compile the code I got this error In file included from
> > ./CSRTPosixQue.h:20:0, from ./CSRTTask.h:20, from main.cpp:26:
> > /usr/xenomai/include/trank/native/task.h: In function 'int
> > rt_task_notify(RT_TASK*, rt_sigset_t)':
> > /usr/xenomai/include/trank/native/task.h:41:64: error:
> > 'trank_warning' was not declared in this scope
> > trank_warning("in-kernel native API is gone, rebase over RTDM");
> > 
> > But this "trank_warning" is defined in trank.h which is included
> >   
> 
> Where you using xeno-config to obtain paths and other compiler
> switches? If not, please compare your settings. If yes, a simple test
> case would be nice. But it can't be very simple because
> 
> #include 
> int main() {}
> 
> compiles via "gcc $(xeno-config --skin native --cflags) ..."
> 
> Jan
> 
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate
> Competence Center Embedded Linux

Re: Migrate project from Debian 8 Xenomai 2.x to Debain 9 Xenomai 3.x

[Henning Schild via Xenomai]

Hi,

coming from xenomai 2.x and debian8 i would advice to skip debian9 and
go for debian10 right away. You will probably face the same issues and
possibly more, but why go for oldstable if you invest today?
Depending on your timeline you might even want to look at debian11.
There is no ipipe-5.4.y yet but you can assume that this version will
be supported eventually. In the meantime you could try debian11 with
4.19.

regards,
Henning

On Mon, 10 Feb 2020 12:03:32 +
Carsten EHRMANN via Xenomai  wrote:

> Hello,
> 
> 
> Because of new PC hardware I have to use debain 9 and Xenomai 3.
> Xenomai is running on the system, I run the testsuite scripts. I
> found a migration document on xenomai.org and changed the
> includepaths and so on in my sourcecode. But now when I want to
> compile the code I got this error In file included from
> ./CSRTPosixQue.h:20:0, from ./CSRTTask.h:20, from main.cpp:26:
> /usr/xenomai/include/trank/native/task.h: In function 'int
> rt_task_notify(RT_TASK*, rt_sigset_t)':
> /usr/xenomai/include/trank/native/task.h:41:64: error:
> 'trank_warning' was not declared in this scope
> trank_warning("in-kernel native API is gone, rebase over RTDM");
> 
> But this "trank_warning" is defined in trank.h which is included
> 
> 
> Mit freundlichen Grüßen / Best regards
> Carsten Ehrmann
> T-S092 Industrial Engineering / Test Engineering & Software
> 
> Diehl Metering
> Industriestr. 13
> 91522 Ansbach
> Germany
> 
> Phone: +49 981 1806-252
> E-Mail: carsten.ehrm...@diehl.com
> Web:
> www.diehl.com/metering<../../../../../metzan/AppData/Local/Temp/notesE05E9E/www.diehl.com/metering>
> 
> 
> 
> _
> Bitte überlegen Sie, ob Sie diese Nachricht wirklich ausdrucken
> müssen/ before printing, think about environmental responsibility.
> Diehl Metering GmbH, Industriestraße 13, 91522 Ansbach Telefon + 49
> 981 1806 0, Telefax +49 981 1806 615 Sitz der Gesellschaft: Ansbach,
> Registergericht: Ansbach HRB 69 Geschäftsführer: Dr. Christof Bosbach
> (Sprecher), Thomas Gastner, Jean-François Marguet Der Inhalt der
> vorstehenden E-Mail ist nicht rechtlich bindend. Diese E-Mail enthält
> vertrauliche und/oder rechtlich geschützte Informationen. Informieren
> Sie uns bitte, wenn Sie diese E-Mail fälschlicherweise erhalten
> haben. Bitte löschen Sie in diesem Fall die Nachricht. Jede
> unerlaubte Form der Reproduktion, Bekanntgabe, Änderung, Verteilung
> und/oder Publikation dieser E-Mail ist strengstens untersagt. The
> contents of the above mentioned e-mail is not legally binding. This
> e-mail contains confidential and/or legally protected information.
> Please inform us if you have received this e-mail by mistake and
> delete it in such a case. Each unauthorized reproduction, disclosure,
> alteration, distribution and/or publication of this e-mail is
> strictly prohibited. Informationen zum Datenschutz finden Sie auf
> unserer Homepage.
> https://www.diehl.com/metering/de/diehl-metering/data-protection
> Information about data protection can be found on our homepage.
> https://www.diehl.com/metering/en/diehl-metering/data-protection

Re: IPIPE patch for 32-bit 4.19 LTS kernel

[Henning Schild via Xenomai]

Hi,

Am Thu, 6 Feb 2020 16:55:15 +0100
schrieb Matthias Winkler via Xenomai :

> Hello Xenomai-Users,
> 
> Has anybody ported the xenomai patch
> for kernel 4.19.101 in 32-Bit?

That target has not been looked at in a long time, i am not sure
whether it is officially discontinued or just happened like that.

I remember multiple discussions around it and nobody stood up and said
they cared about it.

> We need to support also our older devices with 32bit CPUs.
> Help or hints would be appreciated!

I think ipipe-4.4.y has 32bit support and still has long lifetime ahead
of it combined with CIP https://www.cip-project.org/

regards,
Henning

> best regards
> 
> Matthias

Re: [PATCH 0/8] Assorted fixes

[Henning Schild via Xenomai]

Am Fri, 31 Jan 2020 14:20:33 -0500
schrieb Greg Gallagher via Xenomai :

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

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

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

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

Henning

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

Re: Finalizing 3.1

[Henning Schild via Xenomai]

Hi Jan,

from my point of view we are good to go. With the debian patch you
merged the next generation of Siemens MR scanners will be unpatched
upstream Xenomai and 4.19 CIP ipipe kernel together with a patch-free
Debian 10.

Henning

On Tue, 28 Jan 2020 12:36:08 +0100
Jan Kiszka via Xenomai  wrote:

> Hi all,
> 
> there are a couple of unclear issues floating around but I would
> still like to finally tag 3.1 by the end of the week unless some
> serious last-minute blocker occurs. If you have any input regarding
> this, let me know.
> 
> Jan
> 

[PATCH] debian: Enable dlopen-libs in userspace package

[Henning Schild via Xenomai]

From: Henning Schild 

This feature might not be widely used but those debian packages are
supposed to be generic. Having it default on brings more benefits than
drawbacks for generic packages.

Signed-off-by: Henning Schild 
---
 debian/rules | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 68e7a4e37..22c90586d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -19,7 +19,8 @@ CONFIG_OPTS = --prefix=/usr \
 --with-testdir=/usr/lib/xenomai/testsuite \
 --enable-smp \
 --enable-lazy-setsched \
---enable-debug=symbols
+--enable-debug=symbols \
+--enable-dlopen-libs
 
 ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
CONFIG_OPTS += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE)
-- 
2.24.1

RFC: making dlopen support default on for debian/rules

[Henning Schild via Xenomai]

Hi all,

i do carry a local patch to make the debian packages dlopen-aware for
quite some time now. It used to be that debian packaging was not well
supported and just carried for reference.
But with the rise of Isar in the building Xenomai world the current
view on the debian/ support might change.

What are your thoughts on putting "--enable-dlopen-libs" into
debian/rules? I would be happy to send a patch.

regards,
Henning

Re: Xenomai fails to start when running in QEMU VM

[Henning Schild via Xenomai]

Can you provide some more detail on the host-machine? What hardware,
which kernel are you using, where is the kernel config coming from?

There must be something "unusual" in your setup.

Henning

Am Thu, 24 Oct 2019 09:38:23 -0400
schrieb Rob Miller via Xenomai :

> responses in-line...
> 
> Rob Miller
> rob.mil...@broadcom.com
> (919)721-3339
> 
> 
> On Thu, Oct 24, 2019 at 8:12 AM Jan Kiszka  wrote:
> 
> > On 24.10.19 13:46, Rob Miller wrote:  
> > > Pls see below
> > >
> > > Rob Miller
> > > rob.mil...@broadcom.com 
> > > (919)721-3339
> > >
> > >
> > > On Thu, Oct 24, 2019 at 6:25 AM Jan Kiszka  > > > wrote:
> > >
> > > On 23.10.19 23:23, Rob Miller via Xenomai wrote:  
> > > > Correction, stock images work by removing the enable-kvm
> > > > and *NOT  
> > > *adding  
> > > > the -no-hpet QEMU cmdline options.
> > > >
> > > > also latency numbers are crazy with avg being 1678.126 usec
> > > > w/  
> > > worst case  
> > > > being 15463.240usec
> > > >
> > > > at this point, I'm not sure which way to go:
> > > >
> > > > 1) do I hunt down issues in HPET failing w/ KVM mode
> > > > enabled? 2) just go to dovetail
> > > > 3) ???  
> > >
> > > Don't have a the reference image around, but I'm pretty sure
> > > it would work here with QEMU
> > > 4300b7c2cd9f3f273804e8cca325842ccb93b1ad (post  
> > 4.1)  
> > > and KVM from 5.3.6. At least a different image is being used
> > > like  
> > that  
> > > for ages, and kernel config in xenomai-image is basically
> > > derived from it.
> > >  
> > > RJM>] Will try  
> > >
> > >
> > > For the xenomai-images check, did you use "start-qemu.sh x86"
> > > as-is? 
> > > RJM>] Yes, my 1st failed attempts used unmodified start-qemu.sh
> > > RJM>x86,  
> > > then I mod'd the file to remove the -enable-kvm, and it started
> > > to work UNTIL also added -no-hpet, then I can't even boot up.
> > >  
> >
> > Number of host cores >= number of guest CPUs? If not, reduce -smp
> > in the QEMU invocation.
> >
> RJM>] yup, host has 16 cores whilst guest has 4 (using the stock
> RJM>images).  
> 
> >
> > Oh, and don't expect any kind of determinism in these setups. KVM
> > and QEMU are for functional testing only.
> >
> RJM>] Ah, good to know.  
> 
> >
> > Jan
> >  

[xenomai-images][PATCH 1/1] kas.yml: switch isar url to a working clone url

[Henning Schild via Xenomai]

From: Henning Schild 

The url was actually missing the .git extension which seems to break
cloning it. Maybe a github change or who knows, but that new one works.

Signed-off-by: Henning Schild 
---
 kas.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kas.yml b/kas.yml
index 260eb36..a4d12c2 100644
--- a/kas.yml
+++ b/kas.yml
@@ -19,7 +19,7 @@ repos:
   xenomai:
 
   isar:
-url: https://github.com/ilbers/isar
+url: https://github.com/ilbers/isar.git
 refspec: 59c7dd2b8b3172d53de1c7a39fbd49751193559a
 layers:
   meta:
-- 
2.21.0

[xenomai-images][PATCH 0/1] small fix to kas.yml

[Henning Schild via Xenomai]

From: Henning Schild 

I had problems cloning isar with kas-docker yesterday. Can not reproduce
it anymore. But the url is the one you get from github "Clone or
download", while the other might just work as well.

Henning Schild (1):
  kas.yml: switch isar url to a working clone url

 kas.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.21.0

Re: Preview: 4.19-x86 support

[Henning Schild via Xenomai]

Am Fri, 28 Jun 2019 16:00:17 +0200
schrieb Jan Kiszka :

> On 28.06.19 15:48, Henning Schild wrote:
> > Am Fri, 28 Jun 2019 15:06:39 +0200
> > schrieb Jan Kiszka :
> >   
> >> On 28.06.19 14:48, Henning Schild wrote:  
> >>>> BTW, regarding the failing smokey gdb test: Check if gdb is
> >>>> available on the target. That is now a precondition.  
> >>>
> >>> Yes it is. The $ N does not make any sense. It came from running a
> >>> local copy without "make install". That is currently not supported
> >>> by the gdb test, which should be fixed. People might want to test
> >>> before installing, if just working on one machine.  
> >>
> >> This works fine here:
> >>
> >> $ xenomai/build/testsuite/smokey/smokey --run=gdb
> >> gdb OK  
> > 
> > Running local, in a rootfs not containing an old version? The
> > problem is launching smokey again from gdb. In my case the old
> > smokey did not even know about "gdb".
> >   
> 
> OK, I think I got it now. This should fix both issues:
> 
> diff --git a/testsuite/smokey/gdb/gdb.c b/testsuite/smokey/gdb/gdb.c
> index 2fad3da19a..a6909d595b 100644
> --- a/testsuite/smokey/gdb/gdb.c
> +++ b/testsuite/smokey/gdb/gdb.c
> @@ -274,8 +274,7 @@ static int run_gdb(struct smokey_test *t, int
> argc, char *const argv[]) snprintf(run_param, sizeof(run_param),
> "--run=%d", t->__reserved.id);
>   execl("/usr/bin/gdb", "gdb", "--args",
> -   CONFIG_XENO_PREFIX "/bin/smokey",
> run_param,
> -   "run_target", NULL);
> +   argv[0], run_param, "run_target",
> NULL); _exit(ESRCH);
>  
>   default:
> 
> Jan


That solves the one problem, but the test still fails. I further
investigated and it has to be one of the following kernel options that
allowed me to finally run it successfully.

--- /boot/config-4.14.128-henning+.old  2019-06-27 14:36:43.299983371 +
+++ /boot/config-4.14.128-henning+  2019-06-28 13:23:43.569874713 +

 #
 # Latency settings
@@ -455,11 +456,16 @@
 CONFIG_XENO_OPT_TIMING_KSCHEDLAT=0
 CONFIG_XENO_OPT_TIMING_IRQLAT=0
 CONFIG_XENO_OPT_DEBUG=y
-# CONFIG_XENO_OPT_DEBUG_COBALT is not set
-# CONFIG_XENO_OPT_DEBUG_CONTEXT is not set
+CONFIG_XENO_OPT_DEBUG_COBALT=y
+# CONFIG_XENO_OPT_DEBUG_MEMORY is not set
+CONFIG_XENO_OPT_DEBUG_CONTEXT=y
 CONFIG_XENO_OPT_DEBUG_LOCKING=y
-# CONFIG_XENO_OPT_DEBUG_USER is not set
-# CONFIG_XENO_OPT_DEBUG_TRACE_RELAX is not set
+CONFIG_XENO_OPT_DEBUG_USER=y
+CONFIG_XENO_OPT_DEBUG_MUTEX_RELAXED=y
+CONFIG_XENO_OPT_DEBUG_MUTEX_SLEEP=y
+CONFIG_XENO_OPT_DEBUG_POSIX_SYNCHRO=y
+CONFIG_XENO_OPT_DEBUG_LEGACY=y
+CONFIG_XENO_OPT_DEBUG_TRACE_RELAX=y
 CONFIG_XENO_OPT_WATCHDOG=y
 CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=4

Re: Preview: 4.19-x86 support

[Henning Schild via Xenomai]

Am Fri, 28 Jun 2019 15:06:39 +0200
schrieb Jan Kiszka :

> On 28.06.19 14:48, Henning Schild wrote:
> >> BTW, regarding the failing smokey gdb test: Check if gdb is
> >> available on the target. That is now a precondition.  
> > 
> > Yes it is. The $ N does not make any sense. It came from running a
> > local copy without "make install". That is currently not supported
> > by the gdb test, which should be fixed. People might want to test
> > before installing, if just working on one machine.  
> 
> This works fine here:
> 
> $ xenomai/build/testsuite/smokey/smokey --run=gdb
> gdb OK

Running local, in a rootfs not containing an old version? The problem
is launching smokey again from gdb. In my case the old smokey did not
even know about "gdb".

> > 
> > After that i run into  
> >>> FAILURE run_gdb:290: checking expression "primary_mode", expected
> >>> "1", found "0  
> >   
> 
> Can't reproduce. And given that line 290 in master does not contain
> any code, I strongly suspect your build is inconsistent.

Off by two debug printfs that did not cause the problem. 288 in a clean
copy ... a "make install" was required to get rid of the 290.

Henning

> Jan
> 

Re: Preview: 4.19-x86 support

[Henning Schild via Xenomai]

Am Thu, 27 Jun 2019 18:50:30 +0200
schrieb Jan Kiszka :

> On 27.06.19 15:56, Henning Schild via Xenomai wrote:
> > Am Mon, 24 Jun 2019 13:29:16 +0200
> > schrieb Jan Kiszka :
> >   
> >> On 24.06.19 13:18, Henning Schild wrote:  
> >>> Am Mon, 24 Jun 2019 08:32:24 +0200
> >>> schrieb Jan Kiszka :
> >>>  
> >>>> On 21.06.19 18:04, Henning Schild via Xenomai wrote:  
> >>>>> Hi Jan,
> >>>>>
> >>>>> works fine. The only thing that did not was the gdb smokey test.
> >>>>> 
> >>>>>> FAILURE run_gdb:288: checking expression "primary_mode",
> >>>>>> expected "$", found "N"  
> >>>>>
> >>>>> did not look into where this came from.  
> >>>>
> >>>> OK, didn't see that so far. Did you only see this on 4.19 so far,
> >>>> ie. did you test 4.14 or older with master recently?  
> >>>
> >>> Switches from stable to master for just this one, so can not tell.
> >>>  
> >>>>>
> >>>>> Tested todays master but think the 4.19 changes should be
> >>>>> backported to stable as well.  
> >>>>
> >>>> I'm not planning for that due to the number of changes involved.
> >>>> 3.1 will come out "soon", and that is for newer kernels.  
> >>>
> >>> Ok.
> >>>  
> >>>>>
> >>>>> I also ran into an smb issue from upstream, which is fixed
> >>>>> there. So i think this should be rebased on latest 4.19
> >>>>> eventually. Or leave it on 33 and merge for the first release.  
> >>>>
> >>>> Which one exactly?  
> >>>
> >>> 37, but is there anything from preventing 55?  
> >>
> >> I was referring to the concrete issue, or commit. I will rebase, I
> >> just wanted to reduce the number of variables during the initial
> >> stabilization.  
> > 
> > upstream 088aaf17aa79300cab14dbee2569c58cfafd7d6e
> > stable c69330a855ab4342d304f67f8c1e7d1fa2686bec
> >   
> 
> Ah, SMB - I've read SMP and was expecting some thrilling patch.

And i was surprised you wanted to know so much about a smb KASAN fixup.
Btw also in current 4.14 ...

> BTW, regarding the failing smokey gdb test: Check if gdb is available
> on the target. That is now a precondition.

Yes it is. The $ N does not make any sense. It came from running a
local copy without "make install". That is currently not supported by
the gdb test, which should be fixed. People might want to test before
installing, if just working on one machine.

After that i run into 
>> FAILURE run_gdb:290: checking expression "primary_mode", expected
>> "1", found "0

Henning

> Jan
> 

Re: Preview: 4.19-x86 support

[Henning Schild via Xenomai]

Am Mon, 24 Jun 2019 13:29:16 +0200
schrieb Jan Kiszka :

> On 24.06.19 13:18, Henning Schild wrote:
> > Am Mon, 24 Jun 2019 08:32:24 +0200
> > schrieb Jan Kiszka :
> >   
> >> On 21.06.19 18:04, Henning Schild via Xenomai wrote:  
> >>> Hi Jan,
> >>>
> >>> works fine. The only thing that did not was the gdb smokey test.
> >>>  
> >>>> FAILURE run_gdb:288: checking expression "primary_mode", expected
> >>>> "$", found "N"  
> >>>
> >>> did not look into where this came from.  
> >>
> >> OK, didn't see that so far. Did you only see this on 4.19 so far,
> >> ie. did you test 4.14 or older with master recently?  
> > 
> > Switches from stable to master for just this one, so can not tell.
> >   
> >>>
> >>> Tested todays master but think the 4.19 changes should be
> >>> backported to stable as well.  
> >>
> >> I'm not planning for that due to the number of changes involved.
> >> 3.1 will come out "soon", and that is for newer kernels.  
> > 
> > Ok.
> >   
> >>>
> >>> I also ran into an smb issue from upstream, which is fixed there.
> >>> So i think this should be rebased on latest 4.19 eventually. Or
> >>> leave it on 33 and merge for the first release.  
> >>
> >> Which one exactly?  
> > 
> > 37, but is there anything from preventing 55?  
> 
> I was referring to the concrete issue, or commit. I will rebase, I
> just wanted to reduce the number of variables during the initial
> stabilization.

upstream 088aaf17aa79300cab14dbee2569c58cfafd7d6e
stable c69330a855ab4342d304f67f8c1e7d1fa2686bec

Henning

> Jan

Re: Preview: 4.19-x86 support

[Henning Schild via Xenomai]

Am Mon, 24 Jun 2019 08:32:24 +0200
schrieb Jan Kiszka :

> On 21.06.19 18:04, Henning Schild via Xenomai wrote:
> > Hi Jan,
> > 
> > works fine. The only thing that did not was the gdb smokey test.
> >   
> >> FAILURE run_gdb:288: checking expression "primary_mode", expected
> >> "$", found "N"  
> > 
> > did not look into where this came from.  
> 
> OK, didn't see that so far. Did you only see this on 4.19 so far, ie.
> did you test 4.14 or older with master recently?

Switches from stable to master for just this one, so can not tell.

> > 
> > Tested todays master but think the 4.19 changes should be
> > backported to stable as well.  
> 
> I'm not planning for that due to the number of changes involved. 3.1
> will come out "soon", and that is for newer kernels.

Ok.

> > 
> > I also ran into an smb issue from upstream, which is fixed there.
> > So i think this should be rebased on latest 4.19 eventually. Or
> > leave it on 33 and merge for the first release.  
> 
> Which one exactly?

37, but is there anything from preventing 55?

Henning

> Thanks,
> Jan
> 
> > 
> > Henning
> > 
> > Am Tue, 18 Jun 2019 18:37:14 +0200
> > schrieb Jan Kiszka via Xenomai :
> >   
> >> Hi all,
> >>
> >> @all early adopters: There is a first version of upcoming x86
> >> support based on the 4.19 kernel available at [1]. You need
> >> Xenomai master for it. The kernel should boot and run Xenomai
> >> workload fine - at least it does here so far. I only see one
> >> lockdep splat during early boot that needs to be sorted out.
> >> Possibly just an instrumentation issue, not a real problem. For
> >> the first release, cleaning up the series and adding latest 4.19
> >> support are on my to-do list.
> >>
> >> Early test reports appreciated!
> >>
> >> Jan
> >>
> >> [1]
> >> https://gitlab.denx.de/Xenomai/ipipe-x86/commits/wip/ipipe-x86-4.19.y
> >>  
> > 
> > 
> >   
> 

https://www.xenomai.org/ returns 403

[Henning Schild via Xenomai]

reminds me of
https://www.youtube.com/watch?v=W8_Kfjo3VjU

Re: Preview: 4.19-x86 support

[Henning Schild via Xenomai]

Hi Jan,

works fine. The only thing that did not was the gdb smokey test.

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

did not look into where this came from.

Tested todays master but think the 4.19 changes should be backported to
stable as well.

I also ran into an smb issue from upstream, which is fixed there. So i
think this should be rebased on latest 4.19 eventually. Or leave it on
33 and merge for the first release.

Henning

Am Tue, 18 Jun 2019 18:37:14 +0200
schrieb Jan Kiszka via Xenomai :

> Hi all,
> 
> @all early adopters: There is a first version of upcoming x86 support
> based on the 4.19 kernel available at [1]. You need Xenomai master
> for it. The kernel should boot and run Xenomai workload fine - at
> least it does here so far. I only see one lockdep splat during early
> boot that needs to be sorted out. Possibly just an instrumentation
> issue, not a real problem. For the first release, cleaning up the
> series and adding latest 4.19 support are on my to-do list.
> 
> Early test reports appreciated!
> 
> Jan
> 
> [1]
> https://gitlab.denx.de/Xenomai/ipipe-x86/commits/wip/ipipe-x86-4.19.y
> 

Re: [Xenomai] ipipe-4.14: planned release date

[Henning Schild via Xenomai]

Am Thu, 28 Mar 2019 11:19:06 +0100
schrieb Jan Kiszka :

> On 28.03.19 01:32, Virendra Kate wrote:
> >   
> >  >>> Did you all get an update on this issue ? Was it resolved
> >  >>> after all? I have the exact same hardware with the exact same
> >  >>> issue. The board keeps resetting after "Loading initial
> >  >>> ramdisk..."
> >  >>>
> >  >>> My Setup is as follows:
> >  >>> ipipe version: ipipe-core-4.14.89-x86-2
> >  >>> Linux-kernel version: linux-4.14.89
> >  >>> xenomai version: xenomai-3.0.8
> >  >>> Hardware: AMD® Ryzen embedded v1756b
> >  >>>
> >  >>> The board works fine with Linux kernel 3.9.146 patched with
> >  >>> the appropriate xenomai-ipipe files. I would like to move to
> >  >>> linux-kernel_4.14 as the GPU driver is officially supported by
> >  >>> AMD for linux-kernel_4.14. 
> >  >>
> >  >> No direct progress regarding Ryzen, but I will try to glue
> >  >> together a new 4.14 version if pending patches soon so that you
> >  >> can try if that happens to help. Will let you know.
> >  >>  
> >  >
> >  >Just done, see https://gitlab.denx.de/Xenomai/ipipe-x86/  
> > 
> > The same issue persists.
> > 
> > 1. I downloaded the kernel-patched with ipipe from the above link.
> > 2. Added the co-kernel
> > using: ../xenomai-3.0.8/scripts/prepare-kernel.sh --arch=x86_64
> > 3. Made the appropriate kernel config changes.
> > 
> > I have attached my .config file.  
> 
> To exclude or narow-down config-related issues, you could try
> starting of with the x86_64_defconfig, only adding essential Xenomai
> and board-related switches.

And an unpatched mainline kernel of the ~ same version, with the ~same
config would be interesting as well.

Henning

> Jan
> 

Re: Qt application on Xenomai

[Henning Schild via Xenomai]

Hi,

i am not sure i fully understand the question. In case you are worried
about combining Xenomai and Qt, i can assure you that it is possible.
We do have big c++/Qt applications running both rt and non-rt on
xenomai.

regards,
Henning

Am Fri, 1 Mar 2019 14:10:42 +0530
schrieb Sumitabh Ghosh via Xenomai :

> Hi,
> 
> I have a generic question not specific to any platform. If I want to
> run a small graphics application on Xenomai 3.x what would be the
> correct approach. e.g. Qt application framework which needs POSIX
> apis and a linux frame buffer to be able to render 2D applications.
> 
> Kindly provide me some pointers.
> 
> Thanks in advance.
> 
> Cheers!
> Sumit

Re: xenomai-3.0.5 include path

[Henning Schild via Xenomai]

Am Mon, 25 Feb 2019 02:01:53 +0800
schrieb "demon@aliyun.com" :

> Hi,
> My installation was refer to:
> https://rtt-lwr.readthedocs.io/en/latest/rtpc/xenomai3.html: "cd
> xenomai-3.0.5 ./configure --with-pic --with-core=cobalt --enable-smp
> --disable-tls --enable-dlopen-libs --disable-clock-monotonic-raw make
> -j`nproc` sudo make install"

The link suggests that you are on Ubuntu. The documentation says to do
"sudo make install", which will work exactly one time ... This is
wrong, especially since you are on a debian-based distro.

Instaed you should be building debian packages and install those.
Everything you need is in the tree. Just change CONFIG_OPTS in
debian/rules, add an entry to debian/changelog and run
dpkg-buildpackage.
If you are not on debian use prefix/destdir and "xstow" and _never_
"make install" as root.

Now you should probably ask your package manager which files in /usr do
not belong to any package. And remove all that look like xenomai. After
that see if a single "make install" will get you into the same conflict
again, or the installation of the resulting package.

Henning


> Then:
> "echo '
> ### Xenomai
> export XENOMAI_ROOT_DIR=/usr/xenomai
> export XENOMAI_PATH=/usr/xenomai
> export PATH=$PATH:$XENOMAI_PATH/bin:$XENOMAI_PATH/sbin
> export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$XENOMAI_PATH/lib/pkgconfig
> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$XENOMAI_PATH/lib
> export OROCOS_TARGET=xenomai
> ' >> ~/.xenomai_rc
> echo 'source ~/.xenomai_rc' >> ~/.bashrc 
> source ~/.bashrc"
> 
> Is there anything could be fixed,gratefunlly?
> thanks,
> demon.
> 
> 
> demon@aliyun.com
>  
> From: Henning Schild
> Date: 2019-02-22 19:33
> To: demon.han--- via Xenomai
> CC: demon@aliyun.com
> Subject: Re: xenomai-3.0.5 include path
> Hi,
>  
> did you compare the two files? My guess would be that you are on a
> system where a careless "make install" was run on multiple versions of
> xenomai, possibly with prefix dirs set.
>  
> Once you are sure that both headers are indeed coming out of the same
> installation, it would be time to look the the install target of make.
>  
> Henning
>  
> Am Fri, 22 Feb 2019 10:54:33 +0800
> schrieb demon.han--- via Xenomai :
>  
> > Hi,
> > I am working on xenomai3.0.5 with Eherlab Ethercat.
> > Here I got a problem.
> > After installing xenomai,I got 2 include directory:
> > 1. /usr/include/xenomai
> > 2./usr/xenomai/include
> > I find rtdm_driver.h in /usr/include/xenomai but
> > out /usr/xenomai/include. This cause a problem,I think:
> > when I compile Etherlab,I got error as"/master/rtdm.c:37:30: fatal
> > error: rtdm/rtdm_driver.h: No such file or directory", so I copy the
> > header to /usr/xenomai/include/rtdm,and the error is fixed. Is there
> > another way to fix the problem? Best Wishes.
> > demon.
> > 
> > 
> > 
> > demon@aliyun.com  
>  

Re: xenomai-3.0.5 include path

[Henning Schild via Xenomai]

Hi,

did you compare the two files? My guess would be that you are on a
system where a careless "make install" was run on multiple versions of
xenomai, possibly with prefix dirs set.

Once you are sure that both headers are indeed coming out of the same
installation, it would be time to look the the install target of make.

Henning

Am Fri, 22 Feb 2019 10:54:33 +0800
schrieb demon.han--- via Xenomai :

> Hi,
> I am working on xenomai3.0.5 with Eherlab Ethercat.
> Here I got a problem.
> After installing xenomai,I got 2 include directory:
> 1. /usr/include/xenomai
> 2./usr/xenomai/include
> I find rtdm_driver.h in /usr/include/xenomai but
> out /usr/xenomai/include. This cause a problem,I think:
> when I compile Etherlab,I got error as"/master/rtdm.c:37:30: fatal
> error: rtdm/rtdm_driver.h: No such file or directory", so I copy the
> header to /usr/xenomai/include/rtdm,and the error is fixed. Is there
> another way to fix the problem? Best Wishes.
> demon.
> 
> 
> 
> demon@aliyun.com

Re: Help on porting lwIP to Xenomai (Beaglebone Black, AM335X)

[Henning Schild via Xenomai]

On Tue, 29 Jan 2019 15:40:35 +0100
Jan Kiszka via Xenomai  wrote:

> On 29.01.19 10:57, Baur, Elias via Xenomai wrote:
> > Hello everyone,
> > 
> > I am new to lwIP and did a lot of research the last couple of days.
> > My goal ist to do real time networking between wire-connected
> > Beagleboards. Therefore, we have been setting up a Xenomai
> > Co-Kernel on the boards. To actually send and receive UDP-packets,
> > we want to use lwIP instead of RTnet, because we are already using
> > it on other boards.  
> 
> This doesn't sound like a strong argument. You should better look for
> hard facts, what benefits (or downsides) an lwIP stack would have.
> Then it is more realistic to weigh estimated efforts on both sides
> against benefits.

Well the background might be more academic, so i would not be too fast
to judge. If my guess is correct we might be talking about some sort of
student assignment, Masterarbeit, Beleg etc. Knowing the scope, maybe
be can come up with an improved assignment together.

Henning 

> Also, who should be the low-level driver provider in your lwIP setup?
> Do you plan to write one from scratch?
> 
> Jan
> 
> > 
> > I have found out that TI has already ported lwIP on its CPU in its
> > Starterware:
> > http://processors.wiki.ti.com/index.php/StarterWare_CPSW_Port_lwIP
> > Now I am wondering whether it is possible to adapt this for
> > Xenomai? Does anyone have experience on that?
> > 
> > Thank you very much!
> > Best, Eloa
> >   
> 

Re: FPU warn on ipipe 4.9.146-8 i386

[Henning Schild via Xenomai]

Am Fri, 11 Jan 2019 14:47:13 +0100
schrieb Mauro Salvini :

> On Fri, 2019-01-11 at 10:40 +0100, Henning Schild wrote:
> > Am Fri, 11 Jan 2019 09:57:50 +0100
> > schrieb Mauro Salvini via Xenomai :
> >   
> > > Hi all,
> > > 
> > > I'm testing same hardware of [1], with kernel 4.9.146 from ipipe-
> > > 4.9.y
> > > with [2] applied, compiled with ARCH=i386 and Xenomai 3.0.7.  
> > 
> > To be honest i386 is not really tested anymore, in fact in 4.14 not
> > even supported at the moment. If you can you should go for x86_64.
> >   
> 
> Hi Henning,
> 
> Thank you. I'm trying i386 version due to legacy 32bit code that uses
> rtnet (which cannot be used with mixed ABI).

Ok, maybe something you might want to fix for the future.

> > > Launching
> > > 
> > > xeno-test -l "dohell -s xxx -p yyy -m xxx 9" -T 9
> > > 
> > > I got this dump in dmesg, sometimes just after latency starts,
> > > sometimes after few seconds (side effect is a max latency value
> > > increase):
> > > 
> > > [  167.914184] [ cut here ]
> > > [  167.914208] WARNING: CPU: 0 PID: 606
> > > at /home/build-ws/develop/linux-
> > > 4.9.146/arch/x86/include/asm/fpu/internal.h:511
> > > fpu__restore+0x1eb/0x2b0 [  167.914216] Modules linked in:
> > > intel_rapl
> > > intel_powerclamp iTCO_wdt iTCO_vendor_support coretemp kvm_intel
> > > kvm
> > > irqbypass crc32_pclmul aesni_intel xts aes_i586 lrw gf128mul
> > > ablk_helper cryptd snd_pcm intel_cstate snd_timer evdev snd
> > > soundcore
> > > i915 pcspkr drm_kms_helper drm fb_sys_fops syscopyarea sysfillrect
> > > sysimgblt shpchp video lpc_ich mfd_core button ip_tables x_tables
> > > autofs4 ext4 crc16 jbd2 fscrypto mbcache hid_generic usbhid hid
> > > mmc_block crc32c_intel i2c_i801 i2c_smbus igb i2c_algo_bit
> > > xhci_pci ptp pps_core xhci_hcd sdhci_pci sdhci usbcore mmc_core
> > > fjes [last unloaded: rtnet] [  167.914768] CPU: 0 PID: 606 Comm:
> > > dohell Not tainted 4.9.146+ #1 [  167.914772] Hardware name:
> > > Default string Default string/Q7-BW, BIOS V1.20#KW050220A
> > > 03/16/2018 [  167.914775]
> > > I-pipe domain: Linux [  167.914778]  f42e5e44 daeffa2d 
> > > db335030 dac1ff3b f42e5e74 dac59dea db34504c
> > > [  167.914800]  
> > > 025e db335030 01ff dac1ff3b 01ff f4291bc0 0246
> > > [  167.914822]  f4291c00 f42e5e88 dac59efb 0009 
> > > 
> > > f42e5ea4 dac1ff3b [  167.914843] Call Trace:
> > > [  167.914846]  [] dump_stack+0x9f/0xc2
> > > [  167.914849]  [] ? fpu__restore+0x1eb/0x2b0
> > > [  167.914865]  [] __warn+0xea/0x110
> > > [  167.914868]  [] ? fpu__restore+0x1eb/0x2b0
> > > [  167.914871]  [] warn_slowpath_null+0x2b/0x30
> > > [  167.914874]  [] fpu__restore+0x1eb/0x2b0
> > > [  167.914877]  [] __fpu__restore_sig+0x2ba/0x680
> > > [  167.914879]  [] fpu__restore_sig+0x31/0x50
> > > [  167.914882]  [] restore_sigcontext.isra.9+0xf2/0x110
> > > [  167.914885]  [] sys_sigreturn+0xa9/0xc0
> > > [  167.914888]  [] do_int80_syscall_32+0x85/0x190
> > > [  167.914891]  [] entry_INT80_32+0x31/0x31
> > > [  167.914898]
> > > ---[ end trace e57344f10f300a76 ]---  
> > 
> > I am not sure which path leads you there. But it could well be a
> > state
> > that was caused by the ipipe patch.
> > 
> > could you try this:
> > 
> > --- a/arch/x86/kernel/fpu/core.c
> > +++ b/arch/x86/kernel/fpu/core.c
> > @@ -426,6 +426,10 @@ void fpu__restore(struct fpu *fpu)
> > /* Avoid __kernel_fpu_begin() right after fpregs_activate()
> > */
> > kernel_fpu_disable();
> > trace_x86_fpu_before_restore(fpu);
> > +   if (fpregs_activate(fpu)) {  
> 
> This instruction does not compile due to fpregs_activate() returns
> void, perhaps did you mean "if (fpregs_active(fpu))"?
> Given that fpregs_active() have no args, I tried with this:
> 
> if (fpu->fpregs_active)

I did not test what i wrote there, and your fix is what i meant.

> and warning does not raise (even warning added with this patch).

In that case a similar patch should probably be included upstream. I
will prepare a patch for that.

Henning

> > +   WARN_ON_FPU(fpu !=
> > this_cpu_read_stable(fpu_fpregs_owner_ctx));
> > +   fpregs_deactivate(fpu);
> > +   }
> > fpregs_activate(fpu);
>

Re: FPU warn on ipipe 4.9.146-8 i386

[Henning Schild via Xenomai]

Am Fri, 11 Jan 2019 09:57:50 +0100
schrieb Mauro Salvini via Xenomai :

> Hi all,
> 
> I'm testing same hardware of [1], with kernel 4.9.146 from ipipe-4.9.y
> with [2] applied, compiled with ARCH=i386 and Xenomai 3.0.7.

To be honest i386 is not really tested anymore, in fact in 4.14 not
even supported at the moment. If you can you should go for x86_64.

> Launching
> 
> xeno-test -l "dohell -s xxx -p yyy -m xxx 9" -T 9
> 
> I got this dump in dmesg, sometimes just after latency starts,
> sometimes after few seconds (side effect is a max latency value
> increase):
> 
> [  167.914184] [ cut here ]
> [  167.914208] WARNING: CPU: 0 PID: 606
> at 
> /home/build-ws/develop/linux-4.9.146/arch/x86/include/asm/fpu/internal.h:511
> fpu__restore+0x1eb/0x2b0 [  167.914216] Modules linked in: intel_rapl
> intel_powerclamp iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm
> irqbypass crc32_pclmul aesni_intel xts aes_i586 lrw gf128mul
> ablk_helper cryptd snd_pcm intel_cstate snd_timer evdev snd soundcore
> i915 pcspkr drm_kms_helper drm fb_sys_fops syscopyarea sysfillrect
> sysimgblt shpchp video lpc_ich mfd_core button ip_tables x_tables
> autofs4 ext4 crc16 jbd2 fscrypto mbcache hid_generic usbhid hid
> mmc_block crc32c_intel i2c_i801 i2c_smbus igb i2c_algo_bit xhci_pci
> ptp pps_core xhci_hcd sdhci_pci sdhci usbcore mmc_core fjes [last
> unloaded: rtnet] [  167.914768] CPU: 0 PID: 606 Comm: dohell Not
> tainted 4.9.146+ #1 [  167.914772] Hardware name: Default string
> Default string/Q7-BW, BIOS V1.20#KW050220A 03/16/2018 [  167.914775]
> I-pipe domain: Linux [  167.914778]  f42e5e44 daeffa2d 
> db335030 dac1ff3b f42e5e74 dac59dea db34504c [  167.914800]  
> 025e db335030 01ff dac1ff3b 01ff f4291bc0 0246
> [  167.914822]  f4291c00 f42e5e88 dac59efb 0009  
> f42e5ea4 dac1ff3b [  167.914843] Call Trace:
> [  167.914846]  [] dump_stack+0x9f/0xc2
> [  167.914849]  [] ? fpu__restore+0x1eb/0x2b0
> [  167.914865]  [] __warn+0xea/0x110
> [  167.914868]  [] ? fpu__restore+0x1eb/0x2b0
> [  167.914871]  [] warn_slowpath_null+0x2b/0x30
> [  167.914874]  [] fpu__restore+0x1eb/0x2b0
> [  167.914877]  [] __fpu__restore_sig+0x2ba/0x680
> [  167.914879]  [] fpu__restore_sig+0x31/0x50
> [  167.914882]  [] restore_sigcontext.isra.9+0xf2/0x110
> [  167.914885]  [] sys_sigreturn+0xa9/0xc0
> [  167.914888]  [] do_int80_syscall_32+0x85/0x190
> [  167.914891]  [] entry_INT80_32+0x31/0x31 [  167.914898]
> ---[ end trace e57344f10f300a76 ]---

I am not sure which path leads you there. But it could well be a state
that was caused by the ipipe patch.

could you try this:

--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -426,6 +426,10 @@ void fpu__restore(struct fpu *fpu)
/* Avoid __kernel_fpu_begin() right after fpregs_activate() */
kernel_fpu_disable();
trace_x86_fpu_before_restore(fpu);
+   if (fpregs_activate(fpu)) {
+   WARN_ON_FPU(fpu !=
this_cpu_read_stable(fpu_fpregs_owner_ctx));
+   fpregs_deactivate(fpu);
+   }
fpregs_activate(fpu);
copy_kernel_to_fpregs(&fpu->state);
trace_x86_fpu_after_restore(fpu);

This would not be a proper fix, especially if you end up seeing that
warning ...

Henning

> I found discussion at [3], and applied patch at [4] that comes from
> it, but result is the same.
> 
> Starting xeno-test without -l argument result is the same.
> Launching dohell alone (with same arguments as when launched from
> xeno- test -l), dump does not appear.
> 
> Could be a Xenomai-related problem (though the stack seems not concern
> Xenomai) or it is better to post it on LKML?
> 
> Thanks in advance, regards
> 
> Mauro
> 
> [1] https://xenomai.org/pipermail/xenomai/2018-December/040142.html
> [2] https://xenomai.org/pipermail/xenomai/2019-January/040172.html
> [3]
> https://lore.kernel.org/lkml/20181120102635.ddv3fvavxajjlfqk@linutr
> onix.de/ [4]
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/co
> mmit/?h=linux-4.9.y&id=d3741e0390287056011950493a641524f49fa05a
> 
> 

Re: [PATCHv2] cobalt/x86: fix condition in eager fpu code for kernels < 4.14

[Henning Schild via Xenomai]

Am Tue, 8 Jan 2019 15:17:11 +0100
schrieb Mauro Salvini :

> On Mon, 2019-01-07 at 14:04 +0100, Henning Schild wrote:
> > From: Henning Schild 
> > 
> > We should mark the current task as not owning the fpu anymore if it
> > does
> > actually own the fpu, not if the fpu itself is active.
> > 
> > Fixes cb52e6c7438fa
> > 
> > Reported-by: Mauro Salvini 
> > Signed-off-by: Henning Schild 
> > ---
> >  kernel/cobalt/arch/x86/thread.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/kernel/cobalt/arch/x86/thread.c
> > b/kernel/cobalt/arch/x86/thread.c
> > index a09560075..ba807ac1e 100644
> > --- a/kernel/cobalt/arch/x86/thread.c
> > +++ b/kernel/cobalt/arch/x86/thread.c
> > @@ -475,7 +475,7 @@ void xnarch_leave_root(struct xnthread *root)
> >     switch_fpu_finish(¤t->thread.fpu,
> > smp_processor_id()); #else
> >     /* mark current thread as not owning the FPU anymore */
> > -   if (¤t->thread.fpu.fpstate_active)
> > +   if (fpregs_active())
> >     fpregs_deactivate(¤t->thread.fpu);
> >  #endif
> >  }  
> 
> Hi all,
> 
> I tried to launch xeno-test several times under same previous
> conditions and I confirm that this patch fixes the bug.

Good to hear, thanks!

> A side note: would not #include in
> kernel/cobalt/arch/x86/thread.c lines 47,48 and 54 be redundant with
> same includes in kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
> (that is indirectly included in thread.c)?

The latter does not have those includes. It is still very possible
that there are a few too many but that is what you have inclusion guards
for. And the code you are looking at 47,48 and 54 is all to support
legacy/old kernels. You are in the IPIPE_X86_FPU_EAGER case.

Henning

> Thanks, regards
> Mauro

[PATCHv2] cobalt/x86: fix condition in eager fpu code for kernels < 4.14

[Henning Schild via Xenomai]

From: Henning Schild 

We should mark the current task as not owning the fpu anymore if it does
actually own the fpu, not if the fpu itself is active.

Fixes cb52e6c7438fa

Reported-by: Mauro Salvini 
Signed-off-by: Henning Schild 
---
 kernel/cobalt/arch/x86/thread.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/cobalt/arch/x86/thread.c b/kernel/cobalt/arch/x86/thread.c
index a09560075..ba807ac1e 100644
--- a/kernel/cobalt/arch/x86/thread.c
+++ b/kernel/cobalt/arch/x86/thread.c
@@ -475,7 +475,7 @@ void xnarch_leave_root(struct xnthread *root)
switch_fpu_finish(¤t->thread.fpu, smp_processor_id());
 #else
/* mark current thread as not owning the FPU anymore */
-   if (¤t->thread.fpu.fpstate_active)
+   if (fpregs_active())
fpregs_deactivate(¤t->thread.fpu);
 #endif
 }
-- 
2.19.2

Re: Stack dump on ipipe 4.9.135-7 x86_64

[Henning Schild via Xenomai]

Am Thu, 20 Dec 2018 10:10:29 +0100
schrieb Jan Kiszka :

> On 20.12.18 09:28, Mauro Salvini via Xenomai wrote:
> > Hi all,
> > 
> > I'm testing Xenomai 3 on an Intel Braswell board (Atom x5-E8000).
> > I'm using ipipe kernel at last commit from [1], branch ipipe-4.9.y,
> > 64bit build on a Debian Stretch 9.6 64bit.
> > Xenomai library is from [2], branch stable/v3.0.x on commit
> > bc53d03f (I haven't two last commits but seems not related). I
> > tried both 32bit (mixed ABI) and 64bit builds with same following
> > result.
> > 
> > I launch:
> > 
> > xeno-test -l "dohell -s xxx -p yyy -m xxx 9" -T 9
> > 
> > After a variable time (from minutes to hours) from latency test
> > start I get a few overruns that I discovered are generated by a
> > kernel stack dump (attached to mail the dmesg tail). Latency test
> > doesn't stop, and after this stackdump never reports other overruns
> > or latency peaks (seems I need to reboot to reproduce stack).
> > 
> > I read in this mailing list that on last patches much work has done
> > on FPU part, should it be related?
> > 
> > Glad to give other infos if you need.  
> 
> Thanks for reporting. Maybe we need your config later on, but I'm
> first of all looking at the code, see below.
> 
> In general, it's better to run the kernel with frame-pointers enabled
> to get more reliable backtraces, at least when an error occurs.
> 
> > 
> > Thanks in advance, regards.
> > 
> > Mauro
> > 
> > [1] https://gitlab.denx.de/Xenomai/ipipe
> > [2] https://gitlab.denx.de/Xenomai/xenomai
> > -- next part --
> > [  233.205940] 
> > /home/build-user/develop/linux-ipipe-4.9.y/arch/x86/xenomai/include/asm/xenomai/fptest.h:43:
> > Warning: Linux is compiled to use FPU in kernel-space. For this
> > reason, switchtest can not test using FPU in Linux kernel-space.
> > [  295.660454] [ cut here ] [  295.660461]
> > WARNING: CPU: 0 PID: 139
> > at 
> > /home/build-user/develop/linux-ipipe-4.9.y/arch/x86/include/asm/fpu/internal.h:502
> > xnarch_leave_root+0x1a4/0x1b0  
> 
> Henning, the kernel checks fpu->fpregs_active here and finds it off
> while Xenomai looks at fpu.fpstate_active - intentionally or by
> accident?

That was by accident. In eager mode they should mostly be in sync,
unless when playing the nasty tricks ipipe has to play. I guess there
is a path where we tried to "unown" a task that we unowned shortly
before. I did not try to find that path, i just sent a patch.

Mauro, since you can reproduce the problem you can probably tell if the
patch fixes it.

Henning

> Jan
> 
> > [  295.660465] Modules linked in: binfmt_misc msr iTCO_wdt
> > iTCO_vendor_support coretemp kvm_intel kvm irqbypass
> > crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel
> > aes_x86_64 lrw snd_pcm gf128mul glue_helper i915 ablk_helper
> > snd_timer cryptd snd soundcore pcspkr drm_kms_helper drm evdev
> > lpc_ich mfd_core fb_sys_fops syscopyarea sysfillrect sysimgblt sg
> > shpchp video button ip_tables x_tables autofs4 ext4 crc16 jbd2
> > fscrypto mbcache sd_mod hid_generic usbhid hid crc32c_intel ahci
> > igb i2c_i801 libahci i2c_smbus i2c_algo_bit xhci_pci dca ptp
> > pps_core libata xhci_hcd sdhci_pci sdhci usbcore scsi_mod mmc_core
> > fjes [last unloaded: rtnet] [  295.660660] CPU: 0 PID: 139 Comm:
> > jbd2/sda1-8 Tainted: GW   4.9.135+ #1 [  295.660663]
> > Hardware name: Default string Default string/Q7-BW, BIOS
> > V1.20#KW050220A 03/16/2018 [  295.660666] I-pipe domain: Xenomai
> > [  295.660668]   823402c2 
> >  [  295.660680]  829cd400 8206cb68
> > 985636908040 985636504080 [  295.660706]  00099f50
> >  bc1580563040 98567ac9b940 [  295.660718]
> > Call Trace: [  295.660721]  [] ?
> > dump_stack+0xb5/0xd3 [  295.660724]  [] ?
> > __warn+0xc8/0xf0 [  295.660727]  [] ?
> > xnarch_leave_root+0x1a4/0x1b0 [  295.660729]
> > [] ? ___xnsched_run+0x3f6/0x4b0 [  295.660732]
> > [] ? timerfd_handler+0x36/0x50 [  295.660735]
> > [] ? xntimerq_insert+0x5/0xa0 [  295.660738]
> > [] ? xnclock_tick+0x1a9/0x2c0 [  295.660740]
> > [] ? xnintr_core_clock_handler+0x2fa/0x310
> > [  295.660743]  [] ? dispatch_irq_head+0x8a/0x120
> > [  295.660746]  [] ?
> > __ipipe_handle_irq+0x85/0x1b0 [  295.660749]
> > [] ? apic_timer_interrupt+0x89/0xb0
> > [  295.660752]  [] ? continue_block+0x22/0x54
> > [crc32c_intel] [  295.660754]  [] ?
> > crc32c_pcl_intel_update+0x53/0x60 [crc32c_intel] [  295.660757]
> > [] ? jbd2_journal_commit_transaction+0x9e0/0x1850
> > [jbd2] [  295.660760]  [] ?
> > __switch_to_asm+0x40/0x70 [  295.660763]  [] ?
> > try_to_del_timer_sync+0x4f/0x80 [  295.660766]
> > [] ? kjournald2+0xe2/0x290 [jbd2] [  295.660768]
> > [] ? wake_up_atomic_t+0x30/0x30 [  295.660771]
> > [] ? commit_timeout+0x10/0x10 [jbd2]
> > [  295.660774]  [] ? kthread+0xf5/0x110
> > [  295.660776]  [] ? __switch_to_asm+0x40/0x70
> > [  295.660779]

[PATCH] cobalt/x86: fix condition in eager fpu code for kernels < 4.14

[Henning Schild via Xenomai]

From: Henning Schild 

We should mark the current task as not owning the fpu anymore if it does
actually own the fpu, not if the fpu itself is active.

Fixes cb52e6c7438fa

Reported-by: Mauro Salvini 
Signed-off-by: Henning Schild 
---
 kernel/cobalt/arch/x86/thread.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/cobalt/arch/x86/thread.c b/kernel/cobalt/arch/x86/thread.c
index a09560075..0c6054338 100644
--- a/kernel/cobalt/arch/x86/thread.c
+++ b/kernel/cobalt/arch/x86/thread.c
@@ -475,7 +475,7 @@ void xnarch_leave_root(struct xnthread *root)
switch_fpu_finish(¤t->thread.fpu, smp_processor_id());
 #else
/* mark current thread as not owning the FPU anymore */
-   if (¤t->thread.fpu.fpstate_active)
+   if (¤t->thread.fpu.fpregs_active)
fpregs_deactivate(¤t->thread.fpu);
 #endif
 }
-- 
2.19.2

Re: [PATCH] testsuite/xeno-test: do not swallow exit status anymore

[Henning Schild via Xenomai]

Am Fri, 16 Nov 2018 07:28:51 +0100
schrieb Jan Kiszka :

> On 08.11.18 13:42, Henning Schild via Xenomai wrote:
> > xeno-test-run always returned SUCCESS, even if its children exited
> > with non zero. So xeno-test can not be used programmatically i.e.
> > in CI.
> > 
> > This patch adds some more verbosity and makes xeno-test-run exit
> > FAILURE if at least one child returned non-zero.
> > 
> > Signed-off-by: Henning Schild 
> > ---
> >   testsuite/xeno-test/xeno-test-run.c | 16 +++-
> >   1 file changed, 15 insertions(+), 1 deletion(-)
> > 
> > diff --git a/testsuite/xeno-test/xeno-test-run.c
> > b/testsuite/xeno-test/xeno-test-run.c index bfede63fd..6d1bb96c0
> > 100644 --- a/testsuite/xeno-test/xeno-test-run.c
> > +++ b/testsuite/xeno-test/xeno-test-run.c
> > @@ -51,6 +51,8 @@ void handle_checked_child(struct child *child,
> > fd_set *fds); void handle_script_child(struct child *child, fd_set
> > *fds); void handle_load_child(struct child *child, fd_set *fds);
> >   
> > +static int exit_global = EXIT_SUCCESS;
> > +
> >   static inline time_t mono_time(void)
> >   {
> > struct timespec ts;
> > @@ -319,6 +321,18 @@ void sigchld_handler(int sig)
> >   
> > child->exit_status = status;
> > child->dead = 1;
> > +   fprintf(stderr, "child %d returned: ", pid);
> > +   if (WIFEXITED(status)) {
> > +   if (WEXITSTATUS(status))
> > +   exit_global = EXIT_FAILURE;
> > +   fprintf(stderr, "exited with status %d\n",
> > +   WEXITSTATUS(status));
> > +   } else if WIFSIGNALED(status) {
> > +   fprintf(stderr, "killed by signal %d\n",
> > +   WTERMSIG(status));
> > +   } else {
> > +   fprintf(stderr, "unknown reason\n");
> > +   }
> > }
> >   }
> >   
> > @@ -660,5 +674,5 @@ int main(int argc, char *argv[])
> > signal(sigexit, SIG_DFL);
> > raise(sigexit);
> > }
> > -   exit(EXIT_SUCCESS);
> > +   exit(exit_global);
> >   }
> >   
> 
> Merged to next.

With author "via Xenomai", i will always include a "From:" from now on.
But should be something to double-check before merging.

Henning

> Thanks,
> Jan
> 

Re: [PATCH] testsuite/smokey: relax posix-clock time dependancy

[Henning Schild via Xenomai]

Am Mon, 19 Nov 2018 10:52:34 +0100
schrieb Philippe Gerum :

> On 11/19/18 10:40 AM, Henning Schild wrote:
> > Am Fri, 16 Nov 2018 07:23:47 +0100
> > schrieb Jan Kiszka :
> >   
> >> On 09.11.18 10:14, Henning Schild via Xenomai wrote:  
> >>> The test often asserted. This patch gives the thread a priority,
> >>> introduces a 25us margin and prints the value in case we still
> >>> fail.
> >>>
> >>> Signed-off-by: Henning Schild 
> >>> ---
> >>>   testsuite/smokey/posix-clock/posix-clock.c | 15 ++-
> >>>   1 file changed, 14 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/testsuite/smokey/posix-clock/posix-clock.c
> >>> b/testsuite/smokey/posix-clock/posix-clock.c index
> >>> f672a9d52..36e0f5dea 100644 ---
> >>> a/testsuite/smokey/posix-clock/posix-clock.c +++
> >>> b/testsuite/smokey/posix-clock/posix-clock.c @@ -417,8 +417,10 @@
> >>> static int clock_decrease_after_periodic_timer_first_tick(void) 
> >>>   diff = now.tv_sec * 10ULL + now.tv_nsec -
> >>>   (timer.it_value.tv_sec * 10ULL +
> >>> timer.it_value.tv_nsec);
> >>> - if (!smokey_assert(diff < 10))
> >>> + if (!smokey_assert(diff < 10ULL + 25000ULL))
> >>> {
> >>
> >> Philippe, is this margin also reasonable from your perspective? Or
> >> are we risking to miss a problem this way? I'm currently lacking a
> >> feeling.  
> > 
> > Good question. That is an estimate suitable for x86. While it should
> > not defeat the test, the test failing 60% of the time renders it not
> > too useful.
> >   
> 
> Did you calibrate the timer shot with the autotune utility before
> running that test?

I also saw it failing after calibration, otherwise i would have added
the calibration to xeno-test.

Henning

Re: [PATCH] testsuite/smokey: relax posix-clock time dependancy

[Henning Schild via Xenomai]

Am Fri, 16 Nov 2018 07:23:47 +0100
schrieb Jan Kiszka :

> On 09.11.18 10:14, Henning Schild via Xenomai wrote:
> > The test often asserted. This patch gives the thread a priority,
> > introduces a 25us margin and prints the value in case we still fail.
> > 
> > Signed-off-by: Henning Schild 
> > ---
> >   testsuite/smokey/posix-clock/posix-clock.c | 15 ++-
> >   1 file changed, 14 insertions(+), 1 deletion(-)
> > 
> > diff --git a/testsuite/smokey/posix-clock/posix-clock.c
> > b/testsuite/smokey/posix-clock/posix-clock.c index
> > f672a9d52..36e0f5dea 100644 ---
> > a/testsuite/smokey/posix-clock/posix-clock.c +++
> > b/testsuite/smokey/posix-clock/posix-clock.c @@ -417,8 +417,10 @@
> > static int clock_decrease_after_periodic_timer_first_tick(void) 
> > diff = now.tv_sec * 10ULL + now.tv_nsec -
> > (timer.it_value.tv_sec * 10ULL +
> > timer.it_value.tv_nsec);
> > -   if (!smokey_assert(diff < 10))
> > +   if (!smokey_assert(diff < 10ULL + 25000ULL)) {  
> 
> Philippe, is this margin also reasonable from your perspective? Or
> are we risking to miss a problem this way? I'm currently lacking a
> feeling.

Good question. That is an estimate suitable for x86. While it should
not defeat the test, the test failing 60% of the time renders it not
too useful.

Henning

> Thanks,
> Jan
> 
> > +   fprintf(stderr, "diff = %llu\n", diff);
> > return -EINVAL;
> > +   }
> > 
> > ret = smokey_check_errno(read(t, &ticks, sizeof(ticks)));
> > if (ret < 0)
> > @@ -430,10 +432,21 @@ static int
> > clock_decrease_after_periodic_timer_first_tick(void) return
> > smokey_check_errno(close(t)); }
> >   
> > +static int init_posix_clock(void)
> > +{
> > +   struct sched_param params = {.sched_priority = 1};
> > +
> > +   return pthread_setschedparam(pthread_self(), SCHED_FIFO,
> > ¶ms); +}
> > +
> >   static int run_posix_clock(struct smokey_test *t, int argc, char
> > *const argv[]) {
> > int ret;
> >   
> > +   ret = init_posix_clock();
> > +   if (ret)
> > +   return ret;
> > +
> > ret = clock_increase_before_oneshot_timer_first_tick();
> > if (ret)
> > return ret;
> >   
> 

[PATCH] testsuite/smokey: relax posix-clock time dependancy

[Henning Schild via Xenomai]

The test often asserted. This patch gives the thread a priority,
introduces a 25us margin and prints the value in case we still fail.

Signed-off-by: Henning Schild 
---
 testsuite/smokey/posix-clock/posix-clock.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/testsuite/smokey/posix-clock/posix-clock.c 
b/testsuite/smokey/posix-clock/posix-clock.c
index f672a9d52..36e0f5dea 100644
--- a/testsuite/smokey/posix-clock/posix-clock.c
+++ b/testsuite/smokey/posix-clock/posix-clock.c
@@ -417,8 +417,10 @@ static int 
clock_decrease_after_periodic_timer_first_tick(void)
 
diff = now.tv_sec * 10ULL + now.tv_nsec -
(timer.it_value.tv_sec * 10ULL + 
timer.it_value.tv_nsec);
-   if (!smokey_assert(diff < 10))
+   if (!smokey_assert(diff < 10ULL + 25000ULL)) {
+   fprintf(stderr, "diff = %llu\n", diff);
return -EINVAL;
+   }

ret = smokey_check_errno(read(t, &ticks, sizeof(ticks)));
if (ret < 0)
@@ -430,10 +432,21 @@ static int 
clock_decrease_after_periodic_timer_first_tick(void)
return smokey_check_errno(close(t));
 }
 
+static int init_posix_clock(void)
+{
+   struct sched_param params = {.sched_priority = 1};
+
+   return pthread_setschedparam(pthread_self(), SCHED_FIFO, ¶ms);
+}
+
 static int run_posix_clock(struct smokey_test *t, int argc, char *const argv[])
 {
int ret;
 
+   ret = init_posix_clock();
+   if (ret)
+   return ret;
+
ret = clock_increase_before_oneshot_timer_first_tick();
if (ret)
return ret;
-- 
2.19.1

Re: Segmentation error 6 in rt_heap_create() without --enable-pshared

[Henning Schild via Xenomai]

Am Thu, 8 Nov 2018 10:17:44 +0100
schrieb Philippe Gerum :

> On 11/7/18 4:09 PM, Henning Schild wrote:
> > Am Wed, 7 Nov 2018 14:31:10 +0100
> > schrieb Philippe Gerum :
> >   
> >> On 11/7/18 2:00 PM, Henning Schild via Xenomai wrote:  
> >>> Readding list ...
> >>> 
> >>
> >> Does this help?
> >>
> >> diff --git a/lib/copperplate/heapobj-heapmem.c
> >> b/lib/copperplate/heapobj-heapmem.c index 5c0ce9b2d..124fe564a
> >> 100644 --- a/lib/copperplate/heapobj-heapmem.c
> >> +++ b/lib/copperplate/heapobj-heapmem.c
> >> @@ -33,8 +33,8 @@ int __heapobj_init_private(struct heapobj *hobj,
> >> const char *name, int ret;
> >>  
> >>if (mem == NULL) {
> >> -  _mem = __STD(malloc(size));
> >> -  if (_mem == NULL)
> >> +  mem = __STD(malloc(size));
> >> +  if (mem == NULL)
> >>return -ENOMEM;
> >>}
> >>
> >> @@ -43,16 +43,16 @@ int __heapobj_init_private(struct heapobj
> >> *hobj, const char *name, else
> >>snprintf(hobj->name, sizeof(hobj->name), "%p",
> >> hobj); 
> >> -  ret = heapmem_init(hobj->pool, _mem, size);
> >> +  hobj->pool = mem;
> >> +  hobj->size = size;
> >> +
> >> +  ret = heapmem_init(hobj->pool, mem, size);  
> > 
> > ret = -EINVAL  
> 
> Part of the solution in this patch (on top of the previous one), but
> more changes are needed for a complete fix:

Ok, that helps. Can you prepare a patch?

Henning

> diff --git a/lib/copperplate/heapobj-heapmem.c
> b/lib/copperplate/heapobj-heapmem.c index 124fe564a..3961bd054 100644
> --- a/lib/copperplate/heapobj-heapmem.c
> +++ b/lib/copperplate/heapobj-heapmem.c
> @@ -33,6 +33,7 @@ int __heapobj_init_private(struct heapobj *hobj,
> const char *name, int ret;
>  
>   if (mem == NULL) {
> + size = HEAPMEM_ARENA_SIZE(size); /* Count meta-data
> in. */ mem = __STD(malloc(size));
>   if (mem == NULL)
>   return -ENOMEM;
> @@ -60,7 +61,7 @@ int heapobj_init_array_private(struct heapobj
> *hobj, const char *name, size_t size, int elems)
>  {
>   return __bt(__heapobj_init_private(hobj, name,
> -HEAPMEM_ARENA_SIZE(size * elems), NULL));
> +size * elems, NULL));
>  }
>  
>  int heapobj_pkg_init_private(void)
> 

[PATCH] testsuite/xeno-test: do not swallow exit status anymore

[Henning Schild via Xenomai]

xeno-test-run always returned SUCCESS, even if its children exited with
non zero. So xeno-test can not be used programmatically i.e. in CI.

This patch adds some more verbosity and makes xeno-test-run exit FAILURE
if at least one child returned non-zero.

Signed-off-by: Henning Schild 
---
 testsuite/xeno-test/xeno-test-run.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/testsuite/xeno-test/xeno-test-run.c 
b/testsuite/xeno-test/xeno-test-run.c
index bfede63fd..6d1bb96c0 100644
--- a/testsuite/xeno-test/xeno-test-run.c
+++ b/testsuite/xeno-test/xeno-test-run.c
@@ -51,6 +51,8 @@ void handle_checked_child(struct child *child, fd_set *fds);
 void handle_script_child(struct child *child, fd_set *fds);
 void handle_load_child(struct child *child, fd_set *fds);
 
+static int exit_global = EXIT_SUCCESS;
+
 static inline time_t mono_time(void)
 {
struct timespec ts;
@@ -319,6 +321,18 @@ void sigchld_handler(int sig)
 
child->exit_status = status;
child->dead = 1;
+   fprintf(stderr, "child %d returned: ", pid);
+   if (WIFEXITED(status)) {
+   if (WEXITSTATUS(status))
+   exit_global = EXIT_FAILURE;
+   fprintf(stderr, "exited with status %d\n",
+   WEXITSTATUS(status));
+   } else if WIFSIGNALED(status) {
+   fprintf(stderr, "killed by signal %d\n",
+   WTERMSIG(status));
+   } else {
+   fprintf(stderr, "unknown reason\n");
+   }
}
 }
 
@@ -660,5 +674,5 @@ int main(int argc, char *argv[])
signal(sigexit, SIG_DFL);
raise(sigexit);
}
-   exit(EXIT_SUCCESS);
+   exit(exit_global);
 }
-- 
2.19.1

Re: Segmentation error 6 in rt_heap_create() without --enable-pshared

[Henning Schild via Xenomai]

Am Wed, 7 Nov 2018 14:31:10 +0100
schrieb Philippe Gerum :

> On 11/7/18 2:00 PM, Henning Schild via Xenomai wrote:
> > Readding list ...
> >   
> 
> Does this help?
> 
> diff --git a/lib/copperplate/heapobj-heapmem.c
> b/lib/copperplate/heapobj-heapmem.c index 5c0ce9b2d..124fe564a 100644
> --- a/lib/copperplate/heapobj-heapmem.c
> +++ b/lib/copperplate/heapobj-heapmem.c
> @@ -33,8 +33,8 @@ int __heapobj_init_private(struct heapobj *hobj,
> const char *name, int ret;
>  
>   if (mem == NULL) {
> - _mem = __STD(malloc(size));
> - if (_mem == NULL)
> + mem = __STD(malloc(size));
> + if (mem == NULL)
>   return -ENOMEM;
>   }
>   
> @@ -43,16 +43,16 @@ int __heapobj_init_private(struct heapobj *hobj,
> const char *name, else
>   snprintf(hobj->name, sizeof(hobj->name), "%p", hobj);
>  
> - ret = heapmem_init(hobj->pool, _mem, size);
> + hobj->pool = mem;
> + hobj->size = size;
> +
> + ret = heapmem_init(hobj->pool, mem, size);

ret = -EINVAL

Henning

>   if (ret) {
> - if (mem == NULL)
> - __STD(free(_mem));
> + if (_mem == NULL)
> + __STD(free(mem));
>   return ret;
>   }
>  
> - hobj->pool = _mem;
> - hobj->size = size;
> -
>   return 0;
>  }
> 

Fw: Segmentation error 6 in rt_heap_create() without --enable-pshared

[Henning Schild via Xenomai]

Readding list ...

Beginn der weitergeleiteten Nachricht:

Datum: Wed, 7 Nov 2018 13:55:53 +0100
Von: Henning Schild 
An: Xenomai 
Cc: Jan Kiszka , Philippe Gerum
, Petr Červenka  Betreff: Re:
Segmentation error 6 in rt_heap_create() without --enable-pshared


Am Wed, 7 Nov 2018 13:10:34 +0100
schrieb Henning Schild :

> Am Tue, 6 Nov 2018 19:04:51 +0100
> schrieb Jan Kiszka via Xenomai :
>   
> > On 05.11.18 16:48, Petr Červenka wrote:
> > >> Only? Sorry for insisting, but it may help to reduce the search
> > >> space, and it's also important as I'd like to release a new
> > >> stable version - without known issues.
> > >  > 
> > >> Thanks,
> > >> Jan
> > >  >  
> > >  
> > > I can confirm now, that the problem happens only with the master
> > > branch. Petr
> > >   
> > 
> > Thanks. Philippe, any idea?
> 
> I was just looking into an issue in the dlopen-test. Turns out it is a
> segfault from rt_queue_create that only shows in "--enable-dlopen-libs
> --disable-pshared".
> 
> Will at least try and bisect my way to where that was introduced.  

Got it:
# first new commit: [fa39f253518101d0d31dc946ecdde55afb1b88b2]
copperplate/heapobj: enable heapmem for private memory

Henning

> Henning
>   
> > Jan
> > 
>   

Re: [I-PIPE] ipipe-core-4.14.71-x86-1 released

[Henning Schild via Xenomai]

Am Thu, 1 Nov 2018 18:38:47 +0100
schrieb Philippe Gerum :

> On 11/1/18 5:59 PM, Petr Červenka wrote:
> > Hello.
> >  
> > Is it really finished?
> > I have problems to compile the patched kernel.
> >  
> > At first, when it compiles machine.c, there is such error:
> >   CC  arch/x86/xenomai/machine.o
> > In file included from ./include/asm-generic/xenomai/syscall.h:23:0,
> >  from
> > arch/x86/xenomai/include/asm/xenomai/syscall.h:24, from
> > arch/x86/xenomai/machine.c:22: ./arch/x86/include/asm/uaccess.h: In
> > function ‘set_fs’: ./arch/x86/include/asm/uaccess.h:33:9: error:
> > dereferencing pointer to incomplete type ‘struct task_struct’
> > current->thread.addr_limit = fs; ^~
> >  
> > After an ad-hoc fix, there are some other errors for example during
> > compiling of thread.c, mostly connected to fpu: fpu.fpregs_active,
> > fpu.active_state, __fpregs_deactivate(), __fpregs_activate(),
> > clts(), stts(), SLAB_NOTRACK, ... Am I doing something wrong?
> >    
> 
> You are likely not using the proper Xenomai branch, you need -next.

I would not suggest next, master and stable/v3.0.x should do. But
v3.0.7 and older will not work.

As far as i understood we will soon have a v3.1, for people that like
their releases ;).

Henning

Re: [Xenomai] Cobolt core not enabled in kernel

[Henning Schild]

Alec,

are you happy with the current 4.14 amd64, looks like your issue was
just something done wrong in the build process.

Henning

Am Sat, 20 Oct 2018 21:25:47 +
schrieb Alec Ari :

> Ah, prepare-kernel.sh does a bit more than just apply the IPIPE
> patch. I didn't know this, thanks! Alec
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] ipipe-4.14: planned release date

[Henning Schild]

Am Mon, 15 Oct 2018 10:56:41 +
schrieb "Schrenkhammer, Martin" :

> Hi Jan,
> 
> now I run into another problem. My Board does a reset right after
> "Loading initial ramdisk..." It is an AMD Ryzon Embedded V1000. There
> are no logs to kern.log I already tried disabling CONFIG_MAXSMP.
> Original 4.14.71 boots without problems.
> 
> Any ideas?

Any updates on that? We are about to release 4.14 amd64 so any known
open issues should be fixed before.

Please check 361b1bac5d903d2199903a5cb3d6e0fbc3c604ae together with
xenomai/master.

Henning

> Thanks,
> Martin
> 
> 
> -Ursprüngliche Nachricht-
> Von: Xenomai [mailto:xenomai-boun...@xenomai.org] Im Auftrag von
> Schrenkhammer, Martin Gesendet: Donnerstag, 11. Oktober 2018 21:00
> An: Jan Kiszka; xenomai@xenomai.org
> Betreff: Re: [Xenomai] ipipe-4.14: planned release date
> 
> That solved the problem. Thanks a lot for your help!
> 
> Martin
> 11.10.2018 2:22 nachm. schrieb Jan Kiszka  :
> On 11.10.18 11:21, Schrenkhammer, Martin wrote:
> > Thanks for your reply.
> > Checked again today with your latest commit
> > 20db5ea2eee38b123c9641003fe55c895a1fd514 with same errors. I wanted
> > to run a first build without modifications (beside
> > prepare-kernel.sh and make menuconfig to append a local version.
> > Maybe you can send my your actual x86 config and I can check
> > differences and adopt to my platform. Mine .config is enclosed.  
> 
> Reproduced: The actual problem is related to CONFIG_HYPERV which
> selects CONFIG_PARAVIRT which conflicts with CONFIG_IPIPE.
> 
> Furthermore, you want to disable CONFIG_SCHED_MC so that you can also
> turn off the power management features Xenomai complains about.
> 
> And then there is CONFIG_TRANSPARENT_HUGEPAGE and CONFIG_CMA. When
> both are off, you can also disable COMPACTION and MIGRATION.
> 
> In general, it's not optimal to start from a distro config without
> further tuning.
> 
> Jan
> 
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
> 
> 
> Vertrauliche E-Mail von / Confidential e-mail from Data Modul AG
> Vorstand / CEO: Dr. Florian Pesahl
> Vorsitzende des Aufsichtsrates / Chairwoman of the Supervisory Board:
> Kristin D. Russell Sitz der Gesellschaft / Registered Office: München
> Registergericht / Registration Court: München - Handelsregister B 85
> 591
> 
> Datamodul
> [cid:0021-0001@01d46194.a5f3ebae]
> -- next part --
> A non-text attachment was scrubbed...
> Name: ECS-electronica_2018_d.gif
> Type: image/gif
> Size: 8162 bytes
> Desc: ECS-electronica_2018_d.gif
> URL:
> 
> ___ Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai
> 
> Vertrauliche E-Mail von / Confidential e-mail from: DATA MODUL AG
> Vorstand / CEO: Dr. Florian Pesahl
> Vorsitzende des Aufsichtsrates / Chairwoman of the Supervisory Board:
> Kristin D. Russell Sitz der Gesellschaft / Registered Office: München
> Registergericht / Registration Court: München Handelsregister B 85 591
> 
> 
> 
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] ipipe-4.14: planned release date

[Henning Schild]

Is there an ipipe patch we can derive from that? So include the
conflict into the kconfigs.

Henning

Am Thu, 11 Oct 2018 14:23:11 +0200
schrieb "[ext] Jan Kiszka" :

> On 11.10.18 11:21, Schrenkhammer, Martin wrote:
> > Thanks for your reply.
> > Checked again today with your latest commit
> > 20db5ea2eee38b123c9641003fe55c895a1fd514 with same errors. I wanted
> > to run a first build without modifications (beside
> > prepare-kernel.sh and make menuconfig to append a local version.
> > Maybe you can send my your actual x86 config and I can check
> > differences and adopt to my platform. Mine .config is enclosed.  
> 
> Reproduced: The actual problem is related to CONFIG_HYPERV which
> selects CONFIG_PARAVIRT which conflicts with CONFIG_IPIPE.
> 
> Furthermore, you want to disable CONFIG_SCHED_MC so that you can also
> turn off the power management features Xenomai complains about.
> 
> And then there is CONFIG_TRANSPARENT_HUGEPAGE and CONFIG_CMA. When
> both are off, you can also disable COMPACTION and MIGRATION.
> 
> In general, it's not optimal to start from a distro config without
> further tuning.
> 
> Jan
> 

Re: [ipipe 4.14][PATCH] x86: ipipe: Fix trap hooking for userspace routes

[Henning Schild]

Am Fri, 26 Oct 2018 14:32:36 +0100
schrieb Jan Kiszka :

> On 26.10.18 13:50, Henning Schild wrote:
> > Hey,
> > 
> > looks like this one is for the #PF from the sigdebug smokey test.
> > With this patch applied i do not see the crash anymore, but the
> > test gets stuck.
> > Did it work for you, or did i get the context wrong?  
> 
> Yes, this solved the issue for me, and I was able to finish the test.
> But that might be related to configuration variations (I think I sent
> my configuration earlier to the list).

I was still using a modified copy of the test, looks like it works just
fine. I guess we can release if we are ok with not supporting x86_32
for now ... or for the future.

Henning

> Jan
> 
> > 
> > Henning
> > 
> > Am Wed, 10 Oct 2018 13:05:28 +0200
> > schrieb Jan Kiszka :
> >   
> >> Also hook into the trap path when the exception was taken over
> >> userspace code.
> >>
> >> Fixes: e6b81a0ce7fb (x86: ipipe: route traps to co-kernel)
> >> Signed-off-by: Jan Kiszka 
> >> ---
> >>
> >> Makes sense? I'm not feeling 100% safe yet /wrt paranoid and the
> >> userspace path. Should we handle this identically to the kernel
> >> path or not?
> >>
> >> Eventually this should be merged into the original patch, at least
> >> on next major rebase.
> >>
> >>   arch/x86/entry/entry_64.S | 80
> >> +++ 1 file changed, 46
> >> insertions(+), 34 deletions(-)
> >>
> >> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> >> index f6fe849d66ed..42e31d1fddc6 100644
> >> --- a/arch/x86/entry/entry_64.S
> >> +++ b/arch/x86/entry/entry_64.S
> >> @@ -904,6 +904,46 @@ ENTRY(switch_to_thread_stack)
> >>ret
> >>   END(switch_to_thread_stack)
> >>   
> >> +.macro ipipe_idtentry_prologue paranoid=0 trapnr=-1
> >> skip_label=-invalid- +#ifdef CONFIG_IPIPE
> >> +  movqEFLAGS(%rsp), %r14  /*
> >> regs->flags */
> >> +  movq%rsp, %rdi  /* pt_regs
> >> pointer */
> >> +  movl$\trapnr, %esi  /* trap
> >> number */
> >> +  subq$8, %rsp
> >> +  movq%rsp, %rdx  /* &flags */
> >> +  call__ipipe_trap_prologue
> >> +  popq%r13
> >> +  mov %rax, %r12  /* save
> >> propagation status */
> >> +  .if \paranoid == 0  /* paranoid may
> >> not skip handler */
> >> +  testl   %eax, %eax
> >> +  jg  \skip_label /* skip
> >> regular handler if > 0 */
> >> +  .endif
> >> +#endif
> >> +.endm
> >> +
> >> +.macro ipipe_idtentry_epilogue paranoid=0 skip_label=-invalid-
> >> +#ifdef CONFIG_IPIPE
> >> +  testl   %r12d, %r12d
> >> +  jnz 1000f
> >> +  movq%rsp, %rdi  /* pt_regs
> >> pointer */
> >> +  movq%r13, %rsi  /* &flags
> >> from prologue */
> >> +  movq%r14, %rdx  /* original
> >> regs->flags before fixup */
> >> +  call__ipipe_trap_epilogue
> >> +1000:
> >> +  .if \paranoid == 0  /* paranoid
> >> implies normal epilogue */
> >> +  testl   %r12d, %r12d
> >> +  jz  1001f
> >> +\skip_label:
> >> +  UNWIND_HINT_REGS
> >> +  DISABLE_INTERRUPTS(CLBR_ANY)
> >> +  testl   %ebx, %ebx  /* %ebx: return to kernel
> >> mode */
> >> +  jnz retint_kernel_early
> >> +  jmp retint_user_early
> >> +  .endif
> >> +1001:
> >> +#endif
> >> +.endm
> >> +
> >>   .macro idtentry sym do_sym has_error_code:req paranoid=0
> >> shift_ist=-1 trapnr=-1 ENTRY(\sym)
> >>UNWIND_HINT_IRET_REGS offset=\has_error_code*8
> >> @@ -940,20 +980,7 @@ ENTRY(\sym)
> >>.endif
> >>.endif
> >>   
> >> -#ifdef CONFIG_IPIPE
> >> -  movqEFLAGS(%rsp), %r14  /*
> >> regs->flags */
> >> -  movq%rsp, %rdi  /* pt_regs
> >> pointer */
> >> -  movl$\trapnr, %esi  /* trap
> >> number */
> >> -  subq$8, %rsp
> >> -  movq%rsp, %rdx  /* &flags */
> >> -  call__ipipe_trap_prologue
> >> 

Re: [ipipe 4.14][PATCH] x86: ipipe: Fix trap hooking for userspace routes

[Henning Schild]

Hey,

looks like this one is for the #PF from the sigdebug smokey test. With
this patch applied i do not see the crash anymore, but the test gets
stuck.
Did it work for you, or did i get the context wrong?

Henning

Am Wed, 10 Oct 2018 13:05:28 +0200
schrieb Jan Kiszka :

> Also hook into the trap path when the exception was taken over
> userspace code.
> 
> Fixes: e6b81a0ce7fb (x86: ipipe: route traps to co-kernel)
> Signed-off-by: Jan Kiszka 
> ---
> 
> Makes sense? I'm not feeling 100% safe yet /wrt paranoid and the
> userspace path. Should we handle this identically to the kernel path
> or not?
> 
> Eventually this should be merged into the original patch, at least on
> next major rebase.
> 
>  arch/x86/entry/entry_64.S | 80
> +++ 1 file changed, 46
> insertions(+), 34 deletions(-)
> 
> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> index f6fe849d66ed..42e31d1fddc6 100644
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -904,6 +904,46 @@ ENTRY(switch_to_thread_stack)
>   ret
>  END(switch_to_thread_stack)
>  
> +.macro ipipe_idtentry_prologue paranoid=0 trapnr=-1
> skip_label=-invalid- +#ifdef CONFIG_IPIPE
> + movqEFLAGS(%rsp), %r14  /* regs->flags
> */
> + movq%rsp, %rdi  /* pt_regs
> pointer */
> + movl$\trapnr, %esi  /* trap
> number */
> + subq$8, %rsp
> + movq%rsp, %rdx  /* &flags */
> + call__ipipe_trap_prologue
> + popq%r13
> + mov %rax, %r12  /* save
> propagation status */
> + .if \paranoid == 0  /* paranoid may
> not skip handler */
> + testl   %eax, %eax
> + jg  \skip_label /* skip regular
> handler if > 0 */
> + .endif
> +#endif
> +.endm
> +
> +.macro ipipe_idtentry_epilogue paranoid=0 skip_label=-invalid-
> +#ifdef CONFIG_IPIPE
> + testl   %r12d, %r12d
> + jnz 1000f
> + movq%rsp, %rdi  /* pt_regs
> pointer */
> + movq%r13, %rsi  /* &flags from
> prologue */
> + movq%r14, %rdx  /* original
> regs->flags before fixup */
> + call__ipipe_trap_epilogue
> +1000:
> + .if \paranoid == 0  /* paranoid
> implies normal epilogue */
> + testl   %r12d, %r12d
> + jz  1001f
> +\skip_label:
> + UNWIND_HINT_REGS
> + DISABLE_INTERRUPTS(CLBR_ANY)
> + testl   %ebx, %ebx  /* %ebx: return to kernel
> mode */
> + jnz retint_kernel_early
> + jmp retint_user_early
> + .endif
> +1001:
> +#endif
> +.endm
> +
>  .macro idtentry sym do_sym has_error_code:req paranoid=0
> shift_ist=-1 trapnr=-1 ENTRY(\sym)
>   UNWIND_HINT_IRET_REGS offset=\has_error_code*8
> @@ -940,20 +980,7 @@ ENTRY(\sym)
>   .endif
>   .endif
>  
> -#ifdef CONFIG_IPIPE
> - movqEFLAGS(%rsp), %r14  /* regs->flags
> */
> - movq%rsp, %rdi  /* pt_regs
> pointer */
> - movl$\trapnr, %esi  /* trap
> number */
> - subq$8, %rsp
> - movq%rsp, %rdx  /* &flags */
> - call__ipipe_trap_prologue
> - popq%r13
> - mov %rax, %r12  /* save
> propagation status */
> - .if \paranoid == 0  /* paranoid may
> not skip handler */
> - testl   %eax, %eax
> - jg  98f /* skip regular
> handler if > 0 */
> - .endif
> -#endif
> + ipipe_idtentry_prologue paranoid=\paranoid trapnr=\trapnr
> skip_label=kernel_skip_\@ 
>   movq%rsp, %rdi  /* pt_regs
> pointer */ 
> @@ -970,26 +997,7 @@ ENTRY(\sym)
>  
>   call\do_sym
>  
> -#ifdef CONFIG_IPIPE
> - testl   %r12d, %r12d
> - jnz 97f
> - movq%rsp, %rdi  /* pt_regs
> pointer */
> - movq%r13, %rsi  /* &flags from
> prologue */
> - movq%r14, %rdx  /* original
> regs->flags before fixup */
> - call__ipipe_trap_epilogue
> -97:
> - .if \paranoid == 0  /* paranoid
> implies normal epilogue */
> - testl   %r12d, %r12d
> - jz  99f
> -98:
> - UNWIND_HINT_REGS
> - DISABLE_INTERRUPTS(CLBR_ANY)
> - testl   %ebx, %ebx  /* %ebx: return to kernel
> mode */
> - jnz retint_kernel_early
> - jmp retint_user_early
> - .endif
> -99:
> -#endif
> + ipipe_idtentry_epilogue paranoid=\paranoid
> skip_label=kernel_skip_\@ 
>   .if \shift_ist != -1
>   addq$EXCEPTION_STKSZ, CPU_TSS_IST(\shift_ist)
> @@ -1011,6 +1019,8 @@ ENTRY(\sym)
>  .Lfrom_usermode_switch_stack_\@:
>   callerror_entry
>  
> + ipipe_idtentry_prologue paranoid=\paranoid trapnr=\trapnr
> skip_label=user_skip_\@ +
>   movq%rsp, %rdi  

Re: [Xenomai] [I-PIPE][PATCH 00/32] 4.14.71/x86_64 port (split series)

[Henning Schild]

Am Mon, 1 Oct 2018 17:03:52 +0200
schrieb Philippe Gerum :

> On 10/01/2018 04:51 PM, Henning Schild wrote:
> > Am Thu, 27 Sep 2018 14:42:03 +0200
> > schrieb "[ext] Henning Schild" :
> >   
> >> Thanks! I just tried it on my test setup. All looking good except
> >> for one smokey test.
> >>  
> >>>  ./smokey --trace --run=sigdebug
> >>
> >> Crashes the box without any further feedback, also nothing on the
> >> serial.
> >>
> >> Will look into that.  
> > 
> > I already found that the page-fault caused by sigdebug is causing
> > the problem.
> > 
> > ./smokey --verbose=42 --trace=42 --run=sigdebug
> > 
> > Gave me more output. The "*mem = 0xff;" is the last thing it does.
> > Did not look into the kernel(s) and the page-fault handler yet.  
> 
> This looks like the PF event not being reported through the pipeline
> via the __ipipe_notify_trap() call. This points the finger to
> __ipipe_trap_prologue() (or whatever code should call it but does
> not).

I instrumented __ipipe_trap_prologue and did not even see the #PF
there. So it is either in the assembly before that or we do not have
the trap handler mapped or something like that. nopcid and nopti did
not help.
For further analysis i would likely have to move my setup to kvm. Can
anyone actually reproduce this?

Since i will be out of office in the next two weeks, i will not be able
to investigate further before 10/22.

Henning



___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PULL] A couple of fixes to the split series for x86

[Henning Schild]

Applied to https://git.xenomai.org/ipipe-x86.git wip/4.14-split

Thanks!
Henning


Am Mon, 1 Oct 2018 15:28:06 +0200
schrieb Philippe Gerum :

> The following changes since commit
> be45333e3af13c3b7cb12ecd200cb9be7a8fb439:
> 
>   x86: ipipe: do not panic on unexpected IRQ trap (2018-09-27
> 09:09:52 +0200)
> 
> are available in the Git repository at:
> 
>   https://lab.xenomai.org/ipipe-rpm.git x86/4.14.71
> 
> for you to fetch changes up to
> c5540da918650be520d8f5331ec1944ccfcf6c53:
> 
>   sched/core: ipipe: do not panic on failed migration to the head
> stage (2018-10-01 15:10:59 +0200)
> 
> 
> Philippe Gerum (2):
>   ipipe: timer: prevent double-ack if host timer is not grabbed
>   sched/core: ipipe: do not panic on failed migration to the head
> stage
> 
>  kernel/ipipe/timer.c | 11 +++
>  kernel/sched/core.c  |  2 --
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [I-PIPE][PATCH 00/32] 4.14.71/x86_64 port (split series)

[Henning Schild]

Am Thu, 27 Sep 2018 14:42:03 +0200
schrieb "[ext] Henning Schild" :

> Thanks! I just tried it on my test setup. All looking good except for
> one smokey test.
> 
> >  ./smokey --trace --run=sigdebug  
> 
> Crashes the box without any further feedback, also nothing on the
> serial.
> 
> Will look into that.

I already found that the page-fault caused by sigdebug is causing the
problem.

./smokey --verbose=42 --trace=42 --run=sigdebug

Gave me more output. The "*mem = 0xff;" is the last thing it does. Did
not look into the kernel(s) and the page-fault handler yet.

Henning

> Henning
> 
> Am Tue, 25 Sep 2018 12:37:37 +0200
> schrieb Philippe Gerum :
> 
> > This is a port of the interrupt pipeline to kernel 4.14.71 for
> > x86_64, based on the split series published earlier this year [1].
> > 
> > The architecture-specific bits have been reworked to become a series
> > of incremental changes on top of the -noarch tree [2], enabling a
> > feature one at a time, which should ease future kernel upgrades.
> > 
> > The topmost patch disables native 32bit support which was not
> > ported. Support for x32 and ia32 emulation ABIs over long mode is
> > still there and working though.
> > 
> > [1] https://www.xenomai.org/pipermail/xenomai/2018-July/039302.html
> > [2] https://git.xenomai.org/ipipe-noarch
> > 
> > 
> > Henning Schild (2):
> >   x86: fix include for drivers
> >   x86: ipipe fpu support
> > 
> > Philippe Gerum (30):
> >   x86: lockdep: ipipe: make the logic aware of interrupt pipelining
> >   x86: ipipe: add pipeline core
> >   x86: context_tracking: disable if CONFIG_IPIPE
> >   x86: paravirt: disable if CONFIG_IPIPE
> >   x86/iommu: enable interrupt pipelining
> >   x86/htirq: ipipe: enable interrupt pipelining
> >   x86/i8259: ipipe: enable interrupt pipelining
> >   x86/mm: enable PTE pinning
> >   x86: ipipe: share context switch code with head domain
> >   x86/mtrr: ipipe: protect against preemption from head stage
> >   x86/tsc: ipipe: keep calibration accurate
> >   x86: ipipe: notify about GTOD update
> >   x86/kgdb: ipipe: enable support from head domain
> >   x86/vm86_32: ipipe: protect against preemption from head domain
> >   x86/kvm: ipipe: enable shared control with head domain
> >   x86/mmx32: ipipe: use slow copy from head domain
> >   x86/nmi: ipipe: disallow user copy from head domain
> >   x86: ipipe: route traps to co-kernel
> >   x86: ipipe: route syscalls to co-kernel
> >   x86/irq: ipipe: map the cleanup vector to a legit IRQ number
> >   x86/fpu: ipipe: add inline qualifier to kernel_fpu_*() helpers
> >   x86: ipipe: fix interrupt state in syscall routing
> >   x86/irq: ipipe: reconcile lockdep tracing with virtual IRQ state
> >   x86/mm: ipipe: fix lockdep tracing upon PF
> >   x86/msi: ipipe: advertise pipelining support
> >   x86: ipipe: fix stack overflow detection
> >   x86: ipipe: restrict WARN_ON_IN_IRQ() to the root domain
> >   x86: ipipe: remove 32bit support from shared context switch code
> >   x86: ipipe: drop (obsolete) declarations
> >   x86: ipipe: disable 32bit support
> > 
> >  arch/x86/Kconfig|  10 +-
> >  arch/x86/entry/common.c |  98 +-
> >  arch/x86/entry/entry_64.S   | 145 +++--
> >  arch/x86/entry/thunk_32.S   |   1 +
> >  arch/x86/entry/thunk_64.S   |   1 +
> >  arch/x86/entry/vsyscall/vsyscall_gtod.c |   4 +
> >  arch/x86/include/asm/apic.h |  10 +
> >  arch/x86/include/asm/debugreg.h |   2 +-
> >  arch/x86/include/asm/desc.h |   2 +-
> >  arch/x86/include/asm/fpu/internal.h |  20 ++
> >  arch/x86/include/asm/i8259.h|   2 +-
> >  arch/x86/include/asm/ipipe.h|  73 +
> >  arch/x86/include/asm/ipipe_base.h   | 151 +
> >  arch/x86/include/asm/irq_vectors.h  |  17 +-
> >  arch/x86/include/asm/irqflags.h | 198 +++-
> >  arch/x86/include/asm/mmu_context.h  |   6 +-
> >  arch/x86/include/asm/thread_info.h  |  14 +
> >  arch/x86/include/asm/tsc.h  |   1 +
> >  arch/x86/include/asm/uaccess.h  |   3 +-
> >  arch/x86/kernel/Makefile|   1 +
> >  arch/x86/kernel/apic/apic.c |  46 ++-
> >  arch/x86/kernel/apic/apic_flat_64.c |   4 +-
> >  arch/x86/kernel/apic/htirq.c|   5 +-
> >  arch/x86/kernel/apic/io_apic.c  | 182 ++-
> >  arch/x86/kernel/apic/ipi.c  |  29 +-
> >  arch

Re: [Xenomai] ipipe for 4.14 x86?

[Henning Schild]

Am Sun, 30 Sep 2018 20:38:22 +
schrieb Alec Ari :

> This message is meant to be part of the preexisting thread, "ipipe
> for 4.14 x86?"
> 
> I see that 4.14 development is in a branch labeled "split." I read
> through this already:
> https://www.xenomai.org/pipermail/xenomai/2018-September/039458.html
> 
> So the base functionality of IPIPE is still the same, but with the
> split series, this makes commits and code changes easier to dissect?
> 
> When 4.14 support reaches this page:
> https://xenomai.org/downloads/ipipe/v4.x/x86/
> 
> How different will the final patch be to the rest of the patches? Is
> the structure for the most part the same and follow the same pattern
> as the other patches, or will a patch derived from "split" have other
> changes in the final patch? Are all the changes in the split series
> purely cosmetic compared to the other IPIPE patches? Are there even
> any changes to the kernel compared to the other IPIPE patches, or is
> this purely breaking up commits? I'm a bit confused as to how this
> affects the final ipipe-core patches as that is what I use for a
> baseline, not the IPIPE git repos.

This is a change in how the "patch" is structured internally for
developers only. If you look into the git history we always had more
than one patch being part of the "patch", starting from 4.14 the
granularity will be increased.

You will still get one patch to apply to your random vendor kernel that
roughly matches ;).

Henning

> Thank you!
> 
> Alec
> 
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] ipipe for 4.14 x86?

[Henning Schild]

Am Mon, 17 Sep 2018 15:39:08 +0200
schrieb Richard Weinberger :

> Hi!
> 
> Are there plans to have an x86 ipipe for kernel 4.14?
> If there is something missing or needs testing I'm all open to help!
> 

I have pushed the latest version from Philippe to "wip/4.14-split". So 
everyone interested in the topic should maybe use that.

https://gitlab.denx.de/Xenomai/ipipe-x86/tree/wip/4.14-split

This is what Philippe sent as "[I-PIPE][PATCH 00/32] 4.14.71/x86_64
port (split series)".

That was a force push the branches "henning/wip/*" are gone now.

Henning

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [I-PIPE][PATCH 00/32] 4.14.71/x86_64 port (split series)

[Henning Schild]

Thanks! I just tried it on my test setup. All looking good except for
one smokey test.

>  ./smokey --trace --run=sigdebug

Crashes the box without any further feedback, also nothing on the
serial.

Will look into that.

Henning

Am Tue, 25 Sep 2018 12:37:37 +0200
schrieb Philippe Gerum :

> This is a port of the interrupt pipeline to kernel 4.14.71 for x86_64,
> based on the split series published earlier this year [1].
> 
> The architecture-specific bits have been reworked to become a series
> of incremental changes on top of the -noarch tree [2], enabling a
> feature one at a time, which should ease future kernel upgrades.
> 
> The topmost patch disables native 32bit support which was not
> ported. Support for x32 and ia32 emulation ABIs over long mode is
> still there and working though.
> 
> [1] https://www.xenomai.org/pipermail/xenomai/2018-July/039302.html
> [2] https://git.xenomai.org/ipipe-noarch
> 
> 
> Henning Schild (2):
>   x86: fix include for drivers
>   x86: ipipe fpu support
> 
> Philippe Gerum (30):
>   x86: lockdep: ipipe: make the logic aware of interrupt pipelining
>   x86: ipipe: add pipeline core
>   x86: context_tracking: disable if CONFIG_IPIPE
>   x86: paravirt: disable if CONFIG_IPIPE
>   x86/iommu: enable interrupt pipelining
>   x86/htirq: ipipe: enable interrupt pipelining
>   x86/i8259: ipipe: enable interrupt pipelining
>   x86/mm: enable PTE pinning
>   x86: ipipe: share context switch code with head domain
>   x86/mtrr: ipipe: protect against preemption from head stage
>   x86/tsc: ipipe: keep calibration accurate
>   x86: ipipe: notify about GTOD update
>   x86/kgdb: ipipe: enable support from head domain
>   x86/vm86_32: ipipe: protect against preemption from head domain
>   x86/kvm: ipipe: enable shared control with head domain
>   x86/mmx32: ipipe: use slow copy from head domain
>   x86/nmi: ipipe: disallow user copy from head domain
>   x86: ipipe: route traps to co-kernel
>   x86: ipipe: route syscalls to co-kernel
>   x86/irq: ipipe: map the cleanup vector to a legit IRQ number
>   x86/fpu: ipipe: add inline qualifier to kernel_fpu_*() helpers
>   x86: ipipe: fix interrupt state in syscall routing
>   x86/irq: ipipe: reconcile lockdep tracing with virtual IRQ state
>   x86/mm: ipipe: fix lockdep tracing upon PF
>   x86/msi: ipipe: advertise pipelining support
>   x86: ipipe: fix stack overflow detection
>   x86: ipipe: restrict WARN_ON_IN_IRQ() to the root domain
>   x86: ipipe: remove 32bit support from shared context switch code
>   x86: ipipe: drop (obsolete) declarations
>   x86: ipipe: disable 32bit support
> 
>  arch/x86/Kconfig|  10 +-
>  arch/x86/entry/common.c |  98 +-
>  arch/x86/entry/entry_64.S   | 145 +++--
>  arch/x86/entry/thunk_32.S   |   1 +
>  arch/x86/entry/thunk_64.S   |   1 +
>  arch/x86/entry/vsyscall/vsyscall_gtod.c |   4 +
>  arch/x86/include/asm/apic.h |  10 +
>  arch/x86/include/asm/debugreg.h |   2 +-
>  arch/x86/include/asm/desc.h |   2 +-
>  arch/x86/include/asm/fpu/internal.h |  20 ++
>  arch/x86/include/asm/i8259.h|   2 +-
>  arch/x86/include/asm/ipipe.h|  73 +
>  arch/x86/include/asm/ipipe_base.h   | 151 +
>  arch/x86/include/asm/irq_vectors.h  |  17 +-
>  arch/x86/include/asm/irqflags.h | 198 +++-
>  arch/x86/include/asm/mmu_context.h  |   6 +-
>  arch/x86/include/asm/thread_info.h  |  14 +
>  arch/x86/include/asm/tsc.h  |   1 +
>  arch/x86/include/asm/uaccess.h  |   3 +-
>  arch/x86/kernel/Makefile|   1 +
>  arch/x86/kernel/apic/apic.c |  46 ++-
>  arch/x86/kernel/apic/apic_flat_64.c |   4 +-
>  arch/x86/kernel/apic/htirq.c|   5 +-
>  arch/x86/kernel/apic/io_apic.c  | 182 ++-
>  arch/x86/kernel/apic/ipi.c  |  29 +-
>  arch/x86/kernel/apic/msi.c  |  20 +-
>  arch/x86/kernel/apic/vector.c   |  13 +-
>  arch/x86/kernel/apic/x2apic_cluster.c   |   4 +-
>  arch/x86/kernel/apic/x2apic_phys.c  |   4 +-
>  arch/x86/kernel/asm-offsets.c   |   3 +
>  arch/x86/kernel/cpu/common.c|   2 +
>  arch/x86/kernel/cpu/mtrr/cyrix.c|  12 +-
>  arch/x86/kernel/cpu/mtrr/generic.c  |  12 +-
>  arch/x86/kernel/fpu/core.c  |  58 ++--
>  arch/x86/kernel/i8259.c |  31 +-
>  arch/x86/kernel/idt.c   |  24 ++
>  arch/x86/kernel/ipipe.c | 528
> 
> arch/x86/kernel/irq.c   |   5 +-
> arch/x86/kernel/irq_64.c|  12 +-
> arch/x86/kernel/kgdb.

Re: [Xenomai] ipipe 4.14 causing kernel stuck at "Loading initial ramdisk...", failed to boot on x86

[Henning Schild]

Am Wed, 26 Sep 2018 18:24:50 +0800
schrieb c ww :

> Hi all,
> 
> I was able to get it through by disabling the CONFIG_MAXSMP somehow.
> However, when i compiling the 4.14 kernel again from the
> henning/wip/4.14-split branch, it gave bunch of errors related to
> fpu.  :(

You will also need an unreleased version of xenomai, namely the "next"
branch. It contains fpu fixes needed for 4.14 x86.

Henning

> 
> 
> On Wednesday, September 26, 2018, c ww  wrote:
> 
> > Hi All,
> >
> > I wish to try use ipipe 4.14 with Xenomai 3 on x86 platform (core
> > i7-7700) running in Ubuntu linux. So i follow the discussion on the
> > email thread
> > ( https://www.mail-archive.com/xenomai@xenomai.org/msg14309.html),
> > downloaded the ipipe 4.14 repo, switched to henning/wip/4.14-split
> > branch as suggested by henning. From the xconfig, enabled the
> > CONFIG_IPIPE option and compiled the 4.14.58 kernel from the repo.
> > Upon compilation completed, trying to boot using the new compiled
> > kernel (4.14.58+), but it always hang at very beginning "Loading
> > initial ramdisk".
> >
> > One thing i have verified and confirmed, when i compiled the 4.14.58
> > kernel *without *CONFIG_IPIPE option enable in kernel, the kernel
> > can be booted successfully. But once it is enabled, then the new
> > compiled kernel will always hang at "Loading initial ramdisk...".
> > So, may i know if anyone encounter similar issue with the
> > henning/wip/4.14-split branch and any workaround we can put in
> > place?
> >
> > Appreciate your kind advise on this...thanks!
> >
> >  
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [IPIPE] [PATCHv2] x86: make fpu switching eager

[Henning Schild]

Am Tue, 25 Sep 2018 13:20:57 +0200
schrieb Jan Kiszka :

> On 14.09.18 18:14, Henning Schild wrote:
> > Linux 4.14 dropped support for lazy fpu switching and in the 4.4
> > and 4.9 series similar changes where backported.
> > So fpu is eager for those versions. That simplifies things a lot
> > and we can drop several changes from the IPIPE patch.
> > On the Xenomai side the only thing we still have to care about is
> > the kernel fpu state when we interrupt an in kernel fpu user. But
> > we do that explicit and can drop the indirection active_(fp)state.
> > 
> > This patch basically drops most of the fpu specifics from the ipipe
> > patch.
> > 
> > This patch applies on ipipe-4.9.y and it has to be followed by a
> > merge with  
> >> = 4.9.109. Cobalt will not compile if you are already eager and
> >> still  
> > 4.9.108
> > 
> > Signed-off-by: Henning Schild 
> > ---
> >   arch/x86/include/asm/fpu/internal.h | 30
> > - arch/x86/include/asm/fpu/types.h|
> > 12  arch/x86/kernel/fpu/core.c  | 17
> > ++-- arch/x86/kernel/fpu/init.c  |  5 +
> >   4 files changed, 15 insertions(+), 49 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/fpu/internal.h
> > b/arch/x86/include/asm/fpu/internal.h index
> > 35ca184e83e1..6bdceba90f17 100644 ---
> > a/arch/x86/include/asm/fpu/internal.h +++
> > b/arch/x86/include/asm/fpu/internal.h @@ -13,7 +13,6 @@
> >   #include 
> >   #include 
> >   #include 
> > -#include 
> >   #include 
> >   
> >   #include 
> > @@ -190,24 +189,12 @@ static inline int copy_user_to_fregs(struct
> > fregs_state __user *fx) return user_insn(frstor %[fx], "=m" (*fx),
> > [fx] "m" (*fx)); }
> >   
> > -#ifdef CONFIG_IPIPE
> > -static inline union fpregs_state *active_fpstate(struct fpu *fpu)
> > -{
> > -   return fpu->active_state;
> > -}
> > -#else
> > -static inline union fpregs_state *active_fpstate(struct fpu *fpu)
> > -{
> > -   return &fpu->state;
> > -}
> > -#endif
> > -
> >   static inline void copy_fxregs_to_kernel(struct fpu *fpu)
> >   {
> > if (IS_ENABLED(CONFIG_X86_32))
> > -   asm volatile( "fxsave %[fx]" : [fx]
> > "=m" (active_fpstate(fpu)->fxsave));
> > +   asm volatile( "fxsave %[fx]" : [fx]
> > "=m" (fpu->state.fxsave)); else if (IS_ENABLED(CONFIG_AS_FXSAVEQ))
> > -   asm volatile("fxsaveq %[fx]" : [fx]
> > "=m" (active_fpstate(fpu)->fxsave));
> > +   asm volatile("fxsaveq %[fx]" : [fx]
> > "=m" (fpu->state.fxsave)); else {
> > /* Using "rex64; fxsave %0" is broken because, if
> > the memory
> >  * operand uses any extended registers for
> > addressing, a second @@ -231,8 +218,8 @@ static inline void
> > copy_fxregs_to_kernel(struct fpu *fpu)
> >  * registers.
> >  */
> > asm volatile( "rex64/fxsave (%[fx])"
> > - : "=m" (active_fpstate(fpu)->fxsave)
> > - : [fx]
> > "R" (&active_fpstate(fpu)->fxsave));
> > + : "=m" (fpu->state.fxsave)
> > + : [fx] "R" (&fpu->state.fxsave));
> > }
> >   }
> >   
> > @@ -441,7 +428,7 @@ static inline int copy_user_to_xregs(struct
> > xregs_state __user *buf, u64 mask) static inline int
> > copy_fpregs_to_fpstate(struct fpu *fpu) {
> > if (likely(use_xsave())) {
> > -   copy_xregs_to_kernel(&active_fpstate(fpu)->xsave);
> > +   copy_xregs_to_kernel(&fpu->state.xsave);
> > return 1;
> > }
> >   
> > @@ -454,7 +441,7 @@ static inline int copy_fpregs_to_fpstate(struct
> > fpu *fpu)
> >  * Legacy FPU register saving, FNSAVE always clears FPU
> > registers,
> >  * so we have to mark them inactive:
> >  */
> > -   asm volatile("fnsave %[fp]; fwait" : [fp]
> > "=m" (active_fpstate(fpu)->fsave));
> > +   asm volatile("fnsave %[fp]; fwait" : [fp]
> > "=m" (fpu->state.fsave)); 
> > return 0;
> >   }
> > @@ -609,8 +596,7 @@ switch_fpu_prepare(struct fpu *old_fpu, struct
> > fpu *new_fpu, int cpu)
> >  * If the task has used the math, pre-load t

Re: [Xenomai] [PATCHv2 4/4] cobalt/x86: add ipipe-4.14 eager fpu support

[Henning Schild]

Am Mon, 17 Sep 2018 21:18:48 +0200
schrieb "[ext] Henning Schild" :

> Am Mon, 17 Sep 2018 20:23:16 +0200
> schrieb Jan Kiszka :
> 
> > On 17.09.18 20:17, Jan Kiszka wrote:  
> > > On 14.09.18 17:10, Henning Schild wrote:
> > >> 4.14 is always eager, unfortunately we will need a few ifdefs
> > >> inside the eager fpu support as well.
> > >>
> > >> Signed-off-by: Henning Schild 
> > >> ---
> > >>   .../arch/x86/include/asm/xenomai/wrappers.h   |  4 
> > >>   kernel/cobalt/arch/x86/thread.c   | 21
> > >> ++- 2 files changed, 24 insertions(+), 1
> > >> deletion(-)
> > >>
> > >> diff --git
> > >> a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
> > >> b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h index
> > >> a47730106..a4cc368a5 100644 ---
> > >> a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h +++
> > >> b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h @@ -32,6
> > >> +32,10 @@ LINUX_VERSION_CODE < KERNEL_VERSION(4,5,0)
> > >>   #define IPIPE_X86_FPU_EAGER
> > >>   #endif
> > >> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0)
> > >> +#define IPIPE_X86_FPU_EAGER
> > >> +#endif
> > >> +
> > >>   #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
> > >>   #include 
> > >> diff --git a/kernel/cobalt/arch/x86/thread.c
> > >> b/kernel/cobalt/arch/x86/thread.c index 18cf636e5..2668ce274
> > >> 100644 --- a/kernel/cobalt/arch/x86/thread.c
> > >> +++ b/kernel/cobalt/arch/x86/thread.c
> > >> @@ -42,6 +42,7 @@ static struct kmem_cache *xstate_cache;
> > >>   #define cpu_has_xsave boot_cpu_has(X86_FEATURE_XSAVE)
> > >>   #endif
> > >> +#ifndef IPIPE_X86_FPU_EAGER
> > >>   #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
> > >>   #include 
> > >>   #include 
> > >> @@ -72,6 +73,9 @@ static inline void x86_fpregs_activate(struct
> > >> task_struct *t) #define x86_xstate_alignment
> > >> __alignof__(union fpregs_state) #endif
> > >> +#else /* IPIPE_X86_FPU_EAGER */
> > >> +#define x86_xstate_alignment    __alignof__(union
> > >> fpregs_state) +#endif /* ! IPIPE_X86_FPU_EAGER */
> > >>   #if LINUX_VERSION_CODE < KERNEL_VERSION(4,8,0)
> > >>   /*
> > >> @@ -465,9 +469,15 @@ void xnarch_leave_root(struct xnthread
> > >> *root) // save fpregs from in-kernel use
> > >>   copy_fpregs_to_fpstate(rootcb->kfpu);
> > >>   kernel_fpu_enable();
> > >> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0)
> > >> +    // restore current's fpregs
> > >> +    __cpu_invalidate_fpregs_state();
> > >> +    switch_fpu_finish(¤t->thread.fpu, smp_processor_id());
> > >> +#else
> > >>   // mark current thread as not owning the FPU anymore
> > >>   if (¤t->thread.fpu.fpstate_active)
> > >>   fpregs_deactivate(¤t->thread.fpu);
> > >> +#endif
> > >>   }
> > >>   void xnarch_switch_fpu(struct xnthread *from, struct xnthread
> > >> *to) @@ -528,7 +538,11 @@ void xnarch_init_shadow_tcb(struct
> > >> xnthread *thread) #else /* IPIPE_X86_FPU_EAGER */
> > >>   /* XNFPU is always set */
> > >>   xnthread_set_state(thread, XNFPU);
> > >> +#if LINUX_VERSION_CODE < KERNEL_VERSION(4,14,0)
> > >>   fpu__activate_fpstate_read(&p->thread.fpu);
> > >> +#else
> > >> +    fpu__initialize(&p->thread.fpu);
> > >> +#endif
> > >>   #endif /* ! IPIPE_X86_FPU_EAGER */
> > >>   }
> > >> @@ -537,7 +551,12 @@ int mach_x86_thread_init(void)
> > >>   xstate_cache = kmem_cache_create("cobalt_x86_xstate",
> > >>    fpu_kernel_xstate_size,
> > >>    x86_xstate_alignment,
> > >> - SLAB_NOTRACK, NULL);
> > >> +#if LINUX_VERSION_CODE < KERNEL_VERSION(4,14,0)
> > >> + SLAB_NOTRACK,
> > >> +#else
> > >> + 0,
> > >> +#endif
> > >> + NULL);
> > >>   if (xstate_cache == NULL)
> > >>   return -ENOMEM;
> > >>
> > > 
> > > Thanks, taken the whol

Re: [Xenomai] ipipe for 4.14 x86?

[Henning Schild]

Am Tue, 18 Sep 2018 10:52:05 +0200
schrieb Richard Weinberger :

> Jan,
> 
> On Mon, Sep 17, 2018 at 8:10 PM Jan Kiszka 
> wrote:
> >
> > On 17.09.18 15:39, Richard Weinberger wrote:  
> > > Hi!
> > >
> > > Are there plans to have an x86 ipipe for kernel 4.14?
> > > If there is something missing or needs testing I'm all open to
> > > help! 
> >
> > Henning and Philippe are on this, and there is progress as Henning
> > just reported today to me. Maybe just a matter of days, and then we
> > indeed need intensive testing by the community!  
> 
> Is this repo/branch the right one when I want to give ipipe x86 a try?
> Maybe I can help fixing issues too!
> https://gitlab.denx.de/Xenomai/ipipe-x86/tree/wip/4.14-split
> 

This one contains a few more fixes.

https://gitlab.denx.de/Xenomai/ipipe-x86/tree/henning/wip/4.14-split

Both are mainly tested under KVM. The 16 core Xeon i am currently
testing on runs into some timer init issues and gets stuck at boot.

Feedback welcome!

Henning

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCHv2 4/4] cobalt/x86: add ipipe-4.14 eager fpu support

[Henning Schild]

Am Mon, 17 Sep 2018 20:23:16 +0200
schrieb Jan Kiszka :

> On 17.09.18 20:17, Jan Kiszka wrote:
> > On 14.09.18 17:10, Henning Schild wrote:  
> >> 4.14 is always eager, unfortunately we will need a few ifdefs
> >> inside the eager fpu support as well.
> >>
> >> Signed-off-by: Henning Schild 
> >> ---
> >>   .../arch/x86/include/asm/xenomai/wrappers.h   |  4 
> >>   kernel/cobalt/arch/x86/thread.c   | 21
> >> ++- 2 files changed, 24 insertions(+), 1
> >> deletion(-)
> >>
> >> diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h 
> >> b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
> >> index a47730106..a4cc368a5 100644
> >> --- a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
> >> +++ b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
> >> @@ -32,6 +32,10 @@
> >>   LINUX_VERSION_CODE < KERNEL_VERSION(4,5,0)
> >>   #define IPIPE_X86_FPU_EAGER
> >>   #endif
> >> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0)
> >> +#define IPIPE_X86_FPU_EAGER
> >> +#endif
> >> +
> >>   #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
> >>   #include 
> >> diff --git a/kernel/cobalt/arch/x86/thread.c
> >> b/kernel/cobalt/arch/x86/thread.c index 18cf636e5..2668ce274 100644
> >> --- a/kernel/cobalt/arch/x86/thread.c
> >> +++ b/kernel/cobalt/arch/x86/thread.c
> >> @@ -42,6 +42,7 @@ static struct kmem_cache *xstate_cache;
> >>   #define cpu_has_xsave boot_cpu_has(X86_FEATURE_XSAVE)
> >>   #endif
> >> +#ifndef IPIPE_X86_FPU_EAGER
> >>   #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
> >>   #include 
> >>   #include 
> >> @@ -72,6 +73,9 @@ static inline void x86_fpregs_activate(struct
> >> task_struct *t) #define x86_xstate_alignment
> >> __alignof__(union fpregs_state) #endif
> >> +#else /* IPIPE_X86_FPU_EAGER */
> >> +#define x86_xstate_alignment    __alignof__(union
> >> fpregs_state) +#endif /* ! IPIPE_X86_FPU_EAGER */
> >>   #if LINUX_VERSION_CODE < KERNEL_VERSION(4,8,0)
> >>   /*
> >> @@ -465,9 +469,15 @@ void xnarch_leave_root(struct xnthread *root)
> >>   // save fpregs from in-kernel use
> >>   copy_fpregs_to_fpstate(rootcb->kfpu);
> >>   kernel_fpu_enable();
> >> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0)
> >> +    // restore current's fpregs
> >> +    __cpu_invalidate_fpregs_state();
> >> +    switch_fpu_finish(¤t->thread.fpu, smp_processor_id());
> >> +#else
> >>   // mark current thread as not owning the FPU anymore
> >>   if (¤t->thread.fpu.fpstate_active)
> >>   fpregs_deactivate(¤t->thread.fpu);
> >> +#endif
> >>   }
> >>   void xnarch_switch_fpu(struct xnthread *from, struct xnthread
> >> *to) @@ -528,7 +538,11 @@ void xnarch_init_shadow_tcb(struct
> >> xnthread *thread) #else /* IPIPE_X86_FPU_EAGER */
> >>   /* XNFPU is always set */
> >>   xnthread_set_state(thread, XNFPU);
> >> +#if LINUX_VERSION_CODE < KERNEL_VERSION(4,14,0)
> >>   fpu__activate_fpstate_read(&p->thread.fpu);
> >> +#else
> >> +    fpu__initialize(&p->thread.fpu);
> >> +#endif
> >>   #endif /* ! IPIPE_X86_FPU_EAGER */
> >>   }
> >> @@ -537,7 +551,12 @@ int mach_x86_thread_init(void)
> >>   xstate_cache = kmem_cache_create("cobalt_x86_xstate",
> >>    fpu_kernel_xstate_size,
> >>    x86_xstate_alignment,
> >> - SLAB_NOTRACK, NULL);
> >> +#if LINUX_VERSION_CODE < KERNEL_VERSION(4,14,0)
> >> + SLAB_NOTRACK,
> >> +#else
> >> + 0,
> >> +#endif
> >> + NULL);
> >>   if (xstate_cache == NULL)
> >>   return -ENOMEM;
> >>  
> > 
> > Thanks, taken the whole series to next so that we can move forward.
> > I've just changed "//" (C++) style comments to "old-style" C.
> > Kernel style. Please avoid them in the future.
> >   

Sorry missed the // part of the review.

> Forgot: Did you happen to try the series with stable-3.0.x as well? I
> consider them relevant for that branch as well, so that users can
> update the kernel. But I plan to leave them in next until we have
> ipipe kernels available and tested them a bit broader.

Did not do that yet. I guess the ifdefs should all resolve to lazy-fpu,
making the series a no-op for lazy kernels. Will test against 4.9 and
4.4 and confirm that my guess is right.

Henning

> Jan
> 


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCH] gitignore: add build output for in-tree builds

[Henning Schild]

This is the only new patch, the rest was still sitting in the
send-email directory ... sorry for the spam.

Henning

Am Fri, 14 Sep 2018 18:14:38 +0200
schrieb Henning Schild :

> This adds all build output to .gitignore. Not everybody works out of
> tree, or knows that this option exists. So let us add all build output
> to .gitignore. While this names all our binaries and has the risk of
> getting out of sync, it at least makes "git status" human readable
> again.
> 
> Signed-off-by: Henning Schild 
> ---
>  .gitignore | 67
> ++ 1 file
> changed, 67 insertions(+)
> 
> diff --git a/.gitignore b/.gitignore
> index b1d682032..a054a65af 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -15,3 +15,70 @@ config/missing
>  configure
>  aclocal.m4
>  autom4te.cache
> +Makefile
> +.deps
> +config.log
> +config.status
> +include/stamp-h1
> +include/xeno_config.h
> +libtool
> +scripts/xeno
> +scripts/xeno-config
> +utils/net/rtnet
> +utils/net/rtnet.conf
> +*.a
> +*.o
> +*.la
> +*.lo
> +.libs
> +.dirstamp
> +demo/alchemy/altency
> +demo/alchemy/cobalt/cross-link
> +demo/posix/cobalt/bufp-label
> +demo/posix/cobalt/bufp-readwrite
> +demo/posix/cobalt/can_rtt
> +demo/posix/cobalt/eth_p_all
> +demo/posix/cobalt/gpiopwm
> +demo/posix/cobalt/iddp-label
> +demo/posix/cobalt/iddp-sendrecv
> +demo/posix/cobalt/xddp-echo
> +demo/posix/cobalt/xddp-label
> +demo/posix/cobalt/xddp-stream
> +demo/posix/cyclictest/cyclictest
> +lib/boilerplate/config-dump.h
> +lib/boilerplate/git-stamp.h
> +lib/boilerplate/version
> +testsuite/clocktest/clocktest
> +testsuite/gpiotest/gpiotest
> +testsuite/latency/latency
> +testsuite/smokey/net_common/smokey_net_server
> +testsuite/smokey/smokey
> +testsuite/spitest/spitest
> +testsuite/switchtest/switchtest
> +testsuite/xeno-test/xeno-test
> +testsuite/xeno-test/xeno-test-run
> +utils/analogy/analogy_calibrate
> +utils/analogy/analogy_config
> +utils/analogy/cmd_bits
> +utils/analogy/cmd_read
> +utils/analogy/cmd_write
> +utils/analogy/insn_bits
> +utils/analogy/insn_read
> +utils/analogy/insn_write
> +utils/analogy/wf_generate
> +utils/autotune/autotune
> +utils/can/rtcanconfig
> +utils/can/rtcanrecv
> +utils/can/rtcansend
> +utils/corectl/corectl
> +utils/hdb/hdb
> +utils/net/nomaccfg
> +utils/net/rtcfg
> +utils/net/rtifconfig
> +utils/net/rtiwconfig
> +utils/net/rtping
> +utils/net/rtroute
> +utils/net/tdmacfg
> +utils/ps/rtps
> +utils/slackspot/slackspot
> +testsuite/smokey/dlopen/dlopentest


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCHv2 1/4] cobalt/x86: add support for eager fpu handling

[Henning Schild]

Upstream 4.14 switched to purely eager fpu switching. That was
backported to 4.4 and 4.9. This commit makes cobalt able to deal whith
the changed kernel behaviour.
This commit takes care of 4.9 to begin with.

Introduce IPIPE_X86_FPU_EAGER to switch between the new and the old
implementations. The new implementation is much simpler than the old
one. We basically only deal with the odd case where Xenomai preempts
Linux in a kernel-fpu context.
In a regular Linux that can never happen and if it happens we need to
make sure to get things into a consistent state. We have to make
"current" as not owning the fpu anymore and allow others to use
in-kernel fpu (kernel_fpu_enable). __switch_to from Linux will do the
rest.

Signed-off-by: Henning Schild 
---
 .../arch/x86/include/asm/xenomai/thread.h |  8 ++-
 .../arch/x86/include/asm/xenomai/wrappers.h   |  5 ++
 kernel/cobalt/arch/x86/thread.c   | 69 ++-
 3 files changed, 79 insertions(+), 3 deletions(-)

diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h 
b/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
index f174a82c0..0c5c4da9c 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 
+#ifndef IPIPE_X86_FPU_EAGER
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,4,0)
 typedef union thread_xstate x86_fpustate;
 #define x86_fpustate_ptr(t) ((t)->fpu.state)
@@ -31,6 +32,7 @@ typedef union thread_xstate x86_fpustate;
 typedef union fpregs_state x86_fpustate;
 #define x86_fpustate_ptr(t) ((t)->fpu.active_state)
 #endif
+#endif
 
 struct xnarchtcb {
struct xntcb core;
@@ -40,10 +42,14 @@ struct xnarchtcb {
unsigned long ip;
unsigned long *ipp;
 #endif  
+#ifdef IPIPE_X86_FPU_EAGER
+   struct fpu *kfpu;
+#else
x86_fpustate *fpup;
-   unsigned int root_kfpu: 1;
unsigned int root_used_math: 1;
x86_fpustate *kfpu_state;
+#endif
+   unsigned int root_kfpu: 1;
struct {
unsigned long ip;
unsigned long ax;
diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h 
b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
index 5f9cff3c9..00f0aaae5 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
@@ -24,6 +24,11 @@
 #define __get_user_inatomic __get_user
 #define __put_user_inatomic __put_user
 
+#if LINUX_VERSION_CODE > KERNEL_VERSION(4,9,108) && \
+LINUX_VERSION_CODE < KERNEL_VERSION(4,10,0)
+#define IPIPE_X86_FPU_EAGER
+#endif
+
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
 #include 
 #include 
diff --git a/kernel/cobalt/arch/x86/thread.c b/kernel/cobalt/arch/x86/thread.c
index 7fb136300..18cf636e5 100644
--- a/kernel/cobalt/arch/x86/thread.c
+++ b/kernel/cobalt/arch/x86/thread.c
@@ -28,9 +28,13 @@
 
 static struct kmem_cache *xstate_cache;
 
+#ifdef IPIPE_X86_FPU_EAGER
+#define fpu_kernel_xstate_size sizeof(struct fpu)
+#else
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,7,0)
 #define fpu_kernel_xstate_size xstate_size
 #endif
+#endif /* IPIPE_X86_FPU_EAGER */
 
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(4,6,0)
 #define cpu_has_xmm boot_cpu_has(X86_FEATURE_XMM)
@@ -199,14 +203,17 @@ void xnarch_switch_to(struct xnthread *out, struct 
xnthread *in)
struct mm_struct *prev_mm, *next_mm;
 
prev = out_tcb->core.host_task;
+#ifndef IPIPE_X86_FPU_EAGER
if (x86_fpregs_active(prev))
/*
 * __switch_to will try and use __unlazy_fpu, so we
 * need to clear the ts bit.
 */
clts();
+#endif /* ! IPIPE_X86_FPU_EAGER */
 
next = in_tcb->core.host_task;
+#ifndef IPIPE_X86_FPU_EAGER
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(4,2,0)
next->thread.fpu.counter = 0;
 #elif LINUX_VERSION_CODE >= KERNEL_VERSION(3,13,0)
@@ -214,6 +221,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread 
*in)
 #else
next->fpu_counter = 0;
 #endif
+#endif /* ! IPIPE_X86_FPU_EAGER */
prev_mm = out_tcb->core.active_mm;
next_mm = in_tcb->core.mm;
if (next_mm == NULL) {
@@ -245,9 +253,13 @@ void xnarch_switch_to(struct xnthread *out, struct 
xnthread *in)
switch_to(prev, next, last);
 #endif /* LINUX_VERSION_CODE >= 4.8 */
 
+#ifndef IPIPE_X86_FPU_EAGER
stts();
+#endif /* ! IPIPE_X86_FPU_EAGER */
 }
 
+#ifndef IPIPE_X86_FPU_EAGER
+
 #ifdef CONFIG_X86_64
 #define XSAVE_PREFIX   "0x48,"
 #define XSAVE_SUFFIX   "q"
@@ -359,11 +371,21 @@ int xnarch_handle_fpu_fault(struct xnthread *from,
 
return 1;
 }
+#else /* IPIPE_X86_FPU_EAGER */
+
+int xnarch_handle_fpu_fault(struct xnthread *from,
+   struct xnthread *to, struct ipipe_trap_data *d)
+{
+   // in eager mode there are no such faults
+ 

[Xenomai] [IPIPE] [PATCHv2] x86: make fpu switching eager

[Henning Schild]

Linux 4.14 dropped support for lazy fpu switching and in the 4.4 and 4.9
series similar changes where backported.
So fpu is eager for those versions. That simplifies things a lot and we can
drop several changes from the IPIPE patch.
On the Xenomai side the only thing we still have to care about is the
kernel fpu state when we interrupt an in kernel fpu user. But we do that
explicit and can drop the indirection active_(fp)state.

This patch basically drops most of the fpu specifics from the ipipe
patch.

This patch applies on ipipe-4.9.y and it has to be followed by a merge with
>= 4.9.109. Cobalt will not compile if you are already eager and still
4.9.108

Signed-off-by: Henning Schild 
---
 arch/x86/include/asm/fpu/internal.h | 30 -
 arch/x86/include/asm/fpu/types.h| 12 
 arch/x86/kernel/fpu/core.c  | 17 ++--
 arch/x86/kernel/fpu/init.c  |  5 +
 4 files changed, 15 insertions(+), 49 deletions(-)

diff --git a/arch/x86/include/asm/fpu/internal.h 
b/arch/x86/include/asm/fpu/internal.h
index 35ca184e83e1..6bdceba90f17 100644
--- a/arch/x86/include/asm/fpu/internal.h
+++ b/arch/x86/include/asm/fpu/internal.h
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -190,24 +189,12 @@ static inline int copy_user_to_fregs(struct fregs_state 
__user *fx)
return user_insn(frstor %[fx], "=m" (*fx), [fx] "m" (*fx));
 }
 
-#ifdef CONFIG_IPIPE
-static inline union fpregs_state *active_fpstate(struct fpu *fpu)
-{
-   return fpu->active_state;
-}
-#else
-static inline union fpregs_state *active_fpstate(struct fpu *fpu)
-{
-   return &fpu->state;
-}
-#endif
-
 static inline void copy_fxregs_to_kernel(struct fpu *fpu)
 {
if (IS_ENABLED(CONFIG_X86_32))
-   asm volatile( "fxsave %[fx]" : [fx] "=m" 
(active_fpstate(fpu)->fxsave));
+   asm volatile( "fxsave %[fx]" : [fx] "=m" (fpu->state.fxsave));
else if (IS_ENABLED(CONFIG_AS_FXSAVEQ))
-   asm volatile("fxsaveq %[fx]" : [fx] "=m" 
(active_fpstate(fpu)->fxsave));
+   asm volatile("fxsaveq %[fx]" : [fx] "=m" (fpu->state.fxsave));
else {
/* Using "rex64; fxsave %0" is broken because, if the memory
 * operand uses any extended registers for addressing, a second
@@ -231,8 +218,8 @@ static inline void copy_fxregs_to_kernel(struct fpu *fpu)
 * registers.
 */
asm volatile( "rex64/fxsave (%[fx])"
- : "=m" (active_fpstate(fpu)->fxsave)
- : [fx] "R" (&active_fpstate(fpu)->fxsave));
+ : "=m" (fpu->state.fxsave)
+ : [fx] "R" (&fpu->state.fxsave));
}
 }
 
@@ -441,7 +428,7 @@ static inline int copy_user_to_xregs(struct xregs_state 
__user *buf, u64 mask)
 static inline int copy_fpregs_to_fpstate(struct fpu *fpu)
 {
if (likely(use_xsave())) {
-   copy_xregs_to_kernel(&active_fpstate(fpu)->xsave);
+   copy_xregs_to_kernel(&fpu->state.xsave);
return 1;
}
 
@@ -454,7 +441,7 @@ static inline int copy_fpregs_to_fpstate(struct fpu *fpu)
 * Legacy FPU register saving, FNSAVE always clears FPU registers,
 * so we have to mark them inactive:
 */
-   asm volatile("fnsave %[fp]; fwait" : [fp] "=m" 
(active_fpstate(fpu)->fsave));
+   asm volatile("fnsave %[fp]; fwait" : [fp] "=m" (fpu->state.fsave));
 
return 0;
 }
@@ -609,8 +596,7 @@ switch_fpu_prepare(struct fpu *old_fpu, struct fpu 
*new_fpu, int cpu)
 * If the task has used the math, pre-load the FPU on xsave processors
 * or if the past 5 consecutive context-switches used math.
 */
-   fpu.preload = !IS_ENABLED(CONFIG_IPIPE) &&
- static_cpu_has(X86_FEATURE_FPU) &&
+   fpu.preload = static_cpu_has(X86_FEATURE_FPU) &&
  new_fpu->fpstate_active &&
  (use_eager_fpu() || new_fpu->counter > 5);
 
@@ -660,7 +646,7 @@ switch_fpu_prepare(struct fpu *old_fpu, struct fpu 
*new_fpu, int cpu)
  */
 static inline void switch_fpu_finish(struct fpu *new_fpu, fpu_switch_t 
fpu_switch)
 {
-   if (!IS_ENABLED(CONFIG_IPIPE) && fpu_switch.preload)
+   if (fpu_switch.preload)
copy_kernel_to_fpregs(&new_fpu->state);
 }
 
diff --git a/arch/x86/include/asm/fpu/types.h b/arch/x86/include/asm/fpu/types.h
index 497c551469ec..48df486b02f9 100644
--- a/arch/x86/include/asm/fpu/types.h
+++ b/arch/x86/include/asm/fpu/types.h
@@ -332,18 +332,6 @@ struct fpu {
   

[Xenomai] [PATCHv2 4/4] cobalt/x86: add ipipe-4.14 eager fpu support

[Henning Schild]

4.14 is always eager, unfortunately we will need a few ifdefs inside the
eager fpu support as well.

Signed-off-by: Henning Schild 
---
 .../arch/x86/include/asm/xenomai/wrappers.h   |  4 
 kernel/cobalt/arch/x86/thread.c   | 21 ++-
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h 
b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
index a47730106..a4cc368a5 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
@@ -32,6 +32,10 @@
 LINUX_VERSION_CODE < KERNEL_VERSION(4,5,0)
 #define IPIPE_X86_FPU_EAGER
 #endif
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0)
+#define IPIPE_X86_FPU_EAGER
+#endif
+
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
 #include 
diff --git a/kernel/cobalt/arch/x86/thread.c b/kernel/cobalt/arch/x86/thread.c
index 18cf636e5..2668ce274 100644
--- a/kernel/cobalt/arch/x86/thread.c
+++ b/kernel/cobalt/arch/x86/thread.c
@@ -42,6 +42,7 @@ static struct kmem_cache *xstate_cache;
 #define cpu_has_xsave boot_cpu_has(X86_FEATURE_XSAVE)
 #endif
 
+#ifndef IPIPE_X86_FPU_EAGER
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
 #include 
 #include 
@@ -72,6 +73,9 @@ static inline void x86_fpregs_activate(struct task_struct *t)
 #define x86_xstate_alignment   __alignof__(union fpregs_state)
 
 #endif
+#else /* IPIPE_X86_FPU_EAGER */
+#define x86_xstate_alignment   __alignof__(union fpregs_state)
+#endif /* ! IPIPE_X86_FPU_EAGER */
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,8,0)
 /*
@@ -465,9 +469,15 @@ void xnarch_leave_root(struct xnthread *root)
// save fpregs from in-kernel use
copy_fpregs_to_fpstate(rootcb->kfpu);
kernel_fpu_enable();
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0)
+   // restore current's fpregs
+   __cpu_invalidate_fpregs_state();
+   switch_fpu_finish(¤t->thread.fpu, smp_processor_id());
+#else
// mark current thread as not owning the FPU anymore
if (¤t->thread.fpu.fpstate_active)
fpregs_deactivate(¤t->thread.fpu);
+#endif
 }
 
 void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
@@ -528,7 +538,11 @@ void xnarch_init_shadow_tcb(struct xnthread *thread)
 #else /* IPIPE_X86_FPU_EAGER */
/* XNFPU is always set */
xnthread_set_state(thread, XNFPU);
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,14,0)
fpu__activate_fpstate_read(&p->thread.fpu);
+#else
+   fpu__initialize(&p->thread.fpu);
+#endif
 #endif /* ! IPIPE_X86_FPU_EAGER */
 }
 
@@ -537,7 +551,12 @@ int mach_x86_thread_init(void)
xstate_cache = kmem_cache_create("cobalt_x86_xstate",
 fpu_kernel_xstate_size,
 x86_xstate_alignment,
-SLAB_NOTRACK, NULL);
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,14,0)
+SLAB_NOTRACK,
+#else
+0,
+#endif
+NULL);
if (xstate_cache == NULL)
return -ENOMEM;
 
-- 
2.19.0


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCH] gitignore: add build output for in-tree builds

[Henning Schild]

This adds all build output to .gitignore. Not everybody works out of
tree, or knows that this option exists. So let us add all build output
to .gitignore. While this names all our binaries and has the risk of
getting out of sync, it at least makes "git status" human readable again.

Signed-off-by: Henning Schild 
---
 .gitignore | 67 ++
 1 file changed, 67 insertions(+)

diff --git a/.gitignore b/.gitignore
index b1d682032..a054a65af 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,3 +15,70 @@ config/missing
 configure
 aclocal.m4
 autom4te.cache
+Makefile
+.deps
+config.log
+config.status
+include/stamp-h1
+include/xeno_config.h
+libtool
+scripts/xeno
+scripts/xeno-config
+utils/net/rtnet
+utils/net/rtnet.conf
+*.a
+*.o
+*.la
+*.lo
+.libs
+.dirstamp
+demo/alchemy/altency
+demo/alchemy/cobalt/cross-link
+demo/posix/cobalt/bufp-label
+demo/posix/cobalt/bufp-readwrite
+demo/posix/cobalt/can_rtt
+demo/posix/cobalt/eth_p_all
+demo/posix/cobalt/gpiopwm
+demo/posix/cobalt/iddp-label
+demo/posix/cobalt/iddp-sendrecv
+demo/posix/cobalt/xddp-echo
+demo/posix/cobalt/xddp-label
+demo/posix/cobalt/xddp-stream
+demo/posix/cyclictest/cyclictest
+lib/boilerplate/config-dump.h
+lib/boilerplate/git-stamp.h
+lib/boilerplate/version
+testsuite/clocktest/clocktest
+testsuite/gpiotest/gpiotest
+testsuite/latency/latency
+testsuite/smokey/net_common/smokey_net_server
+testsuite/smokey/smokey
+testsuite/spitest/spitest
+testsuite/switchtest/switchtest
+testsuite/xeno-test/xeno-test
+testsuite/xeno-test/xeno-test-run
+utils/analogy/analogy_calibrate
+utils/analogy/analogy_config
+utils/analogy/cmd_bits
+utils/analogy/cmd_read
+utils/analogy/cmd_write
+utils/analogy/insn_bits
+utils/analogy/insn_read
+utils/analogy/insn_write
+utils/analogy/wf_generate
+utils/autotune/autotune
+utils/can/rtcanconfig
+utils/can/rtcanrecv
+utils/can/rtcansend
+utils/corectl/corectl
+utils/hdb/hdb
+utils/net/nomaccfg
+utils/net/rtcfg
+utils/net/rtifconfig
+utils/net/rtiwconfig
+utils/net/rtping
+utils/net/rtroute
+utils/net/tdmacfg
+utils/ps/rtps
+utils/slackspot/slackspot
+testsuite/smokey/dlopen/dlopentest
-- 
2.19.0


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCHv2 3/4] cobalt: fixup for kernel 4.14+

[Henning Schild]

Signed-off-by: Henning Schild 
---
 kernel/cobalt/include/asm-generic/xenomai/syscall.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/kernel/cobalt/include/asm-generic/xenomai/syscall.h 
b/kernel/cobalt/include/asm-generic/xenomai/syscall.h
index f11ade8e7..3873fa634 100644
--- a/kernel/cobalt/include/asm-generic/xenomai/syscall.h
+++ b/kernel/cobalt/include/asm-generic/xenomai/syscall.h
@@ -20,7 +20,12 @@
 #define _COBALT_ASM_GENERIC_SYSCALL_H
 
 #include 
+#include 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,14,0)
 #include 
+#else
+#include 
+#endif
 #include 
 #include 
 #include 
-- 
2.19.0


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCHv2 2/4] cobalt/x86: add ipipe-4.4 eager fpu support

[Henning Schild]

Linux 4.4.138 switched to eager fpu, set IPIPE_X86_FPU_EAGER
accordingly.

Signed-off-by: Henning Schild 
---
 kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h 
b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
index 00f0aaae5..a47730106 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
@@ -28,6 +28,10 @@
 LINUX_VERSION_CODE < KERNEL_VERSION(4,10,0)
 #define IPIPE_X86_FPU_EAGER
 #endif
+#if LINUX_VERSION_CODE > KERNEL_VERSION(4,4,137) && \
+LINUX_VERSION_CODE < KERNEL_VERSION(4,5,0)
+#define IPIPE_X86_FPU_EAGER
+#endif
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
 #include 
-- 
2.19.0


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCHv2 4/4] cobalt/x86: add ipipe-4.14 eager fpu support

[Henning Schild]

All three kernels are tested now. I addressed comments from the first
review. Unfortunately i did not find a nice split to reduce the ifdef
hell we are in here.

I guess once we drop lazy fpu, most of it will go away.

Henning

Am Fri, 14 Sep 2018 17:10:18 +0200
schrieb Henning Schild :

> 4.14 is always eager, unfortunately we will need a few ifdefs inside
> the eager fpu support as well.
> 
> Signed-off-by: Henning Schild 
> ---
>  .../arch/x86/include/asm/xenomai/wrappers.h   |  4 
>  kernel/cobalt/arch/x86/thread.c   | 21
> ++- 2 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
> b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h index
> a47730106..a4cc368a5 100644 ---
> a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h +++
> b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h @@ -32,6
> +32,10 @@ LINUX_VERSION_CODE < KERNEL_VERSION(4,5,0)
>  #define IPIPE_X86_FPU_EAGER
>  #endif
> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0)
> +#define IPIPE_X86_FPU_EAGER
> +#endif
> +
>  
>  #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
>  #include 
> diff --git a/kernel/cobalt/arch/x86/thread.c
> b/kernel/cobalt/arch/x86/thread.c index 18cf636e5..2668ce274 100644
> --- a/kernel/cobalt/arch/x86/thread.c
> +++ b/kernel/cobalt/arch/x86/thread.c
> @@ -42,6 +42,7 @@ static struct kmem_cache *xstate_cache;
>  #define cpu_has_xsave boot_cpu_has(X86_FEATURE_XSAVE)
>  #endif
>  
> +#ifndef IPIPE_X86_FPU_EAGER
>  #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
>  #include 
>  #include 
> @@ -72,6 +73,9 @@ static inline void x86_fpregs_activate(struct
> task_struct *t) #define x86_xstate_alignment
> __alignof__(union fpregs_state) 
>  #endif
> +#else /* IPIPE_X86_FPU_EAGER */
> +#define x86_xstate_alignment __alignof__(union
> fpregs_state) +#endif /* ! IPIPE_X86_FPU_EAGER */
>  
>  #if LINUX_VERSION_CODE < KERNEL_VERSION(4,8,0)
>  /*
> @@ -465,9 +469,15 @@ void xnarch_leave_root(struct xnthread *root)
>   // save fpregs from in-kernel use
>   copy_fpregs_to_fpstate(rootcb->kfpu);
>   kernel_fpu_enable();
> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0)
> + // restore current's fpregs
> + __cpu_invalidate_fpregs_state();
> + switch_fpu_finish(¤t->thread.fpu, smp_processor_id());
> +#else
>   // mark current thread as not owning the FPU anymore
>   if (¤t->thread.fpu.fpstate_active)
>   fpregs_deactivate(¤t->thread.fpu);
> +#endif
>  }
>  
>  void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
> @@ -528,7 +538,11 @@ void xnarch_init_shadow_tcb(struct xnthread
> *thread) #else /* IPIPE_X86_FPU_EAGER */
>   /* XNFPU is always set */
>   xnthread_set_state(thread, XNFPU);
> +#if LINUX_VERSION_CODE < KERNEL_VERSION(4,14,0)
>   fpu__activate_fpstate_read(&p->thread.fpu);
> +#else
> + fpu__initialize(&p->thread.fpu);
> +#endif
>  #endif /* ! IPIPE_X86_FPU_EAGER */
>  }
>  
> @@ -537,7 +551,12 @@ int mach_x86_thread_init(void)
>   xstate_cache = kmem_cache_create("cobalt_x86_xstate",
>fpu_kernel_xstate_size,
>x86_xstate_alignment,
> -  SLAB_NOTRACK, NULL);
> +#if LINUX_VERSION_CODE < KERNEL_VERSION(4,14,0)
> +  SLAB_NOTRACK,
> +#else
> +  0,
> +#endif
> +  NULL);
>   if (xstate_cache == NULL)
>   return -ENOMEM;
>  



-- 
Siemens AG
Corporate Technology
CT RDA IOT SES-DE
Otto-Hahn-Ring 6
81739 Muenchen, Germany
Mobile: +49 172 8378927
mailto: henning.sch...@siemens.com

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [IPIPE] [PATCHv2] x86: make fpu switching eager

[Henning Schild]

Change to v1:
  removed whitespace changes and changed commit message

Am Fri, 14 Sep 2018 17:10:15 +0200
schrieb Henning Schild :

> Linux 4.14 dropped support for lazy fpu switching and in the 4.4 and
> 4.9 series similar changes where backported.
> So fpu is eager for those versions. That simplifies things a lot and
> we can drop several changes from the IPIPE patch.
> On the Xenomai side the only thing we still have to care about is the
> kernel fpu state when we interrupt an in kernel fpu user. But we do
> that explicit and can drop the indirection active_(fp)state.
> 
> This patch basically drops most of the fpu specifics from the ipipe
> patch.
> 
> This patch applies on ipipe-4.9.y and it has to be followed by a
> merge with
> >= 4.9.109. Cobalt will not compile if you are already eager and
> >still  
> 4.9.108
> 
> Signed-off-by: Henning Schild 
> ---
>  arch/x86/include/asm/fpu/internal.h | 30
> - arch/x86/include/asm/fpu/types.h|
> 12  arch/x86/kernel/fpu/core.c  | 17
> ++-- arch/x86/kernel/fpu/init.c  |  5 +
>  4 files changed, 15 insertions(+), 49 deletions(-)
> 
> diff --git a/arch/x86/include/asm/fpu/internal.h
> b/arch/x86/include/asm/fpu/internal.h index
> 35ca184e83e1..6bdceba90f17 100644 ---
> a/arch/x86/include/asm/fpu/internal.h +++
> b/arch/x86/include/asm/fpu/internal.h @@ -13,7 +13,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  #include 
> @@ -190,24 +189,12 @@ static inline int copy_user_to_fregs(struct
> fregs_state __user *fx) return user_insn(frstor %[fx], "=m" (*fx),
> [fx] "m" (*fx)); }
>  
> -#ifdef CONFIG_IPIPE
> -static inline union fpregs_state *active_fpstate(struct fpu *fpu)
> -{
> - return fpu->active_state;
> -}
> -#else
> -static inline union fpregs_state *active_fpstate(struct fpu *fpu)
> -{
> - return &fpu->state;
> -}
> -#endif
> -
>  static inline void copy_fxregs_to_kernel(struct fpu *fpu)
>  {
>   if (IS_ENABLED(CONFIG_X86_32))
> - asm volatile( "fxsave %[fx]" : [fx]
> "=m" (active_fpstate(fpu)->fxsave));
> + asm volatile( "fxsave %[fx]" : [fx]
> "=m" (fpu->state.fxsave)); else if (IS_ENABLED(CONFIG_AS_FXSAVEQ))
> - asm volatile("fxsaveq %[fx]" : [fx]
> "=m" (active_fpstate(fpu)->fxsave));
> + asm volatile("fxsaveq %[fx]" : [fx]
> "=m" (fpu->state.fxsave)); else {
>   /* Using "rex64; fxsave %0" is broken because, if
> the memory
>* operand uses any extended registers for
> addressing, a second @@ -231,8 +218,8 @@ static inline void
> copy_fxregs_to_kernel(struct fpu *fpu)
>* registers.
>*/
>   asm volatile( "rex64/fxsave (%[fx])"
> -   : "=m" (active_fpstate(fpu)->fxsave)
> -   : [fx]
> "R" (&active_fpstate(fpu)->fxsave));
> + : "=m" (fpu->state.fxsave)
> + : [fx] "R" (&fpu->state.fxsave));
>   }
>  }
>  
> @@ -441,7 +428,7 @@ static inline int copy_user_to_xregs(struct
> xregs_state __user *buf, u64 mask) static inline int
> copy_fpregs_to_fpstate(struct fpu *fpu) {
>   if (likely(use_xsave())) {
> - copy_xregs_to_kernel(&active_fpstate(fpu)->xsave);
> + copy_xregs_to_kernel(&fpu->state.xsave);
>   return 1;
>   }
>  
> @@ -454,7 +441,7 @@ static inline int copy_fpregs_to_fpstate(struct
> fpu *fpu)
>* Legacy FPU register saving, FNSAVE always clears FPU
> registers,
>* so we have to mark them inactive:
>*/
> - asm volatile("fnsave %[fp]; fwait" : [fp]
> "=m" (active_fpstate(fpu)->fsave));
> + asm volatile("fnsave %[fp]; fwait" : [fp]
> "=m" (fpu->state.fsave)); 
>   return 0;
>  }
> @@ -609,8 +596,7 @@ switch_fpu_prepare(struct fpu *old_fpu, struct
> fpu *new_fpu, int cpu)
>* If the task has used the math, pre-load the FPU on xsave
> processors
>* or if the past 5 consecutive context-switches used math.
>*/
> - fpu.preload = !IS_ENABLED(CONFIG_IPIPE) &&
> -   static_cpu_has(X86_FEATURE_FPU) &&
> + fpu.preload = static_cpu_has(X86_FEATURE_FPU) &&
> new_fpu->fpstate_active &&
> (use_eager_fpu() || new_fpu->counter > 5);
&

[Xenomai] [PATCHv2 2/4] cobalt/x86: add ipipe-4.4 eager fpu support

[Henning Schild]

Linux 4.4.138 switched to eager fpu, set IPIPE_X86_FPU_EAGER
accordingly.

Signed-off-by: Henning Schild 
---
 kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h 
b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
index 00f0aaae5..a47730106 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
@@ -28,6 +28,10 @@
 LINUX_VERSION_CODE < KERNEL_VERSION(4,10,0)
 #define IPIPE_X86_FPU_EAGER
 #endif
+#if LINUX_VERSION_CODE > KERNEL_VERSION(4,4,137) && \
+LINUX_VERSION_CODE < KERNEL_VERSION(4,5,0)
+#define IPIPE_X86_FPU_EAGER
+#endif
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
 #include 
-- 
2.19.0


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCHv2 3/4] cobalt: fixup for kernel 4.14+

[Henning Schild]

Signed-off-by: Henning Schild 
---
 kernel/cobalt/include/asm-generic/xenomai/syscall.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/kernel/cobalt/include/asm-generic/xenomai/syscall.h 
b/kernel/cobalt/include/asm-generic/xenomai/syscall.h
index f11ade8e7..3873fa634 100644
--- a/kernel/cobalt/include/asm-generic/xenomai/syscall.h
+++ b/kernel/cobalt/include/asm-generic/xenomai/syscall.h
@@ -20,7 +20,12 @@
 #define _COBALT_ASM_GENERIC_SYSCALL_H
 
 #include 
+#include 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,14,0)
 #include 
+#else
+#include 
+#endif
 #include 
 #include 
 #include 
-- 
2.19.0


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCHv2 4/4] cobalt/x86: add ipipe-4.14 eager fpu support

[Henning Schild]

4.14 is always eager, unfortunately we will need a few ifdefs inside the
eager fpu support as well.

Signed-off-by: Henning Schild 
---
 .../arch/x86/include/asm/xenomai/wrappers.h   |  4 
 kernel/cobalt/arch/x86/thread.c   | 21 ++-
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h 
b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
index a47730106..a4cc368a5 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
@@ -32,6 +32,10 @@
 LINUX_VERSION_CODE < KERNEL_VERSION(4,5,0)
 #define IPIPE_X86_FPU_EAGER
 #endif
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0)
+#define IPIPE_X86_FPU_EAGER
+#endif
+
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
 #include 
diff --git a/kernel/cobalt/arch/x86/thread.c b/kernel/cobalt/arch/x86/thread.c
index 18cf636e5..2668ce274 100644
--- a/kernel/cobalt/arch/x86/thread.c
+++ b/kernel/cobalt/arch/x86/thread.c
@@ -42,6 +42,7 @@ static struct kmem_cache *xstate_cache;
 #define cpu_has_xsave boot_cpu_has(X86_FEATURE_XSAVE)
 #endif
 
+#ifndef IPIPE_X86_FPU_EAGER
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
 #include 
 #include 
@@ -72,6 +73,9 @@ static inline void x86_fpregs_activate(struct task_struct *t)
 #define x86_xstate_alignment   __alignof__(union fpregs_state)
 
 #endif
+#else /* IPIPE_X86_FPU_EAGER */
+#define x86_xstate_alignment   __alignof__(union fpregs_state)
+#endif /* ! IPIPE_X86_FPU_EAGER */
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,8,0)
 /*
@@ -465,9 +469,15 @@ void xnarch_leave_root(struct xnthread *root)
// save fpregs from in-kernel use
copy_fpregs_to_fpstate(rootcb->kfpu);
kernel_fpu_enable();
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0)
+   // restore current's fpregs
+   __cpu_invalidate_fpregs_state();
+   switch_fpu_finish(¤t->thread.fpu, smp_processor_id());
+#else
// mark current thread as not owning the FPU anymore
if (¤t->thread.fpu.fpstate_active)
fpregs_deactivate(¤t->thread.fpu);
+#endif
 }
 
 void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
@@ -528,7 +538,11 @@ void xnarch_init_shadow_tcb(struct xnthread *thread)
 #else /* IPIPE_X86_FPU_EAGER */
/* XNFPU is always set */
xnthread_set_state(thread, XNFPU);
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,14,0)
fpu__activate_fpstate_read(&p->thread.fpu);
+#else
+   fpu__initialize(&p->thread.fpu);
+#endif
 #endif /* ! IPIPE_X86_FPU_EAGER */
 }
 
@@ -537,7 +551,12 @@ int mach_x86_thread_init(void)
xstate_cache = kmem_cache_create("cobalt_x86_xstate",
 fpu_kernel_xstate_size,
 x86_xstate_alignment,
-SLAB_NOTRACK, NULL);
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,14,0)
+SLAB_NOTRACK,
+#else
+0,
+#endif
+NULL);
if (xstate_cache == NULL)
return -ENOMEM;
 
-- 
2.19.0


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [IPIPE] [PATCHv2] x86: make fpu switching eager

[Henning Schild]

Linux 4.14 dropped support for lazy fpu switching and in the 4.4 and 4.9
series similar changes where backported.
So fpu is eager for those versions. That simplifies things a lot and we can
drop several changes from the IPIPE patch.
On the Xenomai side the only thing we still have to care about is the
kernel fpu state when we interrupt an in kernel fpu user. But we do that
explicit and can drop the indirection active_(fp)state.

This patch basically drops most of the fpu specifics from the ipipe
patch.

This patch applies on ipipe-4.9.y and it has to be followed by a merge with
>= 4.9.109. Cobalt will not compile if you are already eager and still
4.9.108

Signed-off-by: Henning Schild 
---
 arch/x86/include/asm/fpu/internal.h | 30 -
 arch/x86/include/asm/fpu/types.h| 12 
 arch/x86/kernel/fpu/core.c  | 17 ++--
 arch/x86/kernel/fpu/init.c  |  5 +
 4 files changed, 15 insertions(+), 49 deletions(-)

diff --git a/arch/x86/include/asm/fpu/internal.h 
b/arch/x86/include/asm/fpu/internal.h
index 35ca184e83e1..6bdceba90f17 100644
--- a/arch/x86/include/asm/fpu/internal.h
+++ b/arch/x86/include/asm/fpu/internal.h
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -190,24 +189,12 @@ static inline int copy_user_to_fregs(struct fregs_state 
__user *fx)
return user_insn(frstor %[fx], "=m" (*fx), [fx] "m" (*fx));
 }
 
-#ifdef CONFIG_IPIPE
-static inline union fpregs_state *active_fpstate(struct fpu *fpu)
-{
-   return fpu->active_state;
-}
-#else
-static inline union fpregs_state *active_fpstate(struct fpu *fpu)
-{
-   return &fpu->state;
-}
-#endif
-
 static inline void copy_fxregs_to_kernel(struct fpu *fpu)
 {
if (IS_ENABLED(CONFIG_X86_32))
-   asm volatile( "fxsave %[fx]" : [fx] "=m" 
(active_fpstate(fpu)->fxsave));
+   asm volatile( "fxsave %[fx]" : [fx] "=m" (fpu->state.fxsave));
else if (IS_ENABLED(CONFIG_AS_FXSAVEQ))
-   asm volatile("fxsaveq %[fx]" : [fx] "=m" 
(active_fpstate(fpu)->fxsave));
+   asm volatile("fxsaveq %[fx]" : [fx] "=m" (fpu->state.fxsave));
else {
/* Using "rex64; fxsave %0" is broken because, if the memory
 * operand uses any extended registers for addressing, a second
@@ -231,8 +218,8 @@ static inline void copy_fxregs_to_kernel(struct fpu *fpu)
 * registers.
 */
asm volatile( "rex64/fxsave (%[fx])"
- : "=m" (active_fpstate(fpu)->fxsave)
- : [fx] "R" (&active_fpstate(fpu)->fxsave));
+ : "=m" (fpu->state.fxsave)
+ : [fx] "R" (&fpu->state.fxsave));
}
 }
 
@@ -441,7 +428,7 @@ static inline int copy_user_to_xregs(struct xregs_state 
__user *buf, u64 mask)
 static inline int copy_fpregs_to_fpstate(struct fpu *fpu)
 {
if (likely(use_xsave())) {
-   copy_xregs_to_kernel(&active_fpstate(fpu)->xsave);
+   copy_xregs_to_kernel(&fpu->state.xsave);
return 1;
}
 
@@ -454,7 +441,7 @@ static inline int copy_fpregs_to_fpstate(struct fpu *fpu)
 * Legacy FPU register saving, FNSAVE always clears FPU registers,
 * so we have to mark them inactive:
 */
-   asm volatile("fnsave %[fp]; fwait" : [fp] "=m" 
(active_fpstate(fpu)->fsave));
+   asm volatile("fnsave %[fp]; fwait" : [fp] "=m" (fpu->state.fsave));
 
return 0;
 }
@@ -609,8 +596,7 @@ switch_fpu_prepare(struct fpu *old_fpu, struct fpu 
*new_fpu, int cpu)
 * If the task has used the math, pre-load the FPU on xsave processors
 * or if the past 5 consecutive context-switches used math.
 */
-   fpu.preload = !IS_ENABLED(CONFIG_IPIPE) &&
- static_cpu_has(X86_FEATURE_FPU) &&
+   fpu.preload = static_cpu_has(X86_FEATURE_FPU) &&
  new_fpu->fpstate_active &&
  (use_eager_fpu() || new_fpu->counter > 5);
 
@@ -660,7 +646,7 @@ switch_fpu_prepare(struct fpu *old_fpu, struct fpu 
*new_fpu, int cpu)
  */
 static inline void switch_fpu_finish(struct fpu *new_fpu, fpu_switch_t 
fpu_switch)
 {
-   if (!IS_ENABLED(CONFIG_IPIPE) && fpu_switch.preload)
+   if (fpu_switch.preload)
copy_kernel_to_fpregs(&new_fpu->state);
 }
 
diff --git a/arch/x86/include/asm/fpu/types.h b/arch/x86/include/asm/fpu/types.h
index 497c551469ec..48df486b02f9 100644
--- a/arch/x86/include/asm/fpu/types.h
+++ b/arch/x86/include/asm/fpu/types.h
@@ -332,18 +332,6 @@ struct fpu {
   

[Xenomai] [PATCHv2 1/4] cobalt/x86: add support for eager fpu handling

[Henning Schild]

Upstream 4.14 switched to purely eager fpu switching. That was
backported to 4.4 and 4.9. This commit makes cobalt able to deal whith
the changed kernel behaviour.
This commit takes care of 4.9 to begin with.

Introduce IPIPE_X86_FPU_EAGER to switch between the new and the old
implementations. The new implementation is much simpler than the old
one. We basically only deal with the odd case where Xenomai preempts
Linux in a kernel-fpu context.
In a regular Linux that can never happen and if it happens we need to
make sure to get things into a consistent state. We have to make
"current" as not owning the fpu anymore and allow others to use
in-kernel fpu (kernel_fpu_enable). __switch_to from Linux will do the
rest.

Signed-off-by: Henning Schild 
---
 .../arch/x86/include/asm/xenomai/thread.h |  8 ++-
 .../arch/x86/include/asm/xenomai/wrappers.h   |  5 ++
 kernel/cobalt/arch/x86/thread.c   | 69 ++-
 3 files changed, 79 insertions(+), 3 deletions(-)

diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h 
b/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
index f174a82c0..0c5c4da9c 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 
+#ifndef IPIPE_X86_FPU_EAGER
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,4,0)
 typedef union thread_xstate x86_fpustate;
 #define x86_fpustate_ptr(t) ((t)->fpu.state)
@@ -31,6 +32,7 @@ typedef union thread_xstate x86_fpustate;
 typedef union fpregs_state x86_fpustate;
 #define x86_fpustate_ptr(t) ((t)->fpu.active_state)
 #endif
+#endif
 
 struct xnarchtcb {
struct xntcb core;
@@ -40,10 +42,14 @@ struct xnarchtcb {
unsigned long ip;
unsigned long *ipp;
 #endif  
+#ifdef IPIPE_X86_FPU_EAGER
+   struct fpu *kfpu;
+#else
x86_fpustate *fpup;
-   unsigned int root_kfpu: 1;
unsigned int root_used_math: 1;
x86_fpustate *kfpu_state;
+#endif
+   unsigned int root_kfpu: 1;
struct {
unsigned long ip;
unsigned long ax;
diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h 
b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
index 5f9cff3c9..00f0aaae5 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
@@ -24,6 +24,11 @@
 #define __get_user_inatomic __get_user
 #define __put_user_inatomic __put_user
 
+#if LINUX_VERSION_CODE > KERNEL_VERSION(4,9,108) && \
+LINUX_VERSION_CODE < KERNEL_VERSION(4,10,0)
+#define IPIPE_X86_FPU_EAGER
+#endif
+
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
 #include 
 #include 
diff --git a/kernel/cobalt/arch/x86/thread.c b/kernel/cobalt/arch/x86/thread.c
index 7fb136300..18cf636e5 100644
--- a/kernel/cobalt/arch/x86/thread.c
+++ b/kernel/cobalt/arch/x86/thread.c
@@ -28,9 +28,13 @@
 
 static struct kmem_cache *xstate_cache;
 
+#ifdef IPIPE_X86_FPU_EAGER
+#define fpu_kernel_xstate_size sizeof(struct fpu)
+#else
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,7,0)
 #define fpu_kernel_xstate_size xstate_size
 #endif
+#endif /* IPIPE_X86_FPU_EAGER */
 
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(4,6,0)
 #define cpu_has_xmm boot_cpu_has(X86_FEATURE_XMM)
@@ -199,14 +203,17 @@ void xnarch_switch_to(struct xnthread *out, struct 
xnthread *in)
struct mm_struct *prev_mm, *next_mm;
 
prev = out_tcb->core.host_task;
+#ifndef IPIPE_X86_FPU_EAGER
if (x86_fpregs_active(prev))
/*
 * __switch_to will try and use __unlazy_fpu, so we
 * need to clear the ts bit.
 */
clts();
+#endif /* ! IPIPE_X86_FPU_EAGER */
 
next = in_tcb->core.host_task;
+#ifndef IPIPE_X86_FPU_EAGER
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(4,2,0)
next->thread.fpu.counter = 0;
 #elif LINUX_VERSION_CODE >= KERNEL_VERSION(3,13,0)
@@ -214,6 +221,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread 
*in)
 #else
next->fpu_counter = 0;
 #endif
+#endif /* ! IPIPE_X86_FPU_EAGER */
prev_mm = out_tcb->core.active_mm;
next_mm = in_tcb->core.mm;
if (next_mm == NULL) {
@@ -245,9 +253,13 @@ void xnarch_switch_to(struct xnthread *out, struct 
xnthread *in)
switch_to(prev, next, last);
 #endif /* LINUX_VERSION_CODE >= 4.8 */
 
+#ifndef IPIPE_X86_FPU_EAGER
stts();
+#endif /* ! IPIPE_X86_FPU_EAGER */
 }
 
+#ifndef IPIPE_X86_FPU_EAGER
+
 #ifdef CONFIG_X86_64
 #define XSAVE_PREFIX   "0x48,"
 #define XSAVE_SUFFIX   "q"
@@ -359,11 +371,21 @@ int xnarch_handle_fpu_fault(struct xnthread *from,
 
return 1;
 }
+#else /* IPIPE_X86_FPU_EAGER */
+
+int xnarch_handle_fpu_fault(struct xnthread *from,
+   struct xnthread *to, struct ipipe_trap_data *d)
+{
+   // in eager mode there are no such faults
+ 

Re: [Xenomai] [PATCH 1/1] x86: make fpu switching eager

[Henning Schild]

Am Mon, 27 Aug 2018 18:36:49 +0200
schrieb Jan Kiszka :

> On 2018-08-27 15:33, Henning Schild wrote:
> > Linux 4.14 dropped support for lazy fpu switching and in the 4.4
> > and 4.9 series similar changes where backported.
> > So we can assume that fpu switching is purely eager for those
> > Linux  
> 
> My reading of this patch is that we do not "assume" them to be eager,
> we enforce that for now - until the changes from the related stable
> merge do that.
> 
> > kernel versions. That simplifies things a lot and we can drop
> > several changes from the IPIPE patch.
> > On the Xenomai side the only thing we still have to care about is
> > the kernel fpu state when we interrupt an in kernel fpu user. But
> > we do that explicit and can drop the indirection active_(fp)state.
> >   
> 
> That patch resolving a mechanical merge conflict ahead of the merge, 
> right? Does it break the build?
> 
> > Signed-off-by: Henning Schild 
> > ---
> >   arch/x86/include/asm/fpu/internal.h | 30
> > -- arch/x86/include/asm/fpu/types.h
> > | 12  arch/x86/kernel/fpu/core.c  | 23
> > +-- arch/x86/kernel/fpu/init.c  |  5
> > + 4 files changed, 18 insertions(+), 52 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/fpu/internal.h
> > b/arch/x86/include/asm/fpu/internal.h index
> > 35ca184e83e1..6bdceba90f17 100644 ---
> > a/arch/x86/include/asm/fpu/internal.h +++
> > b/arch/x86/include/asm/fpu/internal.h @@ -13,7 +13,6 @@
> >   #include 
> >   #include 
> >   #include 
> > -#include 
> >   #include 
> >   
> >   #include 
> > @@ -190,24 +189,12 @@ static inline int copy_user_to_fregs(struct
> > fregs_state __user *fx) return user_insn(frstor %[fx], "=m" (*fx),
> > [fx] "m" (*fx)); }
> >   
> > -#ifdef CONFIG_IPIPE
> > -static inline union fpregs_state *active_fpstate(struct fpu *fpu)
> > -{
> > -   return fpu->active_state;
> > -}
> > -#else
> > -static inline union fpregs_state *active_fpstate(struct fpu *fpu)
> > -{
> > -   return &fpu->state;
> > -}
> > -#endif
> > -
> >   static inline void copy_fxregs_to_kernel(struct fpu *fpu)
> >   {
> > if (IS_ENABLED(CONFIG_X86_32))
> > -   asm volatile( "fxsave %[fx]" : [fx]
> > "=m" (active_fpstate(fpu)->fxsave));
> > +   asm volatile( "fxsave %[fx]" : [fx]
> > "=m" (fpu->state.fxsave)); else if (IS_ENABLED(CONFIG_AS_FXSAVEQ))
> > -   asm volatile("fxsaveq %[fx]" : [fx]
> > "=m" (active_fpstate(fpu)->fxsave));
> > +   asm volatile("fxsaveq %[fx]" : [fx]
> > "=m" (fpu->state.fxsave)); else {
> > /* Using "rex64; fxsave %0" is broken because, if
> > the memory
> >  * operand uses any extended registers for
> > addressing, a second @@ -231,8 +218,8 @@ static inline void
> > copy_fxregs_to_kernel(struct fpu *fpu)
> >  * registers.
> >  */
> > asm volatile( "rex64/fxsave (%[fx])"
> > - : "=m" (active_fpstate(fpu)->fxsave)
> > - : [fx]
> > "R" (&active_fpstate(fpu)->fxsave));
> > + : "=m" (fpu->state.fxsave)
> > + : [fx] "R" (&fpu->state.fxsave));
> > }
> >   }
> >   
> > @@ -441,7 +428,7 @@ static inline int copy_user_to_xregs(struct
> > xregs_state __user *buf, u64 mask) static inline int
> > copy_fpregs_to_fpstate(struct fpu *fpu) {
> > if (likely(use_xsave())) {
> > -   copy_xregs_to_kernel(&active_fpstate(fpu)->xsave);
> > +   copy_xregs_to_kernel(&fpu->state.xsave);
> > return 1;
> > }
> >   
> > @@ -454,7 +441,7 @@ static inline int copy_fpregs_to_fpstate(struct
> > fpu *fpu)
> >  * Legacy FPU register saving, FNSAVE always clears FPU
> > registers,
> >  * so we have to mark them inactive:
> >  */
> > -   asm volatile("fnsave %[fp]; fwait" : [fp]
> > "=m" (active_fpstate(fpu)->fsave));
> > +   asm volatile("fnsave %[fp]; fwait" : [fp]
> > "=m" (fpu->state.fsave)); 
> > return 0;
> >   }
> > @@ -609,8 +596,7 @@ switch_fpu_prepare(struct fpu *old_fpu, struct
> > fpu *new_fpu, int cpu)
&g

Re: [Xenomai] Order options to build a Xenomai program

[Henning Schild]

Hey,

i personally am a bit overwhelmed with the amount of information, and i
could not clearly spot the issue you seem to have.

But you might want to have a look at:
https://github.com/nolange/cmake_xenomai

Henning

Am Thu, 6 Sep 2018 11:52:39 +0200
schrieb Leopold Palomo-Avellaneda :

> Hi,
> 
> 
> I resend this message to the list now that it has again more
> activity. Maybe some of you cold help me to understand what is wrong
> here. I'm sorry if it's not appropriate to send again a message to
> the list.
> 
> =
> 
> I have an strange problem and I would like to ask if some clever mind
> can help me.
> 
> I'm trying to build with cmake (this story is for another mail) a
> simple example [1] with xenomai 3.0.7. I have some custom macros that
> basically uses the information from xeno-config.
> 
> I can build and run the example with the Makefile below in the email.
> It just works.
> 
> Narrowing the problem I have obtained the exactly call made by the
> Makefile created by cmake. It compiles the file using:
> 
> $ /usr/bin/cc   -I/usr/include/xenomai/trank
> -I/usr/include/xenomai/cobalt -I/usr/include/xenomai
> -I/usr/include/xenomai/alchemy  -D__XENO_COMPAT__ -g -O2
> -fdebug-prefix-map=/build/xenomai-3.0.7+ds1=. -fstack-protector-strong
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
> -fno-omit-frame-pointer -D_GNU_SOURCE -D_REENTRANT
> -fasynchronous-unwind-tables -D__COBALT__ -o
> CMakeFiles/rtprint.dir/rtprint.c.o   -c
> /home/leopold.palomo/xenomai/cmake/src/native/rtprint.c
> 
> 
> and links the file using:
> 
> $ /usr/bin/cc-Wl,--no-as-needed
> -Wl,@/usr/lib/x86_64-linux-gnu/modechk.wrappers
> /usr/lib/x86_64-linux-gnu/xenomai/bootstrap.o -Wl,--wrap=main
> -Wl,--dynamic-list=/usr/lib/x86_64-linux-gnu/dynlist.ld -Wl,-z,relro
> -Wl,-z,now -Wl,--as-needed -pthread CMakeFiles/rtprint.dir/rtprint.c.o
> -o rtprint -rdynamic -ltrank -lalchemy -lcopperplate -lcobalt
> -lmodechk -lpthread -lrt -lfuse
> 
> 
> Using the Makefile attached, to compile, make call gcc with:
> 
> $ make rtprint.o
> gcc -c -o rtprint.o rtprint.c -I/usr/include/xenomai/trank
> -D__XENO_COMPAT__ -I/usr/include/xenomai/cobalt -I/usr/include/xenomai
> -g -O2 -fdebug-prefix-map=/build/xenomai-3.0.7+ds1=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer -D_GNU_SOURCE -D_REENTRANT
> -fasynchronous-unwind-tables -D__COBALT__
> -I/usr/include/xenomai/alchemy
> 
> and link with:
> 
> $ make rtprint
> gcc -o rtprint rtprint.o -Wl,--no-as-needed -ltrank
> -Wl,@/usr/lib/x86_64-linux-gnu/modechk.wrappers -lalchemy
> -lcopperplate /usr/lib/x86_64-linux-gnu/xenomai/bootstrap.o
> -Wl,--wrap=main
> -Wl,--dynamic-list=/usr/lib/x86_64-linux-gnu/dynlist.ld
> -L/usr/lib/x86_64-linux-gnu -lcobalt -lmodechk -lpthread -lrt
> -Wl,-z,relro -Wl,-z,now -Wl,--as-needed   -lfuse -pthread
> 
> 
> The build result made by CMake is: rtprint (24816 bytes) and rtprint.o
> (16408 bytes)
> 
> The build result make using the makefile: rtprint (24720 bytes) and
> rtprint.o (16312 bytes).
> 
> If I call the gcc directly I obtain the same bytes. The difference is
> the stored path. If I strip the executables the size is the same
> (10224 bytes) but binaries differ.
> 
> But, and here is the problem. If I run the cmake product I obtain:
> 
> /rtprint
> ./rtprint: symbol lookup error:
> /usr/lib/x86_64-linux-gnu/libcopperplate.so.0: undefined symbol:
> __real_malloc
> 
> 
> and the produced with make runs.
> 
> The produced using cmake has:
> 
> $ ldd rtprint
>   linux-vdso.so.1 (0x7ffd0e1e1000)
>   libtrank.so.0 => /usr/lib/x86_64-linux-gnu/libtrank.so.0
> (0x7f7b5dec9000)
>   libalchemy.so.0 => /usr/lib/x86_64-linux-gnu/libalchemy.so.0
> (0x7f7b5dcb7000)
>   libcopperplate.so.0
> => /usr/lib/x86_64-linux-gnu/libcopperplate.so.0 (0x7f7b5da9f000)
>   libcobalt.so.2 => /usr/lib/x86_64-linux-gnu/libcobalt.so.2
> (0x7f7b5d87d000)
>   libfuse.so.2 => /lib/x86_64-linux-gnu/libfuse.so.2
> (0x7f7b5d63f000) libpthread.so.0
> => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f7b5d422000)
>   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> (0x7f7b5d083000) /lib64/ld-linux-x86-64.so.2 (0x7f7b5e2d)
>   librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
> (0x7f7b5ce7b000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
> (0x7f7b5cc77000)
> 
> 
> and with make
> 
> $ ldd rtprint
>   linux-vdso.so.1 (0x7cfe2000)
>   libtrank.so.0 => /usr/lib/x86_64-linux-gnu/libtrank.so.0
> (0x7f621304f000)
>   libalchemy.so.0 => /usr/lib/x86_64-linux-gnu/libalchemy.so.0
> (0x7f6212e3d000)
>   libcopperplate.so.0
> => /usr/lib/x86_64-linux-gnu/libcopperplate.so.0 (0x7f6212c25000)
>   libcobalt.so.2 => /usr/lib/x86_64-linux-gnu/libcobalt.so.2
> (0x7f6212a03000)
>   libmodechk.so.0 => /usr/lib/x86_64-linux-gnu/libmodechk.so.0
> (0x7f6212801000)
>   libpthread.so.0 => /lib/x86_64-linu

Re: [Xenomai] I-pipe split series

[Henning Schild]

Am Thu, 6 Sep 2018 10:08:57 +0200
schrieb Philippe Gerum :

> On 08/27/2018 07:44 PM, Henning Schild wrote:
> > Am Mon, 27 Aug 2018 16:15:21 +0200
> > schrieb Philippe Gerum :
> >   
> >> On 08/27/2018 01:24 PM, Henning Schild wrote:  
> >>> Hi Philippe,
> >>>
> >>> Am Mon, 30 Jul 2018 20:10:17 +0200
> >>> schrieb Philippe Gerum :
> >>> 
> >>>> The generic I-pipe code is now available as a series of
> >>>> incremental commits at [1] on top of the 4.14.58 kernel. This
> >>>> allows to port the I-pipe patch gradually, first to enable IRQ
> >>>> pipelining per se, then add the bits required for co-managing
> >>>> tasks between the regular kernel and the co-kernel, which builds
> >>>> on the former. Most patches have gained a description in their
> >>>> respective short log, which added to Documentation/ipipe.rst,
> >>>> should help clarifying the process of porting the pipeline.
> >>>>
> >>>> While I was at it, I did a pre-port of the x86 patch to kernel
> >>>> 4.14.58, which has been useful for validating the split series. I
> >>>> hope this will help the x86 maintainers to clear that hurdle
> >>>> eventually.
> >>>>
> >>>> The whole pile of patches went through countless incremental
> >>>> builds over multiple configurations, and tedious manual fixups
> >>>> over a few weeks. However, there is room for issues, given the
> >>>> amount of code involved, and the varying configurations one can
> >>>> apply. If you find any problem with that split series, please
> >>>> report them here so that we fix them.
> >>>>
> >>>> Please note that those trees are rebased from time to time.
> >>>
> >>> Really cool! Thanks so much for your work, i quickly looked at the
> >>> structure of the patches and the commit messages. I think that
> >>> should greatly improve the documentation and we will see how well
> >>> that works for the next rebase. But i hope and assume that will
> >>> become much easier with this approach.
> >>> 
> >>>> == Generic changes
> >>>>
> >>>> - select HAVE_IPIPE_SUPPORT is needed from the arch-code
> >>>> (Kconfig) to enable the generic I-pipe bits. This way we can
> >>>> have an incremental build, without requiring the arch-code to be
> >>>> present in the commit stack for testing generic changes.
> >>>>
> >>>> - Likewise, select HAVE_IPIPE_TRACER_SUPPORT is needed from the
> >>>> arch-code when the tracer is available. Only ARM needs this
> >>>> currently, due to the TSC emulation support we need to provide
> >>>> there to get timestamps which is not part of the ARM-specific
> >>>> pipeline core. x86 and ppc32 have their own tsc/timebase readily
> >>>> available when the core bits are in.
> >>>>
> >>>> - __ipipe_init_threadflags() now receives struct thread_info *.
> >>>> To be updated in the arch-specific bits.
> >>>>
> >>>> == x86
> >>>>
> >>>> The basic port available at [2] boots over KVM and a couple of
> >>>> real hw I have here, x86_64 only, x86_32 is untested and likely
> >>>> not complete - although little should be left. It enables the
> >>>> interrupt pipeline, but has not been checked against Xenomai,
> >>>> since FPU support is not there (*).
> >>>
> >>> I have got a working eager-fpu 4.4 and 4.9 and looked into this
> >>> 4.14 as well, in the hope to get the patch against xenomai in a
> >>> shape that will work for all three kernels.
> >>>
> >>> So i ported my kernel patch to this 4.14 and adjusted xenomai to
> >>> work on that as well. Unfortunately the kernel does not boot. It
> >>> gets stuck right after switching the clocksource to tsc. My
> >>> current assumption is that the timer does not work, maybe
> >>> interrupts in general.
> >>>
> >>> Do you have a suggestion how to best debug that? I could also
> >>> share the current state of the fpu-patches so you could have a
> >>> direct look at it yourself.
> >>
> >> I recently wrote a (short) piece about identifying and chasing
> >> those issues:
> >>
> >&

Re: [Xenomai] I-pipe split series

[Henning Schild]

Am Mon, 27 Aug 2018 16:15:21 +0200
schrieb Philippe Gerum :

> On 08/27/2018 01:24 PM, Henning Schild wrote:
> > Hi Philippe,
> > 
> > Am Mon, 30 Jul 2018 20:10:17 +0200
> > schrieb Philippe Gerum :
> >   
> >> The generic I-pipe code is now available as a series of incremental
> >> commits at [1] on top of the 4.14.58 kernel. This allows to port
> >> the I-pipe patch gradually, first to enable IRQ pipelining per se,
> >> then add the bits required for co-managing tasks between the
> >> regular kernel and the co-kernel, which builds on the former. Most
> >> patches have gained a description in their respective short log,
> >> which added to Documentation/ipipe.rst, should help clarifying the
> >> process of porting the pipeline.
> >>
> >> While I was at it, I did a pre-port of the x86 patch to kernel
> >> 4.14.58, which has been useful for validating the split series. I
> >> hope this will help the x86 maintainers to clear that hurdle
> >> eventually.
> >>
> >> The whole pile of patches went through countless incremental builds
> >> over multiple configurations, and tedious manual fixups over a few
> >> weeks. However, there is room for issues, given the amount of code
> >> involved, and the varying configurations one can apply. If you find
> >> any problem with that split series, please report them here so that
> >> we fix them.
> >>
> >> Please note that those trees are rebased from time to time.  
> > 
> > Really cool! Thanks so much for your work, i quickly looked at the
> > structure of the patches and the commit messages. I think that
> > should greatly improve the documentation and we will see how well
> > that works for the next rebase. But i hope and assume that will
> > become much easier with this approach.
> >   
> >> == Generic changes
> >>
> >> - select HAVE_IPIPE_SUPPORT is needed from the arch-code (Kconfig)
> >> to enable the generic I-pipe bits. This way we can have an
> >> incremental build, without requiring the arch-code to be present
> >> in the commit stack for testing generic changes.
> >>
> >> - Likewise, select HAVE_IPIPE_TRACER_SUPPORT is needed from the
> >> arch-code when the tracer is available. Only ARM needs this
> >> currently, due to the TSC emulation support we need to provide
> >> there to get timestamps which is not part of the ARM-specific
> >> pipeline core. x86 and ppc32 have their own tsc/timebase readily
> >> available when the core bits are in.
> >>
> >> - __ipipe_init_threadflags() now receives struct thread_info *. To
> >> be updated in the arch-specific bits.
> >>
> >> == x86
> >>
> >> The basic port available at [2] boots over KVM and a couple of real
> >> hw I have here, x86_64 only, x86_32 is untested and likely not
> >> complete - although little should be left. It enables the interrupt
> >> pipeline, but has not been checked against Xenomai, since FPU
> >> support is not there (*).  
> > 
> > I have got a working eager-fpu 4.4 and 4.9 and looked into this
> > 4.14 as well, in the hope to get the patch against xenomai in a
> > shape that will work for all three kernels.
> > 
> > So i ported my kernel patch to this 4.14 and adjusted xenomai to
> > work on that as well. Unfortunately the kernel does not boot. It
> > gets stuck right after switching the clocksource to tsc. My current
> > assumption is that the timer does not work, maybe interrupts in
> > general.
> > 
> > Do you have a suggestion how to best debug that? I could also share
> > the current state of the fpu-patches so you could have a direct
> > look at it yourself.  
> 
> I recently wrote a (short) piece about identifying and chasing those
> issues:
> 
> https://dovetail.xenomai.org/pipeline/porting/devnotes/#losing-the-timer-tick

Yes, that description sounds about right. I am still digging to see why
_no_ interrupts seem to be arriving.

But i imagine you are looking forward to seeing the 4.14 split series
in action as well and might want to have a look as well. Here is what i
am currently working with, fpu should work ... once we are up.

https://github.com/henning-schild-work/linux-ipipe/tree/henning/fpu/4.14
https://github.com/henning-schild-work/xenomai/tree/henning/fpu

Henning

> This doc applies to Dovetail which unlike the I-pipe provides a
> full-fledged proxy tick device as a regular clockevent object, but the
> basics remain mostly the same.
> 
> Note: you may want to add another potent

Re: [Xenomai] [PATCH 1/3] cobalt/x86: add support for eager fpu handling

[Henning Schild]

As all these ifdefs are getting pretty confusing and hard to read,
especially when looking at patches, i will probably rework this one.

The idea would be to have the old way on top and the new way at the end
of the file. No attempt to keep the two versions of functions close to
each other or "reuse" code from the other. That will increase
readability and allow for easy removal of the "lazy-path" when the time
has come.

Henning

Am Mon, 27 Aug 2018 18:12:39 +0200
schrieb Jan Kiszka :

> On 2018-08-27 15:28, Henning Schild wrote:
> > Upstream 4.14 switched to purely eager fpu switching. That was
> > backported to 4.4 and 4.9. This commit makes cobalt able to deal
> > whith the changed kernel behaviour.
> > 
> > Introduce IPIPE_X86_FPU_EAGER to switch between the new and the old
> > implementations. The new implementation is much simpler than the old
> > one. We basically only deal with the odd case where Xenomai preempts
> > Linux in a kernel-fpu context.
> > In a regular Linux that can never happen and if it happens we need
> > to make sure to get things into a consistent state. We have to make
> > "current" as not owning the fpu anymore and allow others to use
> > in-kernel fpu (kernel_fpu_enable). __switch_to from Linux will do
> > the rest.
> > 
> > Signed-off-by: Henning Schild 
> > ---
> >   .../cobalt/arch/x86/include/asm/xenomai/thread.h   |  8 ++-
> >   .../cobalt/arch/x86/include/asm/xenomai/wrappers.h |  6 ++
> >   kernel/cobalt/arch/x86/thread.c| 67
> > +- 3 files changed, 78 insertions(+), 3
> > deletions(-)
> > 
> > diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
> > b/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h index
> > f174a82c0..0c5c4da9c 100644 ---
> > a/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h +++
> > b/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h @@ -24,6
> > +24,7 @@ #include 
> >   #include 
> >   
> > +#ifndef IPIPE_X86_FPU_EAGER
> >   #if LINUX_VERSION_CODE < KERNEL_VERSION(4,4,0)
> >   typedef union thread_xstate x86_fpustate;
> >   #define x86_fpustate_ptr(t) ((t)->fpu.state)
> > @@ -31,6 +32,7 @@ typedef union thread_xstate x86_fpustate;
> >   typedef union fpregs_state x86_fpustate;
> >   #define x86_fpustate_ptr(t) ((t)->fpu.active_state)
> >   #endif
> > +#endif
> >   
> >   struct xnarchtcb {
> > struct xntcb core;
> > @@ -40,10 +42,14 @@ struct xnarchtcb {
> > unsigned long ip;
> > unsigned long *ipp;
> >   #endif
> > +#ifdef IPIPE_X86_FPU_EAGER
> > +   struct fpu *kfpu;
> > +#else
> > x86_fpustate *fpup;
> > -   unsigned int root_kfpu: 1;
> > unsigned int root_used_math: 1;
> > x86_fpustate *kfpu_state;
> > +#endif
> > +   unsigned int root_kfpu: 1;
> > struct {
> > unsigned long ip;
> > unsigned long ax;
> > diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
> > b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h index
> > 5f9cff3c9..73df60cc6 100644 ---
> > a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h +++
> > b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h @@ -24,6
> > +24,12 @@ #define __get_user_inatomic __get_user
> >   #define __put_user_inatomic __put_user
> >   
> > +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,9,0) && \  
> 
> This condition it redundant to > 4.9.108.
> 
> > +LINUX_VERSION_CODE < KERNEL_VERSION(4,10,0) && \
> > +LINUX_VERSION_CODE > KERNEL_VERSION(4,9,108)
> > +#define IPIPE_X86_FPU_EAGER
> > +#endif
> > +
> >   #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
> >   #include 
> >   #include 
> > diff --git a/kernel/cobalt/arch/x86/thread.c
> > b/kernel/cobalt/arch/x86/thread.c index 7fb136300..54bc5c008 100644
> > --- a/kernel/cobalt/arch/x86/thread.c
> > +++ b/kernel/cobalt/arch/x86/thread.c
> > @@ -28,9 +28,13 @@
> >   
> >   static struct kmem_cache *xstate_cache;
> >   
> > +#ifdef IPIPE_X86_FPU_EAGER
> > +#define fpu_kernel_xstate_size sizeof(struct fpu)
> > +#else
> >   #if LINUX_VERSION_CODE < KERNEL_VERSION(4,7,0)
> >   #define fpu_kernel_xstate_size xstate_size
> >   #endif
> > +#endif
> >   
> >   #if LINUX_VERSION_CODE >= KERNEL_VERSION(4,6,0)
> >   #define cpu_has_xmm boot_cpu_has(X86_FEATURE_XMM)
> > @@ -199,20 +203,24 @@ void xnarch_switch_to(struct xnthread *out,
> > struct xnthread *in) struct mm_struct *pre

Re: [Xenomai] [PATCH 2/3] cobalt/x86: add ipipe-4.4 eager fpu support

[Henning Schild]

Am Mon, 27 Aug 2018 18:41:39 +0200
schrieb Jan Kiszka :

> On 2018-08-27 18:32, Henning Schild wrote:
> > Am Mon, 27 Aug 2018 18:18:01 +0200
> > schrieb Jan Kiszka :
> >   
> >> On 2018-08-27 15:28, Henning Schild wrote:  
> >>> Signed-off-by: Henning Schild 
> >>> ---
> >>>kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h | 6
> >>> ++ 1 file changed, 6 insertions(+)
> >>>
> >>> diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
> >>> b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h index
> >>> 73df60cc6..0156e86f0 100644 ---
> >>> a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h +++
> >>> b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h @@ -29,6
> >>> +29,12 @@ LINUX_VERSION_CODE > KERNEL_VERSION(4,9,108)
> >>>#define IPIPE_X86_FPU_EAGER
> >>>#endif
> >>> +// actually 4.4.138 drops lazy, but in IPIPE we do it at 72  
> >>
> >> Huh? We also do lazy up to 4.4.137, at least in x86 staging (latest
> >> release was .71, indeed). But nothing has been removed from that
> >> old version to prevent laziness.  
> > 
> > The idea of these numbers is to make them work right after a
> > (small) merge has been done on the kernel side. ipipe-4.4.y is at
> > 71 so i chose 72, because we can switch to eager before we have to.
> > 
> > In fact i do not care but that was the easiest for testing, because
> > it allowed testing without dealing with what happened between 71
> > and 152. I started off with that (big) merge and when conflicts
> > came up i decided to devide the problem.
> > 
> > What we could do to stay in line with 4.9 is merge in the minor
> > right before the upstream change (137), apply the patch with the
> > exact number (138), and possibly merge 152 after that. But hey we
> > can go eager whenever we want ... So i prefer the current way. Go
> > eager in 72 and later merge 152+.
> > 
> > Where is that staging branch you are talking about?  
> 
> https://gitlab.denx.de/Xenomai/ipipe-x86/tree/for-upstream/4.4
> 
> ipipe-x86/ipipe-4.4.y is just the mirror of upstream, thus will only 
> start to carry that changes when upstream picked them up. I think I 
> didn't send a PR so far, though.

Ok, i will change that number to >= 138.

Henning

> Jan
> 


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai