[Xenomai] RTDM/RTNet - proposal to support sending/receiving multiple packets with one systemcall

[Lange Norbert]

Hello,

I would like to involve the RTDM Maintainers for discussing an addition to the 
RTDM drivermodel.
This work would be done by Phillipe Gerum as part of a contract, he is also 
better suited to outline the necessary changes,
should nothing stand against the proposal itself.

- Problem description

To be compatible with existing software, Ethernet packets will be polled at 
synchronized events.
The application ideally would give the kernel/rtnet stack the responsibility 
and freedom to do this in an efficient manner,
and be able to directly express the intend to poll all currently available 
packets.

Similarly, but less time-critical thus important, sending multiple packets in a 
burst would be a requirement.

Lastly Linux has this functionality in form of recvmmsg and sendmmsg,
which would be a good fit in terms of existing interface, atleast if used in 
non-blocking mode.

- Hypothetical Proposal

Adding the necessary interfaces to RTDM and RTNet
to allow non-blocking bulk receive/send, and offering functions not unlike the 
mentioned recvmmsg and sendmmsg.

- Potential issues

Copying of multiple packets would be done in RTDM context, potentially blocking 
resources for each packet or the whole duration.
For our usecase it would for example not matter if the involved ethernet driver 
instance is not able to handle IRQs during this time,
but it should not significantly affect worst-case task switch times in general, 
or block reception on other physical interfaces (Ethernet or otherwise).

recvmmsg and timeouts (blocking) are likely to be problematic, but blocking 
mode is not required or wanted.

- Open questions to the RTDM maintainers

What would be the requirements of adding similar functionality to recvmmsg to 
RTNet / RTDM,
and would there be any caveats that would prohibit addition from side of the 
RTDM maintainers?

Other than that, a mmap based approach is also an option, but that's a somewhat 
more involved solution for both kernel and userspace as far as I understood.

Kind regards

Norbert Lange


#
This message and any attachments are solely for the use of the intended 
recipients. They may contain privileged and/or confidential information or 
other information protected from disclosure. If you are not an intended 
recipient, you are hereby notified that you received this email in error and 
that any review, dissemination, distribution or copying of this email and any 
attachment is strictly prohibited. If you have received this email in error, 
please contact the sender and delete the message and any attachment from your 
system.
Thank You.
  ANDRITZ HYDRO GmbH
  Rechtsform/ Legal form: Gesellschaft mit beschr?nkter Haftung / Corporation
  Firmensitz/ Registered seat: Wien
  Firmenbuchgericht/ Court of registry: Handelsgericht Wien
  Firmenbuchnummer/ Company registration: FN 61833 g
  DVR: 0605077
  UID-Nr.: ATU14756806
#


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

Re: [Xenomai] RTDM/RTNet - proposal to support sending/receiving multiple packets with one systemcall

[Lange Norbert]

>-Original Message-
 >From: Stéphane Ancelot [mailto:sance...@numalliance.com]
 >Sent: Mittwoch, 06. Dezember 2017 09:15
 >To: Lange Norbert; Xenomai (xenomai@xenomai.org)
 >Cc: jan.kis...@siemens.com
 >Subject: Re: [Xenomai] RTDM/RTNet - proposal to support sending/receiving
 >multiple packets with one systemcall
 >
 >EMAIL from a NON-ANDRITZ SOURCE: as a security measure, please exercise
 >caution with email content and any links or attachments.
 >
 >
 >Hi,
 >
 >I have done an application that does this thing.
 >
 >the application manages a stack of frames with priorities. high
 >priorities frame are sent at synchronised time (each ms, synchronised by
 >external clock) and then if there is enough remaining time, low priority
 >frames. (ethercat bus application)
 >
 >The job is not done in driver, but in realtime application process.
 >
 >I have  2 stacks => Input / ouput packets
 >
 >I managed to link this task with an internal software switch that
 >permits to embed ethernet packets in ethercat (EoE)
 >
 > From my viewpoint, I don't understand the added value doing this on
 >driver side ?
 >
 >Regards,
 >
 >S.Ancelot

Hello,

Looking at the priorities, the system is roughly:
[irqs]
[rtnet/rtdm]
[rt-application]

We have a couple GBit ethernet connections which each could receive 1500 
Packets per ms (worst case). Any attempt to restrict the impact of a loaded 
connection (whether on purpose or in error) would have to be done at the driver 
side.
So disabling irqs on packet reception and being able to pull out available ones 
would need to be done on the driver level.

Our previous software (on a RT "Taskscheduler") did this by priming only a 
fixed amount of DMA receive buffers, which means there was a *bounded* amount 
of data to inspect, a *bounded* number of IRQS (0) and a *bounded* number of 
system calls,
with excess data dropped as early as possible - by the hardware, instead being 
passed down and rejected later.

Thus we could easily guarantee latencies and available CPU time for the RT 
applications, which is the primary point here (better performance is an 
advantage too): making everything more predictable.

Probably should explain that there is work do be done in the RTNet side, which 
is not the issue here. There is however work needed for RTDM to even *allow* 
modifying the behavior, and the basic question is: how and what could/should be 
done so upstreaming is easily doable.

Norbert

#
This message and any attachments are solely for the use of the intended 
recipients. They may contain privileged and/or confidential information or 
other information protected from disclosure. If you are not an intended 
recipient, you are hereby notified that you received this email in error and 
that any review, dissemination, distribution or copying of this email and any 
attachment is strictly prohibited. If you have received this email in error, 
please contact the sender and delete the message and any attachment from your 
system.
Thank You.
  ANDRITZ HYDRO GmbH
  Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation
  Firmensitz/ Registered seat: Wien
  Firmenbuchgericht/ Court of registry: Handelsgericht Wien
  Firmenbuchnummer/ Company registration: FN 61833 g
  DVR: 0605077
  UID-Nr.: ATU14756806
#

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

Re: [Xenomai] RTDM/RTNet - proposal to support sending/receiving multiple packets with one systemcall

[Lange Norbert]

 >-Original Message-
 >From: Jan Kiszka [mailto:jan.kis...@siemens.com]
 >Sent: Mittwoch, 06. Dezember 2017 09:27
 >To: Stéphane Ancelot; Lange Norbert; Xenomai (xenomai@xenomai.org)
 >Subject: Re: [Xenomai] RTDM/RTNet - proposal to support sending/receiving
 >multiple packets with one systemcall
 >
 >EMAIL from a NON-ANDRITZ SOURCE: as a security measure, please exercise
 >caution with email content and any links or attachments.
 >
 >
 >On 2017-12-06 09:15, Stéphane Ancelot wrote:
 >> Hi,
 >>
 >> I have done an application that does this thing.
 >>
 >> the application manages a stack of frames with priorities. high
 >> priorities frame are sent at synchronised time (each ms, synchronised by
 >> external clock) and then if there is enough remaining time, low priority
 >> frames. (ethercat bus application)
 >>
 >> The job is not done in driver, but in realtime application process.
 >>
 >> I have  2 stacks => Input / ouput packets
 >>
 >> I managed to link this task with an internal software switch that
 >> permits to embed ethernet packets in ethercat (EoE)
 >>
 >> From my viewpoint, I don't understand the added value doing this on
 >> driver side ?
 >
 >In general, it helps a lot in such discussions to have some basic
 >benchmark numbers for the existing the new pattern at hand, even if the
 >latter is just a proof-of-concept hack.

There is more to this than basic performance, easier measurements for 
worst-case impact for one.
Also the RTDM part would be merely enabling such different RTNet schemes, not 
by default replacing anything,
AFAIK you also have a PACKET_MMAP equivalent in RTDM, while its currently not 
available for the network stack.

Norbert.

 >Jan
 >
 >>
 >> Regards,
 >>
 >> S.Ancelot
 >>
 >>
 >> Le 05/12/2017 à 15:38, Lange Norbert a écrit :
 >>> Hello,
 >>>
 >>> I would like to involve the RTDM Maintainers for discussing an
 >>> addition to the RTDM drivermodel.
 >>> This work would be done by Phillipe Gerum as part of a contract, he is
 >>> also better suited to outline the necessary changes,
 >>> should nothing stand against the proposal itself.
 >>>
 >>> - Problem description
 >>>
 >>> To be compatible with existing software, Ethernet packets will be
 >>> polled at synchronized events.
 >>> The application ideally would give the kernel/rtnet stack the
 >>> responsibility and freedom to do this in an efficient manner,
 >>> and be able to directly express the intend to poll all currently
 >>> available packets.
 >>>
 >>> Similarly, but less time-critical thus important, sending multiple
 >>> packets in a burst would be a requirement.
 >>>
 >>> Lastly Linux has this functionality in form of recvmmsg and sendmmsg,
 >>> which would be a good fit in terms of existing interface, atleast if
 >>> used in non-blocking mode.
 >>>
 >>> - Hypothetical Proposal
 >>>
 >>> Adding the necessary interfaces to RTDM and RTNet
 >>> to allow non-blocking bulk receive/send, and offering functions not
 >>> unlike the mentioned recvmmsg and sendmmsg.
 >>>
 >>> - Potential issues
 >>>
 >>> Copying of multiple packets would be done in RTDM context, potentially
 >>> blocking resources for each packet or the whole duration.
 >>> For our usecase it would for example not matter if the involved
 >>> ethernet driver instance is not able to handle IRQs during this time,
 >>> but it should not significantly affect worst-case task switch times in
 >>> general, or block reception on other physical interfaces (Ethernet or
 >>> otherwise).
 >>>
 >>> recvmmsg and timeouts (blocking) are likely to be problematic, but
 >>> blocking mode is not required or wanted.
 >>>
 >>> - Open questions to the RTDM maintainers
 >>>
 >>> What would be the requirements of adding similar functionality to
 >>> recvmmsg to RTNet / RTDM,
 >>> and would there be any caveats that would prohibit addition from side
 >>> of the RTDM maintainers?
 >>>
 >>> Other than that, a mmap based approach is also an option, but that's a
 >>> somewhat more involved solution for both kernel and userspace as far
 >>> as I understood.
 >>>
 >>> Kind regards
 >>>
 >>> Norbert Lange
 >>>
 >>>
 >>>
 >
 >#
 >>>
 >

[Xenomai] Weird behavior during debug

[Lange Norbert]

Hello,

I tried debugging a cobalt application, and when I hit a breakpoint most of the 
system freezes.
If I run for example top over Serial or SSH, then the display won`t be 
refreshed anymore,
A separate program running as RT Task, waiting for an timer-event (occurring 10 
times a second) will block aswell.

So the debug session seems to block a rather big amount of events.

I am using a 4.9 kernel with ipipe at "x86/ipipe: fix detection of unhandled 
faults over the head domain".
Looking at the logs and other threads there seems to be a bigger rework in 
progress?
I will retry with master, and report back.

Kind regards

Norbert Lange



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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You


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

Re: [Xenomai] Weird behavior during debug

[Lange Norbert]

Same issue with latest ipipe. Threads look like this (when the instance is 
halted in the debugger).
Somehow, atleast the RT Tasks will block waiting on a timerfd when one task is 
in state XT (whatever that means)

# cat /proc/xenomai/sched/threads
CPU  PIDCLASS  TYPE  PRI   TIMEOUT   STAT   NAME
  0  0  idle   core   -1   - R  [ROOT/0]
  1  0  idle   core   -1   - R  [ROOT/1]
  2  0  idle   core   -1   - R  [ROOT/2]
  3  0  idle   core   -1   - R  [ROOT/3]
  2  264rt cobalt 20   - XT packetfilter
  1  279rt cobalt 20   - W  packetfilter

 >-Original Message-
 >From: Lange Norbert
 >Sent: Montag, 18. Dezember 2017 14:43
 >To: Xenomai (xenomai@xenomai.org)
 >Subject: Weird behavior during debug
 >
 >Hello,
 >
 >I tried debugging a cobalt application, and when I hit a breakpoint most of 
 >the
 >system freezes.
 >If I run for example top over Serial or SSH, then the display won`t be 
 >refreshed
 >anymore,
 >A separate program running as RT Task, waiting for an timer-event (occurring
 >10 times a second) will block aswell.
 >
 >So the debug session seems to block a rather big amount of events.
 >
 >I am using a 4.9 kernel with ipipe at "x86/ipipe: fix detection of unhandled
 >faults over the head domain".
 >Looking at the logs and other threads there seems to be a bigger rework in
 >progress?
 >I will retry with master, and report back.
 >
 >Kind regards
 >
 >Norbert Lange



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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You


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

Re: [Xenomai] Weird behavior during debug

[Lange Norbert]

Hello Jan,

My follow-up post was done after running the latest ipipe-4.9.y patch, with 
your fix added on top.

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 834e6117f5f8..b9f6121c8530 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -83,7 +83,7 @@ config X86
select HAVE_AOUTif X86_32
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_HUGE_VMAP  if X86_64 || X86_PAE
-   select HAVE_ARCH_JUMP_LABEL
+   select HAVE_ARCH_JUMP_LABEL if !IPIPE
select HAVE_ARCH_KASAN  if X86_64 && SPARSEMEM_VMEMMAP
select HAVE_ARCH_KGDB
select HAVE_ARCH_KMEMCHECK

Norbert

 >-Original Message-
 >From: Jan Kiszka [mailto:jan.kis...@siemens.com]
 >Sent: Dienstag, 19. Dezember 2017 08:16
 >To: Lange Norbert; Xenomai (xenomai@xenomai.org)
 >Subject: Re: Weird behavior during debug
 >
 >EMAIL from a NON-ANDRITZ SOURCE: as a security measure, please exercise
 >caution with email content and any links or attachments.
 >
 >
 >On 2017-12-18 15:49, Lange Norbert wrote:
 >> Same issue with latest ipipe. Threads look like this (when the instance is
 >halted in the debugger).
 >> Somehow, atleast the RT Tasks will block waiting on a timerfd when one task
 >is in state XT (whatever that means)
 >>
 >> # cat /proc/xenomai/sched/threads
 >> CPU  PIDCLASS  TYPE  PRI   TIMEOUT   STAT   NAME
 >>   0  0  idle   core   -1   - R  [ROOT/0]
 >>   1  0  idle   core   -1   - R  [ROOT/1]
 >>   2  0  idle   core   -1   - R  [ROOT/2]
 >>   3  0  idle   core   -1   - R  [ROOT/3]
 >>   2  264rt cobalt 20   - XT packetfilter
 >>   1  279rt cobalt 20   - W  packetfilter
 >>
 >
 >Philippe reverted a number of commits in ipipe-4.9.y some days ago.
 >Please retry either with the latest version or the last release
 >(ipipe-core-4.9.51-x86-4).
 >
 >Jan
 >
 >>  >-Original Message-
 >>  >From: Lange Norbert
 >>  >Sent: Montag, 18. Dezember 2017 14:43
 >>  >To: Xenomai (xenomai@xenomai.org)
 >>  >Subject: Weird behavior during debug
 >>  >
 >>  >Hello,
 >>  >
 >>  >I tried debugging a cobalt application, and when I hit a breakpoint most 
 >> of
 >the
 >>  >system freezes.
 >>  >If I run for example top over Serial or SSH, then the display won`t be
 >refreshed
 >>  >anymore,
 >>  >A separate program running as RT Task, waiting for an timer-event
 >(occurring
 >>  >10 times a second) will block aswell.
 >>  >
 >>  >So the debug session seems to block a rather big amount of events.
 >>  >
 >>  >I am using a 4.9 kernel with ipipe at "x86/ipipe: fix detection of 
 >> unhandled
 >>  >faults over the head domain".
 >>  >Looking at the logs and other threads there seems to be a bigger rework in
 >>  >progress?
 >>  >I will retry with master, and report back.
 >>  >
 >>  >Kind regards
 >>  >
 >>  >Norbert Lange
 >>
 >> 
 >>
 >> This message and any attachments are solely for the use of the intended
 >recipients. They may contain privileged and/or confidential information or
 >other information protected from disclosure. If you are not an intended
 >recipient, you are hereby notified that you received this email in error and 
 >that
 >any review, dissemination, distribution or copying of this email and any
 >attachment is strictly prohibited. If you have received this email in error, 
 >please
 >contact the sender and delete the message and any attachment from your
 >system.
 >>
 >> ANDRITZ HYDRO GmbH
 >>
 >>
 >> Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation
 >>
 >> Firmensitz/ Registered seat: Wien
 >>
 >> Firmenbuchgericht/ Court of registry: Handelsgericht Wien
 >>
 >> Firmenbuchnummer/ Company registration: FN 61833 g
 >>
 >> DVR: 0605077
 >>
 >> UID-Nr.: ATU14756806
 >>
 >>
 >> Thank You
 >> 
 >>
 >> ___
 >> Xenomai mailing list
 >> Xenomai@xenomai.org
 >> https://xenomai.org/mailman/listinfo/xenomai
 >>
 >
 >--
 >Siemens AG, Corporate Technology, CT RDA ITP SES-DE
 >Corporate Competence Center Embedded Linux


This message and any attachments are solely for the 

Re: [Xenomai] Weird behavior during debug

[Lange Norbert]

Problem persists in ipipe-core-4.9.51-x86-4, ipipe-4.4 kernel crashes at boot 
(likely no good support for this SOC).
Used program is attached, it is being executed twice, once directly via serial 
or ssh, once via gdbserver or gdb (tested various combinations).

The directly executed program will stop (supposedly at read), as soon as the 
debugged program is halted.

Norbert

 >-Original Message-
 >From: Jan Kiszka [mailto:jan.kis...@siemens.com]
 >Sent: Dienstag, 19. Dezember 2017 10:35
 >To: Lange Norbert; Xenomai (xenomai@xenomai.org)
 >Subject: Re: Weird behavior during debug
 >
 >EMAIL from a NON-ANDRITZ SOURCE: as a security measure, please exercise
 >caution with email content and any links or attachments.
 >
 >
 >On 2017-12-19 09:56, Lange Norbert wrote:
 >> Hello Jan,
 >>
 >> My follow-up post was done after running the latest ipipe-4.9.y patch, with
 >your fix added on top.
 >>
 >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
 >> index 834e6117f5f8..b9f6121c8530 100644
 >> --- a/arch/x86/Kconfig
 >> +++ b/arch/x86/Kconfig
 >> @@ -83,7 +83,7 @@ config X86
 >> select HAVE_AOUTif X86_32
 >> select HAVE_ARCH_AUDITSYSCALL
 >> select HAVE_ARCH_HUGE_VMAP  if X86_64 || X86_PAE
 >> -   select HAVE_ARCH_JUMP_LABEL
 >> +   select HAVE_ARCH_JUMP_LABEL if !IPIPE
 >> select HAVE_ARCH_KASAN  if X86_64 &&
 >SPARSEMEM_VMEMMAP
 >> select HAVE_ARCH_KGDB
 >> select HAVE_ARCH_KMEMCHECK
 >>
 >
 >Does the problem persist with
 >- ipipe-core-4.9.51-x86-4
 >- ipipe-4.4
 >?
 >
 >Jan
 >
 >> Norbert
 >>
 >>  >-Original Message-
 >>  >From: Jan Kiszka [mailto:jan.kis...@siemens.com]
 >>  >Sent: Dienstag, 19. Dezember 2017 08:16
 >>  >To: Lange Norbert; Xenomai (xenomai@xenomai.org)
 >>  >Subject: Re: Weird behavior during debug
 >>  >
 >>  >EMAIL from a NON-ANDRITZ SOURCE: as a security measure, please
 >exercise
 >>  >caution with email content and any links or attachments.
 >>  >
 >>  >
 >>  >On 2017-12-18 15:49, Lange Norbert wrote:
 >>  >> Same issue with latest ipipe. Threads look like this (when the instance 
 >> is
 >>  >halted in the debugger).
 >>  >> Somehow, atleast the RT Tasks will block waiting on a timerfd when one
 >task
 >>  >is in state XT (whatever that means)
 >>  >>
 >>  >> # cat /proc/xenomai/sched/threads
 >>  >> CPU  PIDCLASS  TYPE  PRI   TIMEOUT   STAT   NAME
 >>  >>   0  0  idle   core   -1   - R  [ROOT/0]
 >>  >>   1  0  idle   core   -1   - R  [ROOT/1]
 >>  >>   2  0  idle   core   -1   - R  [ROOT/2]
 >>  >>   3  0  idle   core   -1   - R  [ROOT/3]
 >>  >>   2  264rt cobalt 20   - XT packetfilter
 >>  >>   1  279rt cobalt 20   - W  packetfilter
 >>  >>
 >>  >
 >>  >Philippe reverted a number of commits in ipipe-4.9.y some days ago.
 >>  >Please retry either with the latest version or the last release
 >>  >(ipipe-core-4.9.51-x86-4).
 >>  >
 >>  >Jan
 >>  >
 >>  >>  >-Original Message-
 >>  >>  >From: Lange Norbert
 >>  >>  >Sent: Montag, 18. Dezember 2017 14:43
 >>  >>  >To: Xenomai (xenomai@xenomai.org)
 >>  >>  >Subject: Weird behavior during debug
 >>  >>  >
 >>  >>  >Hello,
 >>  >>  >
 >>  >>  >I tried debugging a cobalt application, and when I hit a breakpoint 
 >> most
 >of
 >>  >the
 >>  >>  >system freezes.
 >>  >>  >If I run for example top over Serial or SSH, then the display won`t be
 >>  >refreshed
 >>  >>  >anymore,
 >>  >>  >A separate program running as RT Task, waiting for an timer-event
 >>  >(occurring
 >>  >>  >10 times a second) will block aswell.
 >>  >>  >
 >>  >>  >So the debug session seems to block a rather big amount of events.
 >>  >>  >
 >>  >>  >I am using a 4.9 kernel with ipipe at "x86/ipipe: fix detection of
 >unhandled
 >>  >>  >faults over the head domain".
 >>  >>  >Looking at the logs and other threads there seems to be a bigger 
 >> rework
 >in
 >> 

Re: [Xenomai] Weird behavior during debug

[Lange Norbert]

 >-Original Message-
 >From: Jan Kiszka [mailto:jan.kis...@siemens.com]
 >Sent: Dienstag, 19. Dezember 2017 19:57
 >To: Lange Norbert; Xenomai (xenomai@xenomai.org); Philippe Gerum
 >Subject: Re: Weird behavior during debug
 >
 >EMAIL from a NON-ANDRITZ SOURCE: as a security measure, please exercise
 >caution with email content and any links or attachments.
 >
 >
 >On 2017-12-19 14:44, Lange Norbert wrote:
 >>
 >> Problem persists in ipipe-core-4.9.51-x86-4, ipipe-4.4 kernel crashes at 
 >> boot
 >(likely no good support for this SOC).
 >> Used program is attached, it is being executed twice, once directly via 
 >> serial
 >or ssh, once via gdbserver or gdb (tested various combinations).
 >>
 >> The directly executed program will stop (supposedly at read), as soon as the
 >debugged program is halted.
 >
 >OK, now I get the point: You need
 >http://git.xenomai.org/xenomai-
 >3.git/commit/?id=0d653e6db75f01287f83ddc3a4ba8189f0bd0366,
 >but that is only in next so far.

I applies cleanly on the wip/rtnet branch, so I did test it and indeed it fixes 
the issue.

 >
 >What happens in stable (and also in older versions) is that all Xenomai
 >timers in the system are stopped once one Xenomai application enters a
 >ptrace state. That is going to vanish in the next version, and we may
 >consider taking it to stable as well. What do you think, Philippe?

I don't know the direction where you want to go with the cobalt functionality,
this change is IMHO badly needed as digging into one process should never 
affect others.
However, there still is a difference to Linux behavior, namely that a periodic 
timerfd will read the
count of expired events after continuing. The cobalt implementation will just 
forget about them.

I suppose this hackaround is necessary so one-shot events aren`t dropped?

/* Hide overruns due to the most recent ptracing session. */
if (xnthread_test_localinfo(waiter, XNHICCUP))
return 0;

Norbert

 >Jan



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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

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

[Xenomai] Patched kernel headers - are they needed afterwards for gibc and more?

[Lange Norbert]

Hello,

A script with patches together a kernel, ipipe and xenomai kernel drivers. 
Result is the packages to install the kernel image.

A buildroot configuration will build the rootfs, without
  * using the identical kernel version (different patch level)
  * using headers that were used for building the kernel.
  * using the kernel .config

Instead, buildroot DL a different Linux kernel version by itself and used those 
headers.
I don`t think they are needed outside of glibc, but I am not sure.

Further, buildroot will create a "staging" installation for building further 
tools, including those using Xenomai APIs.

So, is this generally safe or something to avoid. I haven't ran into any issues 
yet.

Differences in the basic include files (same kernel version) seem to be rather 
trivial

diff -burN /tmp/header/include/asm-generic/mman-common.h 
/tmp/patched/usr/include/asm-generic/mman-common.h
--- /tmp/header/include/asm-generic/mman-common.h   2018-02-06 
14:26:43.657405976 +0100
+++ /tmp/patched/usr/include/asm-generic/mman-common.h  2018-02-06 
13:43:26.0 +0100
@@ -19,6 +19,9 @@
 #define MAP_TYPE   0x0f/* Mask for type of mapping */
 #define MAP_FIXED  0x10/* Interpret addr exactly */
 #define MAP_ANONYMOUS  0x20/* don't use a file */
+#ifndef MAP_BRK
+# define MAP_BRK   0
+#endif
 #ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED
 # define MAP_UNINITIALIZED 0x400   /* For anonymous mmap, memory could be 
uninitialized */
 #else
diff -burN /tmp/header/include/asm-generic/resource.h 
/tmp/patched/usr/include/asm-generic/resource.h
--- /tmp/header/include/asm-generic/resource.h  2018-02-06 14:26:43.689406277 
+0100
+++ /tmp/patched/usr/include/asm-generic/resource.h 2018-02-06 
13:43:26.0 +0100
@@ -57,5 +57,13 @@
 # define RLIM_INFINITY (~0UL)
 #endif

+/*
+ * Limit the stack by to some sane default: root can always
+ * increase this limit if needed..  8MB seems reasonable.
+ */
+#ifndef _STK_LIM
+# define _STK_LIM  (8*1024*1024)
+#endif
+

 #endif /* _ASM_GENERIC_RESOURCE_H */
diff -burN /tmp/header/include/linux/resource.h 
/tmp/patched/usr/include/linux/resource.h
--- /tmp/header/include/linux/resource.h2018-02-06 14:26:46.433432104 
+0100
+++ /tmp/patched/usr/include/linux/resource.h   2018-02-06 13:43:28.0 
+0100
@@ -59,12 +59,6 @@
 #definePRIO_USER   2

 /*
- * Limit the stack by to some sane default: root can always
- * increase this limit if needed..  8MB seems reasonable.
- */
-#define _STK_LIM   (8*1024*1024)
-
-/*
  * GPG2 wants 64kB of mlocked memory, to make sure pass phrases
  * and other sensitive information are never written to disk.
  */

Kind regards

Norbert Lange
AT-DES
ANDRITZ HYDRO GmbH
Eibesbrunnergasse 20
1120 Wien, Austria
APhone.: +43 50805 56684
. MailTo:norbert.la...@andritz.com
  



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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You


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

Re: [Xenomai] rtdm_timer_start latency?

[Lange Norbert]

Hello,

this seems identical to an issue I have. I wanted to start a millisecond tick, 
aligned to seconds, but used the POSIX timerfd_settime.
Under Linux this works as intendent, under cobalt it doesn't.

I  expect that the first timeout would be somewhat close to the call, on a 
"whole" millisecond.

What happens is that the timer-function convert the (Nano-)seconds to the 
internal resolution. This has a small error, which normally won't matter for 
short timespans.
The problem here is, that the absolute time will get converted with a big 
(absolute) error - growing bigger the longer your system is up.

What you could do, is reading the current time and fixing it up to a whole tick 
close to it, name this prev_secondtime, then use this as initial value.
Now the driver will have to fixup nothing or only a small amount, keeping the 
error low.

You can also try fixing this at driver level, but I haven't dissected this 
carefully yet.
Basically the driver should calculate in the "source time" for as long as 
possible and only use the converted internal value for close events to keep 
conversion errors bounded.

Norbert

Highly experimental patch for ./kernel/cobalt/timer.c

--- timer.c.org 2017-12-18 10:09:37.283116000 +0100
+++ timer.c 2017-12-18 10:39:36.085302719 +0100
@@ -116,7 +116,7 @@
 {
struct xnclock *clock = xntimer_clock(timer);
xntimerq_t *q = xntimer_percpu_queue(timer);
-   xnticks_t date, now, delay, period;
+   xnticks_t date, now, delay, period, expired = 0;
unsigned long gravity;
int ret = 0;

@@ -141,6 +141,7 @@
default: /* XN_ABSOLUTE || XN_REALTIME */
date = xnclock_ns_to_ticks(clock, value);
if ((xnsticks_t)(date - now) <= 0) {
+   _ xnticks t nextvalue;
if (interval == XN_INFINITE)
return -ETIMEDOUT;
/*
@@ -148,9 +149,17 @@
 * delivery, wait for the next shot on the
 * periodic time line.
 */
-   delay = now - date;
+   expired = xnarch_div64(xnclock_ticks_to_ns(now - date), 
interval);
+   nextvalue = value + interval * (expired + 1);
+
+   /*
+* Note: need to think about errors for big offsets,
+* iteration of the correction is likely necessary,
+* until the value is within the boundaries [now, now + 
period)
+*/
+   date = xnclock_ns_to_ticks(clock, nextvalue);
+
period = xnclock_ns_to_ticks(clock, interval);
-   date += period * (xnarch_div64(delay, period) + 1);
}
break;
}

 >-Original Message-
 >From: Xenomai [mailto:xenomai-boun...@xenomai.org] On Behalf Of Lowell
 >Gilbert
 >Sent: Montag, 12. Februar 2018 14:41
 >To: xenomai@xenomai.org
 >Subject: Re: [Xenomai] rtdm_timer_start latency?
 >
 >E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
 >EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
 >ATTACHMENTS.
 >
 >
 >Lowell Gilbert  writes:
 >
 >> Philippe Gerum  writes:
 >>
 >>> On 02/09/2018 11:02 AM, Philippe Gerum wrote:
  On 02/09/2018 12:45 AM, Lowell Gilbert wrote:
 > Am I correct in assuming that when calling rtdm_timer_start(), I should
 > not be getting multi-second latencies before the first call to the timer
 > routine? Just checking before I dig in too far.
 >
 
  Of course not. I suspect an absolute expiry time is given with a
  relative mode spec.
 
 >>>
 >>> More generally, an absolute expiry time which is not based on the right
 >>> clock specified by the mode argument.
 >>>
 >>> i.e.
 >>>
 >>> expiry = rtdm_clock_monotonic(), mode = RTDM_TIMERMODE_REALTIME
 >=> BAD
 >>> expiry = rtdm_clock_realtime(), mode = RTDM_TIMERMODE_ABSOLUTE =>
 >BAD
 >>> expiry = rtdm_clock_realtime() or _monotonic(), mode =
 >>> RTDM_TIMERMODE_RELATIVE => BAD
 >>
 >> Okay, that makes sense.
 >>
 >> I was using 0 for expiry, because I really just wanted the periodic
 >> wakeup. I don't remember why I didn't create a periodic task instead of
 >> using a timer.
 >>
 >> What clock do I want to use to get the timer started? Once it starts, it
 >> runs fine; but it often takes two or three seconds before the first call
 >> into the handler.
 >>
 >> To put it another way, I'm trying to figure out what am I doing wrong in:
 >>   ret = rtdm_timer_start(&pstate.collect.timer, 1,
 >>  pstate.collect.period,
 >>  RTDM_TIMERMODE_RELATIVE);
 >
 >I could just rewrite the code to use a periodic task, but I'd prefer to
 >understand what is actually wrong with my current code first, to be sure
 >that refactoring will really solve my 

[Xenomai] building Xenomai Apps with CMake (RFC)

[Lange Norbert]

Hello,

I went ahead and created a script to add support for Xenomai (3+) to CMake. Its 
currently sufficient for me,
but I would like to get this in a shape that it is useful and robust enough for 
most people.
Ultimately it should end up up streamed to CMake (I hope the binutils-specific 
wrappers aren't a knock-out against adoption).

Mostly this should interest people that want to use CMake, but a few things 
might need support from the Xenomai distribution.
To be more specific: using precompiled object-files like the boostrap code and 
its linker wraps and redirections are something I would
like to avoid, or atleast offer an alternative that does not need that much 
work outside of a "regular build".
For that, having the bootstrap code (configurable or a few variants) installed 
as sourcecode would help.

Code is uploaded to Github : https://github.com/nolange/cmake_xenomai

Kind regards
Norbert Lange




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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You


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

Re: [Xenomai] building Xenomai Apps with CMake (RFC)

[Lange Norbert]

Hello,

 >-Original Message-
 >From: Jan Kiszka [mailto:jan.kis...@siemens.com]
 >Sent: Donnerstag, 05. April 2018 16:55
 >To: Lange Norbert; Xenomai (xenomai@xenomai.org); Henning Schild
 >Subject: Re: building Xenomai Apps with CMake (RFC)
 >
 >E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
 >EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
 >ATTACHMENTS.
 >
 >
 >On 2018-04-03 16:10, Lange Norbert wrote:
 >> Hello,
 >>
 >> I went ahead and created a script to add support for Xenomai (3+) to CMake.
 >Its currently sufficient for me,
 >> but I would like to get this in a shape that it is useful and robust enough 
 >> for
 >most people.
 >> Ultimately it should end up up streamed to CMake (I hope the 
 >> binutils-specific
 >wrappers aren't a knock-out against adoption).
 >>
 >> Mostly this should interest people that want to use CMake, but a few things
 >might need support from the Xenomai distribution.
 >> To be more specific: using precompiled object-files like the boostrap code
 >and its linker wraps and redirections are something I would
 >> like to avoid, or atleast offer an alternative that does not need that much
 >work outside of a "regular build".
 >> For that, having the bootstrap code (configurable or a few variants) 
 >> installed
 >as sourcecode would help.
 >>
 >> Code is uploaded to Github : https://github.com/nolange/cmake_xenomai
 >
 >Thanks for sharing this. IIRC, we have some Xeommai user in-house as
 >well who looked into cmake, need to check the status and scope again
 >(maybe Henning knows more). Could be interesting, indeed.

If I may ask, are you using the "boostraps" from Xenomai or some own init-code?
(that’s currently the biggest headache remaining)

 >
 >For my understanding: You need cmake upstream changes to make things
 >work? Or is this project something that could eventually be carried in
 >Xenomai upstream, just requiring some cmake version >= X?

No strict need to upstream the scripts in either Xenomai or CMake, the files 
just need to be in the search-path of CMake to be usable (likely doesnt need 
anything newer than CMake 3.0 but would need to test this).
I value the feedback from both communities, particularly because I don’t use 
anything but the Posix/Cobalt Skin
and getting it into CMake would be the best thing for maintenance.

Nevertheless it could be really helpful to add a headerfile in the Xenomai 
distribution, replicating the steps that 'boilerplate/init/bootstrap.c' does,
and allowing to disable parts of the functionality like the main wrapper.
That glue code would ideally be built together with libraries/executables using 
it (identical flags and such).
Right now the code is mostly duplicated and placed with the CMake Scripts, 
which is not ideal.

Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

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

Re: [Xenomai] building Xenomai Apps with CMake (RFC)

[Lange Norbert]

 >-Original Message-
 >From: Henning Schild [mailto:henning.sch...@siemens.com]
 >Sent: Freitag, 06. April 2018 10:47
 >To: Lange Norbert
 >Cc: Jan Kiszka; Xenomai (xenomai@xenomai.org)
 >Subject: Re: building Xenomai Apps with CMake (RFC)
 >
 >E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
 >EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
 >ATTACHMENTS.
 >
 >
 >Am Thu, 5 Apr 2018 15:54:34 +
 >schrieb Lange Norbert :
 >
 >> Hello,
 >>
 >>  >-Original Message-
 >>  >From: Jan Kiszka [mailto:jan.kis...@siemens.com]
 >>  >Sent: Donnerstag, 05. April 2018 16:55
 >>  >To: Lange Norbert; Xenomai (xenomai@xenomai.org); Henning Schild
 >>  >Subject: Re: building Xenomai Apps with CMake (RFC)
 >>  >
 >>  >E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
 >>  >EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
 >>  >ATTACHMENTS.
 >>  >
 >>  >
 >>  >On 2018-04-03 16:10, Lange Norbert wrote:
 >>  >> Hello,
 >>  >>
 >>  >> I went ahead and created a script to add support for Xenomai (3+)
 >>  >> to CMake.
 >>  >Its currently sufficient for me,
 >>  >> but I would like to get this in a shape that it is useful and
 >>  >> robust enough for
 >>  >most people.
 >>  >> Ultimately it should end up up streamed to CMake (I hope the
 >>  >> binutils-specific
 >>  >wrappers aren't a knock-out against adoption).
 >>  >>
 >>  >> Mostly this should interest people that want to use CMake, but a
 >>  >> few things
 >>  >might need support from the Xenomai distribution.
 >>  >> To be more specific: using precompiled object-files like the
 >>  >> boostrap code
 >>  >and its linker wraps and redirections are something I would
 >>  >> like to avoid, or atleast offer an alternative that does not need
 >>  >> that much
 >>  >work outside of a "regular build".
 >>  >> For that, having the bootstrap code (configurable or a few
 >>  >> variants) installed
 >>  >as sourcecode would help.
 >>  >>
 >>  >> Code is uploaded to Github :
 >>  >> https://github.com/nolange/cmake_xenomai
 >>  >
 >>  >Thanks for sharing this. IIRC, we have some Xeommai user in-house as
 >>  >well who looked into cmake, need to check the status and scope again
 >>  >(maybe Henning knows more). Could be interesting, indeed.
 >>
 >> If I may ask, are you using the "boostraps" from Xenomai or some own
 >> init-code? (that’s currently the biggest headache remaining)
 >
 >No, i do not know anyone using CMake with Xenomai, so i would not know
 >how to deal with bootstrap there.

This question was not limited to CMake, but I am curious whether the bootstrap 
magic
from the tools shipping with Xenomai is popular outside of it.

 >
 >>  >
 >>  >For my understanding: You need cmake upstream changes to make things
 >>  >work? Or is this project something that could eventually be carried
 >>  >in Xenomai upstream, just requiring some cmake version >= X?
 >>
 >> No strict need to upstream the scripts in either Xenomai or CMake,
 >> the files just need to be in the search-path of CMake to be usable
 >> (likely doesnt need anything newer than CMake 3.0 but would need to
 >> test this). I value the feedback from both communities, particularly
 >> because I don’t use anything but the Posix/Cobalt Skin and getting it
 >> into CMake would be the best thing for maintenance.
 >
 >It would probably be a good idea to try and mainline it in one of the
 >two projects. And my guess is that CMake would not really fit and they
 >might not want such code.

Well, there are multiple Linux-only modules already (FindLTTngUST, FindX11),
aswell as "non-OS" compilers like IAR.
I doubt they would be happy if I add some bootstrap code for Xenomai though.

https://cmake.org/cmake/help/latest/manual/cmake-modules.7.html

 >
 >> Nevertheless it could be really helpful to add a headerfile in the
 >> Xenomai distribution, replicating the steps that
 >> 'boilerplate/init/bootstrap.c' does, and allowing to disable parts of
 >> the functionality like the main wrapper. That glue code would ideally
 >> be built together with libraries/executables using it (identical
 >> flags and such). Right now the code is mostly duplicated and placed
 >> with the CMake Scripts, which is not ideal.
 >
 >I did not fully understand the boo

Re: [Xenomai] building Xenomai Apps with CMake (RFC)

[Lange Norbert]

>- none (--no-auto-init)
 >- bootstrap-pic.o (--auto-init-solib)
 >- bootstrap.o (--auto-init or default)
 >
 >To me the questions then are:
 >- The code there could be encapsulated in a header?
I dont see how it could not, it just uses public API
 >- or could be put in a lib?
As static lib: Not a good idea, as you would then need to pull the code in (ld 
just links objects which have referenced symbols)
As dynamic lib: Not entirely possible, and even less flexible than now. However 
helper-code should be put there (parsing "/proc/self/cmdline")
 >- only could be done in this way?

I actually added the "regular" booststrap linking in the object file,
https://github.com/nolange/cmake_xenomai/blob/master/examples/posix/cyclictest/CMakeLists.txt
Note that this will automatically decide whether to use the bootstrap.o or 
bootstrap-pic.o variant.

But I don’t like how this is done. You could use any kind of different 
compilerflags,
and separating the "bootstrapping" itself (configuring Xenomai + promoting the 
main thread)
from the "other" stuff (handling "--help" and adding a main method) would give 
you
a lot flexibility.

>Regarding to CMake, I solved this passing this arguments to VARS to cmake. So,
 >tge FindXenomai was a simple wrapper to xeno-config to obtain the correct
 >values
 >to build the xeno application.

The VARS approach is fragile, and won't play nice if you have a project
where you build multiple apps/libraries - some not using Xenomai.
Just think of unit-tests that run on plain Linux.
The "modern" CMake approach is to expose targets you can link to.

 >
 >If my memory doesn't fail it was something that Gilles recommend some years
 >ago.
 >The best way to build a xenomai application is to use the xeno-config output 
 >to
 >obtain the correct values.

The best way ist to "concentrate" the knowledge in the Xenomai project,
so Xenomai-4 will (hopefully) just build with your project.
This does not have to be isolated to xeno-config, which has some problems
If you have a relocatable build environment (and should not contain baseline 
and optimization  flags from the toolchain)

 >
 >So, my point of view is that you don't have to modify anything from Xenomai to
 >use it with CMake. Another thing is the bootstrap stuff that maybe it's a bit
 >ugly.

No, you don't have to, but some changes could make it more robust,
namely putting the bootstrap functionality in a header
and having the flags accessible without needing to execute a tool (even if it’s 
a shell-script).

I am still torn between whether a FindXenomai would be fitting better in CMake 
or Xenomai.

In CMake it would be easy to use, even with already released Xenomai Versions,
and easy to just add into your own project so you don’t need a not-yet-released 
CMake.
It might totally break down in the future, should Xenomai (4) have drastical 
changes.

In Xenomai, it would be easier to maintain and getting out information like the 
version
could be just ironed in when installing. It would need more changes to Xenomai 
however,
and this doesn’t help anyone with an already released version, so you will need 
an additional
Method of supporting those.

Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

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

[Xenomai] [PATCH] fix out-of-bounds access

[Lange Norbert]

Fix an invalid memory access in the testsuite.

Signed-off-by: Norbert Lange 
---
 testsuite/smokey/net_common/smokey_net_server.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/testsuite/smokey/net_common/smokey_net_server.c 
b/testsuite/smokey/net_common/smokey_net_server.c
index a0ed52fd9..2e19208e7 100644
--- a/testsuite/smokey/net_common/smokey_net_server.c
+++ b/testsuite/smokey/net_common/smokey_net_server.c
@@ -89,7 +89,7 @@ rtnet_rtcfg_add_client(int fd, const char *hwaddr, const char 
*ipaddr)
cmd.args.add.ip_addr = ip.s_addr;
cmd.args.add.timeout = 3000;
memcpy(cmd.args.add.mac_addr, mac.ether_addr_octet,
-   sizeof(cmd.args.add.mac_addr));
+   sizeof(mac.ether_addr_octet));

check_unix(ioctl(fd, RTCFG_IOC_ADD, &cmd));
 }
--
2.17.0



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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You


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

[Xenomai] [PATCH] add missing headers and casts, prefer POSIX definitions

[Lange Norbert]

Fix a few missing headers and casts

see http://man7.org/linux/man-pages/man2/bind.2.html
and http://man7.org/linux/man-pages/man2/open.2.html
and http://man7.org/linux/man-pages/man7/sigevent.7.html

Signed-off-by: Norbert Lange 
---
demo/posix/cobalt/gpiopwm.c  | 4 ++--
testsuite/smokey/posix-select/posix-select.c | 3 +++
2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/demo/posix/cobalt/gpiopwm.c b/demo/posix/cobalt/gpiopwm.c
index b34cbf1e1..eddd5cce5 100644
--- a/demo/posix/cobalt/gpiopwm.c
+++ b/demo/posix/cobalt/gpiopwm.c
@@ -219,7 +219,7 @@ static void *gpiopwm_udp_ctrl_thread(void *cookie)
   saddr.sin_port = htons(port);
   saddr.sin_family = AF_INET;
-   if (bind(sockfd, &saddr, sizeof(saddr)) < 0)
+  if (bind(sockfd, (struct sockaddr *)&saddr, sizeof(saddr)) < 0)
   perror("bind");
clen = sizeof(caddr);
@@ -230,7 +230,7 @@ static void *gpiopwm_udp_ctrl_thread(void *cookie)
   print_config("UDP Server\n");
memset(buf,'\0', blen);
-   ret = recvfrom(sockfd, buf, blen - 1, 0, &caddr, &clen);
+  ret = recvfrom(sockfd, buf, blen - 1, 0, (struct 
sockaddr *)&caddr, &clen);
   if (ret < 0)
   perror("recvfrom");
diff --git a/testsuite/smokey/posix-select/posix-select.c 
b/testsuite/smokey/posix-select/posix-select.c
index 6bd88ddb5..e9bf938b3 100644
--- a/testsuite/smokey/posix-select/posix-select.c
+++ b/testsuite/smokey/posix-select/posix-select.c
@@ -30,6 +30,9 @@
#include 
#include 
#include 
+#include 
+#include 
+#include 
#include 
 smokey_test_plugin(posix_select,
--
2.17.0



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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

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

Re: [Xenomai] [PATCH 3/3] provide an extended xenomai_init function

[Lange Norbert]

Short Explanation:

This first patch adds a header for creating bootstrap code,
The difference with the auto-init method being that this
should be preferable compiled together with the application.
Upside is that the compilation units (xenomai libs and applications)
now are cleanly separated and arcane linker wrapping is not needed.

This will need some changes, which should be no issue for new
Applications, eg. The main routine needs a small adaption:


int xenomai_init_getargv(int *argc, char *const** argv);

extern "C" int main(int argc, char *const argv[], char * const envp[])
{
xenomai_init_getargv(&argc, &argv);

}



And in one file you need to instance the bootstrap code like this:

#define _XENOMAI_BOOTSTRAP_DEFINE_MAINWRAPPER __real_main
#define _XENOMAI_BOOTSTRAP_WEAKREF_MAINWRAPPER __wrap_main
#include 


auto-init is still supported as before.

Second patch would move some code into the xenomai libraries,
The last one would allow passing flags to the xenomai_init routine.


I would also like to know if the glibc specific simplification would be
acceptable to be enabled by default. (_XENOMAI_BOOTSTRAP_GLIBC_CONSTRUCTORS)
I tested it both for executable and shared libraries and it does work,
But I am not so certain with the macro guards and how long this extended
Functionality has been available.

Kind regards,
Norbert

-Original Message-
From: Norbert Lange 
Sent: Montag, 23. April 2018 16:24
To: xenomai@xenomai.org
Cc: Lange Norbert 
Subject: [PATCH 3/3] provide an extended xenomai_init function

E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE EXERCISE 
CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR ATTACHMENTS.


This function is a single entrypoint for both shared libraries and executables.
Futher it allows passing flags as additional argument.

Signed-off-by: Norbert Lange 
---
 include/xenomai/bootstrap-template.h | 19 +
 include/xenomai/init.h   |  2 ++
 lib/boilerplate/setup.c  | 42 +++-
 3 files changed, 50 insertions(+), 13 deletions(-)

diff --git a/include/xenomai/bootstrap-template.h 
b/include/xenomai/bootstrap-template.h
index d9fb0b313..29eb8e8d6 100644
--- a/include/xenomai/bootstrap-template.h
+++ b/include/xenomai/bootstrap-template.h
@@ -81,6 +81,8 @@
  *  Set a weak reference to the defined main function
  * _XENOMAI_BOOTSTRAP_DSO
  *  Should be defined when building shared libraries
+ * _XENOMAI_BOOTSTRAP_INITFLAGS
+ *  Flags passed to the xenomai_init_ext function
  */

 #define _XENOMAI_BOOTSTRAP_GLIBC_CONSTRUCTORS
@@ -256,11 +258,28 @@ __bootstrap_ctor static void xenomai_bootstrap(void)
return;
 #endif

+
+#if !defined(_XENOMAI_BOOTSTRAP_INITFLAGS)
+   /* prefer previously existing functions for better backwards
+capability */
 #ifdef _XENOMAI_BOOTSTRAP_DSO
xenomai_init_dso(&argc, &argv);
 #else
xenomai_init(&argc, &argv);
 #endif
+#else
+   {
+   int isDso = 0;
+   unsigned long long bflags = 0; #ifdef
+_XENOMAI_BOOTSTRAP_DSO
+   isDso = 1;
+#endif
+#ifdef _XENOMAI_BOOTSTRAP_INITFLAGS
+   bflags = _XENOMAI_BOOTSTRAP_INITFLAGS; #endif
+   xenomai_init_ext(&argc, &argv, isDso, bflags);
+   }
+#endif
+
early_argc = argc;
early_argv = argv;
 }
diff --git a/include/xenomai/init.h b/include/xenomai/init.h index 
2a241aa3b..cca3d4c22 100644
--- a/include/xenomai/init.h
+++ b/include/xenomai/init.h
@@ -29,6 +29,8 @@ void xenomai_init(int *argcp, char *const **argvp);

 void xenomai_init_dso(int *argcp, char *const **argvp);

+void xenomai_init_ext(int *argcp, char *const **argvp, int isDso,
+unsigned long flags);
+
 int xenomai_bootstrap_getargv(int *argc, char *const** argv);

 int xenomai_init_fetchargv(int *argcp, char *const **argvp); diff --git 
a/lib/boilerplate/setup.c b/lib/boilerplate/setup.c index 6cd035134..60d37e35e 
100644
--- a/lib/boilerplate/setup.c
+++ b/lib/boilerplate/setup.c
@@ -486,7 +486,7 @@ __setup_section static int parse_setup_options(int *argcp, 
char **uargv,
return 0;
 }

-__setup_section static void __xenomai_init(int *argcp, char *const **argvp, 
const char *me)
+static void __xenomai_init(int *argcp, char *const **argvp, const char
+*me, unsigned long flags)
 {
struct setup_descriptor *setup;
int ret, base_opt_start;
@@ -641,25 +641,41 @@ fail:
early_panic("initialization failed, %s", symerror(ret));  }

-__setup_section void xenomai_init(int *argcp, char *const **argvp)
+static void _xenomai_init_ext(int *argcp, char *const **argvp, int
+isDso, unsigned long flags)
 {
-   const char *me = get_program_name();
+   const char *me = "DSO";
+   if (isDso)
+ 

Re: [Xenomai] xeno-config --no-mode-check still has -lmodechk

[Lange Norbert]

Hello,

Since I just ran into this….
libcobalt seems to really need libmodechk to define __real_malloc and 
__real_free.
I believe this to be a bug?

$ nm 
/home/lano/buildroot/host/x86_64-buildroot-linux-gnu/sysroot/usr/xenomai/lib/libcobalt.so
 | grep malloc
000199f0 T malloc_ex
 U malloc@@GLIBC_2.2.5
0001aef0 T malloc_usable_size_ex
 U __real_malloc
0001a430 T tlsf_malloc

Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

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

Re: [Xenomai] xeno-config --no-mode-check still has -lmodechk

[Lange Norbert]

Ok, I believe that's my entirely the fault of my changes, ignore the previous 
mail

Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You


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

Re: [Xenomai] Why get low latency while running stress command?

[Lange Norbert]

Hi,

I guess what happens is, that the CPU will be put to sleep and/or lower 
frequency and voltage between calls,
These transitions are rather slow and will then have to happen on wake-up
Disable any kind of powersaving features in Linux and possibly BIOS (C-States).

Kind regards,
Norbert

-Original Message-
From: Xenomai  On Behalf Of Kiwamu Okabe
Sent: Mittwoch, 13. Juni 2018 10:51
To: xenomai@xenomai.org
Subject: [Xenomai] Why get low latency while running stress command?

E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE EXERCISE 
CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR ATTACHMENTS.


Dear all,

I build Xenomai kernel on Debian GNU/Linux Stretch (amd64) with attached config.
It runs on Intel(R) Celeron(R) CPU J3355 @ 2.00GHz.

But the latency is not good:

```
$ sudo /usr/lib/xenomai/testsuite/latency
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
RTH|lat min|lat avg|lat max|-overrun|---msw|---lat best|--lat worst
RTD|  0.912|  6.856|414.649| 104| 0|  0.912|414.649
RTD|  6.065| 10.102|120.338| 109| 0|  0.912|414.649
RTD|  5.473| 10.465|124.834| 116| 0|  0.912|414.649
RTD|  6.224| 10.215|137.833| 125| 0|  0.912|414.649
RTD|  6.058| 10.392|126.856| 131| 0|  0.912|414.649
RTD|  1.126|  8.278|239.556| 145| 0|  0.912|414.649
RTD|  4.789|  9.966|122.924| 149| 0|  0.912|414.649
RTD|  5.228| 10.289|126.303| 157| 0|  0.912|414.649
RTD|  5.470| 10.273|126.994| 165| 0|  0.912|414.649
RTD|  5.624| 10.391|127.353| 171| 0|  0.912|414.649
RTD|  1.128| 10.766|429.696| 245| 0|  0.912|429.696
RTD|  5.568| 10.557|123.488| 249| 0|  0.912|429.696
RTD|  2.113|  8.890|253.340| 282| 0|  0.912|429.696
RTD|  6.056| 10.301|126.958| 285| 0|  0.912|429.696
RTD|  6.230| 10.411|127.802| 293| 0|  0.912|429.696
RTD|  5.787| 10.447|124.719| 299| 0|  0.912|429.696
RTD|  6.143| 10.307|126.947| 301| 0|  0.912|429.696
RTD|  6.250| 10.391|124.367| 303| 0|  0.912|429.696
RTD|  5.861| 10.367|126.357| 309| 0|  0.912|429.696
```

Strangely the result gets better while running stress command:

```
$ stress -v -c 8 -i 10 -d 8 &
$ sudo /usr/lib/xenomai/testsuite/latency
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
RTH|lat min|lat avg|lat max|-overrun|---msw|---lat best|--lat worst
RTD|  2.744|  4.108|  8.634|   0| 0|  2.744|  8.634
RTD|  2.872|  4.225|  8.670|   0| 0|  2.744|  8.670
RTD|  3.147|  4.250|  8.538|   0| 0|  2.744|  8.670
RTD|  2.767|  4.271| 10.512|   0| 0|  2.744| 10.512
RTD|  2.867|  4.239|  8.502|   0| 0|  2.744| 10.512
RTD|  2.826|  4.262|  9.819|   0| 0|  2.744| 10.512
RTD|  2.930|  4.222|  9.128|   0| 0|  2.744| 10.512
RTD|  2.840|  4.159|  8.984|   0| 0|  2.744| 10.512
RTD|  2.841|  4.112|  8.608|   0| 0|  2.744| 10.512
RTD|  2.828|  4.112|  8.557|   0| 0|  2.744| 10.512
RTD|  2.875|  4.124|  8.662|   0| 0|  2.744| 10.512
RTD|  2.795|  4.109|  9.112|   0| 0|  2.744| 10.512
RTD|  2.939|  4.103|  8.677|   0| 0|  2.744| 10.512
RTD|  2.867|  4.123|  8.686|   0| 0|  2.744| 10.512
RTD|  2.808|  4.106|  8.728|   0| 0|  2.744| 10.512
RTD|  2.940|  4.113|  8.488|   0| 0|  2.744| 10.512
RTD|  2.873|  4.132|  8.703|   0| 0|  2.744| 10.512
RTD|  2.994|  4.107|  8.479|   0| 0|  2.744| 10.512
RTD|  2.983|  4.147|  8.642|   0| 0|  2.744| 10.512
```

What's wrong? Should I set some kernel settings?

Best regards,
--
Kiwamu Okabe at METASEPI DESIGN
-- next part --
A non-text attachment was scrubbed...
Name: config-4.9.90-xenomai
Type: application/octet-stream
Size: 187638 bytes
Desc: not available
URL: 

___
Xenomai mailing list
Xenomai@x

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

[Lange Norbert]

Hello,

link order is important and goes left-to-right, this seems to include 
"wrappers",
which only wrap symbols that where already encountered (to the left of the 
wrapper argument)

Compare an application using malloc:
Variant A:
 -Wl,@modechk.wrappers -l modechk

The app is linked, extern symbol malloc is needed.
The call to malloc is wrapped to __wrap_malloc, and __real_malloc would be 
wrapped to malloc (but __real_malloc is not existing).
The function __wrap_malloc locates and uses the function from libmodechk (which 
now need malloc in turn).
malloc is used from libc.

Variant B:
-Wl,@modechk.wrappers   -l modechk

The call to malloc is wrapped to __wrap_malloc and __real_malloc is wrapped to 
malloc,
since there is no object file yet, this does nothing.
libmodechk exports __wrap_malloc and __real_malloc, yet no one cares and 
--as-needed
will remove it as dependency
The app objects depend on malloc.

I am not sure where your dependency to __real_malloc comes from, but I suppose
It's from the bootstrap code, which would be needed to be linked before the 
wrapper.
Probably weak dependencies further complicate things.

As noted by Henning, please look at https://github.com/nolange/cmake_xenomai,
could use some feedback =).
Particularly look at the patchset which also removes some headaches with linking
precompiled object file for bootstrapping (but needs some upstream changes).

Kind regards,
Norbert

-Original Message-
From: Xenomai  On Behalf Of Leopold 
Palomo-Avellaneda
Sent: Donnerstag, 6. September 2018 11:53
To: Xenomai@xenomai.org
Subject: [Xenomai] Order options to build a Xenomai program

E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE EXERCISE 
CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR ATTACHMENTS.


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
(0x000

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

[Lange Norbert]

> So, from my point of view it confirm my suspicious that the wrapper
> mechanism is fragile. I really didn't understand why Xenomai core team
> changed the native API for the POSIX. Although I saw the Jan Kiska
> conference video explaining it, tell me primitive or dump, but I prefer to 
> have
> a RT API that links against RT libraries and you can mix the POSIX functions
> that you want in a clear way.
>
> OTOH I have to admit that convert a POSIX program to RT in an easy way is
> amazing.

You can explicitly use the cobalt or std function with macros.
That said I have my issues with cascading headers from linux, c library and 
cobalt,
this is hard to follow with symbols potentially coming from anywhere.

> Norbert, I have followed your emails and your project. You did a good job,
> but I don't agree with your approach. My points are:
>
> - You are trying to convert Xenomai a CMake project and this probably will
> not happen because Upstream is very happy with the autotools. I don't like
> to touch anything from upstream. Maybe some patch, but incorporated in
> Upstream.

Sorry, that's nonsense, never thought about building Xenomai with CMake.

> - I would prefer follow the Upstream guidelines that recommends use xeno-
> config to obtain the needed parameters to build your application.
> So, any build tool should use xeno-config (maintained by upstream) that
> provide the correct flags or whatever to build your application.

I tried multiple approaches, using xeno-config fell out shortly.
-   it's (logically) an target "executable".
That imposes problems with CMake's normal search for those,
not to mention CI when your builder works in a partition with noexec.
I would want to use config-files directly or with a host-executable,
like pkg-config uses .pc files.
-   has problems if you relocate your build environment
I would prefer relative paths for simplicity
-   I need to extract all information and not just flags for ONE configuration
That’s the most important issue, I need the "building blocks" of the command
line, not ONE commandline. This means you need to know xeno-config
and its flags precisely and figure out how to dissect multiple outputs
in those "building blocks".
Fragile and not forwards-compatible.

Whats left is two variants:

FindXenomai - this would be placed in your project or up streamed in CMake.
Uses CMake functions to guess the paths, this might be hard to do with some 
libdir / includedir
Configurations and would need to be updated independently of Xenomai.

CMake Config files - you place those in /cmake/xenomai.
Those can be generated by config/install_cmakeconfig.sh from the repo (use same 
arguments as when configuring CMake).
The previously mentioned patchset adds those files to Xenomai and does this 
automatically when installing (using the autotools system).
Upstreaming in Xenomai would make everything hassle-free and 
forwards-compatible (the config files would always match the version).

The downside is of course that this would then be a burden to the Xenomai devs, 
but it should not need any changes outside of structural changes.
At which point someone will have to adapt CMake integration, however its done - 
I would prefer it to be done just once


The repo contains other changes, attempting to sanitize the bootstrapping 
methods,
Without those the provided examples might not work (only the upstream 
bootstrapping method will work).
I hope atleast those can be upstreamed.

> - I agree with Norbert that bootstraped code is not a good idea. But this
> change should be done by upstream. But if I'm not wrong, Phillipe said that it
> hasn't an easy solution.

It has no easy solution if you want to do build a POSIX-only project purely 
with linker arguments.
When you can afford add some lines of (Xenomai-specific) code to your project, 
it opens a lot possibilities.

>
> But for the curious, I have done this example:
>
> https://github.com/iocroblab/xenomai-cmake
>
> but it's not polished and had some mistakes. The idea is to use any Xenomai
> installation without touched and then use CMake to build your application.

Yes I get that, and I tried the same with FindXenomai. I consider the CMake 
Config approach
a lot better.

Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuc

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

[Lange Norbert]

>>> Norbert, I have followed your emails and your project. You did a good job,
>>> but I don't agree with your approach. My points are:
>>>
>>> - You are trying to convert Xenomai a CMake project and this probably will
>>> not happen because Upstream is very happy with the autotools. I don't like
>>> to touch anything from upstream. Maybe some patch, but incorporated in
>>> Upstream.
>>
>> Sorry, that's nonsense, never thought about building Xenomai with CMake.

> Sorry, you are right. It seemed that you tried to generated the config files
> generated usually with a cmake project.

I do, but that's not happening during configuration or installation. I created
the config templates with CMake as thast alot less error-prone and easier to 
maintain

>>> - I would prefer follow the Upstream guidelines that recommends use xeno-
>>> config to obtain the needed parameters to build your application.
>>> So, any build tool should use xeno-config (maintained by upstream) that
>>> provide the correct flags or whatever to build your application.
>>
>> I tried multiple approaches, using xeno-config fell out shortly.
>> -   it's (logically) an target "executable".
>> That imposes problems with CMake's normal search for those,
>> not to mention CI when your builder works in a partition with noexec.
>> I would want to use config-files directly or with a host-executable,
>> like pkg-config uses .pc files.
>
> I have not found any important problem with the xeno-config generate info or 
> any
> problem with cmake. I agree with you that you need to exec an script to 
> generate
> the info and it could have problems with partitions with noexec, etc.

Well, I did find problems if you eg. create a "buildroot" and then move it.

>> -   I need to extract all information and not just flags for ONE 
>> configuration
>
> I don't extract the information for one configuration. I extract ALL the 
> modules
> installed.

yes, and xeno-config was not conceived for that.

>> That’s the most important issue, I need the "building blocks" of the 
>>command
>> line, not ONE commandline. This means you need to know xeno-config
>> and its flags precisely and figure out how to dissect multiple outputs
>> in those "building blocks".
>> Fragile and not forwards-compatible.
>
> I don't agree. xeno-config is quite stable and well maintained. And it give 
> you
> the information that Upstream want that YOU use.

figuring out the arguments and parsing them from within CMake is what I meant 
with fragile
and not forwards-compatible.
If you have a project with Xenomai3 and a FindXenomai script,
then you might have to update your code just to be able to use a future
version. like for example if the linking order changed, which I suppose you 
aren't
deducing but use a fixed order.

>> Whats left is two variants:
>>
>> FindXenomai - this would be placed in your project or up streamed in CMake.
>> Uses CMake functions to guess the paths, this might be hard to do with some 
>> libdir / includedir
>> Configurations and would need to be updated independently of Xenomai.
>
> this is one way. Currently it just works.

It works for a couple projects you are using.

>> CMake Config files - you place those in /cmake/xenomai.
>> Those can be generated by config/install_cmakeconfig.sh from the repo (use 
>> same arguments as when configuring CMake).
>> The previously mentioned patchset adds those files to Xenomai and does this 
>> automatically when installing (using the autotools system).
>> Upstreaming in Xenomai would make everything hassle-free and 
>> forwards-compatible (the config files would always match the version).
>>
>> The downside is of course that this would then be a burden to the Xenomai 
>> devs, but it should not need any changes outside of structural changes.
>> At which point someone will have to adapt CMake integration, however its 
>> done - I would prefer it to be done just once
>>
>>
>> The repo contains other changes, attempting to sanitize the bootstrapping 
>> methods,
>> Without those the provided examples might not work (only the upstream 
>> bootstrapping method will work).
>> I hope atleast those can be upstreamed.
>
> So, maybe that config files generated by the autotools, are to me the best
> solution. Then, the responsible of compile and install xenomai in a system
> will generate the config files to use it.

the config files are not generated from scratch but have placeholders,
the same placeholders xeno-config has. That's using the information
right from the source =)

> But for this solution you need that Jan or Phillipe accept that and maintain
> that.

Yep. I have to start somewhere though.

> And looking your code and I would prefer a more simple way without modules
> and simple, just fill some config vars. Because then it could be easy to 
> maintain.

The repo deals with multiple issues, the config stuff is rather simple and 
straightforward.
not sure what you mean with modules? if you me

[Xenomai] Fun with cobalt interposing fcntl

[Lange Norbert]

Hello,

I ran into an annoying problem with cobalt, namely that it interposes functions 
with varargs like fcntl,
The issue is that it won't ever be able to correctly forward the varags.
In the example, fcntl will be interpreted as having an additional int 
parameter, while some functionality has a pointer instead,
This yields to truncation and errors.

Unfortunatly I don't see any way of fixing this easily, but I consider this 
harmful (silently breaking code).
IMHO  Would be better to remove the wrapping for fcntl and use an explicit 
cobalt function where necessary.

King regards,  Norbert

- offending code

bool lockfile(const char *fname)
{
int fd = open(fname, O_WRONLY | O_CREAT, S_IRUSR | S_IWUSR | S_IRGRP | 
S_IROTH);
if (fd < 0)
{
perror("Opening Component Lock");
return false;
}
struct flock fl = {F_WRLCK, SEEK_SET};

int ret = fcntl(fd, F_SETLK, &fl);
if (ret != 0)
{
perror("Acquiring Component Lock");
return false;
}
return true;
}

- wrapping in rtdm.c

COBALT_IMPL(int, fcntl, (int fd, int cmd, ...))
{
va_list ap;
int arg;
int ret;

va_start(ap, cmd);
arg = va_arg(ap, int);
va_end(ap);

ret = XENOMAI_SYSCALL3(sc_cobalt_fcntl, fd, cmd, arg);

if (ret != -EBADF && ret != -ENOSYS)
return set_errno(ret);

return __STD(fcntl(fd, cmd, arg));
}


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You


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

Re: [Xenomai] [PATCH] cobalt: fcntl uses void* instead of int

[Lange Norbert]

> > @@ -139,11 +139,11 @@ static int do_ioctl(int fd, unsigned int
> > request, void *arg)  COBALT_IMPL(int, fcntl, (int fd, int cmd, ...))
> > {
> >   va_list ap;
> > - int arg;
> > + void *arg;
> >   int ret;
> >
> >   va_start(ap, cmd);
> > - arg = va_arg(ap, int);
> > + arg = va_arg(ap, void *);
> >   va_end(ap);
> >
> >   ret = XENOMAI_SYSCALL3(sc_cobalt_fcntl, fd, cmd, arg); diff
> > --git a/lib/cobalt/wrappers.c b/lib/cobalt/wrappers.c index
> > 20ad63a61..2540e3c50 100644
> > --- a/lib/cobalt/wrappers.c
> > +++ b/lib/cobalt/wrappers.c
> > @@ -216,10 +216,10 @@ __weak
> >  int __real_fcntl(int fd, int cmd, ...)  {
> >   va_list ap;
> > - int arg;
> > + void *arg;
> >
> >   va_start(ap, cmd);
> > - arg = va_arg(ap, int);
> > + arg = va_arg(ap, void *);
> >   va_end(ap);
> >
> >   return fcntl(fd, cmd, arg);
> >
>
> Fair enough, however a generic 'long' may be a better pick than an
> opaque pointer type in this case (*), then you would need to fix up the
> Cobalt kernel side implementing the actual syscall to reflect this change.

Some fcntl calls use a pointer-to-struct, so void* or uintptr_t seems fitting 
for this?
 (TBH I just looked at what glibc is doing, and some weird archs might have 
sizeof(long) < sizeof(void*))

If Xenomai only supports calls with an int, maybe truncate it just for the 
syscall?
   ret = XENOMAI_SYSCALL3(sc_cobalt_fcntl, fd, cmd, (int)arg);
(rest of the patch untouched)

Not sure how syscalls are done, I expected the arguments are just passed in 
registers,
In which case it does not matter (unless you don’t fit a pointer in a register)

> Moving away from 'int' to a longer type will also require to make
> Cobalt's fcntl() syscall implementation aware of the mixed ABI models
> when CONFIG_XENO_ARCH_SYS3264 is enabled. i.e. the argument would
> still
> be conveyed as a 32bit value for applications conforming to the ia32emu
> or x32 ABIs running over a 64bit kernel.

Ok, I haven't thought about that at all. But since you apparently don't expect 
a pointer now,
truncating the value to an int for the syscall seems fitting.

Norbert



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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

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

is memory locking per core necessary?

[Lange Norbert via Xenomai]

Hello,

I am trying to track down some spurios relaxes.

What happens is that I:
-   cobalt_init calls  mlockall(MCL_CURRENT | MCL_FUTURE);
-   allocate and initialize some data in the heap area
-   spawn the xenomai-thread
-   wait for notification from the xenomai-thread (so that I know, any 
initialization there is done)
-   call mlockall(MCL_CURRENT | MCL_FUTURE) once more
-   notify the xenomai-thread (only now the real work starts)

Then the Xenomai thread will have spurios relaxes when writing data in the heap 
or bss (reads seem to be fine).
I am a bit confused why this happens, adding a mlockall(MCL_CURRENT | 
MCL_FUTURE) in the Xenomai thread
fixes the issue.
Note that  the locking should happen even before spawning the threads.

Message I get is:
Jan 15 12:05:19 buildroot kernel: [Xenomai] switching realtime_packet to 
secondary mode after exception #14 from user-space at 0x40f3ed (pid 1383)
Code is always a store to heap or bss.

X86_64 + 4.19.152-cip37-xeno15-static + glibc 2.28

/proc/pid/maps:
00429000-00435000 rw-p  00:00 0
014b5000-014f8000 rw-p  00:00 0  [heap]

/proc/pid/smaps:
00429000-00435000 rw-p  00:00 0
Size: 48 kB
KernelPageSize:4 kB
MMUPageSize:   4 kB
Rss:  48 kB
Pss:  48 kB
Shared_Clean:  0 kB
Shared_Dirty:  0 kB
Private_Clean: 0 kB
Private_Dirty:48 kB
Referenced:   48 kB
Anonymous:48 kB
LazyFree:  0 kB
AnonHugePages: 0 kB
ShmemPmdMapped:0 kB
Shared_Hugetlb:0 kB
Private_Hugetlb:   0 kB
Swap:  0 kB
SwapPss:   0 kB
Locked:   48 kB
THPeligible:0
VmFlags: rd wr mr mw me lo ac
014b5000-014f8000 rw-p  00:00 0  [heap]
Size:268 kB
KernelPageSize:4 kB
MMUPageSize:   4 kB
Rss: 268 kB
Pss: 268 kB
Shared_Clean:  0 kB
Shared_Dirty:  0 kB
Private_Clean: 0 kB
Private_Dirty:   268 kB
Referenced:  268 kB
Anonymous:   268 kB
LazyFree:  0 kB
AnonHugePages: 0 kB
ShmemPmdMapped:0 kB
Shared_Hugetlb:0 kB
Private_Hugetlb:   0 kB
Swap:  0 kB
SwapPss:   0 kB
Locked:  268 kB
THPeligible:0
VmFlags: rd wr mr mw me lo ac

Mit besten Grüßen / Kind regards

NORBERT LANGE



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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

FW: is memory locking per core necessary?

[Lange Norbert via Xenomai]

I originally had the Xenomai thread tied to another CPU-Core, hence the subject.
The issue happens also if all threads are tied to Core #0.

So the question should read: is memory locking per *thread* necessary?

> -Original Message-
> From: Lange Norbert
> Sent: Freitag, 15. Jänner 2021 13:14
> To: Xenomai (xenomai@xenomai.org) 
> Subject: is memory locking per core necessary?
>
> Hello,
>
> I am trying to track down some spurios relaxes.
>
> What happens is that I:
> -   cobalt_init calls  mlockall(MCL_CURRENT | MCL_FUTURE);
> -   allocate and initialize some data in the heap area
> -   spawn the xenomai-thread
> -   wait for notification from the xenomai-thread (so that I know, any
> initialization there is done)
> -   call mlockall(MCL_CURRENT | MCL_FUTURE) once more
> -   notify the xenomai-thread (only now the real work starts)
>
> Then the Xenomai thread will have spurios relaxes when writing data in the 
> heap
> or bss (reads seem to be fine).
> I am a bit confused why this happens, adding a mlockall(MCL_CURRENT |
> MCL_FUTURE) in the Xenomai thread fixes the issue.
> Note that  the locking should happen even before spawning the threads.
>
> Message I get is:
> Jan 15 12:05:19 buildroot kernel: [Xenomai] switching realtime_packet to
> secondary mode after exception #14 from user-space at 0x40f3ed (pid 1383)
> Code is always a store to heap or bss.
>
> X86_64 + 4.19.152-cip37-xeno15-static + glibc 2.28
>
> /proc/pid/maps:
> 00429000-00435000 rw-p  00:00 0
> 014b5000-014f8000 rw-p  00:00 0  
> [heap]
>
> /proc/pid/smaps:
> 00429000-00435000 rw-p  00:00 0
> Size: 48 kB
> KernelPageSize:4 kB
> MMUPageSize:   4 kB
> Rss:  48 kB
> Pss:  48 kB
> Shared_Clean:  0 kB
> Shared_Dirty:  0 kB
> Private_Clean: 0 kB
> Private_Dirty:48 kB
> Referenced:   48 kB
> Anonymous:48 kB
> LazyFree:  0 kB
> AnonHugePages: 0 kB
> ShmemPmdMapped:0 kB
> Shared_Hugetlb:0 kB
> Private_Hugetlb:   0 kB
> Swap:  0 kB
> SwapPss:   0 kB
> Locked:   48 kB
> THPeligible:0
> VmFlags: rd wr mr mw me lo ac
> 014b5000-014f8000 rw-p  00:00 0  
> [heap]
> Size:268 kB
> KernelPageSize:4 kB
> MMUPageSize:   4 kB
> Rss: 268 kB
> Pss: 268 kB
> Shared_Clean:  0 kB
> Shared_Dirty:  0 kB
> Private_Clean: 0 kB
> Private_Dirty:   268 kB
> Referenced:  268 kB
> Anonymous:   268 kB
> LazyFree:  0 kB
> AnonHugePages: 0 kB
> ShmemPmdMapped:0 kB
> Shared_Hugetlb:0 kB
> Private_Hugetlb:   0 kB
> Swap:  0 kB
> SwapPss:   0 kB
> Locked:  268 kB
> THPeligible:0
> VmFlags: rd wr mr mw me lo ac
>
> Mit besten Grüßen / Kind regards
>
> NORBERT LANGE



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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

Some build issues with dovetail + ipipe 4.19

[Lange Norbert via Xenomai]

Hello,


By accident I built 4.19.152-cip37-x86-15 with the wip/dovetail branch. I 
understand that this should be supported one day?
In the hope that this is of use for you, I get built following errors during 
the modpost step with this config:

ERROR: "__rtdm_nrtsig_execute" [drivers/xenomai/testing/xeno_switchtest.ko] 
undefined!
ERROR: "__rtdm_nrtsig_execute" [drivers/xenomai/net/drivers/igb/rt_igb.ko] 
undefined!
ERROR: "pipeline_read_wallclock" [drivers/xenomai/net/drivers/igb/rt_igb.ko] 
undefined!

Mit besten Grüßen / Kind regards

NORBERT LANGE

AT-RD3

ANDRITZ HYDRO GmbH
Eibesbrunnergasse 20
1120 Vienna / AUSTRIA
p: +43 50805 56684
norbert.la...@andritz.com
andritz.com



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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

kernel bug if rtnet device is accesses during unbind

[Lange Norbert via Xenomai]

Hello,

There is some bigger kernel oops when an rtnet device is unbound from
linux but still accessible via ioctl.
Effect and backtrace depends on timing, usually the rt_igb module will not
decrease its reference count, and a following soft reboot might hang.

To repoduce, for example with rt_igb (doubt its driver specific):

echo ":01:00.0" > /sys/bus/pci/drivers/rt_igb/bind
# rtifconfig has to run in background
echo ":01:00.0" > /sys/bus/pci/drivers/rt_igb/unbind & rtifconfig rteth0 up

* kernel oops attached at the end of mail.

Background: I wanted to use udev to set  the device up ASAP (and I missed the 
ACTION filter)
ACTION=="add", SUBSYSTEM=="rtnet", KERNEL=="rteth0", RUN+="/sbin/rtifconfig %k 
up"

This rule does not work for the reason that the udev rule fires
before the device is hooked in the rtnet subsystem.
I believe that this ordering might be the cause of the kernel bug aswell
(reachable via rtnet, while already unbound in linux/sysfs)

* udev log is added at the end

  kernel oops

[  350.463476] RTnet: unregistered rteth0
[  350.467328] invalid opcode:  [#1] SMP
[  350.471350] CPU: 0 PID: 564 Comm: zsh Not tainted 5.4.133-xeno6-static #3
[  350.478146] Hardware name: TQ-Group TQMxE39M/Type2 - Board Product Name, 
BIOS 5.12.30.28.22 09/30/2019
[  350.487458] I-pipe domain: Linux
[  350.490705] RIP: 0010:free_msi_irqs+0x170/0x1a0
[  350.495247] Code: 0f 84 e4 fe ff ff 31 ed eb 0f 83 c5 01 39 6b 14 0f 86 d4 
fe ff ff 8b 7b 10 01 ef e8 fa fa c8 ff 48 83 b8 80 00 00 00 00 74 e0 <0f> 0b 49 
8d b5 b0 00 00 00 e8 f2 93 c9 ff e9 d3 fe ff ff 48 8b 7d
[  350.514018] RSP: 0018:a6ad40077d30 EFLAGS: 00010286
[  350.519252] RAX: a32ab799d400 RBX: a32ab9b4b3c0 RCX: 
[  350.526392] RDX: a32aba52b478 RSI: a32aba52b680 RDI: 007c
[  350.533532] RBP:  R08: ac026f80 R09: 
[  350.540676] R10:  R11: ac026f88 R12: a32abb3a11c0
[  350.547817] R13: a32abb3a1000 R14: a6ad40077eb0 R15: a32ab6a26860
[  350.554960] FS:  7fa8dc65e640() GS:a32abba0() 
knlGS:
[  350.563058] CS:  0010 DS:  ES:  CR0: 80050033
[  350.568815] CR2: 0068a7e0 CR3: 000177135000 CR4: 003406f0
[  350.575957] Call Trace:
[  350.578421]  igb_reset_interrupt_capability+0x8a/0x90 [rt_igb]
[  350.584268]  igb_remove+0xbf/0x170 [rt_igb]
[  350.588458]  pci_device_remove+0x28/0x60
[  350.592391]  __device_release_driver+0x134/0x1e0
[  350.597016]  device_driver_detach+0x3c/0xa0
[  350.601205]  unbind_store+0x113/0x130
[  350.604877]  kernfs_fop_write+0xcb/0x1b0
[  350.608810]  vfs_write+0xa5/0x1d0
[  350.612134]  ksys_write+0x5f/0xe0
[  350.615461]  do_syscall_64+0x7a/0x3d0
[  350.619132]  ? ipipe_restore_root+0x47/0x70
[  350.623325]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  350.628386] RIP: 0033:0x7fa8dc7639c4
[  350.631970] Code: 15 d1 d4 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 
0f 1f 00 48 8d 05 f1 13 0d 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 
f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 48 89 54 24 18 48
[  350.650742] RSP: 002b:7ffd1feafee8 EFLAGS: 0246 ORIG_RAX: 
0001
[  350.658322] RAX: ffda RBX: 000d RCX: 7fa8dc7639c4
[  350.665466] RDX: 000d RSI: 00581ce0 RDI: 0001
[  350.672611] RBP: 7fa8dc832760 R08: 7fa8dc65e640 R09: 000a
[  350.679754] R10:  R11: 0246 R12: 000d
[  350.686897] R13: 00581ce0 R14: 000d R15: 7fa8dc82d740
[  350.694042] Modules linked in: rt_igb rtpacket rtnet
[  350.699024] ---[ end trace 582d575b2ac29cad ]---
[  350.703651] RIP: 0010:free_msi_irqs+0x170/0x1a0
[  350.708188] Code: 0f 84 e4 fe ff ff 31 ed eb 0f 83 c5 01 39 6b 14 0f 86 d4 
fe ff ff 8b 7b 10 01 ef e8 fa fa c8 ff 48 83 b8 80 00 00 00 00 74 e0 <0f> 0b 49 
8d b5 b0 00 00 00 e8 f2 93 c9 ff e9 d3 fe ff ff 48 8b 7d
[  350.726964] RSP: 0018:a6ad40077d30 EFLAGS: 00010286
[  350.732195] RAX: a32ab799d400 RBX: a32ab9b4b3c0 RCX: 
[  350.739335] RDX: a32aba52b478 RSI: a32aba52b680 RDI: 007c
[  350.746478] RBP:  R08: ac026f80 R09: 
[  350.753620] R10:  R11: ac026f88 R12: a32abb3a11c0
[  350.760760] R13: a32abb3a1000 R14: a6ad40077eb0 R15: a32ab6a26860
[  350.767902] FS:  7fa8dc65e640() GS:a32abba0() 
knlGS:
[  350.776000] CS:  0010 DS:  ES:  CR0: 80050033
[  350.781755] CR2: 0068a7e0 CR3: 000177135000 CR4: 003406f0
[  350.788907] [ cut here ]
[  350.793534] kernel BUG at drivers/pci/msi.c:375!


  udev log after binding

13:51:27 systemd-udevd[424]: rteth0: Device is queued (SEQNUM=1575, ACTION=add)
13:51:27 systemd-udevd[424]: Validate module index
13:51:27 systemd-ude

RE: kernel bug if rtnet device is accesses during unbind

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Dienstag, 3. August 2021 18:04
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Subject: Re: kernel bug if rtnet device is accesses during unbind
>
>
>
> CAUTION: External email. Do not click on links or open attachments unless you
> know the sender and that the content is safe.
>
> On 03.08.21 13:18, Lange Norbert via Xenomai wrote:
> > Hello,
> >
> > There is some bigger kernel oops when an rtnet device is unbound from
> > linux but still accessible via ioctl.
> > Effect and backtrace depends on timing, usually the rt_igb module will
> > not decrease its reference count, and a following soft reboot might hang.
> >
> > To repoduce, for example with rt_igb (doubt its driver specific):
> >
> > echo ":01:00.0" > /sys/bus/pci/drivers/rt_igb/bind # rtifconfig
> > has to run in background echo ":01:00.0" >
> > /sys/bus/pci/drivers/rt_igb/unbind & rtifconfig rteth0 up
> >
>
> So, running one after the other (rtifconfig up first) will not trigger this? 
> Then it
> would sounds like a race between rtnet or the driver preventing the unbind
> and the ongoing ifup.

There is definitely some missing synchronization, and arguably thing could
Be improved in terms of supporting uevents.
What happens as far as I can tell (the udev example is more explicit):
1) unbinding starts, deallocates (atleast part of) the instance
2) an uevent "remove rteth0" is catched by udev, handled by running 'rtifconfig 
rteth0 up' (this was originally by accident)
3) rtifconfig still finds the rteth0 device, but then accesses invalid memory

Ie. rtifconfig was called *after* linux did broadcast the removal of rteth0

This doesn't happen if commands are sent serially on the terminal or via script,
I guess the write is blocking until the instance is completely removed.

FYI, everything is running on core 0 via affinity mask, and its dead easy to 
reproduce.

Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

cobalt_assert_nrt should use __cobalt_pthread_kill

[Lange Norbert via Xenomai]

Hello,

I have some small slight issue with the cobalt_assert_nrt function,
incase a violation is detected the thread should get a signal,
but the implementation will implicitly get a signal during the execution of 
pthread_kill, see:


#0  getpid () at ../sysdeps/unix/syscall-template.S:60
#1  0x7fc1dc4fa0d6 in __pthread_kill (threadid=, signo=24) 
at ../sysdeps/unix/sysv/linux/pthread_kill.c:53
#2  0x7fc1dc8b2470 in callAssertFunction () at 
/home/lano/git/preload_checkers/src/pchecker.h:199
#3  malloc () at /home/lano/git/preload_checkers/src/pchecker_heap_glibc.c:220
#4 

You see, the signal should happen with the pc of #2, not from the 
implementation of glibc (or whatever c library).
So the function should be changed to:

void cobalt_assert_nrt(void)
{
if (cobalt_should_warn())
__cobalt_pthread_kill(pthread_self(), SIGDEBUG);
}

(or even replaced with the raw syscall ?)

Regards,
Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: cobalt_assert_nrt should use __cobalt_pthread_kill

[Lange Norbert via Xenomai]

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

A better stacktrace. (I actually cut the trace in the signal handler in case of 
hitting an __assert_fail)
BTW, __cobalt_pthread_kill(pthread_self(), SIGDEBUG) doesn’t seem to do a 
thing, doesn’t handle SIGDEBUG?

Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: cobalt_assert_nrt should use __cobalt_pthread_kill

[Lange Norbert via Xenomai]

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

Yes, but I dlsym it.
I would prefer if the cobalt_assert_nrt would be the start of the trace.

>
> > BTW, __cobalt_pthread_kill(pthread_self(), SIGDEBUG) doesn’t seem to do a
> thing, doesn’t handle SIGDEBUG?
> >
>
> It only triggers the signal (in one way or another...). Handling is up to the
> application. If you don't handle that, the application is terminated, 
> obviously.

The application continues running. But I did not try with 
__cobalt_pthread_kill(pthread_self(), SIGDEBUG)
but XENOMAI_SYSCALL2(sc_cobalt_thread_kill, thread, sig).
Means the cobalt syscall is not handling the signal.

So for to satisfy my OCD toggling off/on the modeswitch signals would be 
correct I guess

pthread_setmode_np(PTHREAD_WARNSW, 0, NULL);
pthread_kill(pthread_self(), SIGDEBUG);
pthread_setmode_np(0, PTHREAD_WARNSW, NULL);

or even just using a linux syscall:

getpid();

Point being that right now you trap alteast twice

I went forward and tried using a single linux sycall.

Stacktrace is now cleaner:

#0  0x7fc3997a1797 in cobalt_assert_nrt () from 
/opt/hipase2/buildroot-acpu/x86_64-buildroot-linux-gnu/sysroot/usr/xenomai/lib/libcobalt.so.2
#1  0x7fc3997c0470 in callAssertFunction () at 
/home/lano/git/preload_checkers/src/pchecker.h:199
#2  malloc () at /home/lano/git/preload_checkers/src/pchecker_heap_glibc.c:220
#3  

diff --git a/lib/cobalt/internal

RE: cobalt_assert_nrt should use __cobalt_pthread_kill

[Lange Norbert via Xenomai]

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

RE: cobalt_assert_nrt should use __cobalt_pthread_kill

[Lange Norbert via Xenomai]

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

Build failure branch 3.1.x

[Lange Norbert via Xenomai]

Hello,

rebuilding from the 3.1.x branch yields an error:

ERROR: "__xnthread_discard" [drivers/xenomai/testing/xeno_switchtest.ko] 
undefined!

xeno_switchtest can't be compiled as module because of this (works as built-in)

Mit besten Grüßen / Kind regards

NORBERT LANGE




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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: [PATCH] cobalt/thread: Export __xnthread_discard

[Lange Norbert via Xenomai]

That takes care of the issue, thanks for the quick help.

> -Original Message-
> From: Jan Kiszka 
> Sent: Mittwoch, 15. Dezember 2021 13:57
> To: Xenomai 
> Cc: Lange Norbert 
> Subject: [PATCH] cobalt/thread: Export __xnthread_discard
>
>
>
> CAUTION: External email. Do not click on links or open attachments unless you
> know the sender and that the content is safe.
>
> From: Jan Kiszka 
>
> It's needed since f4dac53c04ae by switchtest, and that could be compiled
> as module.
>
> Reported-by: Lange Norbert 
> Signed-off-by: Jan Kiszka 
> ---
>  kernel/cobalt/thread.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/kernel/cobalt/thread.c b/kernel/cobalt/thread.c
> index 2e1667d197..debc5077b1 100644
> --- a/kernel/cobalt/thread.c
> +++ b/kernel/cobalt/thread.c
> @@ -553,6 +553,7 @@ void __xnthread_discard(struct xnthread *thread)
> xnthread_deregister(thread);
> xnlock_put_irqrestore(&nklock, s);
>  }
> +EXPORT_SYMBOL_GPL(__xnthread_discard);
>
>  /**
>   * @fn void xnthread_init(struct xnthread *thread,const struct
> xnthread_init_attr *attr,struct xnsched_class *sched_class,const union
> xnsched_policy_param *sched_param)
> --
> 2.31.1


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

Kernel module symbol conflicts

[Lange Norbert via Xenomai]

Hello,

We use a setup with multiple network controllers, and so far only one of them 
is realtime capable.
The issue is, that there are nonRt and Rt drivers active at the same time (igb 
statically builtin and rt_igb as module).

And while it works, I got some irregular weird crashes. Is there an issue with 
the loaded rt_igb module having a lot symbols
that are identically named with the igb driver?

Does that mean the rt_igp module will use the exported functions/variables from 
the igb driver,
as a normal dynamic linker would?

Whats the policy of xenomai, should this even work (igp and rt_igp at the same 
time)?

Example of conflicting symbols:

# cat /proc/kallsyms | grep ' T igb_config'
94f3b2e0 T igb_configure_tx_ring
94f3b6f0 T igb_configure_rx_ring
94f49c30 T igb_config_collision_dist
94f49d50 T igb_config_fc_after_link_up

# nm 
/lib/modules/4.14.94-xeno2-static/kernel/drivers/xenomai/net/drivers/igb/rt_igb.ko
 | grep ' T igb_config'
4db0 T igb_config_collision_dist
4eb0 T igb_config_fc_after_link_up
dd60 T igb_configure_rx_ring
d9f0 T igb_configure_tx_ring



Mit besten Grüßen / Kind regards

NORBERT LANGE
AT-DES

ANDRITZ HYDRO GmbH
Eibesbrunnergasse 20
1120 Vienna / AUSTRIA
p: +43 50805 56684
norbert.la...@andritz.com
andritz.com


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: (unknown)

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Mittwoch, 10. April 2019 16:48
> To: Lange Norbert ; Xenomai
> 
> Subject: Re: (unknown)
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR ATTACHMENTS.
>
>
> [re-adding the list]
>
> On 10.04.19 16:44, Lange Norbert wrote:
> >
> >
> >> -Original Message-
> >> From: Xenomai  On Behalf Of Jan Kiszka
> via
> >> Xenomai
> >> Sent: Mittwoch, 10. April 2019 16:36
> >> To: Norbert Lange ; xenomai@xenomai.org
> >> Subject: Re: (unknown)
> >>
> >> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> >> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
> >>
> >>
> >> On 10.04.19 13:14, Norbert Lange via Xenomai wrote:
> >>> V3 of the patchset, corrected many checkstyle issues, simplified
> >>> condvar autoinit.
> >>>
> >>> I did not use ARRAY_SIZE, as that would need another include.
> >>>
> >>
> >> All applied now. Patch 1 was not cleanly based on next, though. I think 
> >> some
> >> local style cleanup was missing.
> >
> > I based all patches on master, thought this is the primary development 
> > branch?
> >
>
> Line 566 in lib/cobalt/mutex.c had a trailing tab, your patch context did not,
> and that made the application fail. Maybe that was removed while transporting
> the patch into your mail client - better use git send-email in that case.

I use git send-email, you would not be happy if I sent patches over our IT 
Server
(one or two examples should reside somewhere in the ML) =).

I did use git-format-patch with --ignore-space-at-eol, maybe that’s the reason.

I know there are a few holdouts, but since you got a gitlab server and ci 
running already,
merge-requests could do all those style checks and test for build-failures 
without taking
any time of the maintainers and shorter feedback cycles for the contributors.
My IT is rather hostile to anything email based.

Norbert



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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: having problems with daemonizing

[Lange Norbert via Xenomai]

> -Original Message-
> From: Xenomai  On Behalf Of Lowell
> Gilbert via Xenomai
> Sent: Freitag, 26. April 2019 23:19
> To: xenomai@xenomai.org
> Subject: having problems with daemonizing
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> Hi.
>
> I have an application working successfully with Xenomai 3.0.8 on a 4.14
> kernel. I use Yocto to build the system; when I tried to move to a newer
> version of Yocto, my application hung on trying to become a daemon. This is
> happening with the daemon() call (which is what I've used up to now) and
> with fork().
>
> I built a test application so that I could confirm that this problem only 
> occurs
> when I link (and wrap) with Xenomai. However, Xenomai doesn't seem to do
> anything significant with fork, so I'm puzzled about why this might be
> happening. I am not using libdaemon.
>
> Here are the changes that I thought might be significant:
> | newer (nonworking setup)  | older (working) |
> | gcc-cross-arm-8.2.0   |   7.3.0 |
> | glibc-2.28|2.26 |
> | glib-2.0-1_2.58.0 | 1_2.52.3-r0 |
> | binutils-cross-arm-2.31.1 |  2.29.1 |
> | coreutils-8.30|8.27 |
>
> Does anything jump out as a candidate for causing problems with a fork()
> call? Is there anything else I should be considering?

There is a general issue with glibc 2.28 (and newer), exec'ing a Xenomai 
executable after a fork:
https://www.xenomai.org/pipermail/xenomai/2019-March/040519.html

Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: [PATCH] lib/cobalt: init: do not call pthread_atfork() from atfork() handlers

[Lange Norbert via Xenomai]

(readding ML)

> -Original Message-
> From: Philippe Gerum 
> Sent: Dienstag, 14. Mai 2019 10:38
> To: Lange Norbert 
> Subject: Re: [PATCH] lib/cobalt: init: do not call pthread_atfork() from
> atfork() handlers
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 5/14/19 10:35 AM, Philippe Gerum wrote:
> > On 5/6/19 9:56 AM, Lange Norbert wrote:
> >> Hello Philippe,
> >>
> >> using this patch, smokey's "fork test" alone finishes, but..
> >> the smokey suite will hang when running that test after the mutex or
> >> cvars test. Eg.
> >>
> >> smokey --run=10,11
> >> smokey --run=12,11
> >
> > I cannot reproduce this with glibc 2.28, and the tip of my
> > for-upstream tree which includes that fix. Which glibc are you running?

Glibc 2.28, Xenomai userspace is based on current master branch
with fix added (tested both with and without our company stuff on top)

>
> Is this the sequence which hangs on your end?
>
> ~ # smokey --run=13-14
> posix_cond OK
> posix_fork OK
> ~ # smokey --run=15-14
> posix_mutex OK
> posix_fork OK
>

Yes:

root@buildroot:~# /usr/xenomai/bin/smokey --run=10
posix_mutex OK
root@buildroot:~# /usr/xenomai/bin/smokey --run=11
posix_fork OK
root@buildroot:~# /usr/xenomai/bin/smokey --run=10,11
posix_mutex OK

When it hangs, this is the stacktrace:
(switched to crosstool-NG for the toolchain, did not check to enable debuginfo 
for glibc).

(gdb) bt
#0  0x7f45b4d86feb in ?? () from /lib64/libc.so.6
#1  0x7f45b4de8b95 in malloc () from /lib64/libc.so.6
#2  0x7f45b4f81a53 in ?? () from /lib64/ld-linux-x86-64.so.2
#3  0x7f45b4f83149 in ?? () from /lib64/ld-linux-x86-64.so.2
#4  0x7f45b4f8d4cc in ?? () from /lib64/ld-linux-x86-64.so.2
#5  0x7f45b4ea7bcf in _dl_catch_exception () from /lib64/libc.so.6
#6  0x7f45b4f8d0bb in ?? () from /lib64/ld-linux-x86-64.so.2
#7  0x7f45b4ea71a3 in ?? () from /lib64/libc.so.6
#8  0x7f45b4ea7bcf in _dl_catch_exception () from /lib64/libc.so.6
#9  0x7f45b4ea7c40 in _dl_catch_error () from /lib64/libc.so.6
#10 0x7f45b4ea72a8 in ?? () from /lib64/libc.so.6
#11 0x7f45b4ea7317 in __libc_dlopen_mode () from /lib64/libc.so.6
#12 0x7f45b4dacfa5 in ?? () from /lib64/libc.so.6
#13 0x7f45b4f2051f in ?? () from /lib64/libpthread.so.0
#14 0x7f45b4e7ca84 in backtrace () from /lib64/libc.so.6
#15 0x7f45b4f4960c in cobalt_sigshadow_handler (sig=, 
si=, ctxt=) at 
/tmp/tmp.cTCUJSMLNc/xeno/lib/cobalt/sigshadow.c:55
#16 0x7f45b4f4965d in sigshadow_handler (sig=28, si=0x7ffcd1fb45f0, 
ctxt=0x7ffcd1fb44c0) at /tmp/tmp.cTCUJSMLNc/xeno/lib/cobalt/sigshadow.c:80
#17 
#18 0x7f45b4e6b242 in mmap64 () from /lib64/libc.so.6
#19 0x7f45b4de6a3c in ?? () from /lib64/libc.so.6
#20 0x7f45b4de775c in ?? () from /lib64/libc.so.6
#21 0x7f45b4de8ba7 in malloc () from /lib64/libc.so.6
#22 0x7f45b4f66754 in heapobj_pkg_init_private () at 
/tmp/tmp.cTCUJSMLNc/xeno/lib/copperplate/heapobj-heapmem.c:102
#23 0x7f45b4f62f17 in copperplate_init () at 
/tmp/tmp.cTCUJSMLNc/xeno/lib/copperplate/init.c:199
#24 0x7f45b4f4d6b0 in __xenomai_init (argcp=argcp@entry=0x7ffcd1fb4e44, 
argvp=argvp@entry=0x7ffcd1fb4e48, me=me@entry=0x7f45b4f53f29 "program") at 
/tmp/tmp.cTCUJSMLNc/xeno/lib/boilerplate/setup.c:630
#25 0x7f45b4f4dcac in xenomai_init (argcp=0x7ffcd1fb4e44, 
argvp=0x7ffcd1fb4e48) at /tmp/tmp.cTCUJSMLNc/xeno/lib/boilerplate/setup.c:685
#26 0x00405177 in ?? ()
#27 0x0041ae7d in ?? ()
#28 0x7f45b4d8740b in __libc_start_main () from /lib64/libc.so.6
#29 0x0040544a in ?? ()

Regards, Norbert

PS. Could you please have a look at this aswell: 
https://www.xenomai.org/pipermail/xenomai/2019-March/040572.html
(Its unrelated, but come back to my mind as I looked at some of my private 
commits not upstreamed)


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: [PATCH] lib/cobalt: init: do not call pthread_atfork() from atfork() handlers

[Lange Norbert via Xenomai]

> -Original Message-
> From: Philippe Gerum 
> Sent: Dienstag, 14. Mai 2019 12:05
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Subject: Re: [PATCH] lib/cobalt: init: do not call pthread_atfork() from
> atfork() handlers
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 5/14/19 11:53 AM, Lange Norbert wrote:
> > (readding ML)
> >
> >> -Original Message-
> >> From: Philippe Gerum 
> >> Sent: Dienstag, 14. Mai 2019 10:38
> >> To: Lange Norbert 
> >> Subject: Re: [PATCH] lib/cobalt: init: do not call pthread_atfork()
> >> from
> >> atfork() handlers
> >>
> >> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE,
> PLEASE
> >> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
> >>
> >>
> >> On 5/14/19 10:35 AM, Philippe Gerum wrote:
> >>> On 5/6/19 9:56 AM, Lange Norbert wrote:
> >>>> Hello Philippe,
> >>>>
> >>>> using this patch, smokey's "fork test" alone finishes, but..
> >>>> the smokey suite will hang when running that test after the mutex
> >>>> or cvars test. Eg.
> >>>>
> >>>> smokey --run=10,11
> >>>> smokey --run=12,11
> >>>
> >>> I cannot reproduce this with glibc 2.28, and the tip of my
> >>> for-upstream tree which includes that fix. Which glibc are you running?
> >
> > Glibc 2.28, Xenomai userspace is based on current master branch with
> > fix added (tested both with and without our company stuff on top)
> >
> >>
> >> Is this the sequence which hangs on your end?
> >>
> >> ~ # smokey --run=13-14
> >> posix_cond OK
> >> posix_fork OK
> >> ~ # smokey --run=15-14
> >> posix_mutex OK
> >> posix_fork OK
> >>
> >
> > Yes:
> >
> > root@buildroot:~# /usr/xenomai/bin/smokey --run=10 posix_mutex OK
> > root@buildroot:~# /usr/xenomai/bin/smokey --run=11 posix_fork OK
> > root@buildroot:~# /usr/xenomai/bin/smokey --run=10,11 posix_mutex OK
> >
> > When it hangs, this is the stacktrace:
> > (switched to crosstool-NG for the toolchain, did not check to enable
> debuginfo for glibc).
> >
> > (gdb) bt
> > #0  0x7f45b4d86feb in ?? () from /lib64/libc.so.6
> > #1  0x7f45b4de8b95 in malloc () from /lib64/libc.so.6
> > #2  0x7f45b4f81a53 in ?? () from /lib64/ld-linux-x86-64.so.2
> > #3  0x7f45b4f83149 in ?? () from /lib64/ld-linux-x86-64.so.2
> > #4  0x7f45b4f8d4cc in ?? () from /lib64/ld-linux-x86-64.so.2
> > #5  0x7f45b4ea7bcf in _dl_catch_exception () from /lib64/libc.so.6
>
> That is a different issue, possibly not directly related. backtrace() is used 
> over
> a signal context in the default SIGSHADOW handler libcobalt installs, which is
> unsafe since backtrace() calls malloc(). This run ends up with a recursive 
> call
> to malloc() which deadlocks on the internal arena lock. Disabling
> CONFIG_XENO_OPT_DEBUG_TRACE_RELAX may paper over the issue.

So smokeys fork will cause some relaxation log entries if I understood this 
correctly,
and a "clean" application should leave realtime before calling fork.
(Unrelated to the issue that a deadlock should not happen)

Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

FW: [PATCH] lib/cobalt: init: do not call pthread_atfork() from atfork() handlers

[Lange Norbert via Xenomai]

What do you think about this hackaround?
Still not "clean" to call in a signal handler but it does work.

Norbert

> -Original Message-
> From: Lange Norbert
> Sent: Dienstag, 14. Mai 2019 12:24
> To: Philippe Gerum ; Xenomai (xenomai@xenomai.org)
> 
> Subject: RE: [PATCH] lib/cobalt: init: do not call pthread_atfork() from
> atfork() handlers
>
>
>
> > -Original Message-
> > From: Philippe Gerum 
> > Sent: Dienstag, 14. Mai 2019 12:05
> > To: Lange Norbert ; Xenomai
> > (xenomai@xenomai.org) 
> > Subject: Re: [PATCH] lib/cobalt: init: do not call pthread_atfork()
> > from
> > atfork() handlers
> >
> > E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> > EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
> >
> >
> > On 5/14/19 11:53 AM, Lange Norbert wrote:
> > > (readding ML)
> > >
> > >> -Original Message-
> > >> From: Philippe Gerum 
> > >> Sent: Dienstag, 14. Mai 2019 10:38
> > >> To: Lange Norbert 
> > >> Subject: Re: [PATCH] lib/cobalt: init: do not call pthread_atfork()
> > >> from
> > >> atfork() handlers
> > >>
> > >> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE,
> > PLEASE
> > >> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> > ATTACHMENTS.
> > >>
> > >>
> > >> On 5/14/19 10:35 AM, Philippe Gerum wrote:
> > >>> On 5/6/19 9:56 AM, Lange Norbert wrote:
> > >>>> Hello Philippe,
> > >>>>
> > >>>> using this patch, smokey's "fork test" alone finishes, but..
> > >>>> the smokey suite will hang when running that test after the mutex
> > >>>> or cvars test. Eg.
> > >>>>
> > >>>> smokey --run=10,11
> > >>>> smokey --run=12,11
> > >>>
> > >>> I cannot reproduce this with glibc 2.28, and the tip of my
> > >>> for-upstream tree which includes that fix. Which glibc are you running?
> > >
> > > Glibc 2.28, Xenomai userspace is based on current master branch with
> > > fix added (tested both with and without our company stuff on top)
> > >
> > >>
> > >> Is this the sequence which hangs on your end?
> > >>
> > >> ~ # smokey --run=13-14
> > >> posix_cond OK
> > >> posix_fork OK
> > >> ~ # smokey --run=15-14
> > >> posix_mutex OK
> > >> posix_fork OK
> > >>
> > >
> > > Yes:
> > >
> > > root@buildroot:~# /usr/xenomai/bin/smokey --run=10 posix_mutex OK
> > > root@buildroot:~# /usr/xenomai/bin/smokey --run=11 posix_fork OK
> > > root@buildroot:~# /usr/xenomai/bin/smokey --run=10,11 posix_mutex
> OK
> > >
> > > When it hangs, this is the stacktrace:
> > > (switched to crosstool-NG for the toolchain, did not check to enable
> > debuginfo for glibc).
> > >
> > > (gdb) bt
> > > #0  0x7f45b4d86feb in ?? () from /lib64/libc.so.6
> > > #1  0x7f45b4de8b95 in malloc () from /lib64/libc.so.6
> > > #2  0x7f45b4f81a53 in ?? () from /lib64/ld-linux-x86-64.so.2
> > > #3  0x7f45b4f83149 in ?? () from /lib64/ld-linux-x86-64.so.2
> > > #4  0x7f45b4f8d4cc in ?? () from /lib64/ld-linux-x86-64.so.2
> > > #5  0x7f45b4ea7bcf in _dl_catch_exception () from
> > > /lib64/libc.so.6
> >
> > That is a different issue, possibly not directly related. backtrace()
> > is used over a signal context in the default SIGSHADOW handler
> > libcobalt installs, which is unsafe since backtrace() calls malloc().
> > This run ends up with a recursive call to malloc() which deadlocks on
> > the internal arena lock. Disabling
> CONFIG_XENO_OPT_DEBUG_TRACE_RELAX may paper over the issue.
>
> So smokeys fork will cause some relaxation log entries if I understood this
> correctly, and a "clean" application should leave realtime before calling 
> fork.
> (Unrelated to the issue that a deadlock should not happen)
>
> Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

-- next part --
A non-text attachment was scrubbed...
Name: 0001-libcobalt-resolve-backtrace-early.patch
Type: application/octet-stream
Size: 1018 bytes
Desc: 0001-libcobalt-resolve-backtrace-early.patch
URL: 
<http://xenomai.org/pipermail/xenomai/attachments/20190514/6b6aa20a/attachment.obj>

RE: libcopperplate.so depends on modecheck?

[Lange Norbert via Xenomai]

I still believe this to be a bug, adding a patch to correct this.

Regards, Norbert

> -Original Message-
> From: Lange Norbert
> Sent: Mittwoch, 20. März 2019 11:49
> To: Xenomai (xenomai@xenomai.org) 
> Subject: libcopperplate.so depends on modecheck?
>
> Hello,
>
> Seems like libcopperplate.so always depends on libmodechk.so, as the
> following symbols would imply:
>
> nm -D /home/lano/buildroot/host/x86_64-buildroot-linux-
> gnu/sysroot/usr/xenomai/lib/libcopperplate.so | grep __real
>  U __real_free
>  U __real_malloc
>
> xeno-config deals with this by always linking modeck, even if you add --no-
> mode-check-
>
> I am not completely confident with the wrapper-magic, but shouldn't
> libcopperplate use either cobalt_malloc or the libc malloc?
> __real_malloc is just a stub for libc malloc, so I really don't get the point
> (assuming this is intentional).
>
> Modeswitches could also be detected by interposing libraries, so removing
> libmodechk Is a viable thing to do.
> (shameless plug: https://github.com/nolange/preload_checkers )
>
>
> Regards, Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

-- next part --
A non-text attachment was scrubbed...
Name: 0001-remove-__STD-for-heap-function.patch
Type: application/octet-stream
Size: 5265 bytes
Desc: 0001-remove-__STD-for-heap-function.patch
URL: 
<http://xenomai.org/pipermail/xenomai/attachments/20190531/6c808169/attachment.obj>

RE: libcopperplate.so depends on modecheck?

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Freitag, 31. Mai 2019 16:26
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) ; Philippe Gerum
> ; Henning Schild 
> Subject: Re: libcopperplate.so depends on modecheck?
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 31.05.19 14:12, Lange Norbert via Xenomai wrote:
> > I still believe this to be a bug, adding a patch to correct this.
> >
>
> The patch lacks a commit message that explains "why". Also, inline would be
> preferred (unless your mail client is consistently preventing that).

I have the choice between git-send-email without context of the previous mail,
or Outlook which breaks any formatting.
(I was kinda expecting a discussion and thus a V2)

> The idea of the wrapping is to establish an instrumentation point that will
> give us an early warning when an application calls into non-rt malloc/free
> from rt context. As those glibc calls only occasionally cause a syscall, the 
> hook
> is needed to have that deterministic warning.

Sure, but this is NOT __wrap_malloc but __real_malloc, which seems pointless to 
me
(this is just routed through as-is to malloc).

The bigger idea behind this is to use preload libraries (#1), at which point 
this symbol wrapping is
counter-productive.

>
> That instrumentation should also work for indirect malloc/free via our
> libraries. From that perspective, I would rather expect unwrapped calls so
> that they *do* point to libmodechk helpers. Seems inconsistent from that
> angle. OTH, internal calls could also be instrumented at build-time, thus 
> could
> avoid the wrapping trick.

Again, the symbols are not the checked ones by libmodechk, and you can avoid the
build-time wrapping with preloaded libraries.

> But all this is fairly complex. Philippe and Henning should have thought this
> through a bit more.
>
> Jan

#1: https://github.com/nolange/preload_checkers

Regards,
Norbert
>
> > Regards, Norbert
> >
> >> -Original Message-
> >> From: Lange Norbert
> >> Sent: Mittwoch, 20. März 2019 11:49
> >> To: Xenomai (xenomai@xenomai.org) 
> >> Subject: libcopperplate.so depends on modecheck?
> >>
> >> Hello,
> >>
> >> Seems like libcopperplate.so always depends on libmodechk.so, as the
> >> following symbols would imply:
> >>
> >> nm -D /home/lano/buildroot/host/x86_64-buildroot-linux-
> >> gnu/sysroot/usr/xenomai/lib/libcopperplate.so | grep __real
> >>   U __real_free
> >>   U __real_malloc
> >>
> >> xeno-config deals with this by always linking modeck, even if you add
> >> --no-
> >> mode-check-
> >>
> >> I am not completely confident with the wrapper-magic, but shouldn't
> >> libcopperplate use either cobalt_malloc or the libc malloc?
> >> __real_malloc is just a stub for libc malloc, so I really don't get
> >> the point (assuming this is intentional).
> >>
> >> Modeswitches could also be detected by interposing libraries, so
> >> removing libmodechk Is a viable thing to do.
> >> (shameless plug: https://github.com/nolange/preload_checkers )
> >>
> >>
> >> Regards, Norbert
> > 
> >
> > This message and any attachments are solely for the use of the intended
> recipients. They may contain privileged and/or confidential information or
> other information protected from disclosure. If you are not an intended
> recipient, you are hereby notified that you received this email in error and
> that any review, dissemination, distribution or copying of this email and any
> attachment is strictly prohibited. If you have received this email in error,
> please contact the sender and delete the message and any attachment from
> your system.
> >
> > ANDRITZ HYDRO GmbH
> >
> >
> > Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung /
> > Corporation
> >
> > Firmensitz/ Registered seat: Wien
> >
> > Firmenbuchgericht/ Court of registry: Handelsgericht Wien
> >
> > Firmenbuchnummer/ Company registration: FN 61833 g
> >
> > DVR: 0605077
> >
> > UID-Nr.: ATU14756806
> >
> >
> > Thank You
> > 
> > -- next part -- A non-text attachment was
> > scrubbed...
> > Name: 0001-remove-__STD-for-heap-function.patch
> > Type: application/octet-stream
> > Size: 5265 bytes
> > Desc:

cobalts printf thread affects signalfd operation

[Lange Norbert via Xenomai]

Hello,

I ran into a problem with the automatically spawned printf thread.

Short summary:
The kernel delivers signals by picking a thread that can accept a signal and 
does not mask the specific signal,
only if none is available then the signal will be queued for asynchronous 
delivery.
signalfd is asynchronous delivery, thus if one thread accepts signals then 
signalfd won't work as expected,
enter cobals printf thread.

Solutions would be:

- Mask all signals for this thread (is there any downside?)
- Mask all signals on the main thread before calling xenomai_init. This is 
ugly, as that removes most methods of interacting with a hung startup.
- Somehow mask the thread for signals later (only ugly solutions?).

The first option would be a rather small patch:

@@ -642,7 +642,11 @@ static void spawn_printer_thread(void)
 pthread_attr_t thattr;

 pthread_attr_init(&thattr);
+sigset_t sset, oset;
+sigfillset(&sset)
+sigprocmask(SIG_BLOCK, &sset, &oset);
 pthread_create(&printer_thread, &thattr, printer_loop, NULL);
+sigprocmask(SIG_SETMASK, &oset, NULL);
 }

Mit besten Grüßen / Kind regards

NORBERT LANGE
AT-DES

ANDRITZ HYDRO GmbH
Eibesbrunnergasse 20
1120 Vienna / AUSTRIA
p: +43 50805 56684
norbert.la...@andritz.com
andritz.com


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: serial driver for imx28

[Lange Norbert via Xenomai]

> -Original Message-
> From: Xenomai  On Behalf Of Julien Blanc
> via Xenomai
> Sent: Freitag, 14. Juni 2019 13:54
> To: Xenomai@xenomai.org
> Subject: serial driver for imx28
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> Hi,
>
> We’re currently trying to make the serial port working on a custom board
> based on an imx28 som.

Are you using the Debug uart or the Application UART?
The debug uart has incredibly slow register accesses, and can't do DMA, you 
would not be happy about that in an RT application.

Further what interfaces are you planning to use? Ethernet is rather horrible to 
use aswell, as you need to byteswap *all* data (hardware bug, I am not talking 
about the Ethernet heads using BigEndian).

Sorry, don’t know the state of Xenomai in regards to this SOC, (but I know the 
Chip and its warts pretty well).

Regards, Norbert



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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: serial driver for imx28

[Lange Norbert via Xenomai]

> -Original Message-
> From: Julien Blanc 
> Sent: Freitag, 14. Juni 2019 14:46
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Subject: Re: serial driver for imx28
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> Le vendredi 14 juin 2019 à 12:26 +, Lange Norbert via Xenomai a écrit :
> > > -Original Message-
> > > From: Xenomai  On Behalf Of Julien
> > > Blanc via Xenomai
> > > Sent: Freitag, 14. Juni 2019 13:54
> > > To: Xenomai@xenomai.org
> > > Subject: serial driver for imx28
> > >
> > >
> > > We’re currently trying to make the serial port working on a custom
> > > board based on an imx28 som.
> >
> > Are you using the Debug uart or the Application UART?
> > The debug uart has incredibly slow register accesses, and can't do
> > DMA, you would not be happy about that in an RT application.
>
> I’m talking about the application uart. Also, note that the UART does not
> need to be realtime (the reason we are using it from plain linux in the first
> place), but the issues we encounter make us reconsider this decision.
>
> > Further what interfaces are you planning to use? Ethernet is rather
> > horrible to use aswell, as you need to byteswap *all* data (hardware
> > bug, I am not talking about the Ethernet heads using BigEndian).
>
> We’re not planning to do any rtnet, and the linux driver seems fine (frow a
> user pov). RT is required for CAN and gpios (both handled by xenomai
> drivers) which work fine. Our only issues are with uart, called from linux
> domain (issues which were unfortunately not seen during the qualification
> phase).

Ok, seems like you would need to increase buffers in the drivers, or try enable
DMA (need to set CRTSCTS in termios, otherwise no DMA is used in the driver).
If anything fails, use a thread to receive data from a pipe/unix socket and
forward that to the uart as fast as it will accept it.
If the issue is on the receive side you probably need HW flow-control via 
RTS/CTS
pins to make sure you don’t lose anything.

> > Sorry, don’t know the state of Xenomai in regards to this SOC, (but I
> > know the Chip and its warts pretty well).
>
> Switching to another chip is not an option (we need to solve this issue for
> existing boards).

Many chips have bugs, helps a lot knowing them.

Regards, Norbert.


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: Commands for reading, loading and unloading drivers on BeagleBone Black?

[Lange Norbert via Xenomai]

Use sysfs-

# unbind the current driver for those devices
for sio in 1-2:1.0  1-2:1.1  1-2:1.2  1-2:1.3; do
echo "$sio" > /sys/bus/usb/devices/"$sio"/driver/unbind
done

# use a specific driver 'ftdi_sio' for a device
echo "1-2:1.0" > /sys/bus/usb/drivers/ftdi_sio/bind
# let linux pick a driver for a device
echo '1-2:1.0' >  /sys/bus/usb/drivers_probe

works similar with other busses.

regards, Norbert Lange

> -Original Message-
> From: Xenomai  On Behalf Of danwe via
> Xenomai
> Sent: Mittwoch, 19. Juni 2019 10:19
> To: xenomai@xenomai.org
> Subject: Commands for reading, loading and unloading drivers on
> BeagleBone Black?
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> Hello,
>
> I am using a BeagleBone Black with Xenomai and RTnet on top. As some real-
> time programs are not working it could be that the installed drivers on my
> BeagleBone Black are still the standard drivers and not the real-time drivers.
>
> As I did not find anything on internet (only how to install drivers for 
> Windows
> when using BeagleBone Black) I would like to ask you if anyobdy knows
> commands for BeagleBone Black to read, load and unload installed drivers on
> BBB?
>
> Regards
>
> Daniel


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: Commands for reading, loading and unloading drivers on BeagleBone Black?

[Lange Norbert via Xenomai]

Hello,

your question was rather vague. The echos I wrote (un)bind drivers to single 
devices, which only needs the linux kernel.

You apparently use Busybox, in case you have the “modprobe” tool, this is 
easier to use that instead of insmod and rmmod.
In case you use (e)udev you probably don’t have to do a thing, and the modules 
get loaded automatically.

Norbert

From: danwe 
Sent: Freitag, 21. Juni 2019 13:23
To: Lange Norbert ; xenomai@xenomai.org
Subject: Re: Commands for reading, loading and unloading drivers on BeagleBone 
Black?


E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE EXERCISE 
CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR ATTACHMENTS.
Hi,
what exactly are you doing with those "echos" you wrote? I mean why should I 
let linux pick a driver for a device? I have Xenomai with RTnet. I would like 
to use Xenomai- / RTnet-drivers for that.
I have found the following commands: lsmod, insmod, rmmode. See the following 
output.
# lsmod
Module  Size  Used byTainted: G
rtipv4 18699  0
rtpacket4179  0
rt_ticpsw  26115  0
rt_davinci_mdio 4570  0
rt_smsc 2165  0
rtnet  28479  3 rtipv4,rtpacket,rt_ticpsw
omap_rng4174  0
# iinsmod
-sh: iinsmod: not found
# lsmod
Module  Size  Used byTainted: G
rtipv4 18699  0
rtpacket4179  0
rt_ticpsw  26115  0
rt_davinci_mdio 4570  0
rt_smsc 2165  0
rtnet  28479  3 rtipv4,rtpacket,rt_ticpsw
omap_rng4174  0
# insmod
BusyBox v1.22.1 (2019-03-16 12:39:06 CET) multi-call binary.

Usage: insmod FILE [SYMBOL=VALUE]...

Load the specified kernel modules into the kernel

# rmmod
BusyBox v1.22.1 (2019-03-16 12:39:06 CET) multi-call binary.

Usage: rmmod [-wfa] [MODULE]...

Unload kernel modules

-w  Wait until the module is no longer used
-f  Force unload
-a  Remove all unused modules (recursively)

Are these modules correct?

Regards,

Daniel

Am Mi., 19. Juni 2019 um 17:41 Uhr schrieb Lange Norbert 
mailto:norbert.la...@andritz.com>>:
Use sysfs-

# unbind the current driver for those devices
for sio in 1-2:1.0  1-2:1.1  1-2:1.2  1-2:1.3; do
echo "$sio" > /sys/bus/usb/devices/"$sio"/driver/unbind
done

# use a specific driver 'ftdi_sio' for a device
echo "1-2:1.0" > /sys/bus/usb/drivers/ftdi_sio/bind
# let linux pick a driver for a device
echo '1-2:1.0' >  /sys/bus/usb/drivers_probe

works similar with other busses.

regards, Norbert Lange

> -Original Message-
> From: Xenomai 
> mailto:xenomai-boun...@xenomai.org>> On Behalf 
> Of danwe via
> Xenomai
> Sent: Mittwoch, 19. Juni 2019 10:19
> To: xenomai@xenomai.org<mailto:xenomai@xenomai.org>
> Subject: Commands for reading, loading and unloading drivers on
> BeagleBone Black?
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> Hello,
>
> I am using a BeagleBone Black with Xenomai and RTnet on top. As some real-
> time programs are not working it could be that the installed drivers on my
> BeagleBone Black are still the standard drivers and not the real-time drivers.
>
> As I did not find anything on internet (only how to install drivers for 
> Windows
> when using BeagleBone Black) I would like to ask you if anyobdy knows
> commands for BeagleBone Black to read, load and unload installed drivers on
> BBB?
>
> Regards
>
> Daniel


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You



This message and any attachments are solely for the use of the intended 
recipients. They may contain privileged and/or confidential information or 
other information protected from disclosure. If you are not an intended 
recipient, you are hereby notified that you received this email in error and 
that any review, dis

Waking up threads from the other xenomai/linux domain

[Lange Norbert via Xenomai]

Hello,

I have multiple threads, one of them is realtime, one other is responsible for 
controlling the service.

The controlling thread blocks on some linux sockets, the realtime one has a 
select on a RT socket and a timeout.

I now have the problem that I need to wake up the other thread under some 
circumstances, not always (then I would just poll),
but potentially in regular burst (forwarding packets).
>From the docs, XDDP seems the only solution, I wonder if there are more.

1) Connect the threads with a XDDP socket, add the fd in the select calls.
2) Atleast when Linux is waking up Xenomai, I could use an IDDP/BUFP socket 
with the linux thread then being promoted for the duration of the call.
3) Signals? Could they be used to interrupt the select (both linux and cobalt 
variant)?. The POSIX skin has no pselect so I wonder how I would make sure the 
signal
is only delivered during select

All the RTIPC sockets seem to use a global pool of ports, and I believe XDDP to 
be rather heavyweight.I am looking for an efficient way (in total CPU time) to 
unblock a thread,
It does not need to have lowest latency.

(Note that this is in the same process, so I would prefer something like 
socketpair to open up an anonymous "pipe" not feeding from global ports).


Mit besten Grüßen / Kind regards

NORBERT LANGE
AT-DES

ANDRITZ HYDRO GmbH
Eibesbrunnergasse 20
1120 Vienna / AUSTRIA
p: +43 50805 56684
norbert.la...@andritz.com
andritz.com


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: Waking up threads from the other xenomai/linux domain

[Lange Norbert via Xenomai]

> -Original Message-
> From: Philippe Gerum 
> Sent: Donnerstag, 27. Juni 2019 14:43
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Subject: Re: Waking up threads from the other xenomai/linux domain
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 6/26/19 1:05 PM, Lange Norbert via Xenomai wrote:
> > Hello,
> >
> > I have multiple threads, one of them is realtime, one other is responsible
> for controlling the service.
> >
> > The controlling thread blocks on some linux sockets, the realtime one has a
> select on a RT socket and a timeout.
> >
> > I now have the problem that I need to wake up the other thread under
> > some circumstances, not always (then I would just poll), but potentially in
> regular burst (forwarding packets).
> >>From the docs, XDDP seems the only solution, I wonder if there are more.
> >
> > 1) Connect the threads with a XDDP socket, add the fd in the select calls.
> > 2) Atleast when Linux is waking up Xenomai, I could use an IDDP/BUFP
> socket with the linux thread then being promoted for the duration of the call.
>
> I would not recommend this unless those packets arrive at a fairly low
> rate: a double mode migration is costly, way, way more than using XDDP.
>
> > 3) Signals? Could they be used to interrupt the select (both linux and
> > cobalt variant)?. The POSIX skin has no pselect so I wonder how I
> > would make sure the signal is only delivered during select
>
> I don't think the POSIX signal machinery can be described as lightweight.
> Besides, since cobalt only implements the synchronous interface via
> sigwait*(), select() would not unblock on signal receipt.
>
> >
> > All the RTIPC sockets seem to use a global pool of ports, and I
> > believe XDDP to be rather heavyweight.I am looking for an efficient way (in
> total CPU time) to unblock a thread, It does not need to have lowest latency.
>
> You may be overestimating the XDDP overhead especially if the message
> rate is low. Having a size-configurable (CONFIG_XENO_OPT_PIPE_NRDEV)
> global pool of ports should not be an issue in a system where you can - and
> should - know in advance how many of them are going to be used at most. If
> the issue is with port naming conflicts, then you can ask XDDP to allocate the
> next free port then attach a label to it. The application goes through the
> registry to refer to such port by label, instead of using its raw port number.
>
> If you don't want messaging at all but only signaling, then you could add
> some kind of cross-domain eventfd() protocol to the RTIPC driver.

I don’t want much more than some sort of condition variable, but working with 
select (and across domains).
The non-existing cobalt-eventfd seems fitting, but I will happily use XDDP for 
now.
I would prefer "anonymous" objects simply for having less sideeffects,
and not needing to know a name/instance number I am not interested in.

> >
> > (Note that this is in the same process, so I would prefer something like
> socketpair to open up an anonymous "pipe" not feeding from global ports).
> >
>
> Cobalt does not provide this.

IMHO, some off-the-shelf solution to setup some in-process synchronization
Would be useful, docs are lacking some recipes for typical problems when trying
to signal between xenomai and linux threads.

(libcobalt is likely the wrong place)

Thanks,
Norbert.


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

ipipe 4.19: spurious APIC interrupt when setting rt_igp to up

[Lange Norbert via Xenomai]

Hello,

using the rt_igb driver with the recent ipipe/kernel will result in a broken 
state
(I assume one cpu core is “stuck”).

This is a quote from Phillipe (note that I tested the plain upstream revivision 
below)
> This happens specifically when the igb driver enables the device at 
> rtifconfig up only with 4.19+.
> The HIPASE clock device is fine and can be enabled manually with no issue. 
> The spurious IRQ
> message is only a symptom, something seems wrong with this fairly old 
> (rt_)igb code on recent kernels.

+ modprobe rtnet
+ modprobe rtpacket
+ modprobe rt_igp
[  325.791715] RTnet: registered rteth0
[  325.795328] rt_igb :03:00.0: Intel(R) Gigabit Ethernet Network Connection
[  325.802505] rt_igb :03:00.0: rteth0: (PCIe:2.5Gb/s:Width x1) 
22:20:47:8d:0f:c9
[  325.810103] rt_igb :03:00.0: rteth0: PBA No: FF-0FF
[  325.815696] rt_igb :03:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx 
queue(s)
[  325.823638] sdhci-pci :00:1b.0: SDHCI controller found [8086:5aca] (rev 
b)

+ rtifconfig rteth0 up
[  326.066500] spurious APIC interrupt through vector ff on CPU#0, should never 
happen.


xenomai master
ipipe-core-4.19.56-x86-2
 (config is attached)

Regards, Norbert Lange


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

-- next part --
A non-text attachment was scrubbed...
Name: config-4.19.tar.xz
Type: application/octet-stream
Size: 22800 bytes
Desc: config-4.19.tar.xz
URL: 

RE: ipipe 4.19: spurious APIC interrupt when setting rt_igp to up

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Freitag, 5. Juli 2019 09:39
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) ; Philippe Gerum
> 
> Subject: Re: ipipe 4.19: spurious APIC interrupt when setting rt_igp to up
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 04.07.19 12:21, Jan Kiszka wrote:
> > On 04.07.19 12:15, Jan Kiszka wrote:
> >> On 04.07.19 10:57, Lange Norbert via Xenomai wrote:
> >>> Hello,
> >>>
> >>> using the rt_igb driver with the recent ipipe/kernel will result in
> >>> a broken state (I assume one cpu core is “stuck”).
> >>>
> >>> This is a quote from Phillipe (note that I tested the plain upstream
> >>> revivision below)
> >>>> This happens specifically when the igb driver enables the device at
> >>>> rtifconfig up only with 4.19+.
> >>>> The HIPASE clock device is fine and can be enabled manually with no
> issue.
> >>>> The spurious IRQ
> >>>> message is only a symptom, something seems wrong with this fairly
> >>>> old (rt_)igb code on recent kernels.
> >>>
> >>> + modprobe rtnet
> >>> + modprobe rtpacket
> >>> + modprobe rt_igp
> >>> [  325.791715] RTnet: registered rteth0 [  325.795328] rt_igb
> >>> :03:00.0: Intel(R) Gigabit Ethernet Network Connection [
> >>> 325.802505] rt_igb :03:00.0: rteth0: (PCIe:2.5Gb/s:Width x1)
> >>> 22:20:47:8d:0f:c9
> >>> [  325.810103] rt_igb :03:00.0: rteth0: PBA No: FF-0FF [
> >>> 325.815696] rt_igb :03:00.0: Using MSI-X interrupts. 1 rx
> >>> queue(s), 1 tx queue(s) [  325.823638] sdhci-pci :00:1b.0: SDHCI
> >>> controller found [8086:5aca] (rev b)
> >>>
> >>> + rtifconfig rteth0 up
> >>> [  326.066500] spurious APIC interrupt through vector ff on CPU#0,
> >>> should never happen.
> >>>
> >>
> >> Can you retry with https://lkml.org/lkml/2019/7/3/143 applied? It
> >> should tell us the real vector number.
> >>
> >> I'll see in parallel if I can reproduce with rt_igb here.

Applying that patch then causes the ipipe-patch to fail.
Would take me some time to cleanup.

> >
> > Already succeeded, with rt_e1000e in KVM. Debugging...
> >
>
> This addresses it on x86 for me:
>
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c index
> 6c279e065879..d503b875f086 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -1099,7 +1099,8 @@ void ipipe_enable_irq(unsigned int irq)
> ipipe_root_only();
>
> raw_spin_lock_irqsave(&desc->lock, flags);
> -   if (desc->istate & IPIPE_IRQS_NEEDS_STARTUP) {
> +   if (desc->istate & IPIPE_IRQS_NEEDS_STARTUP &&
> +   !WARN_ON(irq_activate(desc))) {
> desc->istate &= ~IPIPE_IRQS_NEEDS_STARTUP;
> chip->irq_startup(&desc->irq_data);
> }

Problem still persists for me with that patch. I use a nfsroot (with a USB->ETH 
adapter so I can kick out the linux igb driver),
Maybe that’s related.

Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

Best way to detect if a filedescriptor is a cobalt filedescriptor (/socket)

[Lange Norbert via Xenomai]

Hi,

I am opening a packetsocket, which is supposed to be realtime. Unfortunatly if 
the rtpacket (rtnet?) module is not loaded,
then this will just silently fall back to a linux packet socket. Then later 
demote thread during accesses.

How would I be able to detect this early during startup? I could __STD(close) 
the descriptor and check the returncode for EBADF I suppose...


Mit besten Grüßen / Kind regards

NORBERT LANGE
AT-DES

ANDRITZ HYDRO GmbH
Eibesbrunnergasse 20
1120 Vienna / AUSTRIA
p: +43 50805 56684
norbert.la...@andritz.com
andritz.com


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: ipipe 4.19: spurious APIC interrupt when setting rt_igp to up

[Lange Norbert via Xenomai]

Hello,

maxcpus=1 still causes the spurious int, this time fully locking up.

I attached the debug/irq directory after the cause.

Some things that might be relevant:
-   the SOC would use PINCTRL_BROXTON under linux, but this is disabled (not 
fixed up for Xenomai)
-   I have the regular igb driver in use, and am unbinding the network card 
prior to binding the rt_igp driver

Regards, Norbert

> -Original Message-
> From: Jan Kiszka 
> Sent: Freitag, 5. Juli 2019 15:57
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) ; Philippe Gerum
> 
> Subject: Re: ipipe 4.19: spurious APIC interrupt when setting rt_igp to up
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 05.07.19 13:29, Jan Kiszka wrote:
> > On 05.07.19 12:43, Lange Norbert wrote:
> >>
> >>
> >>> -Original Message-----
> >>> From: Jan Kiszka 
> >>> Sent: Freitag, 5. Juli 2019 09:39
> >>> To: Lange Norbert ; Xenomai
> >>> (xenomai@xenomai.org) ; Philippe Gerum
> >>> 
> >>> Subject: Re: ipipe 4.19: spurious APIC interrupt when setting rt_igp
> >>> to up
> >>>
> >>> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE,
> PLEASE
> >>> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
> >>>
> >>>
> >>> On 04.07.19 12:21, Jan Kiszka wrote:
> >>>> On 04.07.19 12:15, Jan Kiszka wrote:
> >>>>> On 04.07.19 10:57, Lange Norbert via Xenomai wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> using the rt_igb driver with the recent ipipe/kernel will result
> >>>>>> in a broken state (I assume one cpu core is “stuck”).
> >>>>>>
> >>>>>> This is a quote from Phillipe (note that I tested the plain
> >>>>>> upstream revivision below)
> >>>>>>> This happens specifically when the igb driver enables the device
> >>>>>>> at rtifconfig up only with 4.19+.
> >>>>>>> The HIPASE clock device is fine and can be enabled manually with
> >>>>>>> no
> >>> issue.
> >>>>>>> The spurious IRQ
> >>>>>>> message is only a symptom, something seems wrong with this
> >>>>>>> fairly old (rt_)igb code on recent kernels.
> >>>>>>
> >>>>>> + modprobe rtnet
> >>>>>> + modprobe rtpacket
> >>>>>> + modprobe rt_igp
> >>>>>> [  325.791715] RTnet: registered rteth0 [  325.795328] rt_igb
> >>>>>> :03:00.0: Intel(R) Gigabit Ethernet Network Connection [
> >>>>>> 325.802505] rt_igb :03:00.0: rteth0: (PCIe:2.5Gb/s:Width x1)
> >>>>>> 22:20:47:8d:0f:c9
> >>>>>> [  325.810103] rt_igb :03:00.0: rteth0: PBA No: FF-0FF [
> >>>>>> 325.815696] rt_igb :03:00.0: Using MSI-X interrupts. 1 rx
> >>>>>> queue(s), 1 tx queue(s) [  325.823638] sdhci-pci :00:1b.0:
> >>>>>> SDHCI controller found [8086:5aca] (rev b)
> >>>>>>
> >>>>>> + rtifconfig rteth0 up
> >>>>>> [  326.066500] spurious APIC interrupt through vector ff on
> >>>>>> CPU#0, should never happen.
> >>>>>>
> >>>>>
> >>>>> Can you retry with https://lkml.org/lkml/2019/7/3/143 applied? It
> >>>>> should tell us the real vector number.
> >>>>>
> >>>>> I'll see in parallel if I can reproduce with rt_igb here.
> >>
> >> Applying that patch then causes the ipipe-patch to fail.
> >> Would take me some time to cleanup.
> >>
> >
> > Yes, did this yesterday, and it requires more work. But the
> > information from it is no longer essential.
> >
> >>>>
> >>>> Already succeeded, with rt_e1000e in KVM. Debugging...
> >>>>
> >>>
> >>> This addresses it on x86 for me:
> >>>
> >>> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c index
> >>> 6c279e065879..d503b875f086 100644
> >>> --- a/kernel/irq/chip.c
> >>> +++ b/kernel/irq/chip.c
> >>> @@ -1099,7 +1099,8 @@ void ipipe_enable_irq(unsigned int irq)
> >>>  ipipe_root_only();
> &g

RE: ipipe 4.19: spurious APIC interrupt when setting rt_igp to up

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Dienstag, 9. Juli 2019 19:54
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) ; Philippe Gerum
> 
> Subject: Re: ipipe 4.19: spurious APIC interrupt when setting rt_igp to up
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 09.07.19 18:33, Jan Kiszka wrote:
> > On 09.07.19 18:21, Lange Norbert wrote:
> >> Hello,
> >>
> >> maxcpus=1 still causes the spurious int, this time fully locking up.
> >>
> >> I attached the debug/irq directory after the cause.
> >>> Some things that might be relevant:
> >> -   the SOC would use PINCTRL_BROXTON under linux, but this is disabled
> (not fixed up for Xenomai)
> >> -   I have the regular igb driver in use, and am unbinding the network card
> prior to binding the rt_igp driver
> >>
> >
> > Thanks. What's the interrupt number that Xenomai is using? Should be
> > the same that the Linux driver is using as well.
>
> Found already: Should be IRQ 130-132 for device 00:03.0. If the directory
> state was like that while Xenomai was still holding those interrupts, the
> problem it that there are no vectors assigned to them. Can you confirm that
> rt_igb was still loaded and the interface was up?

Well, the bug happens when bringing up the interface.

# modprobe rt_igb
[  117.274639] rt_igb :03:00.0: Intel(R) Gigabit Ethernet Network Connection
[  117.281800] rt_igb :03:00.0: enp3s0: (PCIe:2.5Gb/s:Width x1) 
22:20:47:8d:0f:c9
[  117.289397] rt_igb :03:00.0: enp3s0: PBA No: FF-0FF
[  117.294997] rt_igb :03:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx 
queue(s)
[  117.303500] [Xenomai] HIPASE PPS on SDP0
[  117.307529] sdhci-pci :00:1b.0: SDHCI controller found [8086:5aca] (rev 
b)

# rtifconfig enp3s0 up
[  166.503855] spurious APIC interrupt through vector ff on CPU#0, should never 
happen.

> Are those interrupts MSI or MSI-X? Can't read that from the logs.

MSI-X from the kernel log.

>
> I probably need to get some rt_igb running somewhere...
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate
> Competence Center Embedded Linux


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: Best way to detect if a filedescriptor is a cobalt filedescriptor (/socket)

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Mittwoch, 10. Juli 2019 08:13
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) ; Philippe Gerum
> 
> Subject: Re: Best way to detect if a filedescriptor is a cobalt filedescriptor
> (/socket)
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 09.07.19 16:49, Lange Norbert via Xenomai wrote:
> > Hi,
> >
> > I am opening a packetsocket, which is supposed to be realtime.
> > Unfortunatly if the rtpacket (rtnet?) module is not loaded, then this will
> just silently fall back to a linux packet socket. Then later demote thread
> during accesses.
> >
> > How would I be able to detect this early during startup? I could
> __STD(close) the descriptor and check the returncode for EBADF I suppose...
> >
>
> Yeah, looks this is some feature we lost while embedding the RTDM file
> descriptor range into the regular Linux space.

My scheme does not work either, __STD(close) seems to return 0 for the cobalt 
fd,
But doesn’t seem to do anything beyond that.

Note: I am using Philippe's "cobalt: switch hand over status to -ENODEV for 
non-RTDM fd" patch,
so potential it’s a regression of this patch.

> We could either add a compile-time or runtime feature to libcobalt that
> permits to disable this silent fallback again or introduce alternative open 
> and
> socket implementations that do not expose this behavior. Spontaneously, I
> would be in favor or a runtime switch for the existing implementations.

I assumed that __RT(open) would call the __cobalt_open function (without 
fallback),
__STD(open) would call libc' open, and  __wrap_open would be the only function 
trying both.
Turns out that __wrap and __cobalt are identical, but I don’t understand the 
reasoning behind it.

Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: ipipe 4.19: spurious APIC interrupt when setting rt_igp to up

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Mittwoch, 10. Juli 2019 23:31
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) ; Philippe Gerum
> 
> Subject: Re: ipipe 4.19: spurious APIC interrupt when setting rt_igp to up
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 09.07.19 19:54, Jan Kiszka wrote:
> > On 09.07.19 18:33, Jan Kiszka wrote:
> >> On 09.07.19 18:21, Lange Norbert wrote:
> >>> Hello,
> >>>
> >>> maxcpus=1 still causes the spurious int, this time fully locking up.
> >>>
> >>> I attached the debug/irq directory after the cause.
> >>>> Some things that might be relevant:
> >>> -   the SOC would use PINCTRL_BROXTON under linux, but this is disabled
> (not fixed up for Xenomai)
> >>> -   I have the regular igb driver in use, and am unbinding the network
> card prior to binding the rt_igp driver
> >>>
> >>
> >> Thanks. What's the interrupt number that Xenomai is using? Should be
> >> the same that the Linux driver is using as well.
> >
> > Found already: Should be IRQ 130-132 for device 00:03.0. If the
> > directory state was like that while Xenomai was still holding those
> > interrupts, the problem it that there are no vectors assigned to them.
> > Can you confirm that rt_igb was still loaded and the interface was up?
> >
> > Are those interrupts MSI or MSI-X? Can't read that from the logs.
> >
> > I probably need to get some rt_igb running somewhere...
> >
>
> Still no luck, even on a box with a igb-driven NIC (I350):
>
> [  667.928036] rt_igb :06:00.1: Intel(R) Gigabit Ethernet Network
> Connection [  667.928064] rt_igb :06:00.1: rteth0: (PCIe:5.0Gb/s:Width
> x4) 00:25:90:5d:10:19 [  667.928149] rt_igb :06:00.1: rteth0: PBA No:
> 010A00-000 [  667.928153] rt_igb :06:00.1: Using MSI-X interrupts. 1 rx
> queue(s), 1 tx queue(s) xeon-d:~ # cat /proc/xenomai/irq
>   IRQ CPU0...CPU15
>47:   0...   79 rteth0-TxRx-0
>
> I'm currently using the two attached patches on top of ipipe-core-4.19.57-
> x86-3.

With those 2 patches ist now fixed on my end,
So far I used this:

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 6c279e065879..d503b875f086 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -1099,7 +1099,8 @@ void ipipe_enable_irq(unsigned int irq)
 ipipe_root_only();

 raw_spin_lock_irqsave(&desc->lock, flags);
-if (desc->istate & IPIPE_IRQS_NEEDS_STARTUP) {
+if (desc->istate & IPIPE_IRQS_NEEDS_STARTUP &&
+!WARN_ON(irq_activate(desc))) {
 desc->istate &= ~IPIPE_IRQS_NEEDS_STARTUP;
 chip->irq_startup(&desc->irq_data);
 }

>
> Did you cross-check if the running kernel contains the fix(es)?

Yes, the old one.
Thanks for the fix.

Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: [PATCH] cobalt: remove call to sigprocmask

[Lange Norbert via Xenomai]

> -Original Message-
> From: Xenomai  On Behalf Of Jan Kiszka
> via Xenomai
> Sent: Freitag, 12. Juli 2019 15:07
> To: Norbert Lange ; xenomai@xenomai.org
> Subject: Re: [PATCH] cobalt: remove call to sigprocmask
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 12.07.19 13:18, Norbert Lange via Xenomai wrote:
> > sigprocmask should not be used in multithreaded applications, doing so
> > is "unspecified".
>
> Is this more than cosmetic on Linux? Then it should be documented here
> because we shipped the change in 3.0.9, and if that may have caused
> regressions, users should know.

There is no practical issue to be expected, AFAIK with NPTL at least.
The only issue could be, that libpthread is not pulled in (might need to run 
some setup), but that’s ensured with libcobalt.

Sorry for the mess, must have send a stale patch in the first place (always get 
problems with whitespace issues).

Norbert




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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

affinity of main thread is bound to current core

[Lange Norbert via Xenomai]

Hello,

I use Xenomai master on ipipe-core-4.19.60-x86-5.
I start out with an affinity mask of 0xF, in the function cobalt_init_2,  
pthread_setschedparam will get called, after the syscall 
sc_cobalt_thread_setschedparam_ex the affinity mask will contain a single CPU 
(supposedly the current one).

All methods to control affinity are executed before this point (cmdline args, 
/proc/xenomai/affinity), so there is no working way to control it.

Kind regards, Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: affinity of main thread is bound to current core

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Donnerstag, 22. August 2019 16:52
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Subject: Re: affinity of main thread is bound to current core
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 21.08.19 14:12, Lange Norbert via Xenomai wrote:
> > Hello,
> >
> > I use Xenomai master on ipipe-core-4.19.60-x86-5.
> > I start out with an affinity mask of 0xF, in the function cobalt_init_2,
> pthread_setschedparam will get called, after the syscall
> sc_cobalt_thread_setschedparam_ex the affinity mask will contain a single
> CPU (supposedly the current one).
> >
> > All methods to control affinity are executed before this point (cmdline 
> > args,
> /proc/xenomai/affinity), so there is no working way to control it.
> >
>
> Not sure I get the problem yet: "some-xenomai-app --cpu-affinity X" seems
> to work fine, so does setting /proc/xenomai/affinity. Can you describe more
> concretely what behaves unexpectedly, maybe with a test case?

Well, it does not work for me.

-- file test.c
#define _GNU_SOURCE
#include 

#include 
#include 

static void printaff()
{
cpu_set_t cpuset;
pthread_getaffinity_np(pthread_self(), sizeof(cpuset), &cpuset);
printf("Affinity: ");
for(unsigned i = 0; i < 256; ++i)
{
if(CPU_ISSET(i, &cpuset))
printf("%u,", i);
}
printf("\n");
}

int main(int argc, char const *argv[])
{
printaff();
return 0;
}
--

root@buildroot:~# cat /proc/xenomai/affinity
000f

root@buildroot:~# /tmp/a.out
Affinity: 2,

root@buildroot:~# /tmp/a.out app --cpu-affinity 0,1,2,3
Affinity: 3,

I traced the point where affinity collapsed to the
sc_cobalt_thread_setschedparam_ex call.

Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: affinity of main thread is bound to current core

[Lange Norbert via Xenomai]

> -Original Message-
> From: Philippe Gerum 
> Sent: Donnerstag, 22. August 2019 17:29
> To: Lange Norbert ; Jan Kiszka
> ; Xenomai (xenomai@xenomai.org)
> 
> Subject: Re: affinity of main thread is bound to current core
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 8/22/19 5:16 PM, Lange Norbert via Xenomai wrote:
> >> -Original Message-
> >> From: Jan Kiszka 
> >> Sent: Donnerstag, 22. August 2019 16:52
> >> To: Lange Norbert ; Xenomai
> >> (xenomai@xenomai.org) 
> >> Subject: Re: affinity of main thread is bound to current core
> >>
> >> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE,
> PLEASE
> >> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
> >>
> >>
> >> On 21.08.19 14:12, Lange Norbert via Xenomai wrote:
> >>> Hello,
> >>>
> >>> I use Xenomai master on ipipe-core-4.19.60-x86-5.
> >>> I start out with an affinity mask of 0xF, in the function
> >>> cobalt_init_2,
> >> pthread_setschedparam will get called, after the syscall
> >> sc_cobalt_thread_setschedparam_ex the affinity mask will contain a
> >> single CPU (supposedly the current one).
> >>>
> >>> All methods to control affinity are executed before this point
> >>> (cmdline args,
> >> /proc/xenomai/affinity), so there is no working way to control it.
> >>>
> >>
> >> Not sure I get the problem yet: "some-xenomai-app --cpu-affinity X"
> >> seems to work fine, so does setting /proc/xenomai/affinity. Can you
> >> describe more concretely what behaves unexpectedly, maybe with a test
> case?
> >
> > Well, it does not work for me.
> >
> > -- file test.c
> > #define _GNU_SOURCE
> > #include 
> >
> > #include 
> > #include 
> >
> > static void printaff()
> > {
> > cpu_set_t cpuset;
> > pthread_getaffinity_np(pthread_self(), sizeof(cpuset), &cpuset);
> > printf("Affinity: ");
> > for(unsigned i = 0; i < 256; ++i)
> > {
> > if(CPU_ISSET(i, &cpuset))
> > printf("%u,", i);
> > }
> > printf("\n");
> > }
> >
> > int main(int argc, char const *argv[]) { printaff(); return 0; }
> > --
> >
> > root@buildroot:~# cat /proc/xenomai/affinity 000f
> >
> > root@buildroot:~# /tmp/a.out
> > Affinity: 2,
> >
> > root@buildroot:~# /tmp/a.out app --cpu-affinity 0,1,2,3
> > Affinity: 3,
> >
> > I traced the point where affinity collapsed to the
> > sc_cobalt_thread_setschedparam_ex call.
> >
>
> Feature, note bug. CPU migration is at odds with (very) low-latency
> requirement, so cobalt pins the thread to one of the cores defined by --cpu-
> affinity, preferably the current one. There is no point in having more than a
> single core in the affinity mask for a real-time thread: we simply don't want
> that one to be involved in any load balancing strategy.

Why is all that trickery in setup reading /proc/xenomai/affinity,
parsing --cpu-affinity, and setting the resulting affinity when
soon thereafter *the same setup* will call pthread_setschedparam,
destroying its previous work?

Is that a feature to warm up the CPU, aside of sending me on a
goose chase...

This is the C main thread, even the most unnecessary thread I start with
__STD(pthread_create) will inherit that mask.
Sorry, but I have a hard time figuring out a single argument for that "feature".

I would understand if you bind the thread to a core, potentially affecting the 
affinity mask,
as soon the user explicitly kicked that thread into a realtime priority.
Is the affinity mask even affecting cobalt threads that don’t get demoted 
(would be a precondition for low-latency)?

Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: [PATCH 2/2] cobalt: switch hand over status to -ENODEV for non-RTDM fd

[Lange Norbert via Xenomai]

I ran into a rather big issue with linux filehandles
I use Xenomai master on ipipe-core-4.19.60-x86-5 with those patches,
(can't be 100% sure its not some kernel/userspace conflict, but I doubt it)

What happens is that upon a __cobalt_close with a linux filehande, the
syscall sc_cobalt_close returns EBADF, but that means the libc close will
never be tried and filehandles are leaking like mad.

test.c
int fileread(const char *pFilename, int *pErrno)
{
int fd = open(pFilename, O_RDONLY | FILEIO_OPENOPTS);
bool isOk = true;

if (fd < 0) {
*pErrno = errno;
return -1;
}

char buffer[1024];

ssize_t result = read(fd, buffer, sizeof(buffer));

if (result < 0) {
*pErrno = errno;
isOk = false;
}

close(fd);
return isOk ? (int)(result) : -1;
}


int main(int argc, char **argv)
{
if (argc != 2)
return -1;

int err;

for (;;) {
if(fileread(argv[1], &err) < 0)
{
perror("read failed: ");
break;
}
usleep(100);
}
}
---

Kind regards, Norbert

> -Original Message-
> From: Xenomai  On Behalf Of Philippe
> Gerum via Xenomai
> Sent: Donnerstag, 20. Juni 2019 19:30
> To: xenomai@xenomai.org
> Subject: [PATCH 2/2] cobalt: switch hand over status to -ENODEV for non-
> RTDM fd
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> Having the RTDM core return -EBADF to indicate that it does not manage a
> file descriptor is a problem, as several drivers also raise this error to 
> notify
> userland about an aborted wait due to a connection being dismantled (e.g.
> RTnet). In this case, libcobalt ends up forwarding the aborted request to the
> glibc, which is wrong.
>
> Switch from -EBADF to -ENODEV to notify userland that RTDM does not
> manage a file descriptor, which cannot conflict with any sensible return from
> active I/O operations. This is also consistent with the status RTDM currently
> returns to notify that it cannot handle a device open request.
> ---
>  kernel/cobalt/rtdm/fd.c |  7 ---
>  lib/cobalt/rtdm.c   | 46 -
>  2 files changed, 27 insertions(+), 26 deletions(-)
>
> diff --git a/kernel/cobalt/rtdm/fd.c b/kernel/cobalt/rtdm/fd.c index
> f3b6444c3..75c4acf28 100644
> --- a/kernel/cobalt/rtdm/fd.c
> +++ b/kernel/cobalt/rtdm/fd.c
> @@ -204,8 +204,9 @@ int rtdm_fd_register(struct rtdm_fd *fd, int ufd)
>   * @param[in] ufd User-side file descriptor
>   * @param[in] magic Magic word for lookup validation
>   *
> - * @return Pointer to the RTDM file descriptor matching @a ufd, or
> - * ERR_PTR(-EBADF).
> + * @return Pointer to the RTDM file descriptor matching @a
> + * ufd. Otherwise ERR_PTR(-ENODEV) is returned if the use-space handle
> + * is either invalid or not managed by RTDM.
>   *
>   * @note The file descriptor returned must be later released by a call
>   * to rtdm_fd_put().
> @@ -221,7 +222,7 @@ struct rtdm_fd *rtdm_fd_get(int ufd, unsigned int
> magic)
> xnlock_get_irqsave(&fdtree_lock, s);
> fd = fetch_fd(p, ufd);
> if (fd == NULL || (magic != 0 && fd->magic != magic)) {
> -   fd = ERR_PTR(-EBADF);
> +   fd = ERR_PTR(-ENODEV);
> goto out;
> }
>
> diff --git a/lib/cobalt/rtdm.c b/lib/cobalt/rtdm.c index 176210ddc..506302d26
> 100644
> --- a/lib/cobalt/rtdm.c
> +++ b/lib/cobalt/rtdm.c
> @@ -123,7 +123,7 @@ COBALT_IMPL(int, close, (int fd))
>
> pthread_setcanceltype(oldtype, NULL);
>
> -   if (ret != -EBADF && ret != -ENOSYS)
> +   if (ret != -ENODEV && ret != -ENOSYS)
> return set_errno(ret);
>
> return __STD(close(fd));
> @@ -154,7 +154,7 @@ COBALT_IMPL(int, fcntl, (int fd, int cmd, ...))
>
> ret = XENOMAI_SYSCALL3(sc_cobalt_fcntl, fd, cmd, arg);
>
> -   if (ret != -EBADF && ret != -ENOSYS)
> +   if (ret != -ENODEV && ret != -ENOSYS)
> return set_errno(ret);
>
> return __STD(fcntl(fd, cmd, arg)); @@ -171,7 +171,7 @@
> COBALT_IMPL(int, ioctl, (int fd, unsigned int request, ...))
> va_end(ap);
>
> ret = do_ioctl(fd, request, arg);
> -   if (ret != -EBADF && ret != -ENOSYS)
> +   if (ret != -ENODEV && ret != -ENOSYS)
> return set_errno(ret);
>
> return __STD(ioctl(fd, request, arg)); @@ -187,7 +187,7 @@
> COBALT_IMPL(ssize_t, read, (int fd, void *buf, size_t nbyte))
>
> pthread_setcanceltype(oldtype, NULL);
>
> -   if (ret != -EBADF && ret != -ENOSYS)
> +   if (ret != -ENODEV && ret != -ENOSYS)
> return set_errno(ret);
>
> return __STD(read(fd, buf, nbyte)); @@ -203,7 +203,7 @@
> COBALT_IMPL(ssize_t, write, (int fd, const void *buf, size_t nbyte))
>
> pthread_setcanceltype(oldtype, NULL);
>
> -   if (ret != 

RE: [PATCH 2/2] cobalt: switch hand over status to -ENODEV for non-RTDM fd

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Donnerstag, 29. August 2019 16:52
> To: Lange Norbert ; Philippe Gerum
> ; Xenomai (xenomai@xenomai.org)
> 
> Subject: Re: [PATCH 2/2] cobalt: switch hand over status to -ENODEV for non-
> RTDM fd
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 29.08.19 16:12, Lange Norbert via Xenomai wrote:
> >
> > I ran into a rather big issue with linux filehandles I use Xenomai
> > master on ipipe-core-4.19.60-x86-5 with those patches, (can't be 100%
> > sure its not some kernel/userspace conflict, but I doubt it)
> >
> > What happens is that upon a __cobalt_close with a linux filehande, the
> > syscall sc_cobalt_close returns EBADF, but that means the libc close
> > will never be tried and filehandles are leaking like mad.
> >
>
> Ah, good catch. Looks like Philippe's patch was missing a change to
> rtdm_fd_close().

Yes, but his v3 works.

> Thanks a lot for testing pro-actively!

You are welcome, its less benign than you might think though,
Philippe's patches (allow for device teardown) were requested from myself.

How does Xenomai/cobalt handle kernel/userspace conflicts like these BTW,
Is there some ABI variable that needs to be incremented and can detect 
mismatches?
(if you use an old libcobalt on a new kernel module with patchset or vice 
verse, it would result in leaks or other issues)

Kind regards,
Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

Static build of rtnet

[Lange Norbert via Xenomai]

Hello,

I havent tested this in a while, but building rtnet static will crash the 
kernel when this module initializes.
With the various fixes and cleanups in master/next (like rtdm_available) that 
might be worth a look?

I would hope to build a static kernel one day, and so far there are 2 
roadblocks:

-   rtnet (+ rtpacket) crashing when built statically

-   symbol nameclashes with linux + rt drivers enabled (I could work on 
fixing that for rt_igb atleast)



Mit besten Grüßen / Kind regards


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: Static build of rtnet

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Dienstag, 17. September 2019 09:42
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Subject: Re: Static build of rtnet
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> On 16.09.19 11:13, Lange Norbert via Xenomai wrote:
> > Hello,
> >
> > I havent tested this in a while, but building rtnet static will crash the 
> > kernel
> when this module initializes.
> > With the various fixes and cleanups in master/next (like rtdm_available) 
> > that
> might be worth a look?
> >
> > I would hope to build a static kernel one day, and so far there are 2
> roadblocks:
> >
> > -   rtnet (+ rtpacket) crashing when built statically
> >
> > -   symbol nameclashes with linux + rt drivers enabled (I could work on 
> > fixing
> that for rt_igb atleast)
> >
>
> Do you mean removing the "depends on m"?

Yes, ideally I would use a kernel without loadable modules, so kernel 
upgrades/changes don’t affect the rootfs (ideally read-only apart from few 
places).

> Possibly, that moves the
> initialization order in a way that causes troubles. I also just added another 
> case
> that exploits the module [1], but that would be solvable. More critical is
> understanding the crashes.

I had a quick test removing the "depends on m" about a year ago, I brought this 
up now because it might be fitting with the recent cleanups.

Regards, Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: [PATCH] Allow RTNet to be builtin kernel

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Mittwoch, 9. Oktober 2019 13:00
> To: Lange Norbert ; François Legal
> 
> Subject: Re: [PATCH] Allow RTNet to be builtin kernel
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> On 09.10.19 12:49, Lange Norbert wrote:
> >
> >
> >> -Original Message-
> >> From: Xenomai  On Behalf Of Jan
> Kiszka
> >> via Xenomai
> >> Sent: Freitag, 4. Oktober 2019 16:31
> >> To: François Legal 
> >> Cc: Xenomai 
> >> Subject: Re: [PATCH] Allow RTNet to be builtin kernel
> >>
> >> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
> >>
> >>
> >> On 04.10.19 16:22, François Legal wrote:
> >>> Le Vendredi, Octobre 04, 2019 15:36 CEST, Jan Kiszka
> >>  a écrit:
> >>>
> >>>> On 04.10.19 13:10, Jan Kiszka wrote:
> >>>>> On 03.10.19 10:10, François Legal via Xenomai wrote:
> >>>>>> Subject: [PATCH] Allow RTNet to be builtin kernel
> >>>>>>
> >>>>>> Makefile is changed because when builtin, the modules get loaded
> in
> >>>>>> the link order. In the previous version protocols would get loaded
> >>>>>> before stackmgr which obviously fails.
> >>>>>>
> >>>>>> Signed-off-by: François LEGAL 
> >>>>>>
> >>>>>> ---
> >>>>>>
> >>>>>> This has been tested on Zynq 7000 Hardware (microzed
> >>>>>> board) with MACB/GEM RTNet driver, with linux 4.4.189 vanilla.
> >>>>>> Kernel boots up correctly, and the following messages get printed
> >>>>>> on the console during the boot :
> >>>>>>
> >>>>>> [   13.875451] sdhci-pltfm: SDHCI platform and OF driver helper
> >>>>>> [   13.881627] sdhci-arasan e010.sdhci: No vmmc regulator found
> >>>>>> [   13.887581] sdhci-arasan e010.sdhci: No vqmmc regulator
> found
> >>>>>> [   13.927585] mmc0: SDHCI controller on e010.sdhci
> >> [e010.sdhci] using ADMA
> >>>>>> [   13.945085] fpga_manager fpga0: Xilinx Zynq FPGA Manager
> >> registered
> >>>>>> [   13.951896]
> >>>>>> [   13.951896] *** RTnet for Xenomai v3.0.9 ***
> >>>>>> [   13.951896]
> >>>>>> [   13.959156] RTnet: initialising real-time networking
> >>>>>> [   13.964928] RTmac/TDMA: init time division multiple access control
> >> mechanism
> >>>>>> [   13.972074] RTmac: init realtime media access control
> >>>>>> [   13.977064] RTcfg: init real-time configuration distribution 
> >>>>>> protocol
> >>>>>> [   13.983752] initializing loopback...
> >>>>>> [   13.987295] RTnet: registered rtlo
> >>>>>> [   13.993238] RTnet: registered rteth0
> >>>>>> [   13.996832] libphy: MACB_mii_bus: probed
> >>>>>> [   14.001140] rt_macb: rteth0: Cadence GEM at 0xe000b000 irq 26
> >> (00:0a:35:00:01:22)
> >>>>>> [   14.008630] rt_macb: rteth0: attached PHY driver [Marvell 88E1510]
> >> (mii_bus:phy_addr=e000b000.ethernet-:00, irq=-1)
> >>>>>> [   14.019845] RTcap: real-time capturing interface
> >>>>>> [   14.026562] RTproxy attached to rteth0
> >>>>>> [   14.031129] rtnetproxy installed as "rtproxy"
> >>>>>> [   14.035693] NET: Registered protocol family 26
> >>>>>> [   14.040309] NET: Registered protocol family 17
> >>>>>> [   14.044686] can: controller area network core (rev 20120528 abi 9)
> >>>>>> [   14.050957] NET: Registered protocol family 29
> >>>>>> [   14.055329] can: raw protocol (rev 20120528)
> >>>>>> [   14.059683] can: broadcast manager protocol (rev 20120528 t)
> >>>>>>
> >>>>>> kernel/drivers/net/Kconfig|  1 -
> >>>>>> kernel/drivers/net/addons/Kconfig |  4 ++--
> >>>>>> kernel/drivers/net/stack/Makefile | 16 
> >>>>>> utils/net/rtnet.in | 144
> >> +++--
> >>>>>> 4 files changed, 105 insertions(+), 6

Script for namespacing a few intel drivers

[Lange Norbert via Xenomai]

I managed to build a kernel with statically linked igb, e1000 and e1000e for 
linux and rtnet, after running the below script to namespace those drivers (I 
only use [rt_]igb, but this driver needs symbols from e1000).
Seems to basically work, with some caveats that might only relate to my changes.

Even if you don't use both drivers at one, I am not sure if there aren't some 
definitions leaking from the linux headers right now, so a cleanup might be 
useful anyway.


Norbert

---
# run me in kernel/drivers/net/drivers

sedreplace() {
(
TMPFILE=/tmp/functions.lst
{
grep -roh '\bigb_[[:alnum:]_]*[[:space:]]*(' | sed 
's,[[:space:]]*(,,'
grep -roh 'struct[[:space:]]*igb_[[:alnum:]_]*\b' | sed 
's,struct[[:space:]]*,,'
grep -roh '\be1000e*_[[:alnum:]_]*[[:space:]]*(' | sed 
's,[[:space:]]*(,,'
grep -roh 'struct[[:space:]]*e1000e*_[[:alnum:]_]*\b' | sed 
's,struct[[:space:]]*,,'

for ad; do echo $ad; done
} | sort -u >$TMPFILE

while read -r f; do
  printf -- '-e s,\\b%s\\b,rt_%s,g ' $f $f
done < $TMPFILE
)
}

SEDREP=$(sedreplace igb_driver_name igb_driver_version e1000_driver_name 
e1000_driver_version e1000e_driver_name e1000e_driver_version)

sed $SEDREP -e 's,^#include "rt_e1000_,#include "e1000_,' -i $(find -name '*.c' 
-o -name '*.h')

Mit besten Grüßen / Kind regards

NORBERT LANGE

AT-DES

ANDRITZ HYDRO GmbH
Eibesbrunnergasse 20
1120 Vienna / AUSTRIA
p: +43 50805 56684
norbert.la...@andritz.com
andritz.com


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

xeno_heapcheck kernel module not loadable?

[Lange Norbert via Xenomai]

Hello,

I built the xeno_*test components as loadable modules, but it seems 
xeno_heapcheck is either broken or can’t be built as module?
Version is  Xenomai v3.1-rc2

~# modprobe xeno_rtdmtest
~# modprobe xeno_heapcheck
[57980.549627] xeno_heapcheck: Unknown symbol xnthread_relax (err -2)
[57980.555854] xeno_heapcheck: Unknown symbol __rtdm_task_sleep (err -2)
[57980.562332] xeno_heapcheck: Unknown symbol xnheap_init (err -2)
[57980.568274] xeno_heapcheck: Unknown symbol xnthread_harden (err -2)
[57980.574576] xeno_heapcheck: Unknown symbol xnheap_alloc (err -2)
[57980.580609] xeno_heapcheck: Unknown symbol xnclock_core_read_monotonic (err 
-2)
[57980.587946] xeno_heapcheck: Unknown symbol xnheap_destroy (err -2)
[57980.594158] xeno_heapcheck: Unknown symbol rtdm_dev_unregister (err -2)
[57980.600804] xeno_heapcheck: Unknown symbol xnheap_free (err -2)
[57980.606747] xeno_heapcheck: Unknown symbol rtdm_dev_register (err -2)
[57980.618524] xeno_heapcheck: Unknown symbol xnthread_relax (err -2)
[57980.624749] xeno_heapcheck: Unknown symbol __rtdm_task_sleep (err -2)
[57980.631223] xeno_heapcheck: Unknown symbol xnheap_init (err -2)
[57980.637170] xeno_heapcheck: Unknown symbol xnthread_harden (err -2)
[57980.643468] xeno_heapcheck: Unknown symbol xnheap_alloc (err -2)
[57980.649508] xeno_heapcheck: Unknown symbol xnclock_core_read_monotonic (err 
-2)
[57980.656841] xeno_heapcheck: Unknown symbol xnheap_destroy (err -2)
[57980.663056] xeno_heapcheck: Unknown symbol rtdm_dev_unregister (err -2)
[57980.669696] xeno_heapcheck: Unknown symbol xnheap_free (err -2)
[57980.675669] xeno_heapcheck: Unknown symbol rtdm_dev_register (err -2)

Regards, Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

Re: running xenomai through scan-build or: some 100 issues

[Lange Norbert via Xenomai]

> -Original Message-

> From: Xenomai 
> mailto:xenomai-boun...@xenomai.org>> On Behalf 
> Of Jan Kiszka

> via Xenomai

> Sent: Montag, 14. Oktober 2019 08:26

> To: Norbert Lange mailto:nolang...@gmail.com>>; Xenomai 
> mailto:xenomai@xenomai.org>>

> Subject: Re: running xenomai through scan-build or: some 100 issues

> with static code analysis

>

> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR ATTACHMENTS.

>

>

> On 13.10.19 21:49, Norbert Lange via Xenomai wrote:

> > Hello,

> >

> > I did run some static analysis tools over xenomai 3.1rc2 userspace

> > libraries, and there seems to be alot of real issues.

> >

> > The tools are clangs builtin statical analysis and clang-tidy,

> > naturally there is some overlap in the reports.

> > clang-tidy would need to be configured to fit Xenomai's practices

> > (there is a ton of configurable checks), so this is more of an example.

> > The other, clang's statical analysis is more relevant as there are

> > very few false positives.

> >

> > Additionally to the checks, there is a directory failures, files

> > that cant be built with clang. Even if no one ships Xenomai built by

> > that compiler, fixing those should help, for being able to run those

> > tools and several IDE's and Editors already use clangd for code competition 
> > etc.

> >

> > I'd hope that such reports could be incorporated into the CI builds.

> > running the analysis on cross-builds is alot more daunting, but on

> > native builds its rather easy.

>

> This is generally a valuable thing. Unfortunately, it starts with some

> more

> work: modelling of functions and syscalls that clang has no insight

> into and, thus, throws false-positives around them. Quickly browsing

> through the report, I only saw one real finding so far, and that was a

> harmless "assigned but never used" warning. But I'm sure that there

> are a few more severe issues in that haystack.



Did you look only at the tidy-report? The other, website based report has tons 
of valid issues, and clang models POSIX/GNU functions - that's enough for most 
of the code.



eg.:



utils/analogy/calibration_ni_m.c: use after free (your error() macro is broken).

lib/copperplate/heapobj-heapmem.c: heapobj_init_array_private with size=0 has 
undefined behavior



Every report I looked at seemed valid, those that are questionable, like 
heapobj_init_array_private Are questionable because it's not clear if this 
function is allowed to be called with size=0.

Means it's questionable for everyone reading the code, and something an 
analyzer should throw up.

Its either a bug or some annotation would help (__builtin_expect(size != 0, 1) 
or assert(size != 0)).



>

> I was already considering to enable Coverity via our CI. It generally

> works, it has proven to find real issues without too much modelling

> effort (though this case may be different because of all the custom

> syscalls), but since Synopsis bought it, the availability and quality

> of their public OSS service massively degraded.

>

> So, looking into clang might be a more reliable alternative. I'm open

> for patches that pave the way. For CI, we may need a more recent

> source than

> clang-6 because that is what Travis provides us ATM.



I dont have any experience with travis, but can't you just tell you want a 
recent Ubuntu/Debian?



Norbert





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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: running xenomai through scan-build or: some 100 issues with static code analysis

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Montag, 14. Oktober 2019 12:09
> To: Lange Norbert ; Xenomai
> 
> Subject: Re: running xenomai through scan-build or: some 100 issues with
> static code analysis
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> Readding the list.
>
> On 14.10.19 11:36, Lange Norbert wrote:
> >> -Original Message-
> >> From: Xenomai  On Behalf Of Jan
> Kiszka
> >> via Xenomai
> >> Sent: Montag, 14. Oktober 2019 08:26
> >> To: Norbert Lange ; Xenomai
> >> 
> >> Subject: Re: running xenomai through scan-build or: some 100 issues
> >> with static code analysis
> >>
> >> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
> >>
> >>
> >> On 13.10.19 21:49, Norbert Lange via Xenomai wrote:
> >>> Hello,
> >>>
> >>> I did run some static analysis tools over xenomai 3.1rc2 userspace
> >>> libraries, and there seems to be alot of real issues.
> >>>
> >>> The tools are clangs builtin statical analysis and clang-tidy,
> >>> naturally there is some overlap in the reports.
> >>> clang-tidy would need to be configured to fit Xenomai's practices
> >>> (there is a ton of configurable checks), so this is more of an example.
> >>> The other, clang's statical analysis is more relevant as there are
> >>> very few false positives.
> >>>
> >>> Additionally to the checks, there is a directory failures, files that
> >>> cant be built with clang. Even if no one ships Xenomai built by that
> >>> compiler, fixing those should help, for being able to run those tools
> >>> and several IDE's and Editors already use clangd for code competition
> etc.
> >>>
> >>> I'd hope that such reports could be incorporated into the CI builds.
> >>> running the analysis on cross-builds is alot more daunting, but on
> >>> native builds its rather easy.
> >>
> >> This is generally a valuable thing. Unfortunately, it starts with some more
> >> work: modelling of functions and syscalls that clang has no insight into
> and,
> >> thus, throws false-positives around them. Quickly browsing through the
> >> report, I only saw one real finding so far, and that was a harmless
> "assigned
> >> but never used" warning. But I'm sure that there are a few more severe
> >> issues in that haystack.
> >
> > Did you look only at the tidy-report? The other, website based report has
> tons of valid issues,
> > and clang models POSIX/GNU functions - that’s enough for most of the
> code.
>
> No, I didn't look at the tidy reports, the other ones instead. And a lot
> of those I checked (might not have been representative) stumbled over
> the unknown behavior of Xenomai systems - naturally. Some may have also
> stumbled over missing noreturn annotations. Others simply because the
> graph didn't get that a path was not taken with the assumed input
> values. All normal for static analysis.
>
> >
> > eg.:
> >
> > utils/analogy/calibration_ni_m.c: use after free (your error() macro is
> broken).
>
> A nice example for improper modeling of clang: error[_at_line] will
> never return when passed a non-zero status.

It's actually worse than that, glibc uses a gcc extension __builtin_va_arg_pack,
Which clang does not support but would be necessary to use the inline 
declaration.

>
> The error macro is still wrong because it assumes that this will only
> happen for status < 0.

Yes, thats what I meant.

>
> > lib/copperplate/heapobj-heapmem.c: heapobj_init_array_private with
> size=0 has undefined behavior
> >
> > Every report I looked at seemed valid, those that are questionable, like
> heapobj_init_array_private
> > Are questionable because it's not clear if this function is allowed to be
> called with size=0.
> > Means it's questionable for everyone reading the code, and something an
> analyzer should throw up.
> > Its either a bug or some annotation would help (__builtin_expect(size != 0,
> 1) or assert(size != 0)).
> >
>
> This one indeed requires a closer look and likely proper error handline
> for size == 0.
>
> >>
> >> I was already considering to enable Coverity via our CI. It generally 
> >> works,
> it
> >> has proven to find real issues without too much modelling effort (though
> this
> >> case may be different because of all the

RE: pthread_cond_wait() never returns?

[Lange Norbert via Xenomai]

Signaling the waiting thread happens when you unlock the corresponding mutex,
You need to lock/unlock the mutex around the  pthread_cond_signal call.

Regards, Norbert

> -Original Message-
> From: Xenomai  On Behalf Of Jan Leupold
> via Xenomai
> Sent: Mittwoch, 23. Oktober 2019 17:52
> To: xenomai@xenomai.org
> Subject: pthread_cond_wait() never returns?
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> Hi all,
>
> I am trying to use pthread_cond_t in a Xenomai application. When compiling
> and linking with the flags from xeno-config, the condition variable stops
> working as expected. It seems as if pthread_cond_wait() would never
> return.
>
> Is this a known issue?
> (but most probably I think it's just my fault and I would be glad if someone
> could give me a hint)
>
> BTW, "cyclictest -M" (also uses pthread_cond_t to signal a refresh) does not
> work as expected either.
>
> Regards,
> Jan
>
> Using:
> 
> ipipe-arm, branched off at tag ipipe-core-4.19.33-arm-2 xenomai-3, branched
> off at 44065a107 (master April 2019) custom hardware, SAMA5D2 SoC
>
> The program:
> --
> #include 
> #include 
> #include 
>
> pthread_mutex_t mutex;
> pthread_cond_t cond;
>
> void*
> task(void* arg)
> {
> (void) arg;
> printf("task\n");
> for (int i = 0; i < 3; ++i)
> {
> pthread_mutex_lock(&mutex);
> pthread_cond_wait(&cond, &mutex);
> pthread_mutex_unlock(&mutex);
> printf("task: condition signaled (i=%d)\n", i);
> }
> printf("task: done\n");
> return NULL;
> }
>
> int
> main()
> {
> printf("main\n");
>
> pthread_mutex_init(&mutex, NULL);
> pthread_cond_init(&cond, NULL);
>
> pthread_t t;
> pthread_create(&t, NULL, task, NULL);
>
> for (int i = 0; i < 3; ++i)
> {
> sleep(1);
> pthread_cond_signal(&cond);
> printf("main: signal(i=%d)\n", i);
> }
>
> pthread_join(t, NULL);
>
> printf("main: done\n");
> return 0;
> }
>
> When compiling without Xenomai the output is:
>
> main
> task
> main: signal(i=0)
> task: condition signaled (i=0)
> main: signal(i=1)
> task: condition signaled (i=1)
> main: signal(i=2)
> task: condition signaled (i=2)
> task: done
> main: done
>
> When compiling with Xenomai the output is:
>
> main
> task
> main: signal(i=0)
> main: signal(i=1)
> main: signal(i=2)
> ^C
> (pthread_join() never returns)
>
> The difference in Makefile.am:
> --
>
> bin_PROGRAMS = test-condition-xeno test-condition-linux
>
> test_condition_linux_SOURCES = condition_c.c
> test_condition_linux_LDFLAGS = -pthread
>
> test_condition_xeno_SOURCES = condition_c.c
> test_condition_xeno_CFLAGS = $(shell xeno-config --skin=posix --cflags)
> test_condition_xeno_LDADD = $(shell xeno-config --skin=posix --ldflags)
>
> Output from --dump-config:
> --
> based on Xenomai/cobalt v3.1-devel -- #94e729d53 (2019-06-03 13:32:22
> +0200)
> CONFIG_MMU=1
> CONFIG_XENO_BUILD_ARGS=" '--build=x86_64-linux'
> '--host=arm-poky-linux-gnueabi' '--target=arm-poky-linux-gnueabi'
> '--prefix=/usr' '--exec_prefix=/usr' '--bindir=/usr/bin'
> '--sbindir=/usr/sbin' '--libexecdir=/usr/libexec' '--datadir=/usr/share'
> '--sysconfdir=/etc' '--sharedstatedir=/com' '--localstatedir=/var'
> '--libdir=/usr/lib' '--includedir=/usr/include/xenomai'
> '--oldincludedir=/usr/include/xenomai' '--infodir=/usr/share/info'
> '--mandir=/usr/share/man' '--disable-silent-rules'
> '--with-libtool-sysroot=/home/jan/yocto/aertronic2.0-io/build-
> betrieb/tmp/work/cortexa5t2hf-vfp-poky-linux-gnueabi/xenomai/3+git999-
> r0/recipe-sysroot'
> '--disable-static' '--disable-async-cancel' '--disable-clock-monotonic-raw'
> '--with-core=cobalt' '--enable-debug=symbols' '--disable-dlopen-libs'
> '--disable-doc-build' '--disable-fortify' '--disable-lores-clock'
> '--disable-pshared' '--disable-registry' '--disable-smp' '--disable-tls'
> 'build_alias=x86_64-linux' 'host_alias=arm-poky-linux-gnueabi'
> 'target_alias=arm-poky-linux-gnueabi' 'CC=arm-poky-linux-gnueabi-gcc -
> mthumb -mfpu=vfp -mfloat-abi=hard -mcpu=cortex-a5 -fstack-protector-
> strong
>  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-
> security --sysroot=/home/jan/yocto/aertronic2.0-io/build-
> betrieb/tmp/work/cortexa5t2hf-vfp-poky-linux-gnueabi/xenomai/3+git999-
> r0/recipe-sysroot'
> 'CFLAGS= -O2 -pipe -g -feliminate-unused-debug-types
> -fmacro-prefix-map=/home/jan/yocto/aertronic2.0-io/build-
> betrieb/tmp/work/cortexa5t2hf-vfp-poky-linux-gnueabi/xenomai/3+git999-
> r0=/usr/src/debug/xenomai/3+git999-r0
>
> -fdebug-prefix-map=/home/jan/yocto/aertronic2.0-io/build-
> betrieb/tmp/work/cortexa5t2hf-vfp-poky-linux-gnueabi/xenomai/3+git999-
> r0=/usr/src/debug/xenomai/3+git999-r0
>
> -fdebug-prefix-map=/home/jan/yocto/aertronic2.0-io/build-
> betrieb/tmp/work/cortexa5t2hf-vfp-poky-linux-gnueabi/xenomai/3+git999-
> r0/recipe-sysroot=
>
> -fdebug-prefix-map=/home/jan/y

RE: Process load balancing among CPU

[Lange Norbert via Xenomai]

Nothing has an effect, as the cobalt setup routine binds the main thread to the 
single core.
See: https://xenomai.org/pipermail/xenomai/2019-August/041381.html

Every thread you spawn will inherit the same affinity mask (with a single bit 
set), and all options (tunables, cmdline) affect the mask *before* the setup 
then  picks the current core as mask.
You will need to reset the affinity mask yourself.

Kind regards, Norbert

> -Original Message-
> From: Xenomai  On Behalf Of Stéphane
> Ancelot via Xenomai
> Sent: Donnerstag, 24. Oktober 2019 16:01
> To: Jan Kiszka ; xenomai@xenomai.org
> Subject: Re: Process load balancing among CPU
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> Le 24/10/2019 à 12:28, Jan Kiszka a écrit :
> > On 24.10.19 12:21, Stéphane Ancelot wrote:
> >> Le 24/10/2019 à 12:13, Jan Kiszka a écrit :
> >>> On 24.10.19 10:00, Stéphane Ancelot via Xenomai wrote:
>  Hi,
> 
>  In our system, I noticed maybe a setup problem, or a xenomai
>  related setup problem regarding user processes.
> 
>  I have 2 user tasks that does not use RT (but xenomai shared memory
>  access), I noticed that if these both tasks were consuming 50% of
>  the CPU they were not migrated on other cpus.
> 
>  There is no CPU affinity setup in these programs , so I kept the
>  kernel scheduler doing its job.
> 
>  Is this a bad kernel setting or xenomai setting  to allow process
>  cpu migration for user processes ?
> >>> There is - by design - no automatic load balancing for Xenomai threads.
> >>> The common case is static schedules /wrt RT task for each CPU.
> >> This is not an RT thread, this is a userspace non rt task linking
> >> xenomai heap shared memory.
> >>
> >> having a look at this page, the documentation states  cpu_affinity
> >> Defaults to any online CPU.
> > As long as that non-RT task is in Linux mode and has an affinity mask
> > that is not reduced to the single core, Linux will happily
> > load-balance it. But if that task went through shadowing by Xenomai,
> > its affinity mask was likely reduced.
>
> A tunable should permit to change it, but it has no effect
>
>  cpu_set_t cpus;
>  CPU_ZERO(&cpus);
>  CPU_SET(0,&cpus);
>  CPU_SET(1,&cpus);
>  CPU_SET(2,&cpus);
>  CPU_SET(3,&cpus);
>
>  set_config_tunable(cpu_affinity,cpus);
>
> > Jan


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

binding to iddp socket often blocks forever

[Lange Norbert via Xenomai]

Hello,

I have some problems with Xenomai 3.1rc2, the following function will often 
block after printing "b".
This does not happen always and never happens when I run the program through 
gdb, and I can't attach
with gdb if its blocked.
Using another port then -1 makes no difference, and there is a single XDDP 
connection active at the time
(on port #0), but this should be the first and only IDDP socket open.

static int s_bindRtIpcEndpoint(int protocol, czstring pLabel, const int *pArgs, 
int *pErrno)
{
int ret;
int __attribute__((cleanup(auto_closesocket_rt))) fd =  
__RT(socket)(AF_RTIPC, SOCK_DGRAM, protocol);
TEST_LOG_ERRNO_ERROR_M_SCOPE(fd < 0, *pErrno, "socket", -1);
printf("a\n");
if (protocol == IPCPROTO_BUFP) {
size_t bufsz = 32768; /* bytes */
if (pArgs)
bufsz = *pArgs;
ret = setsockopt(fd, SOL_BUFP, BUFP_BUFSZ, &bufsz, sizeof(bufsz));
TEST_LOG_ERRNO_ERROR_M_SCOPE(ret != 0, *pErrno, "setsockopt", -1);
}

if (pLabel)
setLabel(fd, protocol, pLabel);

printf("b\n");
// bind first endpoint
struct sockaddr_ipc saddr = {AF_RTIPC, -1};

ret = __RT(bind)(fd, (struct sockaddr *)&saddr, sizeof(saddr));
printf("c\n");
TEST_LOG_ERRNO_ERROR_M_SCOPE(ret != 0, *pErrno, "bind", -1);
ret = fd;
fd = -1; // NOLINT(clang-analyzer-deadcode.DeadStores)
return ret;
}

The function is called like this:

int tmp;
s_bindRtIpcEndpoint(IPCPROTO_IDDP, NULL, NULL, &tmp);

I really don't know how to tackle this, any hints?

Mit besten Grüßen / Kind regards

NORBERT LANGE

AT-RD3

ANDRITZ HYDRO GmbH
Eibesbrunnergasse 20
1120 Vienna / AUSTRIA
p: +43 50805 56684
norbert.la...@andritz.com
andritz.com



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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: binding to iddp socket often blocks forever

[Lange Norbert via Xenomai]

Well, seems like my bootargs are related,
I tried to bind linux to Core #0 and leve the remaining for Xenomai,
Using "isolcpus=1-3 xenomai.supported_cpus=0x6"

I get this Warning when the deadlock happens:
[  106.882123] [Xenomai] thread new_project[798] switched to non-rt CPU0, 
aborted.

I am not clear what happened, this is likely my non-rt thread suddenly running 
on the
non-Xenomai CPU, I don't know how it happened.
This is not the first Xenomai/cobalt function I am calling, I don't understand 
why its failing always at that point.

> -Original Message-
> From: Xenomai  On Behalf Of Lange
> Norbert via Xenomai
> Sent: Dienstag, 29. Oktober 2019 17:32
> To: Xenomai (xenomai@xenomai.org) 
> Subject: binding to iddp socket often blocks forever
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> Hello,
>
> I have some problems with Xenomai 3.1rc2, the following function will often
> block after printing "b".
> This does not happen always and never happens when I run the program
> through gdb, and I can't attach with gdb if its blocked.
> Using another port then -1 makes no difference, and there is a single XDDP
> connection active at the time (on port #0), but this should be the first and
> only IDDP socket open.
>
> static int s_bindRtIpcEndpoint(int protocol, czstring pLabel, const int 
> *pArgs,
> int *pErrno) {
> int ret;
> int __attribute__((cleanup(auto_closesocket_rt))) fd =
> __RT(socket)(AF_RTIPC, SOCK_DGRAM, protocol);
> TEST_LOG_ERRNO_ERROR_M_SCOPE(fd < 0, *pErrno, "socket", -1);
> printf("a\n");
> if (protocol == IPCPROTO_BUFP) {
> size_t bufsz = 32768; /* bytes */
> if (pArgs)
> bufsz = *pArgs;
> ret = setsockopt(fd, SOL_BUFP, BUFP_BUFSZ, &bufsz, sizeof(bufsz));
> TEST_LOG_ERRNO_ERROR_M_SCOPE(ret != 0, *pErrno, "setsockopt", -
> 1);
> }
>
> if (pLabel)
> setLabel(fd, protocol, pLabel);
>
> printf("b\n");
> // bind first endpoint
> struct sockaddr_ipc saddr = {AF_RTIPC, -1};
>
> ret = __RT(bind)(fd, (struct sockaddr *)&saddr, sizeof(saddr));
> printf("c\n");
> TEST_LOG_ERRNO_ERROR_M_SCOPE(ret != 0, *pErrno, "bind", -1);
> ret = fd;
> fd = -1; // NOLINT(clang-analyzer-deadcode.DeadStores)
> return ret;
> }
>
> The function is called like this:
>
> int tmp;
> s_bindRtIpcEndpoint(IPCPROTO_IDDP, NULL, NULL, &tmp);
>
> I really don't know how to tackle this, any hints?
>
> Mit besten Grüßen / Kind regards
>
> NORBERT LANGE
>
> AT-RD3
>
> ANDRITZ HYDRO GmbH
> Eibesbrunnergasse 20
> 1120 Vienna / AUSTRIA
> p: +43 50805 56684
> norbert.la...@andritz.com
> andritz.com
>
> 
>
> This message and any attachments are solely for the use of the intended
> recipients. They may contain privileged and/or confidential information or
> other information protected from disclosure. If you are not an intended
> recipient, you are hereby notified that you received this email in error and
> that any review, dissemination, distribution or copying of this email and any
> attachment is strictly prohibited. If you have received this email in error,
> please contact the sender and delete the message and any attachment from
> your system.
>
> ANDRITZ HYDRO GmbH
>
>
> Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation
>
> Firmensitz/ Registered seat: Wien
>
> Firmenbuchgericht/ Court of registry: Handelsgericht Wien
>
> Firmenbuchnummer/ Company registration: FN 61833 g
>
> DVR: 0605077
>
> UID-Nr.: ATU14756806
>
>
> Thank You
> 



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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RTnet sendmmsg and ENOBUFS

[Lange Norbert via Xenomai]

Hello,

for one of our applications, we have (unfortunatly) a single ethernet 
connection for Realtime and Nonrealtime.

We solve this by sending timeslices with RT first, then filling up the 
remaining space. When stressing the limits (quite possibly beyond if accounting 
for bugs),
the sendmmsg call over a raw socket returns ENOBUFS (even with a single small 
packet).
I was expecting this call to just block until the resouces are available.

Timeslices are 1 ms, so that could be around 12Kbyte total or ~190 60Byte 
packets (theoretical max).

What variables are involved (whats the xenomai buffer limits, are they shared 
or per interface) and choices do I have?

- I could send the packages nonblocking and wait or drop the remaining myself
- I could deal with ENOBUFS the same way as EAGAIN (is there any difference 
actually)
- I could raise the amount of internal buffer somehow

Also while stresstesting I get these messages:

[ 5572.044934] hard_start_xmit returned 16
[ 5572.054989] hard_start_xmit returned 16
[ 5572.064007] hard_start_xmit returned 16
[ 5572.067893] hard_start_xmit returned 16
[ 5572.071739] hard_start_xmit returned 16
[ 5572.075586] hard_start_xmit returned 16
[ 5575.096116] hard_start_xmit returned 16
[ 5579.377038] hard_start_xmit returned 16

Kind regards, Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

Xenomai crashes when braking into the debugger

[Lange Norbert via Xenomai]

Hello,

I am running into some bad issues with debugging,
can't really narrow down when they happen, but usually when I run through GDB 
and want to "break" (pause execution),
it seems to be related to *other* Xenomai programs running at the same time (as 
said its hard to narrow down).

Kind regards, Norbert Lange

[10352.719588] I-pipe: Detected stalled head domain, probably caused by a bug.
[10352.719588] A critical section may have been left unterminated.
[10352.733165] CPU: 2 PID: 12883 Comm: aboard_runner Tainted: GW
 4.19.75-xeno7-static #1
[10352.742389] Hardware name: TQ-Group TQMxE39M/Type2 - Board Product Name, 
BIOS 5.12.30.21.16 01/31/2019
[10352.751702] I-pipe domain: Linux
[10352.754938] Call Trace:
[10352.757406]  dump_stack+0x82/0xb0
[10352.760735]  ipipe_stall_root+0xc/0x30
[10352.764497]  __ipipe_trap_prologue+0x209/0x210
[10352.768955]  page_fault+0x24/0x5b
[10352.772281] RIP: 0010:xnthread_suspend+0x13/0x4e0
[10352.776992] Code: f8 c3 a5 e8 1f ce f3 ff e9 e4 fe ff ff 66 2e 0f 1f 84 00 
00 00 00 00 e8 bb 0b 87 00 41 57 41 56 41 55 41 54 55 53 48 83 ec 20  c
[10352.795762] RSP: :a45140797e10 EFLAGS: 00010082 ORIG_RAX: 

[10352.803343] RAX:  RBX: eab8 RCX: 
[10352.810485] RDX:  RSI: 0040 RDI: eaf8
[10352.817626] RBP: a4514060ab80 R08:  R09: 
[10352.824770] R10:  R11:  R12: 94477bb30780
[10352.831910] R13:  R14:  R15: 94477bb30400
[10352.839058]  ? __cobalt_clock_nanosleep+0x4b0/0x4b0
[10352.843946]  ? CoBaLt_clock_nanosleep+0x7f/0x100
[10352.848571]  stop_debugged_process+0x51/0x70
[10352.852850]  ipipe_trap_hook+0x2da/0x3f0
[10352.856785]  __ipipe_notify_trap+0x80/0xc0
[10352.860892]  __ipipe_trap_prologue+0x76/0x210
[10352.865259]  ? int3+0x29/0x70
[10352.868236]  int3+0x45/0x70
[10352.871040] RIP: 0033:0x409fb8
[10352.874102] Code: ff 15 34 47 95 00 c7 05 fe e2 99 00 00 00 00 00 48 8d 95 
78 fd ff ff 48 8d 85 70 fe ff ff 48 89 d6 48 89 c7 e8 08 14 00 00 cc  6
[10352.892874] RSP: 002b:7fffe890 EFLAGS: 0297
[10352.898111] RAX:  RBX:  RCX: 0002
[10352.905249] RDX:  RSI:  RDI: 
[10352.912389] RBP: 7fffebb0 R08: 0001 R09: 0015
[10352.919531] R10: 7fffe820 R11: 0246 R12: 00409170
[10352.926671] R13: 7fffec90 R14:  R15: 
[10352.933813]  ? int3+0x29/0x70
[10352.936872] BUG: Unhandled exception over domain Xenomai at 
0xa4b90f23 - switching to ROOT
[10352.945841] CPU: 2 PID: 12883 Comm: aboard_runner Tainted: GW
 4.19.75-xeno7-static #1
[10352.955065] Hardware name: TQ-Group TQMxE39M/Type2 - Board Product Name, 
BIOS 5.12.30.21.16 01/31/2019
[10352.964374] I-pipe domain: Linux
[10352.967611] Call Trace:
[10352.970070]  dump_stack+0x82/0xb0
[10352.973393]  __ipipe_trap_prologue.cold+0x22/0x4e
[10352.978108]  page_fault+0x24/0x5b
[10352.981435] RIP: 0010:xnthread_suspend+0x13/0x4e0
[10352.986144] Code: f8 c3 a5 e8 1f ce f3 ff e9 e4 fe ff ff 66 2e 0f 1f 84 00 
00 00 00 00 e8 bb 0b 87 00 41 57 41 56 41 55 41 54 55 53 48 83 ec 20  c
[10353.004916] RSP: :a45140797e10 EFLAGS: 00010082 ORIG_RAX: 

[10353.012497] RAX:  RBX: eab8 RCX: 
[10353.019637] RDX:  RSI: 0040 RDI: eaf8
[10353.026777] RBP: a4514060ab80 R08:  R09: 
[10353.033918] R10:  R11:  R12: 94477bb30780
[10353.041060] R13:  R14:  R15: 94477bb30400
[10353.048204]  ? __cobalt_clock_nanosleep+0x4b0/0x4b0
[10353.053087]  ? CoBaLt_clock_nanosleep+0x7f/0x100
[10353.057713]  stop_debugged_process+0x51/0x70
[10353.061991]  ipipe_trap_hook+0x2da/0x3f0
[10353.065921]  __ipipe_notify_trap+0x80/0xc0
[10353.070029]  __ipipe_trap_prologue+0x76/0x210
[10353.074393]  ? int3+0x29/0x70
[10353.077369]  int3+0x45/0x70
[10353.080171] RIP: 0033:0x409fb8
[10353.083232] Code: ff 15 34 47 95 00 c7 05 fe e2 99 00 00 00 00 00 48 8d 95 
78 fd ff ff 48 8d 85 70 fe ff ff 48 89 d6 48 89 c7 e8 08 14 00 00 cc  6
[10353.102002] RSP: 002b:7fffe890 EFLAGS: 0297
[10353.107238] RAX:  RBX:  RCX: 0002
[10353.114380] RDX:  RSI:  RDI: 
[10353.121522] RBP: 7fffebb0 R08: 0001 R09: 0015
[10353.128663] R10: 7fffe820 R11: 0246 R12: 00409170
[10353.135803] R13: 7fffec90 R14:  R15: 
[10353.142947]  ? int3+0x29/0x70
[10353.145931] BUG: unable to handle kernel paging request at fcba
[10353.152900] PGD 12600c067

RE: RTnet sendmmsg and ENOBUFS

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Mittwoch, 13. November 2019 18:39
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Subject: Re: RTnet sendmmsg and ENOBUFS
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> On 13.11.19 16:10, Lange Norbert via Xenomai wrote:
> > Hello,
> >
> > for one of our applications, we have (unfortunatly) a single ethernet
> connection for Realtime and Nonrealtime.
> >
> > We solve this by sending timeslices with RT first, then filling up the
> > remaining space. When stressing the limits (quite possibly beyond if
> accounting for bugs), the sendmmsg call over a raw socket returns ENOBUFS
> (even with a single small packet).
> > I was expecting this call to just block until the resouces are available.
>
> Blocking would mean that the sites which make buffers available again had to
> signal this. The original design idea was to avoid such overhead and rather
> rely on the applications to schedule their submissions properly and
> preallocate resources accordingly.

Ok.
In other words, this is the same behaviour as using MSG_DONTWAIT
(with a different errno value)

>
> >
> > Timeslices are 1 ms, so that could be around 12Kbyte total or ~190 60Byte
> packets (theoretical max).
> >
> > What variables are involved (whats the xenomai buffer limits, are they
> shared or per interface) and choices do I have?
> >
> > - I could send the packages nonblocking and wait or drop the remaining
> > myself
> > - I could deal with ENOBUFS the same way as EAGAIN (is there any
> > difference actually)
> > - I could raise the amount of internal buffer somehow
>
> Check kernel/drivers/net/doc/README.pools
>
> >
> > Also while stresstesting I get these messages:
> >
> > [ 5572.044934] hard_start_xmit returned 16 [ 5572.054989]
> > hard_start_xmit returned 16 [ 5572.064007] hard_start_xmit returned 16
> > [ 5572.067893] hard_start_xmit returned 16 [ 5572.071739]
> > hard_start_xmit returned 16 [ 5572.075586] hard_start_xmit returned 16
> > [ 5575.096116] hard_start_xmit returned 16 [ 5579.377038]
> > hard_start_xmit returned 16
>
> This likely comes from NETDEV_TX_BUSY signaled by the driver. Check the
> one you use for reasons. May include "I don't have buffers left".

Yes it does, I was afraid this would indicate some leaked buffers.

Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: Xenomai crashes when braking into the debugger

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Mittwoch, 13. November 2019 18:42
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Subject: Re: Xenomai crashes when braking into the debugger
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> On 13.11.19 16:18, Lange Norbert via Xenomai wrote:
> > Hello,
> >
> > I am running into some bad issues with debugging, can't really narrow
> > down when they happen, but usually when I run through GDB and want to
> > "break" (pause execution), it seems to be related to *other* Xenomai
> programs running at the same time (as said its hard to narrow down).
>
> We have a gdb test case. Does it trigger for you as well when you run some
> other program in parallel?
>
> Also, could you provide the kernel full log? Possibly, enabling the I-pipe
> tracer with panic dump could be useful as well. But the most important step
> would be to create reproducibility for a third party like me.

Currently the issue is gone, and I don't have time for researching the cause.
is panic dump a kernel compilation config?

Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: RTnet sendmmsg and ENOBUFS

[Lange Norbert via Xenomai]

So, for my setup socket_rtskbs is 16, the rt_igp driver rtskbs are 256TX + 
256RX.

As said, our software prepares packets before a timeslice, and would aim to 
minimize systemcalls and interrupts,
packets are sent over raw rtsockets.

if  understand __rtdm_fd_sendmmsg and rt_packet_sendmsg correctly,
sendmsg will pick one socket_rtskbs, copies data from userspace and
then passes this rtskbs to rtdev_xmit.
I don’t see how a free buffers gets passed back, like README.pools describes,
I guess rtskb_acquire should somehow do this.

So in short, I am using only one socket_rtskbs temporarily, as the function 
passes
the buffer to the rtdev (rt_igp driver)?
I suppose the receive path works similarly.


Now if I would want to send nonblocking, ie. as much packets as are possible,
exhausting the rtskbs then I would expect the EAGAIN/EWOULDBLOCK error and 
getting
back the number of successfully queued packets (so I could  drop them and send 
the remaining later).

According to the code in __rtdm_fd_sendmmsg, that’s not what happens, ENOBUFS 
would be returned instead,
And the amount of sent packets is lost forever.

if (datagrams > 0 && (ret == 0 || ret == -EWOULDBLOCK)) {
/* NOTE: SO_ERROR should be honored for other errors. */
rtdm_fd_put(fd);
return datagrams;
}

IMHO this condition would need to added:
((flags | MSG_DONTWAIT) && ret == -ENOBUFS)

(Recvmmsg possibly similarly, havent checked yet)

Thanks for the help,
Norbert

> -Original Message-
> From: Xenomai  On Behalf Of Lange
> Norbert via Xenomai
> Sent: Mittwoch, 13. November 2019 18:53
> To: Jan Kiszka ; Xenomai
> (xenomai@xenomai.org) 
> Subject: RE: RTnet sendmmsg and ENOBUFS
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> > -Original Message-
> > From: Jan Kiszka 
> > Sent: Mittwoch, 13. November 2019 18:39
> > To: Lange Norbert ; Xenomai
> > (xenomai@xenomai.org) 
> > Subject: Re: RTnet sendmmsg and ENOBUFS
> >
> > NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
> >
> >
> > On 13.11.19 16:10, Lange Norbert via Xenomai wrote:
> > > Hello,
> > >
> > > for one of our applications, we have (unfortunatly) a single ethernet
> > connection for Realtime and Nonrealtime.
> > >
> > > We solve this by sending timeslices with RT first, then filling up the
> > > remaining space. When stressing the limits (quite possibly beyond if
> > accounting for bugs), the sendmmsg call over a raw socket returns
> ENOBUFS
> > (even with a single small packet).
> > > I was expecting this call to just block until the resouces are available.
> >
> > Blocking would mean that the sites which make buffers available again had
> to
> > signal this. The original design idea was to avoid such overhead and rather
> > rely on the applications to schedule their submissions properly and
> > preallocate resources accordingly.
>
> Ok.
> In other words, this is the same behaviour as using MSG_DONTWAIT
> (with a different errno value)
>
> >
> > >
> > > Timeslices are 1 ms, so that could be around 12Kbyte total or ~190 60Byte
> > packets (theoretical max).
> > >
> > > What variables are involved (whats the xenomai buffer limits, are they
> > shared or per interface) and choices do I have?
> > >
> > > - I could send the packages nonblocking and wait or drop the remaining
> > > myself
> > > - I could deal with ENOBUFS the same way as EAGAIN (is there any
> > > difference actually)
> > > - I could raise the amount of internal buffer somehow
> >
> > Check kernel/drivers/net/doc/README.pools
> >
> > >
> > > Also while stresstesting I get these messages:
> > >
> > > [ 5572.044934] hard_start_xmit returned 16 [ 5572.054989]
> > > hard_start_xmit returned 16 [ 5572.064007] hard_start_xmit returned 16
> > > [ 5572.067893] hard_start_xmit returned 16 [ 5572.071739]
> > > hard_start_xmit returned 16 [ 5572.075586] hard_start_xmit returned 16
> > > [ 5575.096116] hard_start_xmit returned 16 [ 5579.377038]
> > > hard_start_xmit returned 16
> >
> > This likely comes from NETDEV_TX_BUSY signaled by the driver. Check the
> > one you use for reasons. May include "I don't have buffers left".
>
> Yes it does, I was afraid this would indicate some leaked buffers.
>
> Norbert
> 
>
> This message and any attachments are solely for the use of the intended
> recipients. They may contain privileged and/or confidential information or
> other information protected from disclosure. If you are not 

RE: RTnet sendmmsg and ENOBUFS

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Donnerstag, 14. November 2019 19:18
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Cc: Philippe Gerum (r...@xenomai.org) 
> Subject: Re: RTnet sendmmsg and ENOBUFS
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> On 14.11.19 18:55, Lange Norbert wrote:
> > So, for my setup socket_rtskbs is 16, the rt_igp driver rtskbs are 256TX +
> 256RX.
> >
> > As said, our software prepares packets before a timeslice, and would
> > aim to minimize systemcalls and interrupts, packets are sent over raw
> rtsockets.
> >
> > if  understand __rtdm_fd_sendmmsg and rt_packet_sendmsg correctly,
> > sendmsg will pick one socket_rtskbs, copies data from userspace and
> > then passes this rtskbs to rtdev_xmit.
> > I don’t see how a free buffers gets passed back, like README.pools
> > describes, I guess rtskb_acquire should somehow do this.
>
> The buffer returns (not necessarily the same one, though) when the packet
> was truly sent, and the driver ran its TX cleanup. If you submit many packets
> as a chunk, that may block them for a while.
>
> >
> > So in short, I am using only one socket_rtskbs temporarily, as the
> > function passes the buffer to the rtdev (rt_igp driver)?
>
> You are using as many rtskbs as it takes to get the data you passed down
> forwarded as packets to the NIC, and that as long as the NIC needs to get
> that data DMA'ed to the transmitter.

I was talking about the pools. The socket pool has 16  rtskbs, the device pool 
has 512.
As I understand it, the __rtdm_fd_sendmmsg picks one rtskb from the socket pool,
Then exchanges this buffer with a free one from the device pool 
(rtskb_acquire?).
So sendmmsg requires a single "slot" from their pool, then gets that "slot" back
when passing the rtskb down to the device.

Or In other words, I could successfully sendmmsg 100 messages, aslong there is 
one free
slot in the socket pool, and the device pool has enough free slots.

>
> > I suppose the receive path works similarly.
> >
>
> RX works by accepting a global-pool buffer (this is where incoming packets
> first end up in) filled with data in exchange to an empty rtskb from the 
> socket
> pool. That filled rtskb is put into the socket pool once the data was
> transferred to userspace.

I suppose all pools can exchange rtskb, so this is just a matter of which pool 
size is limiting.
If I want to recvmmsg 100 messages, will I get at most 16 (socket pool size),
or will a single slot be used and exchanged with the drivers?

>
> >
> > Now if I would want to send nonblocking, ie. as much packets as are
> > possible, exhausting the rtskbs then I would expect the
> > EAGAIN/EWOULDBLOCK error and getting back the number of successfully
> queued packets (so I could  drop them and send the remaining later).
>
> I don't recall why anymore, but we decided to use a different error code in
> RTnet for this back then, possibly to differentiate this "should never ever
> happen in a deterministic network" from other errors.

Yes, I guess that makes sense in alot usecases. Mine is a bit different,
I use a service that just tunnels a TUN to a RT Packet socket, and once someone
connects to an IDDP socket for RT traffic, timeslices are used.

So the network is not always in "deterministic mode".

>
> >
> > According to the code in __rtdm_fd_sendmmsg, that’s not what happens,
> > ENOBUFS would be returned instead, And the amount of sent packets is
> lost forever.
> >
> > if (datagrams > 0 && (ret == 0 || ret == -EWOULDBLOCK)) {
> > /* NOTE: SO_ERROR should be honored for other errors. */
> > rtdm_fd_put(fd); return datagrams; }
> >
> > IMHO this condition would need to added:
> > ((flags | MSG_DONTWAIT) && ret == -ENOBUFS)
> >
> > (Recvmmsg possibly similarly, havent checked yet)
>
> sendmmsg was only added to Xenomai 3.1. There might be room for
> improvements, if not corrections. So, if we do not return the number of sent
> messages or signal an error where we should not (this is how I read the man
> page currently), this needs a patch...

Yes, seems you either need to drop the number of transmitted msgs (unlike the 
linux call)
or the error condition.
If you can pass both out of the kernel function, perhaps you could still set 
errno in case of an (real) error?
(I really don’t need it, but it's worth considering)

Thanks,
Norbert


This message and any attachments are solely for the use of the intended 
recipients. They may contain privileged and/or confidential information or 
other information protected from di

RE: RTnet sendmmsg and ENOBUFS

[Lange Norbert via Xenomai]

>
> >
> >>
> >>> I suppose the receive path works similarly.
> >>>
> >>
> >> RX works by accepting a global-pool buffer (this is where incoming packets
> >> first end up in) filled with data in exchange to an empty rtskb from the
> socket
> >> pool. That filled rtskb is put into the socket pool once the data was
> >> transferred to userspace.
> >
> > I suppose all pools can exchange rtskb, so this is just a matter of which 
> > pool
> size is limiting.
> > If I want to recvmmsg 100 messages, will I get at most 16 (socket pool 
> > size),
> > or will a single slot be used and exchanged with the drivers?
>
> One packet, one rtskb. So you have both the device and the socket pool
> as limiting factors.

I guess this is different to the sendpath as the device "pushes up" the rtskb's,
And the recvmmsg call then picks up the packets that are available?
(having some trouble following the path in the kernel sources)

We have some legacy application that ran on an imx28, and we have to keep the 
protocols for now,
They are almost exclusively UDP/IP4 but there's one message for distributing 
timestamps with a 802.2 SNAP packet.
(had some technical/implementation reasons, cant remember now).
Currently I use an ETH_P_ALL packet socket for that reason, but looking at the 
code it seems beneficial to drop that.

-   there seems to be copies of rtskb made
-   the packets are not consumed, but kicked up further in the stack

What I would want is a socket that simply drains everything, packets in use are 
ETH_P_IP,
ETH_P_ARP and whatever is necessary to send/receive those 802.2 SNAP packets.

I see ETH_P_802_EX1 used for such packets in examples, but I don’t see how your 
stack identifies such packets?

-   I don’t know which ETH_P type to use, theres ETH_P_802_2, ETH_P_802_EX1, 
ETH_P_SNAP potentially others.
-   Those constants seems to be largely missing in xenomais sources, so I don’t 
know how you would test for a match.
-   Easiest for me would be a ETH_P_ALL_CONSUME type, buffers just end there 
when such a socket is open (feasible, would be accepted upstream?)

Regards, Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: [PATCH] rtdm: Do not return an error from send/recvmmsg if there are packets

[Lange Norbert via Xenomai]

Hello,

Just for consideration, If you can pass both error value and # of successfully 
sent packets out of the kernel function,
perhaps you could return the # (if > 0) and still set errno in case of an 
(real) error?

It would be somewhat different to Linux, but that would not be the only 
difference (like theres no way to block until all msgs are sent/received).

Norbert

> -Original Message-
> From: Xenomai  On Behalf Of Jan Kiszka
> via Xenomai
> Sent: Freitag, 15. November 2019 10:43
> To: Philippe Gerum ; Xenomai
> 
> Subject: Re: [PATCH] rtdm: Do not return an error from send/recvmmsg if
> there are packets
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> On 15.11.19 10:39, Philippe Gerum wrote:
> > On 11/15/19 10:37 AM, Philippe Gerum via Xenomai wrote:
> >> On 11/14/19 7:59 PM, Jan Kiszka wrote:
> >>> From: Jan Kiszka 
> >>>
> >>> This is in line with Linux behavior.
> >>>
> >>> We likely still miss an equivalent to sk_err in recvmmsg, though.
> >>
> >> Ack. Tracing on early exit due to null vlen in sendmmsg() is still missing;
> having this might help in debugging issue(s) at call site.
> >>
> >
> > Likewise in recvmmsg().
> >
>
> Yes, I'll simply remove the "vlan == 0" optimization.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate
> Competence Center Embedded Linux



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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: RTnet sendmmsg and ENOBUFS

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Freitag, 15. November 2019 14:36
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Subject: Re: RTnet sendmmsg and ENOBUFS
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> On 15.11.19 13:37, Lange Norbert wrote:
> >
> >
> >>
> >>>
> >>>>
> >>>>> I suppose the receive path works similarly.
> >>>>>
> >>>>
> >>>> RX works by accepting a global-pool buffer (this is where incoming
> >>>> packets first end up in) filled with data in exchange to an empty
> >>>> rtskb from the
> >> socket
> >>>> pool. That filled rtskb is put into the socket pool once the data
> >>>> was transferred to userspace.
> >>>
> >>> I suppose all pools can exchange rtskb, so this is just a matter of
> >>> which pool
> >> size is limiting.
> >>> If I want to recvmmsg 100 messages, will I get at most 16 (socket
> >>> pool size), or will a single slot be used and exchanged with the drivers?
> >>
> >> One packet, one rtskb. So you have both the device and the socket
> >> pool as limiting factors.
> >
> > I guess this is different to the sendpath as the device "pushes up"
> > the rtskb's,
>
> Actually, commit 91b3302284fd "aligned" TX to RX path. But the documents
> still state something else. And I doubt now that this commit was going in the
> right direction.
>
> In fact, it introduced a way for competing transmitters to starve each other
> by exhausting the now shared device pool for TX.
>
> > And the recvmmsg call then picks up the packets that are available?
> > (having some trouble following the path in the kernel sources)
>
> The point of the ownership transfer on RX is that, when receiving only with
> one queue (RTnet can't handle more in fact, though it should by now...), we
> first need to parse the packet content in order to dispatch it. That makes the
> packet first owned by the device (formerly the RX pool), and once the actual
> owner is known, it is transferred - or dropped if the recipient has no free
> buffer.

Right, but if I open up a packetsocket with ETH_P_802_EX1, rt_stack_deliver will
try to match the incoming packets, so somewhere the eth packet needs to be
dissected, is that rt_eth_type_trans?
means the valid values for a packet socket would be ETH_P_802_2, ETH_P_802_3,
and the protocols >= 0x600 from 802.3.

>
> >
> > We have some legacy application that ran on an imx28, and we have to
> > keep the protocols for now, They are almost exclusively UDP/IP4 but
> there's one message for distributing timestamps with a 802.2 SNAP packet.
> > (had some technical/implementation reasons, cant remember now).
> > Currently I use an ETH_P_ALL packet socket for that reason, but looking at
> the code it seems beneficial to drop that.
> >
> > -   there seems to be copies of rtskb made
> > -   the packets are not consumed, but kicked up further in the stack
>
> ETH_P_ALL is a kind of snooping mode, therefore the copies. You rather
> want to register on the desired (non-IP) type(s).

See above, seems the only usable types are ETH_P_802_2 and ETH_P_802_3?

> > What I would want is a socket that simply drains everything, packets
> > in use are ETH_P_IP, ETH_P_ARP and whatever is necessary to
> send/receive those 802.2 SNAP packets.
>
> IP and ARP will be handled by RTnet, the other types is what you need
> packet sockets for.

I use neither IP or ARP from RtNet, and I don’t have the choice right now,
Our timesync is via an external wire, and I gotta burst out everything at that 
point.
This is no cleanroom design.

Further, a tftp server is hooked into the RT connection via a TUN device,
So packets not for the RT Application (udp port range) go to that device.

> > I see ETH_P_802_EX1 used for such packets in examples, but I don’t see
> how your stack identifies such packets?
>
> rt_packet_bind -> rtdev_add_pack. Dispatching is done in rt_stack_deliver,
> in rt-kernel thread context.

Yes, and I fail to see anything supported outside ETH_P_802_2 and ETH_P_802_3
and the protocols from 803.
Nowhere will a eth packet be dissected and classified as ETH_P_802_EX1 or 
ETH_P_SNAP,
What packets would end up in such a socket?

> > -   I don’t know which ETH_P type to use, theres ETH_P_802_2,
> ETH_P_802_EX1, ETH_P_SNAP potentially others.
> > -   Those constants seems to be largely missing in xenomais sources, so I
> don’t know how you would test for a match.
>
> You can register any value you 

unable to handle kernel paging request

[Lange Norbert via Xenomai]

Hello,

How can I get to the bottom of bugs that lockup the system completely?
I got that error now the 3rd time.

[ 1643.652566] BUG: unable to handle kernel paging request at 00044540
[ 1643.659546] PGD 1750d1067 P4D 1750d1067 PUD 1775e7067 PMD 0
[ 1643.665237] Oops: 0010 [#1] SMP NOPTI
[ 1643.668911] CPU: 2 PID: 862 Comm: fup.medium Tainted: GW 
4.19.75-xeno7-static #1
[ 1643.677703] Hardware name: TQ-Group TQMxE39M/Type2 - Board Product Name, 
BIOS 5.12.30.21.16 01/31/2019
[ 1643.687013] I-pipe domain: Linux
[ 1643.690250] RIP: 0086:0x1c000
[ 1643.693231] Code: Bad RIP value.
[ 1643.696468] RSP: 3bb0:0083 EFLAGS: 92103bb25090 
ORIG_RAX: 0046
[ 1643.705092] RAX: 92103bb30400 RBX: 92103bb30400 RCX: 92103bb31bb0
[ 1643.712235] RDX: 92103bb31d58 RSI: 8ab85272 RDI: 921039f24cc0
[ 1643.719378] RBP: 92103bb305c8 R08: 0002 R09: 92103bb31d58
[ 1643.726517] R10: 92103bb31bb0 R11: 4000 R12: 8bc3f3c0
[ 1643.733657] R13: 8ab8284b R14: 0001c000 R15: 0086
[ 1643.740799] FS:  7fffe81da700 GS:  
[ 1643.746033] Modules linked in: rt_igb plusb usbnet mii
[ 1643.751210] CR2: 00044540
[ 1643.754542] ---[ end trace 7dda9c557e28b024 ]---
[ 1643.759167] RIP: 0086:0x1c000
[ 1643.762146] Code: Bad RIP value.
[ 1643.765379] RSP: 3bb0:0083 EFLAGS: 92103bb25090 
ORIG_RAX: 0046
[ 1643.774003] RAX: 92103bb30400 RBX: 92103bb30400 RCX: 92103bb31bb0
[ 1643.781147] RDX: 92103bb31d58 RSI: 8ab85272 RDI: 921039f24cc0
[ 1643.788289] RBP: 92103bb305c8 R08: 0002 R09: 92103bb31d58
[ 1643.795427] R10: 92103bb31bb0 R11: 4000 R12: 8bc3f3c0
[ 1643.802569] R13: 8ab8284b R14: 0001c000 R15: 0086
[ 1643.809712] FS:  7fffe81da700() GS:92103bb0() 
knlGS:
[ 1643.817806] CS:  0010 DS:  ES:  CR0: 80050033
[ 1643.823558] CR2: 0001bfd6 CR3: 0001750e4000 CR4: 003406e0

Mit besten Grüßen / Kind regards

NORBERT LANGE

AT-RD3

ANDRITZ HYDRO GmbH
Eibesbrunnergasse 20
1120 Vienna / AUSTRIA
p: +43 50805 56684
norbert.la...@andritz.com
andritz.com



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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

Deadlock during debugging

[Lange Norbert via Xenomai]

Hello,

Here's one of my deadlocks, the output seems interleaved from 2 concurrent 
dumps,
I ran the crashlog through decode_stacktrace.sh.

I got to this, after enabling a breakpoint in gdb  (execution did stop there), 
setting another breakpoint and
hitting continue.

[  135.414273] CPU: 1 PID: 0 Comm: swapper/2 Tainted: GW 
4.19.84-xeno8-static #1
[  135.414275] I-pipe: Detected stalled head domain, probably caused by a bug.
[  135.414275] A critical section may have been left unterminated.
[  135.414287] CPU: 2 PID: 798 Comm: fup.fast Tainted: GW 
4.19.84-xeno8-static #1
[  135.422810] Hardware name: TQ-Group TQMxE39M/Type2 - Board Product Name, 
BIOS 5.12.30.21.16 01/31/2019
[  135.436373] Hardware name: TQ-Group TQMxE39M/Type2 - Board Product Name, 
BIOS 5.12.30.21.16 01/31/2019
[  135.444984] I-pipe domain: Linux
[  135.454290] I-pipe domain: Linux
[  135.463598] RIP: 0010:rcu_nmi_exit+0x140/0x150
[  135.466825] Call Trace:
[  135.470057] Code: 45 89 f0 4c 89 f9 4c 89 e2 4c 89 ee ff d0 48 8b 03 48 85 
c0 75 e2 48 8b 45 08 4c 8d 78 fe e9 5b ff ff ff 0f 0b e9 ee fe ff ff <0f> 0b e9 
f8
[  135.474513]  dump_stack+0x8c/0xc0
[  135.476950] RSP: 0018:a3513bb03f18 EFLAGS: 00010046
[  135.495720]  ipipe_stall_root+0xc/0x30
[  135.504264]  __ipipe_trap_prologue+0x209/0x210
[  135.508011] RAX: 000573f4 RBX: 00019480 RCX: 001f
[  135.512458]  invalid_op+0x26/0x51
[  135.519592] RDX:  RSI: 50523fbe RDI: 0001
[  135.522914] RIP: 0010:xnthread_suspend+0x3d5/0x4e0
[  135.530050] RBP: a3513ba99480 R08: 0001 R09: 
[  135.534843] Code: 58 12 00 00 4c 89 e7 e8 f9 cf ff ff 41 83 8c 24 c4 11 00 
00 01 e9 92 fd ff ff 0f 0b 48 83 bf 58 12 00 00 00 0f 84 63 fc ff ff <0f> 0b 0f 
0b
[  135.541979] R10: a35139832440 R11: 0424 R12: 
[  135.560746] RSP: 0018:bddd0073fd60 EFLAGS: 00010082
[  135.567878] R13: 0022 R14:  R15: 
[  135.580241] FS:  () GS:a3513ba8() 
knlGS:
[  135.580246] RAX: bddd005fbe30 RBX: 00025090 RCX: 
[  135.588336] CS:  0010 DS:  ES:  CR0: 80050033
[  135.595477] RDX:  RSI: 0002 RDI: bddd005fa240
[  135.601225] CR2: 7f8899c36a10 CR3: 00017b31c000 CR4: 003406e0
[  135.608362] RBP: bddd005fbe08 R08: bddd005fbe08 R09: 
[  135.615500] Call Trace:
[  135.622637] R10:  R11:  R12: bddd005fa240
[  135.625085] ---[ end trace adb8b44963759cc1 ]---
[  135.632220] R13:  R14:  R15: bddd005fbe08
[  135.636851] WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:941 
rcu_nmi_enter+0xe4/0xf0
[  135.643982]  xnsynch_sleep_on+0x102/0x260
[  135.651634] Modules linked in:
[  135.655649]  __cobalt_cond_wait_prologue+0x295/0x8c0
[  135.655653]  rt_igb
[  135.658713]  ? __cobalt_cond_wait_prologue+0x8c0/0x8c0
[  135.663677]  plusb
[  135.665781]  CoBaLt_cond_wait_prologue+0x23/0x30
[  135.670918]  usbnet
[  135.672936]  handle_head_syscall+0xe1/0x370
[  135.677555]  mii
[  135.679658]  ipipe_fastcall_hook+0x14/0x20
[  135.685687]  ipipe_handle_syscall+0x4a/0xa0
[  135.689784] CPU: 1 PID: 0 Comm: swapper/2 Tainted: GW 
4.19.84-xeno8-static #1
[  135.693971]  do_syscall_64+0x41/0x3d0
[  135.702495] Hardware name: TQ-Group TQMxE39M/Type2 - Board Product Name, 
BIOS 5.12.30.21.16 01/31/2019
[  135.706160]  ? __ipipe_handle_irq+0xb7/0x200
[  135.715464] I-pipe domain: Linux
[  135.719738]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  135.722972] RIP: 0010:rcu_nmi_enter+0xe4/0xf0
[  135.728025] RIP: 0033:0x77f9c134
[  135.732386] Code: 48 85 c0 75 d9 48 8b 6b 08 eb 9a e8 b6 a9 ff ff 48 8b 6b 
08 41 bd 01 00 00 00 4c 8b 35 5d cb 23 01 4c 8d 7d 01 e9 72 ff ff ff <0f> 0b e9 
44
[  135.735966] Code: 8b 73 04 49 89 dc e8 fb ef ff ff 48 89 de 48 8b 5c 24 10 
45 31 c0 b9 23 00 00 10 48 8d 54 24 44 45 31 d2 48 89 df 89 c8 0f 05 <8b> 7c 24 
29
[  135.754730] RSP: 0018:a3513bb03f38 EFLAGS: 00010082
[  135.773496] RSP: 002b:7fffe82dab10 EFLAGS: 0246
[  135.778728]  ORIG_RAX: 1023
[  135.783954] RAX: 00019480 RBX: a3513ba99480 RCX: a3513ba9c008
[  135.787792] RAX: ffda RBX: 74127c78 RCX: 77f9c134
[  135.794927] RDX: a3513ba9c000 RSI: 0001 RDI: 1140
[  135.802065] RDX: 7fffe82dab54 RSI: 74127c48 RDI: 74127c78
[  135.809201] RBP: fffe R08: a3513ba9c228 R09: 0045
[  135.816337] RBP: 7fffe82dac30 R08:  R09: 
[  135.823470] R10: a35139832440 R11: 0424 R12: 9e7af080
[  135.830604] R10:  R11: 0246 R12: 74127c48
[  135.837738] R13: 00045000 R14: 

RE: Deadlock during debugging

[Lange Norbert via Xenomai]

New crash, same thing with ipipe panic trace (the decoded log does not add 
information to the relevant parts).

Is the dump_stack function itself trashing the stack?

[  168.411205] [Xenomai] watchdog triggered on CPU #1 -- runaway thread 'main' 
signaled
[  209.176742] [ cut here ]
[  209.181381] xnthread_relax() failed for thread aboard_runner[790]
[  209.181389] BUG: Unhandled exception over domain Xenomai at 
0x7fed - switching to ROOT
[  209.196451] CPU: 0 PID: 790 Comm: aboard_runner Tainted: GW 
4.19.84-xenod8-static #1
[  209.205588] Hardware name: TQ-Group TQMxE39M/Type2 - Board Product Name, 
BIOS 5.12.30.21.16 01/31/2019
[  209.214900] I-pipe domain: Linux
[  209.218137] Call Trace:
[  209.220593]  dump_stack+0x8c/0xc0
[  209.223919]  __ipipe_trap_prologue.cold+0x1f/0x5e
[  209.228629]  invalid_op+0x26/0x51
[  209.231952] RIP: 0010:xnthread_relax+0x46d/0x4a0
[  209.236576] Code: f6 83 c2 11 00 00 01 75 0e 48 8b 03 48 85 c0 74 33 8b 90 
c0 04 00 00 48 8d b3 5c 14 00 00 48 c7 c7 90 00 8b 9a e8 02 02 ef ff <0f> 0b e9 
42 fd ff ff 89 c6 48 c7 c7 c4 f8 a3 9a e8 2e 71 f3 ff e9
[  209.255347] RSP: 0018:9a0e4074fd90 EFLAGS: 00010286
[  209.260586] RAX:  RBX: 9a0e4065aa40 RCX: 000b
[  209.267728] RDX: 5129 RSI: 902a794791f8 RDI: 007800c0
[  209.274869] RBP: 9a0e4074fe68 R08: 007800c0 R09: 0002e248
[  209.282013] R10: 9bb72040 R11: 9bb3209c R12: 9bbfdc80
[  209.289157] R13: 902a76da8000 R14: 0001 R15: 0292
[  209.296299]  ? xnthread_prepare_wait+0x20/0x20
[  209.300752]  ? trace+0x59/0x8d
[  209.303814]  ? __cobalt_clock_nanosleep+0x540/0x540
[  209.308700]  handle_head_syscall+0x307/0x370
[  209.312979]  ipipe_fastcall_hook+0x14/0x20
[  209.317083]  ipipe_handle_syscall+0x57/0xe0
[  209.321280]  do_syscall_64+0x4b/0x500
[  209.324950]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  209.330011] RIP: 0033:0x77f9bd68
[  209.333598] Code: 89 fb bf 01 00 00 00 48 83 ec 18 48 8d 74 24 0c e8 bd f3 
ff ff b9 19 00 00 10 48 63 f5 48 63 fb 4d 89 ea 4c 89 e2 89 c8 0f 05 <8b> 7c 24 
0c 48 89 c3 31 f6 e8 9a f3 ff ff 48 83 c4 18 89 d8 f7 d8
[  209.352370] RSP: 002b:7fffe7d0 EFLAGS: 0246 ORIG_RAX: 
1019
[  209.359954] RAX: fe00 RBX: 0001 RCX: 77f9bd68
[  209.367098] RDX: 7fffe820 RSI: 0001 RDI: 0001
[  209.374237] RBP: 0001 R08: 0001 R09: 0014
[  209.381381] R10: 7fffe820 R11: 0246 R12: 7fffe820
[  209.388524] R13: 7fffe820 R14:  R15: 
[  209.395665] I-pipe tracer log (100 points):
[  209.399857]  | #func0 ipipe_trace_panic_freeze+0x0 
(__ipipe_trap_prologue+0x237)
[  209.409056]  | +func0 ipipe_root_only+0x0 
(ipipe_stall_root+0xe)
[  209.416862]  | +func   -1 ipipe_stall_root+0x0 
(__ipipe_trap_prologue+0x2ae)
[  209.425365]  |+ func   -2 ipipe_trap_hook+0x0 
(__ipipe_notify_trap+0x98)
[  209.433523]  |+ func   -3 __ipipe_notify_trap+0x0 
(__ipipe_trap_prologue+0x7f)
[  209.442199]  |+ func   -4 __ipipe_trap_prologue+0x0 
(invalid_op+0x26)
[  209.450097]  |+ end 0x8001 -5 
__ipipe_spin_unlock_irqrestore+0x4f (<>)
[  209.458425]  |# func   -6 __ipipe_spin_unlock_irqrestore+0x0 
(__ipipe_log_printk+0x69)
[  209.467797]  |+ begin   0x8001-10 __ipipe_spin_lock_irqsave+0x5e 
(<>)
[  209.475693]   + func  -10 __ipipe_spin_lock_irqsave+0x0 
(__ipipe_log_printk+0x22)
[  209.484630]   + func  -10 __ipipe_log_printk+0x0 
(__warn_printk+0x6c)
[  209.492525]  |+ end 0x8001-11 do_vprintk+0xf6 (<>)
[  209.499120]  |+ begin   0x8001-11 do_vprintk+0x106 (<>)
[  209.505799]   + func  -12 do_vprintk+0x0 (__warn_printk+0x6c)
[  209.513000]   + func  -12 vprintk+0x0 (__warn_printk+0x6c)
[  209.519939]  |+ end 0x8001-12 ipipe_raise_irq+0x70 (<>)
[  209.526969]  |+ func  -13 __ipipe_set_irq_pending+0x0 
(__ipipe_dispatch_irq+0xad)
[  209.535905]  |+ func  -14 __ipipe_dispatch_irq+0x0 
(ipipe_raise_irq+0x7e)
[  209.544148]  |+ begin   0x8001-14 ipipe_raise_irq+0x64 (<>)
[  209.551178]   + func  -15 ipipe_raise_irq+0x0 
(__ipipe_log_printk+0x84)
[  209.559250]  |+ end 0x8001-15 
__ipipe_spin_unlock_irqrestore+0x4f (<>)
[  209.567581]  |# func  -15 __ipipe_spin_unlock_irqrestore+0x0 
(__ipipe_log_printk+0x69)
[  209.576951]  |+ begin   0x8001-17 __ipipe_spin_lock_irqsave+0x5e 
(<>)
[  209.584847]   + func  -18 __ipipe_spin_lock_irqsave+0x0 
(__ipipe_log_printk+0x22)
[  2

RE: Deadlock during debugging

[Lange Norbert via Xenomai]

One more,

Note that there seem to be quite different reports, from a recursive fault to 
some threads getting marked as "runaway".
I can reproduce the issue now easily, but its proprietary software I cant reach 
around.

Norbert

[  226.354729] I-pipe: Detected stalled head domain, probably caused by a bug.
[  226.354729] A critical section may have been left unterminated.
[  226.370156] CPU: 1 PID: 0 Comm: swapper/2 Tainted: GW 
4.19.84-xenod8-static #1
[  226.370160] CPU: 2 PID: 732 Comm: fup.fast Tainted: GW 
4.19.84-xenod8-static #1
[  226.378775] Hardware name: TQ-Group TQMxE39M/Type2 - Board Product Name, 
BIOS 5.12.30.21.16 01/31/2019
[  226.387475] Hardware name: TQ-Group TQMxE39M/Type2 - Board Product Name, 
BIOS 5.12.30.21.16 01/31/2019
[  226.396782] I-pipe domain: Linux
[  226.406089] I-pipe domain: Linux
[  226.409320] RIP: 0010:do_idle+0xaf/0x140
[  226.412549] Call Trace:
[  226.416476] Code: 85 92 00 00 00 e8 51 f5 04 00 e8 bc 65 03 00 e8 77 36 7c 
00 f0 80 4d 02 20 9c 58 f6 c4 02 74 7e e8 66 2d 07 00 48 85 c0 74 6b <0f> 0b e8 
0a 42 07 00 e8 45 68 03 00 9c 58 f6 c4 02 0f 85 79 ff ff
[  226.418936]  dump_stack+0x8c/0xc0
[  226.437687] RSP: 0018:932cc00afef8 EFLAGS: 00010002
[  226.441009]  ipipe_root_only.cold+0x11/0x32
[  226.446240]  ipipe_stall_root+0xe/0x60
[  226.450424] RAX: 0001 RBX: 0002 RCX: 000b
[  226.454182]  __ipipe_trap_prologue+0x2ae/0x2f0
[  226.461319] RDX: a3fc RSI: 8f63f99c8208 RDI: 
[  226.465767]  ? __ipipe_complete_domain_migration+0x40/0x40
[  226.472899] RBP: 8f63f815a7c0 R08:  R09: 0002e248
[  226.478386]  invalid_op+0x26/0x51
[  226.485518] R10: 00015800 R11: 003480cf3801 R12: 8f63f815a7c0
[  226.488839] RIP: 0010:xnthread_suspend+0x3ef/0x540
[  226.495973] R13:  R14:  R15: 
[  226.500766] Code: 58 12 00 00 4c 89 e7 e8 ef ca ff ff 41 83 8c 24 c4 11 00 
00 01 e9 82 fd ff ff 0f 0b 48 83 bf 58 12 00 00 00 0f 84 49 fc ff ff <0f> 0b 0f 
0b 9c 58 f6 c4 02 0f 84 85 fd ff ff fa bf 00 00 00 80 e8
[  226.507900] FS:  () GS:8f63f980() 
knlGS:
[  226.52] RSP: 0018:932cc083bd60 EFLAGS: 00010082
[  226.534755] CS:  0010 DS:  ES:  CR0: 80050033
[  226.539986] CR2: 7ff8dca27000 CR3: 000174c54000 CR4: 003406e0
[  226.545738] RAX: 932cc0617e30 RBX: 00025090 RCX: 
[  226.552870] Call Trace:
[  226.560005] RDX:  RSI: 0002 RDI: 932cc0616240
[  226.562461]  cpu_startup_entry+0x6f/0x80
[  226.569590] RBP: 932cc0617e08 R08: 932cc0617e08 R09: 0005cc88
[  226.573520]  start_secondary+0x169/0x1b0
[  226.580655] R10:  R11:  R12: 932cc0616240
[  226.584585]  secondary_startup_64+0xa4/0xb0
[  226.591716] R13:  R14:  R15: 932cc0617e08
[  226.595905] ---[ end trace aa5dc96dbf303c58 ]---
[  226.603042]  xnsynch_sleep_on+0x117/0x2d0
[  226.611670]  __cobalt_cond_wait_prologue+0x29f/0x950
[  226.616647]  ? __cobalt_cond_wait_prologue+0x950/0x950
[  226.621798]  CoBaLt_cond_wait_prologue+0x23/0x30
[  226.626425]  handle_head_syscall+0xe1/0x370
[  226.630618]  ipipe_fastcall_hook+0x14/0x20
[  226.634724]  ipipe_handle_syscall+0x57/0xe0
[  226.638920]  do_syscall_64+0x4b/0x500
[  226.642598]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  226.647660] RIP: 0033:0x77f9c134
[  226.651244] Code: 8b 73 04 49 89 dc e8 fb ef ff ff 48 89 de 48 8b 5c 24 10 
45 31 c0 b9 23 00 00 10 48 8d 54 24 44 45 31 d2 48 89 df 89 c8 0f 05 <8b> 7c 24 
2c 31 f6 49 89 c5 89 c5 e8 cc ef ff ff 4c 89 ff e8 74 e9
[  226.670014] RSP: 002b:7fffe1a6bb10 EFLAGS: 0246 ORIG_RAX: 
1023
[  226.677599] RAX: ffda RBX: 74d91c78 RCX: 77f9c134
[  226.684744] RDX: 7fffe1a6bb54 RSI: 74d91c48 RDI: 74d91c78
[  226.691885] RBP: 7fffe1a6bc30 R08:  R09: 
[  226.699027] R10:  R11: 0246 R12: 74d91c48
[  226.706166] R13:  R14: 0001 R15: 7fffe1a6bb60
[  226.713325] I-pipe tracer log (100 points):
[  226.717520]  |*+func0 ipipe_trace_panic_freeze+0x0 
(ipipe_root_only+0xcf)
[  226.726114]  |*+func0 ipipe_root_only+0x0 
(ipipe_stall_root+0xe)
[  226.733926]  |*+func   -1 ipipe_stall_root+0x0 
(__ipipe_trap_prologue+0x2ae)
[  226.742431]  |# func   -2 ipipe_trap_hook+0x0 
(__ipipe_notify_trap+0x98)
[  226.750590]  |# func   -3 __ipipe_notify_trap+0x0 
(__ipipe_trap_prologue+0x7f)
[  226.759268]  |# func   -3 __ipipe_trap_prologue+0x0 
(invalid_op+0x26)
[  226.767167]  |# func   -5 xnthread_suspend+0x0 
(xnsynch_sleep_on+0x117)
[  226.7752

RE: Deadlock during debugging

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Montag, 18. November 2019 18:22
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Subject: Re: Deadlock during debugging
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> On 18.11.19 17:24, Lange Norbert via Xenomai wrote:
> > One more,
> >
> > Note that there seem to be quite different reports, from a recursive fault
> to some threads getting marked as "runaway".
> > I can reproduce the issue now easily, but its proprietary software I cant
> reach around.
>
> Understood. Will try to read something from the traces.
>
> This is a regression over 3.0 now, correct?

No, can't say that. I had various recurring issues with 4.9, 4.14 and 4.19 
kernels,
aswell as 3.0 and and 3.1.
It's hard to narrow down and often just vanished after a while, and my only
gut-feeling is that condition variables are involved.
I also have a couple cobalt threads *not* pinned to a single cpu.

Atleast I can now say it’s a single app causing the issue, not using rtnet or 
having additional cobalt applications running.
Since I can easily reproduce the issue, I will now try using debian's gcc-8, to 
rule out troubles with the toolchain.

Norbert.



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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: Deadlock during debugging

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Dienstag, 19. November 2019 07:51
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Subject: Re: Deadlock during debugging
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> On 18.11.19 18:31, Lange Norbert wrote:
> >
> >
> >> -Original Message-
> >> From: Jan Kiszka 
> >> Sent: Montag, 18. November 2019 18:22
> >> To: Lange Norbert ; Xenomai
> >> (xenomai@xenomai.org) 
> >> Subject: Re: Deadlock during debugging
> >>
> >> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
> >>
> >>
> >> On 18.11.19 17:24, Lange Norbert via Xenomai wrote:
> >>> One more,
> >>>
> >>> Note that there seem to be quite different reports, from a recursive
> fault
> >> to some threads getting marked as "runaway".
> >>> I can reproduce the issue now easily, but its proprietary software I cant
> >> reach around.
> >>
> >> Understood. Will try to read something from the traces.
> >>
> >> This is a regression over 3.0 now, correct?
> >
> > No, can't say that. I had various recurring issues with 4.9, 4.14 and 4.19
> kernels,
> > aswell as 3.0 and and 3.1.
> > It's hard to narrow down and often just vanished after a while, and my only
> > gut-feeling is that condition variables are involved.
> > I also have a couple cobalt threads *not* pinned to a single cpu.
>
> I'm only talking about the crash during debug - one issue after the other.

So did I, the crashes produce different logs (likely just the effect, after 
some mem corruption)
and I occasionally had these crashes for a while. So this does *not* appear to 
be a 3.1 regression,
which is why I brought these points up.

Compiling the kernel with another gcc and pinning the threads did not help BTW.

Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

urcu/lttng (Userspace) and Xenomai

[Lange Norbert via Xenomai]

Hello,

I am trying to figure out if Xenomai would work correctly with Lttng. Currently 
I haven’t figured out how the system manages buffers,
but I am checking if this would be generally applicable to Xenomai.

I’d like to know if anyone has already used Lttng UST with xenomai threads,
and if there is any need to compile lttng/liburcu for xenomai or using some 
patches.
(I haven’t seen anything that indicates it would not work).

## urcu flavours
This has a few variants, lttng uses the bulletproof one. Most others should be
faster on average – but all of them might unlock a futex with a raw syscall.

Other flavours like qsbr could likely be faster if the futex sycall would be 
replaced with a cobalt mutex
(it’s very unlikely this path is executed). Would need some work to get this 
done (and lttng to use it).

## sys_membarrier
recent kernels and liburcu versions support this syscall, which supposedly
allows removal of reader memory barriers.
The syscall will somehow interrupt the threads (all *running threads* of the 
process), which implicitly causes a barrier for readers.

Q: I guess this will *not* interrupt xenomai threads, as their shadow linux 
thread is not *running*?
Q: x86_64 accesses are strictly ordered, do you actually need membarriers at 
all?

Kind regards, Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: urcu/lttng (Userspace) and Xenomai

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Donnerstag, 21. November 2019 14:46
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Subject: Re: urcu/lttng (Userspace) and Xenomai
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> On 21.11.19 11:26, Lange Norbert via Xenomai wrote:
> > Hello,
> >
> > I am trying to figure out if Xenomai would work correctly with Lttng.
> > Currently I haven’t figured out how the system manages buffers, but I am
> checking if this would be generally applicable to Xenomai.
> >
> > I’d like to know if anyone has already used Lttng UST with xenomai
> > threads, and if there is any need to compile lttng/liburcu for xenomai or
> using some patches.
> > (I haven’t seen anything that indicates it would not work).
> >
> > ## urcu flavours
> > This has a few variants, lttng uses the bulletproof one. Most others
> > should be faster on average – but all of them might unlock a futex with a
> raw syscall.
> >
> > Other flavours like qsbr could likely be faster if the futex sycall
> > would be replaced with a cobalt mutex (it’s very unlikely this path is
> executed). Would need some work to get this done (and lttng to use it).
> >
> > ## sys_membarrier
> > recent kernels and liburcu versions support this syscall, which
> > supposedly allows removal of reader memory barriers.
> > The syscall will somehow interrupt the threads (all *running threads* of
> the process), which implicitly causes a barrier for readers.
> >
> > Q: I guess this will *not* interrupt xenomai threads, as their shadow linux
> thread is not *running*?
> > Q: x86_64 accesses are strictly ordered, do you actually need membarriers
> at all?
> >
>
> I didn't look into details of enabling userspace lttng yet, but I had a chat 
> with
> Mathieu about this, maybe a year ago. He said back then that there is also a
> polling mode where a data collection thread is simply trying to obtain the
> trace output time-driven.

I believe that’s the "bulletproof" rcu mode that lttng uses. I don’t see any 
OS-level
synchronization in the readers, only some atomic variables.
Mathieu is a lttng dev?

> Then the producer (including cobalt threads) would
> not need any syscall at all.

In the context of lttng those are readers (of the shared rcu structures),
writes would only happen if tracepoint providers are added/removed.

But then I don’t know how the buffers are managed, this appears to
be system-wide in another process.

The sys_membarrier syscall would be called by writers (not xenomai threads) to 
additionally allow
instructions like dmb (for arm) around atomic accesses to be removed for the 
readers.
I think it's useless for x86_64 and the syscall itself would not do anything 
for running xenomai threads.
(you can only force the syscall but not disable it, without changing sources 
that is).

> As I said, that was just a conceptual discussion.
> None of us actually looked into the implementation.

Hmm, would like to test this soon. Still need a way to totally disable it 
in-case something goes wrong.. ie ugly macro magic.
Can you tell me that I am right about 
membarrier(MEMBARRIER_CMD_PRIVATE_EXPEDITED) not blocking until
the running xenomai thread had some sort of syscall synchronization?

Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

Impact and use of the membarrier syscall

[Lange Norbert via Xenomai]

Hello,

I looked at this sycall, as lttng makes use of it, and the last posts on this 
ML would imply that Xenomai is using "IPI" aswell.
This raises a few questions:


-  Could an linux app (like lttng), that uses the membarrier syscall 
create IRQs/IPIs that ultimately negative affect realtime threads?
Ie. should this be kernel config be recommended to be disabled for Xenomai.

-  Does the syscall do anything for running Xenomai threads 
(particularly, Lttng makes use of MEMBARRIER_CMD_PRIVATE_EXPEDITED).

Regards, Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

Request: offer CLOCK_HOST_MONOTONIC for systemwide tracing

[Lange Norbert via Xenomai]

Hello,

Systemwide traces would require the same clock, so Linux processes use 
CLOCK_MONOTONIC (they normally do by default),
Kernel traces should do so too (ktime_get_mono_fast_ns).
Xenomai Processes/Thread have no reliable to produce matching traces. The idea 
would be to
configure the tracing frameworks to use the new CLOCK_HOST_MONOTONIC for those.
As concrete example, Lttng would use a clock plugin (only) for Xenomai.

I looked at the kernel sources if I can add this myself quickly, but seems to 
be involve
some stuff like kevents which I know nothing about (killing the “quickly” part 
at the very least).

The request would be that
- Similar to CLOCK_HOST_REALTIME, a CLOCK_HOST_MONOTONIC would result in 
timestamps that a very close to the plain Linux CLOCK_MONOTONIC.
- This should happen without syscalls and be very efficient
- In respect to being able to attach preloaded tracer dso’s (like tracing 
malloc/free), the call should work correctly before cobalt is initialized 
(could be worked around, but still..)

Other alternatives (most not realistic):

Calling the linux vdso functions might result in deadlocks [1].

A “safe” variant like ktime_get_mono_fast_ns is not accessible per syscall or 
userspace vDSO.

The normal xenomai CLOCK_MONOTONIC is not skew corrected to REALTIME

CLOCK_MONOTONIC_RAW perhaps might be easily convertible between domains, but 
likely
problematic on several CPUs (unstable TSC, not in sync between CPUs)

As a sidenote, recent Kernels (5.3?) have a cleaned up and unified vDSO 
framework,
Potentially could grab stuff from there.

[1] - https://www.xenomai.org/pipermail/xenomai/2018-December/040134.html



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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: Request: offer CLOCK_HOST_MONOTONIC for systemwide tracing

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Mittwoch, 27. November 2019 18:06
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Cc: mathieu.desnoy...@efficios.com
> Subject: Re: Request: offer CLOCK_HOST_MONOTONIC for systemwide
> tracing
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> On 27.11.19 17:20, Lange Norbert via Xenomai wrote:
> > Hello,
> >
> > Systemwide traces would require the same clock, so Linux processes use
> > CLOCK_MONOTONIC (they normally do by default), Kernel traces should
> do so too (ktime_get_mono_fast_ns).
> > Xenomai Processes/Thread have no reliable to produce matching traces.
> > The idea would be to configure the tracing frameworks to use the new
> CLOCK_HOST_MONOTONIC for those.
>
> Do we know what makes the two monotonic clock deviate? Does Linux apply
> the frequency modifications of the realtime clock on the monotonic one as
> well?

Yes it does, it leaves out the jumps but rate is adjusted.

>
> > As concrete example, Lttng would use a clock plugin (only) for Xenomai.
> >
> > I looked at the kernel sources if I can add this myself quickly, but
> > seems to be involve some stuff like kevents which I know nothing about
> (killing the “quickly” part at the very least).
> >
> > The request would be that
> > - Similar to CLOCK_HOST_REALTIME, a CLOCK_HOST_MONOTONIC would
> result in timestamps that a very close to the plain Linux CLOCK_MONOTONIC.
> > - This should happen without syscalls and be very efficient
> > - In respect to being able to attach preloaded tracer dso’s (like
> > tracing malloc/free), the call should work correctly before cobalt is
> > initialized (could be worked around, but still..)
> >
> > Other alternatives (most not realistic):
> >
> > Calling the linux vdso functions might result in deadlocks [1].
> >
> > A “safe” variant like ktime_get_mono_fast_ns is not accessible per syscall
> or userspace vDSO.
> >
> > The normal xenomai CLOCK_MONOTONIC is not skew corrected to
> REALTIME
> >
> > CLOCK_MONOTONIC_RAW perhaps might be easily convertible between
> > domains, but likely problematic on several CPUs (unstable TSC, not in
> > sync between CPUs)
>
> We do not support such CPUs with Xenomai (and they get rarer these days).

You use some specific architectural timer like rdstc on x86. The monotonic clock
could have different/switchable sources.

> >
> > As a sidenote, recent Kernels (5.3?) have a cleaned up and unified
> > vDSO framework, Potentially could grab stuff from there.
>
> If we go for hardening the kernel's gtod data updates, I guess we could also
> switch to that as source. I now wonder why that path wasn't considered back
> then, or why it wasn't possible.

Well, they are paranoid about keeping the monotonic clock monotonic.
Look at the implementation for ktime_get_mono_fast_ns,
this has a proper implementation for "safe" access, but it might violate
the monotonic property now and then.
(which would be perfectly fine for a timestamp source)

>
> Thinking longer term, synchronizing the two clock sets not just for tracing
> would likely be beneficial - PTP/TSN...

Sure, but I would keep a clock that is as simple as cobalts clock now (ie. what 
should have been
CLOCK_MONOTONIC_RAW and arguably the default),
for durations of max a couple seconds you typically need, everything else would 
be overkill.

For timestamps (and absolute waits) a synchronized clock might make sense.

Adding the interpolation values from ktime_get_mono_fast_ns to the Linux vDSO
without the usual lock (but alternating buffers, like the function does)
might be the best solution, AFAIU this time is the same as CLOCK_MONOTONIC,
 (ie. but is not "bulletproof monotonic") used for kernel traces.


Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: Moving on

[Lange Norbert via Xenomai]

> -Original Message-
> From: Xenomai  On Behalf Of Philippe
> Gerum via Xenomai
> Sent: Montag, 2. Dezember 2019 17:05
> To: Xenomai@xenomai.org
> Subject: Moving on
>
>
> It has been two years since I stepped down as Xenomai's lead maintainer.
> In the meantime, Jan took over and did a very good job in this role as
> expected.
>
> Since this transition period is now taking an end, I'm switching focus to the
> EVL project [1] I have been nurturing for some time, with the goal to make it
> production-grade next year. In a nutshell, EVL is about laying the groundwork
> for dual kernel systems to become first-class citizens of Linux. This work
> includes a SMP scalable real-time core which can be maintained with
> common kernel knowledge over the latest mainline kernel series, a standard
> driver model, and a single, compact API
>
> I will still review patches coming my way for the I-pipe ARM and arm64 trees
> for a few weeks, until the next maintainer is appointed for these
> architectures. I'll be around to help with Xenomai core issues if needed.

Doesnt seem like you will move too far away, good luck with EVL (and getting it 
upstreamed if that’s the aim).

Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

Inspecting heap allocations?

[Lange Norbert via Xenomai]

Hello,

I have some circumstances where I run out of global heap and then simple stull 
like creating a mutex fails with ENOMEM.
My suspicion is an IDDP connection between 2 processes, where 1 process might 
send a lot small packets before the other will pull them (I will try using a 
local pool).

In the future, is there a way to dump the owners of heap objects?

Mit besten Grüßen / Kind regards

NORBERT LANGE

AT-RD3

ANDRITZ HYDRO GmbH
Eibesbrunnergasse 20
1120 Vienna / AUSTRIA
p: +43 50805 56684
norbert.la...@andritz.com
andritz.com



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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

stalled head domain with 3.1rc4

[Lange Norbert via Xenomai]

Just had a bug msg pop up. Its triggered by enabling tracing, while we have 2 
processes running, using IDDP, XDDP and RTNet (just packet sockets, no ip 
stack).
Some points:

-   trace-cmd stores in tmp, so shouldn't touch other filesystems than 
tmpfs, sysfs

-   upon starting this, our process complains about a 150ms hole in CPU 
time (likely the time of the bug)

-   it seems to happen only the first time after a boot

-   running trace-cmd "dry" (without our processes) doesn't trigger the 
bug. Neither when disabling active communication on our project (per 
millisecond up to 15 eth packets in both directions via packet socket, using 
the new send/recv_mmsg calls).

-   system seems to continue stable afterwards

-   a trace is attached, not after triggering the bug (then it would just 
contain our project in error state) but showing or project with active 
communication  (ie. trace-cmd started a second time after a bug)


# trace-cmd record -e 'cobalt*'
[  160.443596] I-pipe: Detected stalled head domain, probably caused by a bug.
[  160.443596] A critical section may have been left unterminated.
[  160.457178] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.19.84-xeno8-static #1
[  160.464323] Hardware name: TQ-Group TQMxE39M/Type2 - Board Product Name, 
BIOS 5.12.30.21.20 08/05/2019
[  160.473640] I-pipe domain: Linux
[  160.476877] Call Trace:
[  160.479345]  dump_stack+0x8c/0xc0
[  160.482672]  ipipe_stall_root+0xc/0x30
[  160.486436]  __ipipe_trap_prologue+0x100/0x210
[  160.490894]  int3+0x45/0x70
[  160.493702] RIP: 0010:xnthread_resume+0x75/0x3a0
[  160.498329] Code: 0f eb 00 74 21 31 c0 ba 01 00 00 00 f0 0f b1 15 c5 0f eb 
00 85 c0 0f 85 db 02 00 00 4c 8b 2c 24 89 1d af 0f eb 00 4d0
[  160.517108] RSP: 0018:9934400a7dd8 EFLAGS: 0046
[  160.522349] RAX: 0001 RBX: 0001 RCX: 7f37aa603700
[  160.529490] RDX: 0001 RSI: 0080 RDI: 9934405dc240
[  160.536631] RBP: 9934405dc240 R08: 000f7df7 R09: 9140f8cb2800
[  160.543774] R10: 03b3 R11: 000b8c4a R12: 00025090
[  160.550918] R13: 0003 R14: 0080 R15: 0080
[  160.558064]  ? xnthread_resume+0x75/0x3a0
[  160.562083]  ? xnthread_resume+0x1f/0x3a0
[  160.566104]  ipipe_migration_hook+0xda/0x1d0
[  160.570385]  complete_domain_migration+0x79/0xe0
[  160.575011]  __ipipe_switch_tail+0x39/0x50
[  160.579118]  __schedule+0x2d0/0x890
[  160.582615]  schedule_idle+0x28/0x40
[  160.586203]  do_idle+0x101/0x130
[  160.589440]  cpu_startup_entry+0x6f/0x80
[  160.593373]  start_secondary+0x169/0x1b0
[  160.597312]  secondary_startup_64+0xa4/0xb0



Mit besten Grüßen / Kind regards

NORBERT LANGE

AT-RD3

ANDRITZ HYDRO GmbH
Eibesbrunnergasse 20
1120 Vienna / AUSTRIA
p: +43 50805 56684
norbert.la...@andritz.com
andritz.com



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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

-- next part --
A non-text attachment was scrubbed...
Name: trace.dat.xz
Type: application/octet-stream
Size: 2775472 bytes
Desc: trace.dat.xz
URL: 

RE: stalled head domain with 3.1rc4

[Lange Norbert via Xenomai]

Added the trace starting 1 second before the bug (might help you more).
(last one was the same trace cut at the time of the bug)

> -Original Message-
> From: Lange Norbert 
> Sent: Freitag, 13. Dezember 2019 11:54
> To: Lange Norbert 
> Cc: Philippe Gerum (r...@xenomai.org) 
> Subject: RE: stalled head domain with 3.1rc4
>
> I now removed calls to recv/send_mmsg and instead call the single *msg
> variant in a loop. This makes the bug appear less,
> but it now triggered once when stopping the trace, so there might be goods
> in there for you.
> (the last sendmsg/recvmsg pair at 1842.622889 -> 1842.622956  is the IDDP
> socket to wakeup the other process)
>
> [ 1842.420470] I-pipe: Detected stalled head domain, probably caused by a
> bug.
> [ 1842.420470] A critical section may have been left unterminated.
> [ 1842.434053] CPU: 0 PID: 1353 Comm: trace-cmd Not tainted 4.19.84-xeno8-
> static #1
> [ 1842.441456] Hardware name: TQ-Group TQMxE39M/Type2 - Board
> Product Name, BIOS 5.12.30.21.20 08/05/2019
> [ 1842.450773] I-pipe domain: Linux
> [ 1842.454014] Call Trace:
> [ 1842.456472]  
> [ 1842.458502]  dump_stack+0x8c/0xc0
> [ 1842.461829]  ipipe_stall_root+0xc/0x30
> [ 1842.465591]  __ipipe_trap_prologue+0x100/0x210
> [ 1842.470045]  int3+0x45/0x70
> [ 1842.472854] RIP: 0010:xntimer_start+0x3a/0x330
> [ 1842.477308] Code: 55 49 89 d5 41 54 55 48 89 fd 53 48 83 ec 10 48 8b 47 70 
> 4c
> 8b 37 48 63 40 18 4d 8b a6 90 00 00 00 4c 03 24 c5 00 d3f
> [ 1842.496083] RSP: 0018:8fe9fba03e80 EFLAGS: 0082
> [ 1842.501324] RAX:  RBX: 00025090 RCX:
> 
> [ 1842.508468] RDX:  RSI: 0003b55f RDI:
> 8fe9fba305c8
> [ 1842.515609] RBP: 8fe9fba305c8 R08:  R09:
> 01acc52f873d
> [ 1842.522754] R10: 01acc52b974d R11: 01acc52b974d R12:
> 8fe9fba3aee0
> [ 1842.529898] R13:  R14: b223bbe0 R15:
> 0003b55f
> [ 1842.537044]  ? xntimer_start+0x3a/0x330
> [ 1842.540889]  ? enqueue_hrtimer+0x36/0x90
> [ 1842.544823]  program_htick_shot+0x83/0x100
> [ 1842.548931]  clockevents_program_event+0x88/0xe0
> [ 1842.553561]  hrtimer_interrupt+0x140/0x230
> [ 1842.557669]  smp_apic_timer_interrupt+0x46/0x110
> [ 1842.562296]  __ipipe_do_sync_stage+0x130/0x180
> [ 1842.566751]  __ipipe_handle_irq+0x94/0x200
> [ 1842.570860]  apic_timer_interrupt+0x12/0x40
> [ 1842.575054]  
> [ 1842.577163] RIP: 0010:smp_call_function_many+0x1b6/0x250
> [ 1842.582485] Code: e8 6f a0 6b 00 3b 05 dd 60 01 01 89 c7 0f 83 c4 fe ff ff 
> 48
> 63 c7 48 8b 0b 48 03 0c c5 00 d3 11 b2 8b 41 18 a8 01 745
> [ 1842.601264] RSP: 0018:957380bbfba8 EFLAGS: 0202 ORIG_RAX:
> ff13
> [ 1842.608846] RAX: 0003 RBX: 8fe9fba34ac0 RCX:
> 8fe9fbbb8680
> [ 1842.615989] RDX: 0001 RSI:  RDI:
> 0003
> [ 1842.623133] RBP: b12179a0 R08: 8fe9fba34ac8 R09:
> 
> [ 1842.630276] R10: 000a R11: f000 R12:
> 
> [ 1842.637417] R13: 8fe9fba34ac8 R14: 0004 R15:
> 0001
> [ 1842.644565]  ? optimize_nops.isra.0+0x90/0x90
> [ 1842.648934]  ? smp_call_function_many+0x191/0x250
> [ 1842.653650]  ? optimize_nops.isra.0+0x90/0x90
> [ 1842.658015]  ? xntimer_start+0x39/0x330
> [ 1842.661859]  ? xntimer_start+0x3a/0x330
> [ 1842.665705]  on_each_cpu+0x28/0x50
> [ 1842.669116]  ? xntimer_start+0x39/0x330
> [ 1842.672959]  text_poke_bp+0x91/0xde
> [ 1842.676460]  __jump_label_transform.isra.0+0x102/0x150
> [ 1842.681610]  arch_jump_label_transform+0x2e/0x40
> [ 1842.686239]  __jump_label_update+0x67/0xa0
> [ 1842.690348]  __static_key_slow_dec_cpuslocked+0x30/0x80
> [ 1842.695583]  static_key_slow_dec+0x23/0x50
> [ 1842.699689]  tracepoint_probe_unregister+0x176/0x1b0
> [ 1842.704661]  trace_event_reg+0x31/0xa0
> [ 1842.708421]  ? mutex_lock+0x13/0x30
> [ 1842.711921]  __ftrace_event_enable_disable+0x120/0x230
> [ 1842.717072]  __ftrace_set_clr_event_nolock+0xe6/0x130
> [ 1842.722133]  system_enable_write+0xaa/0xe0
> [ 1842.726240]  __vfs_write+0x34/0x190
> [ 1842.729739]  ? __check_heap_object+0x5/0x120
> [ 1842.734021]  ? __check_object_size+0x136/0x147
> [ 1842.738474]  ? rcu_all_qs+0x5/0x80
> [ 1842.741884]  vfs_write+0xb6/0x190
> [ 1842.745210]  ksys_write+0x57/0xd0
> [ 1842.748537]  do_syscall_64+0x78/0x3c0
> [ 1842.752212]  ? __do_page_fault+0x207/0x400
> [ 1842.756319]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 1842.761381] RIP: 0033:0x45f5d9
> [ 1842.76] Code: 89 d6 0f 05 c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 
> f8
> 4d 89 c2 48 89 f7 4d 89 c8 48 89