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

[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]

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] 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
 >>>
 >>>
 >>>
 >
 >#
 >>>
 >>> 

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

[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] 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

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

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(, 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 

[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] 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 <norbert.la...@andritz.com>:
 >
 >> 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 bo

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]

>- 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] 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, , sizeof(saddr)) < 0)
+  if (bind(sockfd, (struct sockaddr *), 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, , );
+  ret = recvfrom(sockfd, buf, blen - 1, 0, (struct 
sockaddr *), );
   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

[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, ));
 }
--
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(, );

}



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 <nolang...@gmail.com>
Sent: Montag, 23. April 2018 16:24
To: xenomai@xenomai.org
Cc: Lange Norbert <norbert.la...@andritz.com>
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 <norbert.la...@andritz.com>
---
 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(, );
 #else
xenomai_init(, );
 #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(, , 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();
+   con

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] 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

[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, );
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

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

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 

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

RE: Cobalt Preemption of kernel update_fast_timekeeper can cause deadlocks

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Donnerstag, 20. Dezember 2018 14:33
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Subject: Re: Cobalt Preemption of kernel update_fast_timekeeper can cause
> deadlocks
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 20.12.18 13:29, Lange Norbert via Xenomai wrote:
> >> On 19.12.18 19:26, Auel, Kendall via Xenomai wrote:
> >>> Jan,
> >>>
> >>> I'm very much in favor of providing a way to prevent Xenomai modules
> >> from using features which can result in deadlock, if there is a clean
> >> way to detect such a situation.
> >>>
> >>> We used gettimeofday in one of our modules and it mostly worked
> great.
> >> But once in a great while the system would deadlock. Most calls to
> >> gettimeofday are benign and appear to work normally, which is why it
> >> is especially problematic. It would have saved some debug cycles if
> >> there was a kernel log message to warn us of our danger.
> >>>
> >>> Or perhaps we could collect a blacklist of references which will
> >>> produce
> >> warnings when linking a Xenomai module. All of these things are 'nice
> >> to have' but certainly not urgent matters.
> >>
> >> We do have the infrastructure and a small use case for such RT traps
> already:
> >> If you use --mode-check on xeno-config, any usage of malloc and free
> >> from RT contexts will be detected and reported. These calls are evil
> >> as well because they tend no not trigger a syscall in the fast path
> >> and only fail on contention or empty-pool situations of the userspace
> allocator.
> >
> > There is still the issue that the cobald kernel can interrupt the
> > linux kernel while holding a lock.
> > Consider the case that you have a 4 core CPU, several cobalt threads are
> bound to eg. Core 0 (legacy code assuming single core).
> >
> > 1) linux wants to update the timekeeper struct
> > 2) now cobalt preempts the linux kernel while holding the lock on Core
> > 0
> > 3) the cobalt threads run close to each other and thus Core 0 remains in
> cobalt domain for hundreds of ms.
> > 4) finally all cobalt threads (that are bound to core 0) idle and
> > linux can free the lock
> >
> > This means that all Linux threads on *any core* that try to call some
> *gettime functions (possible others) will busywait on the lock.
> >
>
> You do not need to look at the GTOD lock to construct such delays: every
> Linux spinlock taken on one core that is then interrupted by RT workload for
> a longer period can delay other cores doing Linux stuff that needs that lock.
> That is a generic property of the co-kernel architecture - and the reason you
> should allow Linux to run every few ms, on *every* core.

You are right, I did not realize that.
Userspace usually does not spinlock, so I consider those functions a lot more 
critical,
clock_gettime is also heavily used (especially for tracing).

Funny enough, the linux x86 vdso handles clock_gettime(CLOCK_MONOTONIC) but not 
clock_gettime(CLOCK_MONOTONIC_RAW).
Seems the common denominator would be to use rdtsc directly =/
(I know about the pitfalls, but our hardware should have a stable, invariant 
tsc)

>
> > That a rt thread (potentially just temporary promoted non-rt thread, or not
> lazily demoted yet) can additionally deadlock the system sits just on top of
> this issue.
> >
> > Regarding to what I am allowed to do:
> > AFAIK a thread started as cobalt thread can freely switch between
> domains, typically around syscalls and the switches are "lazy". What are the
> rules for a thread that needs to collect some data RT (potentially using some
> RT Mutexes with prio inheritance) calling into DSOs that aren’t compiled with
> the "cobalt wrappings" active (say a logging framework that uses libcs
> clock_gettime).
> > Do I manually have to demote the thread somehow before calling DSO
> functions, is it not allowed at all to use DSOs that were compiled with 
> "cobalt
> wrappings"?
>
> If you are calling into an "unknown" non-RT blob, dropping from RT may
> actually be required. We do not promote explicit mode switches because
> they are not needed if you control (wrap) all your code. This might be  an
> exception.

The non-RT "blob" is the regular linux rootfs in my case, ie. libstdc++ and I 
plan
to use libnttg-ust and stuff like xml parsers.
I understand this as motivation to actually *have* the POSIX

RE: Cobalt Preemption of kernel update_fast_timekeeper can cause deadlocks

[Lange Norbert via Xenomai]

> On 19.12.18 19:26, Auel, Kendall via Xenomai wrote:
> > Jan,
> >
> > I'm very much in favor of providing a way to prevent Xenomai modules
> from using features which can result in deadlock, if there is a clean way to
> detect such a situation.
> >
> > We used gettimeofday in one of our modules and it mostly worked great.
> But once in a great while the system would deadlock. Most calls to
> gettimeofday are benign and appear to work normally, which is why it is
> especially problematic. It would have saved some debug cycles if there was a
> kernel log message to warn us of our danger.
> >
> > Or perhaps we could collect a blacklist of references which will produce
> warnings when linking a Xenomai module. All of these things are 'nice to
> have' but certainly not urgent matters.
>
> We do have the infrastructure and a small use case for such RT traps already:
> If you use --mode-check on xeno-config, any usage of malloc and free from
> RT contexts will be detected and reported. These calls are evil as well
> because they tend no not trigger a syscall in the fast path and only fail on
> contention or empty-pool situations of the userspace allocator.

There is still the issue that the cobald kernel can interrupt the linux kernel
while holding a lock.
Consider the case that you have a 4 core CPU, several cobalt threads are bound 
to eg. Core 0 (legacy code assuming single core).

1) linux wants to update the timekeeper struct
2) now cobalt preempts the linux kernel while holding the lock on Core 0
3) the cobalt threads run close to each other and thus Core 0 remains in cobalt 
domain for hundreds of ms.
4) finally all cobalt threads (that are bound to core 0) idle and linux can 
free the lock

This means that all Linux threads on *any core* that try to call some *gettime 
functions (possible others) will busywait on the lock.

That a rt thread (potentially just temporary promoted non-rt thread, or not 
lazily demoted yet) can additionally deadlock the system sits just on top of 
this issue.

Regarding to what I am allowed to do:
AFAIK a thread started as cobalt thread can freely switch between domains, 
typically around syscalls and the switches are "lazy". What are the rules for a 
thread that needs to collect some data RT (potentially using some RT Mutexes 
with prio inheritance) calling into DSOs that aren’t compiled with the "cobalt 
wrappings" active (say a logging framework that uses libcs clock_gettime).
Do I manually have to demote the thread somehow before calling DSO functions, 
is it not allowed at all to use DSOs that were compiled with "cobalt wrappings"?

> with posix, you are already
> redirected to the RT-safe implementations of those functions.

In my case (posix skin, not "native" as I replied earlier), the call came from 
another DSO which is unaffected by the
link-time wrapping.
I would likely have to LD_PRELOAD a checker DSO, seems more sane to me,
as the calls could originate from implicitly linked DSO aswell (C++ runtime 
library)

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 Preemption of kernel update_fast_timekeeper can cause deadlocks

[Lange Norbert via Xenomai]

> >>
> >> If you are calling into an "unknown" non-RT blob, dropping from RT
> >> may actually be required. We do not promote explicit mode switches
> >> because they are not needed if you control (wrap) all your code. This
> >> might be  an exception.
> >
> > The non-RT "blob" is the regular linux rootfs in my case, ie.
> > libstdc++ and I plan to use libnttg-ust and stuff like xml parsers.
>
> That's all fine - as long as you are not in RT context.

To make sure I am not in RT Context needs alot knowledge of callstacks.
Easy to do if you create the code from scratch, not so easy if you are porting.

>
> Actually, if you use a SCHED_WEAK thread for calling into both RT and non-
> RT, you will not have to do the explicit switching because those threads fall
> back to non-RT as soon as they have no RT business (lock ownership or
> blocking) anymore, and then you are safe.

Thanks for clearing up another misunderstanding.

> >>
>
> >>
> >> Irrespective of that, I would definitely be interested in a
> >> LD_PRELOAD-based checker that you can attach to an application
> >> easily, without the need to switch to link-time wrapping (which is not
> needed with non-posix skins).
> >
> > If you don’t know lttng-ust, you could spend a hour or two playing
> > with it, Eg you can interpose and trace any malloc/free by just preloading
> the wrapper:
> > LD_PRELOAD=liblttng-ust-libc-wrapper your_app
> >
> > This could help with non-posix skins mixing with dangerous other functions
> aswell.
>
> It takes more than that if you look at how we decide whether to raise an
> alarm or not (context detection, warning flag evaluation, signal raising). 
> lttng-
> ust can be a nice tracing tool, but for a runtime equivalent to --mode-check, 
> I
> would rather set up a tool that behaves like the link-time version.

It does not take a lot, I had a stab at writing a preload checker for 
clock_gettime that bugged me a long time (most time was spent figuring out I 
have to enable PTHREAD_WARNSW for anything to happen).
Most function could be done similarly. Malloc/free are tricky as the dl loading 
might call those functions,
Packages like lttng already solved those issues, which was the point I was 
trying to make.

With such checkers you can find issues related to external DSOs, something the 
linker tricks won't be able to.

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 --
An embedded and charset-unspecified text was scrubbed...
Name: cobalt_preload_helper.c
URL: 

RE: improve and provide a header for bootstrapping

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Dienstag, 4. Dezember 2018 18:59
> To: Lange Norbert 
> Cc: Xenomai ; Philippe Gerum
> 
> Subject: Re: improve and provide a header for bootstrapping
>
> 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.12.18 18:21, Lange Norbert wrote:
> >
> >
> >> -Original Message-
> >> From: Jan Kiszka 
> >> Sent: Dienstag, 4. Dezember 2018 17:30
> >> To: Lange Norbert 
> >> Cc: Xenomai ; Philippe Gerum
> 
> >> Subject: Re: improve and provide a header for bootstrapping
> >>
> >> 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.12.18 16:53, Lange Norbert wrote:
> >>> So any update on this.
> >>> Do you have something similar to patchwork to keep up on those loose
> >> email-threads?
> >>>
> >>
> >> This was less a patch tracking issue than the missing decision how to
> >> address the topic.
> >
> > I understand that, but there is still a lack of feedback. (And I
> > already brought that topic up some months ago, so there is some
> redundancy explaining it again).
>
> Just saw your first round from April which didn't get any feedback at all - 
> not
> optimal, I agree.

Some public issue tracker would be badly needed IMHO
>
> >
> >> On the one hand, I see a desire to control bootstrapping in more
> >> details. On the other hand, I wonder how much *additional* control is
> >> practically needed - did you study --no-auto-init sufficiently? And I
> >> wonder how much new interfaces we want to open up that way.
> >
> > Yes I know --no-auto-init, but that’s only one side of the story. What
> > are you doing in place of auto-init?
>
> Call xenomai_init() - or what are you missing then?

Call it when from where? If its called manually from main, then you must not 
use xenomai from "constructor" functions (global C++ object initializers). And 
its slightly different for DSOs.

What I would want is a template for this, like aa minimum:

__bootstrap_ctor static void xenomai_bootstrap(void)
{
#ifdef _XENOMAI_BOOTSTRAP_DSO
xenomai_init_dso(...);
#else
xenomai_init();
#endif
}

__bootstrap_ctor, xenomai_init_dso, xenomai_init all are interface details,
that would fit best in an upstream header.

>
> > To me, the most sensible approach is to place building blocks in the
> > xenomai Headers and libraries.
> >
> > *   parsing of the commandline args got moved from the bootstrap
> (lib/boilerplate/init/bootstrap.c)
> >  to the DSO. Don’t want to replicate this everywhere
>
> Are you using command line paramete - main funtionrs to tune the Xenomai core?

No, and *I* don’t want to. The larger context is 
https://github.com/nolange/cmake_xenomai/tree/master/patchset,
I would want to have CMake support, which should include the existing usecases.

The aim would be to have CMake automatically use the right bootstrap method,
And be agnostic to compiler settings (means I would want to compile the 
boostrap code
identical to the rest of the application).

>
> > *   the setup code from bootstrapping is separated from the main wrapping
> magic (currently this is either both or none)
> >  That’s currently done with a header, as quite frankly proving object 
> > code
> does not scale well with compilerflags and options.
> >
> > What I generally want is to easily add the setup code into an application,
> while avoiding the additional wrapping magic.
> > The cause of action is either to do everything myself or try to modulize the
> upstream bootstrapping.
> >
> > In terms of external interfaces, only 'xenomai_init_fetchargv' would be
> added to libcobalt/libmercury.
> > A second function 'xenomai_bootstrap_getargv' is defined by the
> > bootstrapping code, to be consumed by the application (or can be ignored).
>
> In fact, the other reason I'm reluctant to create new interfaces here is that 
> I
> don't believe hooking into the command line of the main process is a good
> interface for a library like Xenomai in the first place. We had problems with
> that before, and I would rather like to think about moving away from it.
> Without all that parameter parsing, xenomai_init would take void as
> arguments, and we had no need for moving code around here.

How about backwards compatibility (otherwise I agree)?
I was trying to stay 100% compatible with the old

RE: HelloWorld with CMake

[Lange Norbert via Xenomai]

> -Original Message-
> From: Xenomai  On Behalf Of Evandro
> Sestrem via Xenomai
> Sent: Dienstag, 4. Dezember 2018 12:40
> To: xenomai@xenomai.org
> Subject: HelloWorld with CMake
>
> ** cmake_xenomai attempt **
> -
> I also tried to use the cmake_xenomai github project:
> git clone https://github.com/nolange/cmake_xenomai
>
> But when I check the patch:
> git apply --check
> /home/pi/cmake_xenomai/patchset/0001-add-an-flexible-bootstrap-
> template-header.patch
>
> I got these errors, so I didn't applied it:
> error: include/xenomai/Makefile.am: no such file or directory
> error: include/xenomai/init.h: no such file or directory
> error: lib/boilerplate/init/Makefile.am: no such file or directory
> error: lib/boilerplate/init/bootstrap.c: no such file or directory
>
>
> Evandro Sestrem

I did rebased that patchset on the latest stable branch, but you probably tried 
to apply it in the wrong directory?

You are supposed to
*) change to  the xenomai  sources directoy
*) apply those patches
for p in PATH_TO/xeno_cmake/patchset/*; do git am $p; done
*) configure, build and install xenomai.

After that CMake support should be  either automatic (if you installed Xenomai 
in your root/sysroot),
or you can specifiy the location with 'cmake -DXenomai_DIR='.

An empty project is available here:
https://github.com/nolange/cmake_xenomai/tree/master/examples/template

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: improve and provide a header for bootstrapping

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Dienstag, 4. Dezember 2018 17:30
> To: Lange Norbert 
> Cc: Xenomai ; Philippe Gerum
> 
> Subject: Re: improve and provide a header for bootstrapping
>
> 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.12.18 16:53, Lange Norbert wrote:
> > So any update on this.
> > Do you have something similar to patchwork to keep up on those loose
> email-threads?
> >
>
> This was less a patch tracking issue than the missing decision how to address
> the topic.

I understand that, but there is still a lack of feedback. (And I already 
brought that topic
up some months ago, so there is some redundancy explaining it again).

> On the one hand, I see a desire to control bootstrapping in more details. On
> the other hand, I wonder how much *additional* control is practically
> needed - did you study --no-auto-init sufficiently? And I wonder how much
> new interfaces we want to open up that way.

Yes I know --no-auto-init, but that’s only one side of the story. What are you 
doing
in place of auto-init?
To me, the most sensible approach is to place building blocks in the xenomai
Headers and libraries.

*   parsing of the commandline args got moved from the bootstrap 
(lib/boilerplate/init/bootstrap.c)
to the DSO. Don’t want to replicate this everywhere
*   the setup code from bootstrapping is separated from the main wrapping magic 
(currently this is either both or none)
That’s currently done with a header, as quite frankly proving object code 
does not scale well with compilerflags and options.

What I generally want is to easily add the setup code into an application, 
while avoiding the additional wrapping magic.
The cause of action is either to do everything myself or try to modulize the 
upstream bootstrapping.

In terms of external interfaces, only 'xenomai_init_fetchargv' would be added 
to libcobalt/libmercury.
A second function 'xenomai_bootstrap_getargv' is defined by the bootstrapping 
code,
to be consumed by the application (or can be ignored).

>
> Providing a user interface based on larger code templates does not make me
> feel comfortable at all. That's why I'm reluctant to move into that direction.
>
> Philippe is busy these days, but maybe later he - as the original designer of
> this code - can comment on the envisioned use cases and potential
> limitations.

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: improve and provide a header for bootstrapping

[Lange Norbert via Xenomai]

So any update on this.
Do you have something similar to patchwork to keep up on those loose 
email-threads?

Norbert

> -Original Message-
> From: Xenomai  On Behalf Of Norbert
> Lange
> Sent: Freitag, 26. Oktober 2018 18:36
> To: jan.kis...@siemens.com
> Cc: Xenomai 
> Subject: Re: improve and provide a header for bootstrapping
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> Am Fr., 26. Okt. 2018 um 15:48 Uhr schrieb Jan Kiszka
> :
> >
> > On 23.10.18 16:16, Norbert Lange wrote:
> > > Hello,
> > >
> > > the following patches allow a variety of options additional to the
> > > linker magic involved for hijacking the aplications main function.
> > >
> > > the original method will still continue to work, differences are
> > >
> > > *   the code dealing with retrieving the commandline arguments
> > >  is moved into libcobale/libmercury. Making the necessary per-
> application
> > >  code much smaller.
> > >
> > > *   the implementation was moved into a header, with several macros
> > >  controlling functionality (not everyone wants to define a main
> function).
> > >
> > >
> > > The approach I use personally is to compile and link my own
> > > bootstrap code, which is preferable in many build systems as
> > > source-files are understood while objects files generally need some
> > > special care. (And it cant hurt if the compiler flags match exactly).
> > >
> > > As example:
> > >
> > > - add this to your file  containing main
> > >
> > > int xenomai_init_getargv(int *argc, char *const** argv);
> > >
> > > int main(int argc, char *const argv[]) { #if defined(__COBALT__) ||
> > > defined(__MERCURY__)
> > >  xenomai_init_getargv(, ); #endif
> > >   
> > > }
> > >
> > > - create another file, lets call it mybootstrap.c
> > >
> > > #define _XENOMAI_BOOTSTRAP_GLIBC_CONSTRUCTORS
> > > #include 
> > >
> > > --
> > >
> > > Norbert
> > >
> > > [PATCH 1/2] separate bootstrap code to get commandline, move it into
> > > [PATCH 2/2] add a header to create flexible bootstrap code
> > >
> > >
> >
> > I need to look more carefully at the details and your use case, but my
> > first impression is that at least patch 2 is not very beautiful due to
> > that large template header. Could you explain again why explicitly
> > calling the bootstrap code in a library is not sufficient?
>
> Just so that we are on the same page, the bootstrap code thats generated
> looks like this (in a couple variants):
> 
> #include 
>
> static int early_argc;
> static char *const *early_argv;
>
> int xenomai_bootstrap_getargv(int *argc, char *const** argv) { if
> (early_argc) { *argc = early_argc; *argv = early_argv; return 1; } return 0; }
>
> __bootstrap_ctor static void xenomai_bootstrap(void) { char *const *argv;
> int argc; if (xenomai_init_fetchargv(, ) != 0) return;
> xenomai_init(, ); early_argc = argc; early_argv = argv; }
> --
>
> I believe what you meant with bootstrap code is called with 'xenomai_init',
> and I dont plan to touch or replace that.
>
> The code further replicates the code from lib/boilerplate/init/bootstrap.c,
> with the important difference, that you can chose not to define a main
> function and assorted wrappers (one of my main motivations is to
> disable/separate that).
>
> >
> > Also note that this pattern may make it harder to maintain a
> > compatible interface along updates, increasing the risk of having to
> > recompile your application, rather than just replacing some central library,
> when Xenomai changes.
>
> before Patch #2:
> your-app --links-> lib/xenomai/bootstrap.o --calls->xenomai_init
>
> after Patch #2 (and an optional variant):
> your-app --contains-> include/xenomai/bootstrap-template.h
> --calls->xenomai_init
>
> this means I need no precompiled object 'lib/xenomai/bootstrap.o', and the
> ABI to the libs has not changed.
>
> You call a large header with functions not beautiful, I would call precompiled
> objects and the linker wrapping not beautiful.
> If we are pragmatic, with Patch #2 you can pick between 2 not beautiful
> solutions =)
>
> Patch #1 is the one changing the ABI in a not BW-compatible manner (adds
> one function), but Patch #2 arguably improves on that, as the .o objects from
> a compiler have no ABI stability guarantee whatsoever.
>
> Further I can freely use no-pic/pic/pie and other ABI-changing settings, as
> there is no need to link a object with potentially incompatible ABI 
> (compiler,-
> version or settings).
>
> 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, 

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

[Lange Norbert via Xenomai]

To close this up,

is there anything expected from my side? I am not able to fix up the kernel 
side, esp. with the x32 API,
and my disagreement with long vs void*/uintptr_t likely won't end up getting us 
anywhere.

Norbert

> -Original Message-
> From: Philippe Gerum 
> Sent: Mittwoch, 17. Oktober 2018 17:27
> To: Lange Norbert ; xenomai@xenomai.org
> Subject: Re: [Xenomai] [PATCH] cobalt: fcntl uses void* instead of int
>
> 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/17/2018 01:30 PM, Lange Norbert wrote:
> >>> @@ -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*))
>
> The glibc is not involved in Cobalt calls, the Cobalt core in kernel space
> (obviously) is. In that space, a pointer always fits in a long word (it may 
> even
> be shorter in the ia32emu/x32 ABI models).
>
> >
> > 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)
> >
>
> Kernel-wise, register values are native long words.
>
> >> 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.
> >
>
> Generally speaking, having the userland interface and the kernel
> implementation disagree on some argument type is hard to justify. In
> contrast, we may want to enable long argument types right now in the fcntl
> implementation, so that we would not have to break the ABI twice to
> support them later. That would align both userland and kernel space on using
> a long type for the argument, fixing the issue you observed in the same
> move.
>
> --
> Philippe.


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

LD_PRELOAD checker for clock_gettime and consorts

[Lange Norbert via Xenomai]

Hello,

as you might know, I run into alot of troubles with realtime code calling 
clock_gettime.
This function is now a syscall on many architectures and depends on a linux 
kernel spinlock,
so a RT thread might deadlock itself when both trying to claim that lock and 
preventing the linux kernel to free it.

Usage is rather simple, the code compiles without any Cobalt/Xenomai headers.
RT-threads need to enable PTHREAD_WARNSW:
pthread_setmode_np(0, PTHREAD_WARNSW, NULL);

And the checker library needs to be preloaded:
LD_PRELOAD=libcobalt-gettime_checker.so ./yourapp -and -your -params.

Unlike the existing mode-checker, this does not need any changes to the binary,
and will also catch calls from all directly and indirectly loaded DSOs.

Other skins should be supported aswell, aslong as libcobalt is loaded (or more 
specific, the code looks for a symbol "cobalt_assert_nrt").

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

-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: libcobalt-gettime_checker.c
URL: 

FW: LD_PRELOAD checker for clock_gettime and consorts

[Lange Norbert via Xenomai]

And heres a checker for malloc/free and consorts. This one is a bit trickier 
and I have barely tested it.

> -Original Message-
> From: Xenomai  On Behalf Of Lange
> Norbert via Xenomai
> Sent: Donnerstag, 10. Jänner 2019 14:47
> To: Xenomai (xenomai@xenomai.org) 
> Subject: LD_PRELOAD checker for clock_gettime and consorts
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> Hello,
>
> as you might know, I run into alot of troubles with realtime code calling
> clock_gettime.
> This function is now a syscall on many architectures and depends on a linux
> kernel spinlock, so a RT thread might deadlock itself when both trying to
> claim that lock and preventing the linux kernel to free it.
>
> Usage is rather simple, the code compiles without any Cobalt/Xenomai
> headers.
> RT-threads need to enable PTHREAD_WARNSW:
> pthread_setmode_np(0, PTHREAD_WARNSW, NULL);
>
> And the checker library needs to be preloaded:
> LD_PRELOAD=libcobalt-gettime_checker.so ./yourapp -and -your -params.
>
> Unlike the existing mode-checker, this does not need any changes to the
> binary, and will also catch calls from all directly and indirectly loaded 
> DSOs.
>
> Other skins should be supported aswell, aslong as libcobalt is loaded (or more
> specific, the code looks for a symbol "cobalt_assert_nrt").
>
> 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
> 
> -- next part --
> An embedded and charset-unspecified text was scrubbed...
> Name: libcobalt-gettime_checker.c
> URL:
> <http://xenomai.org/pipermail/xenomai/attachments/20190110/bc2720f2/a
> ttachment.c>


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 --
An embedded and charset-unspecified text was scrubbed...
Name: libcobalt-malloc_checker.c
URL: 
<http://xenomai.org/pipermail/xenomai/attachments/20190110/4a80304a/attachment.c>

Cobalt Preemption of kernel update_fast_timekeeper can cause deadlocks

[Lange Norbert via Xenomai]

There is a deadlock issue that haunted me for several weeks,
it is caused by the kernels update of the user-visible
timekeeping structures used by the VDSO clock_gettime functions.

The kernel regularly updates a Timestamp structure, which is accessible in 
user-mode,
it does so by something akin to a rw-lock in update_fast_timekeeper.

If cobalt preempts the core during holding the lock, any thread trying to read 
the time
will continue to spin. (This alone is an issue IMHO).
If the cobalt thread itself now call the vDSO function as reader,
it will spin on the lock and block the lock from getting released.


Either the update_fast_timekeeper funtion should not be preemptible by cobalt,
or the spin-lock on reading could fallback to the syscall after a certain 
amount of retries.

The later is probably easier to implement, but then could randomly demote 
cobalt threads.
(on the other hand, this would be always a demotion on platforms without the 
vdso function)

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: Cobalt Preemption of kernel update_fast_timekeeper can cause deadlocks

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Mittwoch, 19. Dezember 2018 13:45
> To: Philippe Gerum ; Lange Norbert
> ; Xenomai (xenomai@xenomai.org)
> 
> Subject: Re: Cobalt Preemption of kernel update_fast_timekeeper can cause
> deadlocks
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 19.12.18 13:09, Philippe Gerum via Xenomai wrote:
> > On 12/19/18 11:20 AM, Lange Norbert via Xenomai wrote:
> >> There is a deadlock issue that haunted me for several weeks, it is
> >> caused by the kernels update of the user-visible timekeeping
> >> structures used by the VDSO clock_gettime functions.
> >>
> >> The kernel regularly updates a Timestamp structure, which is
> >> accessible in user-mode, it does so by something akin to a rw-lock in
> update_fast_timekeeper.
> >>
> >> If cobalt preempts the core during holding the lock, any thread
> >> trying to read the time will continue to spin. (This alone is an issue 
> >> IMHO).
> >> If the cobalt thread itself now call the vDSO function as reader, it
> >> will spin on the lock and block the lock from getting released.
> >>
> >>
> >> Either the update_fast_timekeeper funtion should not be preemptible
> >> by cobalt, or the spin-lock on reading could fallback to the syscall after 
> >> a
> certain amount of retries.
> >>
> >> The later is probably easier to implement, but then could randomly
> demote cobalt threads.
> >> (on the other hand, this would be always a demotion on platforms
> >> without the vdso function)
> >>
> >
> > update_vsyscall() is locking the write-side. If the analysis is correct, 
> > this
> patch may help at the expense of a some cycles more spent uninterruptible:
> >
> > diff --git a/arch/x86/entry/vsyscall/vsyscall_gtod.c
> > b/arch/x86/entry/vsyscall/vsyscall_gtod.c
> > index 9fb89b6e88c3..e9baa57e8385 100644
> > --- a/arch/x86/entry/vsyscall/vsyscall_gtod.c
> > +++ b/arch/x86/entry/vsyscall/vsyscall_gtod.c
> > @@ -32,11 +32,14 @@ void update_vsyscall(struct timekeeper *tk)
> >   {
> >   int vclock_mode = tk->tkr_mono.clock->archdata.vclock_mode;
> >   struct vsyscall_gtod_data *vdata = _gtod_data;
> > + unsigned long flags;
> >
> >   /* Mark the new vclock used. */
> >   BUILD_BUG_ON(VCLOCK_MAX >= 32);
> >   WRITE_ONCE(vclocks_used, READ_ONCE(vclocks_used) | (1 <<
> > vclock_mode));
> >
> > + flags = hard_cond_local_irq_save();
> > +
> >   gtod_write_begin(vdata);
> >
> >   /* copy vsyscall data */
> > @@ -77,6 +80,8 @@ void update_vsyscall(struct timekeeper *tk)
> >
> >   gtod_write_end(vdata);
> >
> > + hard_cond_local_irq_restore(flags);
> > +
> >   if (tk->tkr_mono.clock == _tsc)
> >   ipipe_update_hostrt(tk);
> >   }
> >
>
> This should rather be an application bug: An RT (Xenomai) thread is
> apparently using Linux gettimeofday & Co. (glibc) from RT context. That was
> never supported, we rather have RT services for that
> (CLOCK_HOST_REALTIME).

Any RT thread can preempt the kernel holding the write-lock. A deadlock only 
occurs if
*that* thread then tries to read-lock - true.
Keeping any number of linux threads in the reader "spin-lock" for the duration 
of the cobald mode will always happen
(I assume update_vsyscall is called regularly)

>
> We may think about detecting such cases better, though. Norbert, are you
> using native/alchemy APIs?

Native.
Btw. I thought mixing APIs is explicitly supported and one of the main features 
of Xenomai (like reading state, synchronized with RT mutexes and logging it to 
the filesystem), the existence of prio-inheritance would strongly imply that 
aswell. Otherwise, it's rather hard to guess which thread runs in the cobalt 
context, particularly it if might be just a temporal priority boost.
Compiling your own code with the "cobalt wrappers" is no issue, the deadlock 
above was caused by
Indirectly by another "linux" DSO (libstdc++).

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

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: x86_64 kernel does not start under qemu

[Lange Norbert via Xenomai]

Hello,

I have a similar issue on real hardware (cc Philippe). Can you try booting with 
notscdeadline?

Norbert


> -Original Message-
> From: Xenomai  On Behalf Of Richard
> Weinberger via Xenomai
> Sent: Mittwoch, 6. März 2019 11:17
> To: xenomai@xenomai.org; henning.sch...@siemens.com
> Subject: x86_64 kernel does not start under qemu
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> Hi!
>
> When I try to run ipipe-core-4.14.89-x86-2.patch under qemu, the kernel
> does not start.
> I does always start when only one core is used.
> It starts 9 out of 10 times when I enable KVM.
>
> The kernel seems to wait forever for an IPI in ipipe_critical_enter().
> Please find the gdb backtraces and full dmesg below.
>
> qemu command line is:
> qemu-system-x86_64 -hda disk.ext4 -nographic -kernel bzImage -append
> "root=/dev/sda panic=1 rw console=ttyS0 init=/bin/bash" -no-reboot -usb -
> m 2G -s -smp 2
>
> (gdb) thread apply all bt
>
> Thread 2 (Thread 2):
> #0  __ipipe_halt_root (use_mwait=0) at arch/x86/kernel/ipipe.c:317
> #1  0x819be70d in arch_safe_halt () at
> ./arch/x86/include/asm/irqflags.h:120
> #2  default_idle () at arch/x86/kernel/process.c:572
> #3  0x81024500 in arch_cpu_idle () at arch/x86/kernel/process.c:563
> #4  0x819beb82 in default_idle_call () at kernel/sched/idle.c:103
> #5  0x81097e1b in cpuidle_idle_call () at kernel/sched/idle.c:163
> #6  do_idle () at kernel/sched/idle.c:262
> #7  0x81097fd8 in cpu_startup_entry
> (state=CPUHP_AP_ONLINE_IDLE) at kernel/sched/idle.c:371
> #8  0x8103cf10 in start_secondary (unused=) at
> arch/x86/kernel/smpboot.c:272
> #9  0x81d5 in secondary_startup_64 () at
> arch/x86/kernel/head_64.S:240
> #10 0x in ?? ()
>
> Thread 1 (Thread 1):
> #0  ipipe_critical_enter (syncfn=0x0 ) at
> kernel/ipipe/core.c:1701
> #1  0x81102867 in ipipe_set_hooks (ipd=0x8257af80
> , enables=5) at kernel/ipipe/core.c:959
> #2  0x823d1daa in cobalt_init () at
> kernel/xenomai/posix/process.c:1546
> #3  0x823d08ba in xenomai_init () at kernel/xenomai/init.c:385
> #4  0x8100049e in do_one_initcall (fn=0x823d0506
> ) at init/main.c:833
> #5  0x823abffa in do_initcall_level (level=) at
> init/main.c:899
> #6  do_initcalls () at init/main.c:907
> #7  do_basic_setup () at init/main.c:926
> #8  kernel_init_freeable () at init/main.c:1081
> #9  0x819b8939 in kernel_init (unused=) at
> init/main.c:1008
> #10 0x81a001e6 in ret_from_fork () at arch/x86/entry/entry_64.S:405
> #11 0x in ?? ()
>
>
> [0.00] Linux version 4.14.89+ (rw@spankyham) (gcc version
> 7.3.1 20180323 [gcc-7-branch revision 258812] (SUSE Linux)) #83 SMP Tue Mar
> 5 15:12:14 CET 2019
> [0.00] Command line: root=/dev/sda panic=1 rw console=ttyS0
> init=/bin/bash
> [0.00] x86/fpu: x87 FPU will use FXSAVE
> [0.00] e820: BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x0009fbff]
> usable
> [0.00] BIOS-e820: [mem 0x0009fc00-0x0009]
> reserved
> [0.00] BIOS-e820: [mem 0x000f-0x000f]
> reserved
> [0.00] BIOS-e820: [mem 0x0010-0x7ffd]
> usable
> [0.00] BIOS-e820: [mem 0x7ffe-0x7fff]
> reserved
> [0.00] BIOS-e820: [mem 0xfffc-0x]
> reserved
> [0.00] NX (Execute Disable) protection: active
> [0.00] SMBIOS 2.8 present.
> [0.00] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> rel-1.11.0-0-g63451fc-prebuilt.qemu-project.org 04/01/2014
> [0.00] tsc: Fast TSC calibration using PIT
> [0.00] e820: last_pfn = 0x7ffe0 max_arch_pfn = 0x4
> [0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT
> [0.00] found SMP MP-table at [mem 0x000f5d40-0x000f5d4f]
> mapped at [ff200d40]
> [0.00] Scanning 1 areas for low memory corruption
> [0.00] ACPI: Early table checksum verification disabled
> [0.00] ACPI: RSDP 0x000F5B00 14 (v00 BOCHS )
> [0.00] ACPI: RSDT 0x7FFE1656 30 (v01 BOCHS
> BXPCRSDT 0001 BXPC 0001)
> [0.00] ACPI: FACP 0x7FFE14AA 74 (v01 BOCHS
> BXPCFACP 0001 BXPC 0001)
> [0.00] ACPI: DSDT 0x7FFE0040 00146A (v01 BOCHS
> BXPCDSDT 0001 BXPC 0001)
> [0.00] ACPI: FACS 0x7FFE 40
> [0.00] ACPI: APIC 0x7FFE159E 80 (v01 BOCHS
> BXPCAPIC 0001 BXPC 0001)
> [0.00] ACPI: HPET 0x7FFE161E 38 (v01 BOCHS
> BXPCHPET 0001 BXPC 0001)
> [0.00] No NUMA configuration found
> [0.00] Faking a node at [mem 0x-
> 0x7ffd]
> [0.00] NODE_DATA(0) 

Posix skin and Mutex initialisation/destruction inconsistencies

[Lange Norbert via Xenomai]

Hello,

1)
There is an inconsistency with the documentation [1], which claims that mutex 
and condition variables
need to be explicitly initialized with the *_init functions.
The implementation however checks the state via a flag and calls *_init if 
necessary, and the program below works correctly.

2)
There is some further issue, if you depend on the "lazy initialization", 
demonstrated by running the
program below with an argument. This case can happen for example if some 
subsystem was removed
before being used (never needed the lock).
In other words, the "lazy initialization" scheme is working with lock/unlock 
but not with destroy.


#include 
#include 

int main(int argc, char const *argv[]) {
pthread_mutex_t mymutex = PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP;

  if (argc == 1) {
assert(0 == pthread_mutex_lock());
assert(0 == pthread_mutex_unlock());
  }
  assert(0 == pthread_mutex_destroy());

  return 0;
}

[1] - https://gitlab.denx.de/Xenomai/xenomai/wikis/Porting_To_Xenomai_POSIX

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: smokey's fork tests hangs?

[Lange Norbert via Xenomai]

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

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

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

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

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

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

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

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

Norbert


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

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

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

[Lange Norbert via Xenomai]

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

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

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

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


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

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

[Lange Norbert via Xenomai]

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

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


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

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

smokey's fork tests hangs?

[Lange Norbert via Xenomai]

Hello,

I have problems with the fork tests, they both hang for me.

# xeno smokey --run=11 --verbose=2


# xeno smokey --run=20 --verbose=2
no leak withthread
no leak withmutex
no leak withcond
no leak withsem
no leak withnamed sem
no leak withtimer
no leak withmq


When started under gdb, the parent is running into waitpid,
The child is stuck at an innocent locking snippet [1].

#0  __lll_lock_wait_private ()
at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:63
#1  0x77ed74de in __GI___register_atfork (
prepare=0x77f5edc0 , prepare@entry=0x0,
parent=parent@entry=0x0,
child=child@entry=0x77f9f4e0 ,
dso_handle=0x77de0e5b <__lll_lock_wait_private+27>)
at register-atfork.c:40
#2  0x77faca9d in __pthread_atfork (prepare=prepare@entry=0x0,
parent=parent@entry=0x0,
child=child@entry=0x77f9f4e0 )
at pthread_atfork.c:51
#3  0x77f9f307 in __cobalt_init ()
at /home/lano/buildroot/build/xenomai/lib/cobalt/init.c:212
#4  cobalt_init () at /home/lano/buildroot/build/xenomai/lib/cobalt/init.c:252
#5  0x77f9f4fc in cobalt_fork_handler ()
at /home/lano/buildroot/build/xenomai/lib/cobalt/init.c:192
#6  0x77ed7898 in __run_fork_handlers (who=who@entry=atfork_run_child)
at register-atfork.c:134
#7  0x77e9b04a in __libc_fork () at ../sysdeps/nptl/fork.c:137
#8  0x00408d0b in ?? ()
#9  0x004051d1 in main ()

[1] - 
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/x86_64/lowlevellock.S;h=71dd740202b1d6501a2ffd929aa99cbd99a019ef;hb=1e5c5303a522764d7e9d2302a60e4a32cdb902f1


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: smokey's fork tests hangs?

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Freitag, 8. März 2019 14:59
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Subject: Re: smokey's fork tests hangs?
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 08.03.19 14:47, Lange Norbert wrote:
> >
> >>
> >> Not reproducible here with stable/3.0.x or next, and with ipipe-x86-
> 4.14.y.
> >> What are your parameters?
> >
> > Not entirely upstream, but based on ipipe-core-4.14.89-x86-2 and
> > xenomai master, the difference is contained in the rt_igb driver, which is
> not even loaded.
> > Defconfig is attached.
> >
> > I mostly suspect glibc as the relevant difference, I am using
> > glibc-2.28-69-g1e5c5303a522764d7e9d2302a60e4a32cdb902f1.
> >
> > Looking at the strace the child process 1039 is stuck at
> > FUTEX_WAIT_PRIVATE, Don’t really know how to tackle this.
>
> Is this a regression? Then try bisecting the causing commit.

Not really, I haven't ran the smokey suite often (and only for specific tests).
I use buildroot for my rootfs, so I have no easy way of swapping around glibc 
versions.
I have not encountered other issues outside of those tests.

Which version of glibc is running on your end?



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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

RE: smokey's fork tests hangs?

[Lange Norbert via Xenomai]

>
> Not reproducible here with stable/3.0.x or next, and with ipipe-x86-4.14.y.
> What are your parameters?

Not entirely upstream, but based on ipipe-core-4.14.89-x86-2 and xenomai master,
the difference is contained in the rt_igb driver, which is not even loaded.
Defconfig is attached.

I mostly suspect glibc as the relevant difference, I am using
glibc-2.28-69-g1e5c5303a522764d7e9d2302a60e4a32cdb902f1.

Looking at the strace the child process 1039 is stuck at FUTEX_WAIT_PRIVATE,
Don’t really know how to tackle this.

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: defconfig_rtnet_static
Type: application/octet-stream
Size: 13373 bytes
Desc: defconfig_rtnet_static
URL: 

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

libcopperplate.so depends on modecheck?

[Lange Norbert via Xenomai]

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

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

[Lange Norbert via Xenomai]

Thanks Phillipe,

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

Norbert

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


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

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

[Lange Norbert via Xenomai]

Thanks Phillipe,

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

Norbert

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


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

ANDRITZ HYDRO GmbH


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

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

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: 0001-remo

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: 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: 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, dissemination, dist

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();
+sigset_t sset, oset;
+sigfillset()
+sigprocmask(SIG_BLOCK, , );
 pthread_create(_thread, , printer_loop, NULL);
+sigprocmask(SIG_SETMASK, , 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: 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: [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: 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: 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(>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(>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

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

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

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

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: (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: 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), );
> > printf("Affinity: ");
> > for(unsigned i = 0; i < 256; ++i)
> > {
> > if(CPU_ISSET(i, ))
> > 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: 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), );
printf("Affinity: ");
for(unsigned i = 0; i < 256; ++i)
{
if(CPU_ISSET(i, ))
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: [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

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], ) < 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(_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 != -EBADF && 

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: 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

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: 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();

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: 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: 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]

> -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

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 

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 an in

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)
[  

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]

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)
[  

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 like with AF_

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

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

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

RE: stalled head domain with 3.1rc4

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Freitag, 13. Dezember 2019 14:13
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Subject: Re: stalled head domain with 3.1rc4
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> On 13.12.19 13:25, Lange Norbert via Xenomai wrote:
> > Same thing with panic trace enabled (another, longer trace with 4000
> > samples attached)
> >
> > [  292.743618] I-pipe: Detected stalled head domain, probably caused by a
> bug.
> > [  292.743618] A critical section may have been left unterminated.
> > [  292.757195] CPU: 0 PID: 1159 Comm: trace-cmd Tainted: GW
> 4.19.84-xeno8-static #1
> > [  292.765986] Hardware name: TQ-Group TQMxE39M/Type2 - Board
> Product
> > Name, BIOS 5.12.30.21.20 08/05/2019 [  292.775304] I-pipe domain:
> > Linux [  292.778546] Call Trace:
> > [  292.781005]  
> > [  292.783034]  dump_stack+0x8c/0xc0
> > [  292.786363]  ipipe_root_only.cold+0x11/0x32 [  292.790560]
> > ipipe_stall_root+0xe/0x60 [  292.794322]
> > __ipipe_trap_prologue+0x11d/0x2f0 [  292.798782]  int3+0x45/0x70 [
> > 292.801592] RIP: 0010:xntimer_start+0x3a/0x330 [  292.806050] 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 e3f [  292.824832] RSP:
> > 0018:97d43ac03e78 EFLAGS: 0082 [  292.830075] RAX:
> >  RBX: 00025090 RCX:  [
> > 292.837219] RDX:  RSI: 000c6130 RDI:
> > 97d43aeb0708 [  292.844367] RBP: 97d43aeb0708 R08:
> >  R09: 0027e6d0 [  292.851514] R10:
> > 0043f5344961 R11: 0043f5344961 R12: 97d43aebb020 [
> > 292.858658] R13:  R14: 9e03bca0 R15:
> > 000c6130 [  292.865804]  ? xntimer_start+0x3a/0x330 [
> > 292.869653]  program_htick_shot+0x8d/0x130 [  292.873761]
> > clockevents_program_event+0x88/0xe0
> > [  292.878392]  hrtimer_interrupt+0x140/0x230 [  292.882502]
> > smp_apic_timer_interrupt+0x46/0x110
> > [  292.887132]  __ipipe_do_sync_stage+0x15d/0x1c0 [  292.891592]
> > __ipipe_handle_irq+0xa0/0x220 [  292.895699]
> > ipipe_reschedule_interrupt+0x12/0x40
> > [  292.900412]  
> > [  292.902525] RIP: 0010:smp_call_function_many+0x1b6/0x250
> > [  292.907848] Code: e8 4f 23 6c 00 3b 05 5d 5f 01 01 89 c7 0f 83 c4
> > fe ff ff 48 63 c7 48 8b 0b 48 03 0c c5 00 e3 f1 9d 8b 41 18 a8 01 745
> > [  292.926626] RSP: 0018:ab24c0c9bb40 EFLAGS: 0202 ORIG_RAX:
> > ff15 [  292.934210] RAX: 0003 RBX:
> > 97d43aeb4c00 RCX: 97d43b2b7ac0 [  292.941357] RDX:
> > 0001 RSI:  RDI: 0001 [
> > 292.948500] RBP: 9d017b70 R08: 97d43aeb4c08 R09:
> > 0002e248 [  292.955644] R10: 97d43aeb7780 R11:
> > 97d43a003800 R12:  [  292.962789] R13:
> > 97d43aeb4c08 R14: 0004 R15: 0001 [
> > 292.969936]  ? optimize_nops.isra.0+0x90/0x90 [  292.974306]  ?
> > optimize_nops.isra.0+0x90/0x90 [  292.978673]  ?
> > xntimer_start+0x39/0x330 [  292.982519]  ? xntimer_start+0x3a/0x330 [
> > 292.986368]  on_each_cpu+0x28/0x50 [  292.989782]  ?
> > xntimer_start+0x39/0x330 [  292.993630]  text_poke_bp+0x68/0xde [
> > 292.997128]  ?
> trace_event_raw_event_cobalt_thread_suspend+0xe0/0xe0
> > [  293.003495]  __jump_label_transform.isra.0+0x102/0x150
> > [  293.008645]  arch_jump_label_transform+0x2e/0x40
> > [  293.013276]  __jump_label_update+0x67/0xa0 [  293.017382]
> > static_key_slow_inc_cpuslocked+0x75/0x80
> > [  293.022445]  static_key_slow_inc+0x16/0x20 [  293.026555]
> > tracepoint_probe_register_prio+0x1f3/0x2a0
> > [  293.031790]  ?
> > trace_event_raw_event_cobalt_thread_suspend+0xe0/0xe0
> > [  293.038155]  __ftrace_event_enable_disable+0x6f/0x230
> > [  293.043217]  __ftrace_set_clr_event_nolock+0xe6/0x130
> > [  293.048280]  system_enable_write+0xaa/0xe0 [  293.052392]
> > do_iter_write+0x140/0x180 [  293.056151]  vfs_writev+0xa6/0xf0 [
> > 293.059484]  do_writev+0x5f/0x100 [  293.062813]
> > do_syscall_64+0x82/0x4e0 [  293.066489]
> > entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > [  293.071554] RIP: 0033:0x45874c
> > [  293.074619] Code: ed 01 48 29 d0 49 83 c5 10 49 8b 55 08 48 63 dd
> > 48 29 c2 49 01 45 00 49 89 55 08 49 63 7f 78 4c 89 e0 4c 89 ee 48 898
> > [  293.093397] RSP: 002b:7ffc91a57a00 EFLAGS: 0202 ORIG_RAX:
> > 0014 [  293.100983] RAX: ffda RBX:
> > 

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: 

3.1rc4: rcu_sched self-detected stall on CPU

[Lange Norbert via Xenomai]

Got this stall, when trying to reboot. Apparently a Xenomai process can't be 
killed.

[  350.298889] rcu: INFO: rcu_sched self-detected stall on CPU
[  350.304621] rcu:2-: (20999 ticks this GP) 
idle=546/1/0x4002 softirq=9363/9363 fqs=5108
[  350.314280] rcu: (t=21000 jiffies g=26533 q=91)
[  350.319134] NMI backtrace for cpu 2
[  350.322716] CPU: 2 PID: 1 Comm: systemd Tainted: GW 
4.19.84-xeno8-static #1
[  350.331151] Hardware name: TQ-Group TQMxE39M/Type2 - Board Product Name, 
BIOS 5.12.30.21.20 08/05/2019
[  350.340542] I-pipe domain: Linux
[  350.343855] Call Trace:
[  350.346398]  
[  350.348510]  dump_stack+0x8c/0xc0
[  350.351922]  nmi_cpu_backtrace.cold+0x14/0x53
[  350.356371]  ? lapic_can_unplug_cpu.cold+0x42/0x42
[  350.361255]  nmi_trigger_cpumask_backtrace+0x7a/0x87
[  350.366314]  rcu_dump_cpu_stacks+0x86/0xbe
[  350.370507]  rcu_check_callbacks.cold+0x1fb/0x363
[  350.375318]  update_process_times+0x41/0x80
[  350.379595]  tick_sched_handle+0x34/0x50
[  350.383610]  tick_sched_timer+0x38/0x80
[  350.387540]  __hrtimer_run_queues+0xfd/0x270
[  350.391900]  ? tick_sched_do_timer+0x60/0x60
[  350.396277]  hrtimer_interrupt+0x106/0x230
[  350.400489]  smp_apic_timer_interrupt+0x46/0x110
[  350.405204]  __ipipe_do_sync_stage+0x15d/0x1c0
[  350.409748]  __ipipe_handle_irq+0xa0/0x220
[  350.413953]  apic_timer_interrupt+0x12/0x40
[  350.418225]  
[  350.420419] RIP: 0010:smp_call_function_single+0xd5/0x120
[  350.425907] Code: 00 00 75 5d 48 8d 65 e8 5b 41 5c 41 5d 5d c3 48 8d 74 24 
20 4c 89 e2 4c 89 e9 e8 56 fe ff ff 8b 54 24 38 83 e2 01 74 0b f3 90 <8b> 54 24 
38 83 e2 01 75 f5 eb bf 89 7c 24 1c e8 87 eb 01 00 8b 7c
[  350.444761] RSP: 0018:a22840047b80 EFLAGS: 0202 ORIG_RAX: 
ff13
[  350.452471] RAX:  RBX: 0001 RCX: 000b
[  350.459687] RDX: 0001 RSI: 956bbb561548 RDI: 000a0040
[  350.466902] RBP: a22840047bf8 R08: 000a0040 R09: 0002e248
[  350.474119] R10: b2dc R11: 006468fd R12: 8e56c120
[  350.481338] R13: a22840047c08 R14: a22840047cb0 R15: a22840047ce0
[  350.488571]  ? perf_cgroup_attach+0x70/0x70
[  350.492878]  ? trace+0x59/0x8d
[  350.496026]  ? perf_cgroup_attach+0x70/0x70
[  350.500306]  ? smp_call_function_single+0x5/0x120
[  350.505109]  task_function_call+0x45/0x70
[  350.509208]  ? perf_cgroup_switch+0x170/0x170
[  350.513657]  perf_cgroup_attach+0x37/0x70
[  350.517757]  cgroup_migrate_execute+0x2c3/0x370
[  350.522392]  cgroup_attach_task+0x154/0x1f0
[  350.526707]  cgroup_procs_write+0xc7/0x100
[  350.530905]  cgroup_file_write+0x88/0x150
[  350.535012]  kernfs_fop_write+0x10b/0x190
[  350.539121]  __vfs_write+0x34/0x190
[  350.542711]  ? __vfs_write+0x5/0x190
[  350.546377]  ? rcu_all_qs+0x5/0x80
[  350.549867]  vfs_write+0xb6/0x190
[  350.553282]  ksys_write+0x57/0xd0
[  350.556696]  do_syscall_64+0x82/0x4e0
[  350.560473]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  350.565614] RIP: 0033:0x7f6e72efd4e4
[  350.569280] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb bc 0f 1f 80 00 
00 00 00 48 8d 05 19 22 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 8d 64 24 d8 48 89 54 24 18
[  350.588133] RSP: 002b:7ffd434b8cb8 EFLAGS: 0246 ORIG_RAX: 
0001
[  350.595845] RAX: ffda RBX: 0005 RCX: 7f6e72efd4e4
[  350.603061] RDX: 0005 RSI: 7ffd434b8e8a RDI: 002a
[  350.610279] RBP: 7ffd434b8e8a R08:  R09: 0005
[  350.617495] R10:  R11: 0246 R12: 0005
[  350.624714] R13: 009abaf0 R14: 0005 R15: 7f6e72fc6760
[  413.301893] rcu: INFO: rcu_sched self-detected stall on CPU
[  413.307621] rcu:2-: (83670 ticks this GP) 
idle=546/1/0x4002 softirq=9363/9363 fqs=20382
[  413.317366] rcu: (t=84003 jiffies g=26533 q=170)
[  413.322307] NMI backtrace for cpu 2
[  413.325887] CPU: 2 PID: 1 Comm: systemd Tainted: GW 
4.19.84-xeno8-static #1
[  413.334321] Hardware name: TQ-Group TQMxE39M/Type2 - Board Product Name, 
BIOS 5.12.30.21.20 08/05/2019
[  413.343712] I-pipe domain: Linux
[  413.347025] Call Trace:
[  413.349566]  
[  413.351677]  dump_stack+0x8c/0xc0
[  413.355089]  nmi_cpu_backtrace.cold+0x14/0x53
[  413.359535]  ? lapic_can_unplug_cpu.cold+0x42/0x42
[  413.364418]  nmi_trigger_cpumask_backtrace+0x7a/0x87
[  413.369480]  rcu_dump_cpu_stacks+0x86/0xbe
[  413.373672]  rcu_check_callbacks.cold+0x1fb/0x363
[  413.378482]  update_process_times+0x41/0x80
[  413.382761]  tick_sched_handle+0x34/0x50
[  413.386769]  tick_sched_timer+0x38/0x80
[  413.390698]  __hrtimer_run_queues+0xfd/0x270
[  413.395058]  ? tick_sched_do_timer+0x60/0x60
[  413.399434]  hrtimer_interrupt+0x106/0x230
[  413.403644]  smp_apic_timer_interrupt+0x46/0x110
[  413.408358]  

RE: stalled head domain with 3.1rc4

[Lange Norbert via Xenomai]

nc  -24 __update_load_avg_se+0x0 
(update_load_avg+0x341)
[  293.638525]#func  -25 cgroup_rstat_updated+0x0 
(__cgroup_account_cputime+0x24)
[  293.647558]#func  -25 __cgroup_account_cputime+0x0 
(update_curr+0x101)
[  293.655891]#func  -26 cpuacct_charge+0x0 
(update_curr+0xe4)
[  293.663270]#func  -26 update_min_vruntime+0x0 
(update_curr+0x73)
[  293.671087]#func  -26 update_curr+0x0 
(task_tick_fair+0x3d)
[  293.678468]#func  -27 task_tick_fair+0x0 
(scheduler_tick+0x5d)
[  293.686107]#func  -27 __accumulate_pelt_segments+0x0 
(update_irq_load_avg+0x22c)
[  293.695310]#func  -28 update_irq_load_avg+0x0 
(scheduler_tick+0x4b)
[  293.703381]#func  -28 update_rq_clock+0x0 
(scheduler_tick+0x4b)
[  293.711104]#func  -28 _raw_spin_lock+0x0 
(scheduler_tick+0x3c)
[  293.718744]#func  -29 scheduler_tick+0x0 
(update_process_times+0x69)
[  293.726901]  | #end 0x8001-29 ipipe_test_root+0x55 (<>)
[  293.733930]  | #begin   0x8001-30 ipipe_test_root+0x40 (<>)
[  293.740959]#func  -30 ipipe_test_root+0x0 
(irq_work_run_list+0xe)
[  293.748862]#func  -30 rcu_segcblist_ready_cbs+0x0 
(rcu_check_callbacks+0x16d)
[  293.757803]#func  -31 rcu_segcblist_ready_cbs+0x0 
(rcu_check_callbacks+0x16d)
[  293.766742]#func  -31 rcu_check_callbacks+0x0 
(update_process_times+0x41)
[  293.775335]  | #end 0x8001-32 ipipe_stall_root+0x53 (<>)
[  293.782451]  | #begin   0x8001-32 ipipe_stall_root+0x47 (<>)
[  293.789569]  | #end 0x8001-32 ipipe_root_only+0x74 (<>)
[  293.796601]  | #begin   0x8001-33 ipipe_root_only+0x68 (<>)
[  293.803633]#func  -33 ipipe_root_only+0x0 
(ipipe_stall_root+0xe)
[  293.811445]#func  -33 ipipe_stall_root+0x0 
(update_process_times+0x3a)
[  293.819778]  | #end 0x8001-34 ipipe_root_only+0x74 (<>)
[  293.826809]  | #begin   0x8001-34 ipipe_root_only+0x68 (<>)
[  293.833837]#func  -35 ipipe_root_only+0x0 
(ipipe_restore_root+0xe)
[  293.841821]#func  -35 ipipe_restore_root+0x0 
(update_process_times+0x3a)
[  293.850327]  | #end 0x8001-35 ipipe_stall_root+0x53 (<>)
[  293.857444]  | #begin   0x8001-36 ipipe_stall_root+0x47 (<>)
[  293.864560]  | #end 0x8001-36 ipipe_root_only+0x74 (<>)
[  293.871590]  | #begin   0x8001-37 ipipe_root_only+0x68 (<>)
[  293.878622]#func  -37 ipipe_root_only+0x0 
(ipipe_stall_root+0xe)
[  293.886434]#func  -37 ipipe_stall_root+0x0 
(raise_softirq+0x1f)
[  293.894163]  | #end 0x8001-38 ipipe_test_root+0x55 (<>)
[  293.901192]  | #begin   0x8001-38 ipipe_test_root+0x40 (<>)
[  293.908221]#func  -38 ipipe_test_root+0x0 
(raise_softirq+0x13)
[  293.915861]#func  -39 raise_softirq+0x0 
(update_process_times+0x3a)
[  293.923933]#func  -39 hrtimer_run_queues+0x0 
(run_local_timers+0x1a)
[  293.932092]#func  -39 run_local_timers+0x0 
(update_process_times+0x3a)
[  293.960301] Scheduler tracepoints stat_sleep, stat_iowait, stat_blocked and 
stat_runtime require the kernel parameter schedstats=enabl1

> -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/0x3

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

RE: CONFIG_XENO_DRIVERS_NET_CHECKED not possible to enable

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Dienstag, 17. Dezember 2019 07:53
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Subject: Re: CONFIG_XENO_DRIVERS_NET_CHECKED not possible to enable
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> On 16.12.19 18:49, Lange Norbert via Xenomai wrote:
> > Seems to me like a lot instances of XENO_DRIVERS_NET_CHECKED should
> be
> > renamed to XENO_DRIVERS_RTNET_CHECKED
> >
>
> Good catch, was always wrong. But as the higher-level config is called
> XENO_DRIVERS_NET, we should rather rename
> XENO_DRIVERS_RTNET_CHECKED.

Fixing and enabling the option results in multiple compile errors,
so it probably was never tested either.


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: [I-PIPE] ipipe-core-4.19.89-x86-9 released

[Lange Norbert via Xenomai]

Is there an easily digestible list of i-pipe changes (on top of the upstream 
Kernel)?

Norbert

> -Original Message-
> From: Xenomai  On Behalf Of xenomai---
> via Xenomai
> Sent: Dienstag, 17. Dezember 2019 09:47
> To: xenomai@xenomai.org
> Subject: [I-PIPE] ipipe-core-4.19.89-x86-9 released
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> Download URL: https://xenomai.org/downloads/ipipe/v4.x/x86/ipipe-core-
> 4.19.89-x86-9.patch
>
> Repository: https://git.xenomai.org/ipipe-x86 Release tag: ipipe-core-
> 4.19.89-x86-9



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: rtcap destroys packet contents

[Lange Norbert via Xenomai]

> -Original Message-
> From: Jan Kiszka 
> Sent: Dienstag, 17. Dezember 2019 08:10
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org) 
> Subject: Re: rtcap destroys packet contents
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> On 16.12.19 13:36, Lange Norbert via Xenomai wrote:
> > Hi,
> >
> > I have such a setup, where I push/pull ethernet traffic from an Application
> every millisecond:
> >
> > [App] ---IDDP--> [RTSwitch] --ETH_P_ALL socket--> [rt_igp] [App]
> > <---IDDP-- [RTSwitch] <--ETH_P_ALL socket-- [rt_igp] [Tun]
> > <---tundev---/
> >
> >
> > Now I am sometimes missing packets that the other side should
> > definitely have sent. I wanted to use rtcap to inspect this issue, but
> unfortunately then I get messed up data so that I can't even finish some
> handshake procedures.
> >
> > Is there some incompatibility between RTCAP and ETH_P_ALL (which
> makes its own copies of rtskb's)?
> > Btw, I can't unload rtap/rtnet once loaded.
>
> There is at least no known incompatibility but it may simply have never been
> tested in that combination.
>
> Do you see corruption on packets sent from the rtcap machine or received by
> it?

I definitely see corruption from the "normal" reception over the raw packet 
socket (as soon as the rtcap module is active).
Seems like rtskb are reused before/while they are copied to userspace.

Analyzing the packets from the rtcap fake device for corruption would be 
time-consuming.

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