On 14.02.20 13:26, Q. Gylstorff wrote:
From: Quirin Gylstorff
Gitlab uses extends as an alternative to YAML Anchors since 11.3.
Signed-off-by: Quirin Gylstorff
---
.gitlab-ci.yml | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/.gitl
On 17.02.20 12:43, Jan Kiszka via Xenomai wrote:
On 14.02.20 13:26, Q. Gylstorff wrote:
From: Quirin Gylstorff
Gitlab uses extends as an alternative to YAML Anchors since 11.3.
Signed-off-by: Quirin Gylstorff
---
.gitlab-ci.yml | 35 ++-
1 file changed, 18
TU14756806
Thank You
-- next part --
A non-text attachment was scrubbed...
Name: config-4.19.tar.xz
Type: application/octet-stream
Size: 20180 bytes
Desc: config-4.19.tar.xz
URL:
<http://xenomai.org/pipermail/xenomai/attachments/20200217/bb047cbd/attachment.obj>
On 2/17/20 12:45 PM, Jan Kiszka wrote:
On 17.02.20 12:43, Jan Kiszka via Xenomai wrote:
On 14.02.20 13:26, Q. Gylstorff wrote:
From: Quirin Gylstorff
Gitlab uses extends as an alternative to YAML Anchors since 11.3.
Signed-off-by: Quirin Gylstorff
---
.gitlab-ci.yml | 35 ++
On 17.02.20 17:12, Gylstorff Quirin wrote:
On 2/17/20 12:45 PM, Jan Kiszka wrote:
On 17.02.20 12:43, Jan Kiszka via Xenomai wrote:
On 14.02.20 13:26, Q. Gylstorff wrote:
From: Quirin Gylstorff
Gitlab uses extends as an alternative to YAML Anchors since 11.3.
Signed-off-by: Quirin Gylstorf
On 14.02.20 15:15, Antoine Hoarau wrote:
I just built the debians:
debchange -v 3.1 Release 3.1
debuild -uc -us
I've done that (well, minus debchange) on a Debian 10, installed a
Xenomai kernel, and ran xeno-test - no problem. I would need this info:
ldd /usr/lib/xenomai/testsuite/libalchem
I managed to narrow it down to this:
trace-cmd start -e 'tlb:tlb_flush'
Seems to bug the kernel even if no cobalt thread is running, only a rt_igb and
the rtnet stack.
> -Original Message-
> From: Xenomai On Behalf Of Lange
> Norbert via Xenomai
> Sent: Montag, 17. Februar 2020 17:09
On 17.02.20 17:50, Lange Norbert via Xenomai wrote:
I managed to narrow it down to this:
trace-cmd start -e 'tlb:tlb_flush'
Seems to bug the kernel even if no cobalt thread is running, only a rt_igb and
the rtnet stack.
OK, that was already my idea as well.
That rcu_irq_enter_irqson must
On 17.02.20 17:57, Jan Kiszka via Xenomai wrote:
On 17.02.20 17:50, Lange Norbert via Xenomai wrote:
I managed to narrow it down to this:
trace-cmd start -e 'tlb:tlb_flush'
Seems to bug the kernel even if no cobalt thread is running, only a
rt_igb and the rtnet stack.
OK, that was alread
From: Jan Kiszka
Put it where the rest goes as well.
Signed-off-by: Jan Kiszka
---
testsuite/smokey/net_common/Makefile.am | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/testsuite/smokey/net_common/Makefile.am
b/testsuite/smokey/net_common/Makefile.am
index 5185449feb..
On 2/17/20 6:15 PM, Jan Kiszka via Xenomai wrote:
> On 17.02.20 17:57, Jan Kiszka via Xenomai wrote:
>> On 17.02.20 17:50, Lange Norbert via Xenomai wrote:
>>> I managed to narrow it down to this:
>>>
>>> trace-cmd start -e 'tlb:tlb_flush'
>>>
>>> Seems to bug the kernel even if no cobalt thread i
> -Original Message-
> From: Jan Kiszka
> Sent: Montag, 17. Februar 2020 18:16
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org)
> Subject: Re: Still some lockups when enabling ftrace
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> On 17.02.20 17:57,
On 17.02.20 18:25, Philippe Gerum wrote:
On 2/17/20 6:15 PM, Jan Kiszka via Xenomai wrote:
On 17.02.20 17:57, Jan Kiszka via Xenomai wrote:
On 17.02.20 17:50, Lange Norbert via Xenomai wrote:
I managed to narrow it down to this:
trace-cmd start -e 'tlb:tlb_flush'
Seems to bug the kernel eve
From: Jan Kiszka
We do not need the special handling of __DO_TRACE(..., rcuidle=1) when
running over the head domain. In fact, we cannot use it because it
switches to srcu which is incompatible with that context. It's safe to
switch to normal RCU because no head domain caller of a trace_*_rcuidle
On 2/17/20 6:33 PM, Jan Kiszka wrote:
> On 17.02.20 18:25, Philippe Gerum wrote:
>> On 2/17/20 6:15 PM, Jan Kiszka via Xenomai wrote:
>>> On 17.02.20 17:57, Jan Kiszka via Xenomai wrote:
On 17.02.20 17:50, Lange Norbert via Xenomai wrote:
> I managed to narrow it down to this:
>
>
On 17.02.20 19:10, Philippe Gerum wrote:
On 2/17/20 6:33 PM, Jan Kiszka wrote:
On 17.02.20 18:25, Philippe Gerum wrote:
On 2/17/20 6:15 PM, Jan Kiszka via Xenomai wrote:
On 17.02.20 17:57, Jan Kiszka via Xenomai wrote:
On 17.02.20 17:50, Lange Norbert via Xenomai wrote:
I managed to narrow i
On 2/17/20 7:13 PM, Jan Kiszka wrote:
> On 17.02.20 19:10, Philippe Gerum wrote:
>> On 2/17/20 6:33 PM, Jan Kiszka wrote:
>>> On 17.02.20 18:25, Philippe Gerum wrote:
On 2/17/20 6:15 PM, Jan Kiszka via Xenomai wrote:
> On 17.02.20 17:57, Jan Kiszka via Xenomai wrote:
>> On 17.02.20 17:
From: Jan Kiszka
This fixes the version of the generated packages.
Signed-off-by: Jan Kiszka
---
recipes-xenomai/xenomai/xenomai.inc | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/recipes-xenomai/xenomai/xenomai.inc
b/recipes-xenomai/xenomai/xenomai.inc
ind
From: Jan Kiszka
This fixes the version of the generated packages.
For recipes that do not carry a release version, set a Debian-compliant
one. For those cases, we also need to remove upstream's source/format.
Signed-off-by: Jan Kiszka
---
Changes in v2:
- fix builds of non-release versions
# ldd /usr/lib/xenomai/testsuite/libalchemy-test.so
linux-vdso.so.1 (0x7fff1f944000)
libcobalt.so.2 => /usr/lib/libcobalt.so.2 (0x7f2a40bc9000)
libalchemy.so.0 => /usr/lib/libalchemy.so.0 (0x7f2a409b1000)
libcopperplate.so.0 => /usr/lib/libcopperplate.so.
20 matches
Mail list logo
