Testing of 4.4/Ipipe + Xenomai 3.0.X on ARM32

Testing of 4.4/Ipipe + Xenomai 3.0.X on ARM32

[Josef Holzmayr]

Hello!

To improve the testing situation for the 4.4 Kernel family on ARM32, I
created a set of layers [1] for OpenEmbedded. Currently the features are
rather limited:

- only the Morty branch exists, as this one natively includes Linux 4.4
  and therefore the GCC version etc. matches.
- only one BSP layer so far, namely the Beaglebone. This was chosen for
  two major reasons: a) it is supported well enough in 4.4. to not need
  additional patches which might introduce new issues, and b) it is
  hardware that I have here ready for testing.
- no higher automation like a kas cofiguration so far. Yet this probably
  will be the first limitation to be gotten rid of.

My current planning is to add a set of testing scripts based of
Philippe's suggestion, and run that suite on each new release for a
couple of days and post the results to the ML.

Preliminary results to kick off things:
- xeno-test completes successfully
- latency -t0 under load maxes at ~58µs
- latency -t2 under load maxes at ~18µs

Greetz

[1] https://github.com/LetoThe2nd/meta-xenomai
-- 
———————————————
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———————————————
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548 

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

Re: Testing of 4.4/Ipipe + Xenomai 3.0.X on ARM32

[Jan Kiszka]

Hi Sepp,

On 23.11.18 13:27, Josef Holzmayr via Xenomai wrote:
> Hello!
> 
> To improve the testing situation for the 4.4 Kernel family on ARM32, I
> created a set of layers [1] for OpenEmbedded. Currently the features are
> rather limited:
> 
> - only the Morty branch exists, as this one natively includes Linux 4.4
>    and therefore the GCC version etc. matches.

To my best knowledge, there is no dependency (yet) between a too new compiler 
and kernel 4.4. We are building 4.4-cip with pyro, e.g.

> - only one BSP layer so far, namely the Beaglebone. This was chosen for
>    two major reasons: a) it is supported well enough in 4.4. to not need
>    additional patches which might introduce new issues, and b) it is
>    hardware that I have here ready for testing.

I was thinking about which ARMv7 board to add to xenomai-images (enabling qemu 
will be first, though), and that is a good candidate there as well.

Another half-done topic here: CI builds. For that, the BB defconfig could be 
useful too.

> - no higher automation like a kas cofiguration so far. Yet this probably
>    will be the first limitation to be gotten rid of.
> 
> My current planning is to add a set of testing scripts based of
> Philippe's suggestion, and run that suite on each new release for a
> couple of days and post the results to the ML.

That sounds very helpful! We should try to keep common parts (anything unrelated 
to the image build system) in the core so that we can reuse that in 
xenomai-images as well.

> 
> Preliminary results to kick off things:
> - xeno-test completes successfully
> - latency -t0 under load maxes at ~58µs
> - latency -t2 under load maxes at ~18µs
> 

Great! According to [1], we could then tag 63637800 also for ARM? Or do you want 
to run more of the tests you have in mind first?

Jan

> Greetz
> 
> [1] https://github.com/LetoThe2nd/meta-xenomai
> 

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

Re: Testing of 4.4/Ipipe + Xenomai 3.0.X on ARM32

[Josef Holzmayr]

Hi Jan,

On Fri, Nov 23, 2018 at 01:48:27PM +0100, Jan Kiszka wrote:
> Hi Sepp,
> 
> On 23.11.18 13:27, Josef Holzmayr via Xenomai wrote:
> > Hello!
> > 
> > To improve the testing situation for the 4.4 Kernel family on ARM32, I
> > created a set of layers [1] for OpenEmbedded. Currently the features are
> > rather limited:
> > 
> > - only the Morty branch exists, as this one natively includes Linux 4.4
> >    and therefore the GCC version etc. matches.
> 
> To my best knowledge, there is no dependency (yet) between a too new
> compiler and kernel 4.4. We are building 4.4-cip with pyro, e.g.

Yes, I agree that pyro and rocko should probably not give any major
trouble. Yet, something in the back of my head tells me that thud and
maybe sumo will be problematic. Will investigate and report!

> > - only one BSP layer so far, namely the Beaglebone. This was chosen for
> >    two major reasons: a) it is supported well enough in 4.4. to not need
> >    additional patches which might introduce new issues, and b) it is
> >    hardware that I have here ready for testing.
> 
> I was thinking about which ARMv7 board to add to xenomai-images (enabling
> qemu will be first, though), and that is a good candidate there as well.
> 
> Another half-done topic here: CI builds. For that, the BB defconfig could be
> useful too.

My local tinkering of xenoami-images to create a qemu-armhf build is
still in progress. But yes, we should have a build there too. But I
don't think the BB defconfig I'm using at the moment is really suited
for xenomai testing. I'll certainly need to tinker with it some more.

> 
> > - no higher automation like a kas cofiguration so far. Yet this probably
> >    will be the first limitation to be gotten rid of.
> > 
> > My current planning is to add a set of testing scripts based of
> > Philippe's suggestion, and run that suite on each new release for a
> > couple of days and post the results to the ML.
> 
> That sounds very helpful! We should try to keep common parts (anything
> unrelated to the image build system) in the core so that we can reuse that
> in xenomai-images as well.

In the end, it would probably just be something like "xeno-test-long"

> 
> > 
> > Preliminary results to kick off things:
> > - xeno-test completes successfully
> > - latency -t0 under load maxes at ~58µs
> > - latency -t2 under load maxes at ~18µs
> > 
> 
> Great! According to [1], we could then tag 63637800 also for ARM? Or do you
> want to run more of the tests you have in mind first?

Given my current testing experience, I would like to not say yes or no,
as I'm not knowledgeable enough to judge. So please decide yourself upon
the given information, with those additional "hints":
- xeno-test "only" runs for 15minutes by default.
- the latency tests I did were not really more long-lived, I don't think
  any one exceeded 30minutes.
- it will be at least two more weeks until I have the long-run results.
  Could also be three. So if you want to tag rather soon, I can't rally
  help more.

Greetz
-- 
———————————————
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———————————————
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548 

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

Re: Testing of 4.4/Ipipe + Xenomai 3.0.X on ARM32

[Jan Kiszka]

On 26.11.18 15:30, Josef Holzmayr wrote:
> Hi Jan,
> 
> On Fri, Nov 23, 2018 at 01:48:27PM +0100, Jan Kiszka wrote:
>> Hi Sepp,
>>
>> On 23.11.18 13:27, Josef Holzmayr via Xenomai wrote:
>>> Hello!
>>>
>>> To improve the testing situation for the 4.4 Kernel family on ARM32, I
>>> created a set of layers [1] for OpenEmbedded. Currently the features are
>>> rather limited:
>>>
>>> - only the Morty branch exists, as this one natively includes Linux 4.4
>>>     and therefore the GCC version etc. matches.
>>
>> To my best knowledge, there is no dependency (yet) between a too new
>> compiler and kernel 4.4. We are building 4.4-cip with pyro, e.g.
> 
> Yes, I agree that pyro and rocko should probably not give any major
> trouble. Yet, something in the back of my head tells me that thud and
> maybe sumo will be problematic. Will investigate and report!

OK, understood.

> 
>>> - only one BSP layer so far, namely the Beaglebone. This was chosen for
>>>     two major reasons: a) it is supported well enough in 4.4. to not need
>>>     additional patches which might introduce new issues, and b) it is
>>>     hardware that I have here ready for testing.
>>
>> I was thinking about which ARMv7 board to add to xenomai-images (enabling
>> qemu will be first, though), and that is a good candidate there as well.
>>
>> Another half-done topic here: CI builds. For that, the BB defconfig could be
>> useful too.
> 
> My local tinkering of xenoami-images to create a qemu-armhf build is
> still in progress. But yes, we should have a build there too. But I

Oh, we might have worked in parallel, sorry: I've qemu-armhf for xenomai-images 
locally already (just started today). Will post later.

> don't think the BB defconfig I'm using at the moment is really suited
> for xenomai testing. I'll certainly need to tinker with it some more.

Yes, configs is a good topic. I was playing with them a lot today, to get some 
output first, then to find some reasonable debug setup. Considering to have a 
"release" (measurement) and "debug" profile for configs.

> 
>>
>>> - no higher automation like a kas cofiguration so far. Yet this probably
>>>     will be the first limitation to be gotten rid of.
>>>
>>> My current planning is to add a set of testing scripts based of
>>> Philippe's suggestion, and run that suite on each new release for a
>>> couple of days and post the results to the ML.
>>
>> That sounds very helpful! We should try to keep common parts (anything
>> unrelated to the image build system) in the core so that we can reuse that
>> in xenomai-images as well.
> 
> In the end, it would probably just be something like "xeno-test-long"
> 
>>
>>>
>>> Preliminary results to kick off things:
>>> - xeno-test completes successfully
>>> - latency -t0 under load maxes at ~58µs
>>> - latency -t2 under load maxes at ~18µs
>>>
>>
>> Great! According to [1], we could then tag 63637800 also for ARM? Or do you
>> want to run more of the tests you have in mind first?
> 
> Given my current testing experience, I would like to not say yes or no,
> as I'm not knowledgeable enough to judge. So please decide yourself upon
> the given information, with those additional "hints":
> - xeno-test "only" runs for 15minutes by default.
> - the latency tests I did were not really more long-lived, I don't think
>    any one exceeded 30minutes.
> - it will be at least two more weeks until I have the long-run results.
>    Could also be three. So if you want to tag rather soon, I can't rally
>    help more.

OK, then I will not hurry.

Thanks,
Jan

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

Re: Testing of 4.4/Ipipe + Xenomai 3.0.X on ARM32

[Josef Holzmayr]

Hi Jan,

On Mon, Nov 26, 2018 at 03:40:38PM +0100, Jan Kiszka wrote:
> On 26.11.18 15:30, Josef Holzmayr wrote:
> > On Fri, Nov 23, 2018 at 01:48:27PM +0100, Jan Kiszka wrote:
> > > On 23.11.18 13:27, Josef Holzmayr via Xenomai wrote:
> > > > - only one BSP layer so far, namely the Beaglebone. This was chosen for
> > > >     two major reasons: a) it is supported well enough in 4.4. to not need
> > > >     additional patches which might introduce new issues, and b) it is
> > > >     hardware that I have here ready for testing.
> > > 
> > > I was thinking about which ARMv7 board to add to xenomai-images (enabling
> > > qemu will be first, though), and that is a good candidate there as well.
> > > 
> > > Another half-done topic here: CI builds. For that, the BB defconfig could be
> > > useful too.
> > 
> > My local tinkering of xenoami-images to create a qemu-armhf build is
> > still in progress. But yes, we should have a build there too. But I
> 
> Oh, we might have worked in parallel, sorry: I've qemu-armhf for
> xenomai-images locally already (just started today). Will post later.

Saw that, thanks. Given my limited time investment, I'm happy to see it
happening, and thats it.

> 
> > don't think the BB defconfig I'm using at the moment is really suited
> > for xenomai testing. I'll certainly need to tinker with it some more.
> 
> Yes, configs is a good topic. I was playing with them a lot today, to get
> some output first, then to find some reasonable debug setup. Considering to
> have a "release" (measurement) and "debug" profile for configs.
> 
> > 
> > > 
> > > > - no higher automation like a kas cofiguration so far. Yet this probably
> > > >     will be the first limitation to be gotten rid of.

kas files are now in place, equivalent to the ones in xenomai-images

> > > > Preliminary results to kick off things:
> > > > - xeno-test completes successfully
> > > > - latency -t0 under load maxes at ~58µs
> > > > - latency -t2 under load maxes at ~18µs
> > > > 
> > > 
> > > Great! According to [1], we could then tag 63637800 also for ARM? Or do you
> > > want to run more of the tests you have in mind first?
> > 
> > Given my current testing experience, I would like to not say yes or no,
> > as I'm not knowledgeable enough to judge. So please decide yourself upon
> > the given information, with those additional "hints":
> > - xeno-test "only" runs for 15minutes by default.
> > - the latency tests I did were not really more long-lived, I don't think
> >    any one exceeded 30minutes.
> > - it will be at least two more weeks until I have the long-run results.
> >    Could also be three. So if you want to tag rather soon, I can't rally
> >    help more.
> 
> OK, then I will not hurry.

Digging deeper, I now have a couple of questions. xeno-test gives me

net_packet_dgram skipped (no kernel support)
net_packet_raw skipped (no kernel support)
net_udp skipped (no kernel support)
...
mutex_trylock not supported
...
sched_quota skipped (no kernel support)
sched_tp skipped (no kernel support)
...
sigdebug "SIGDEBUG_MIGRATE_PRIOINV" skipped (no kernel support)

So what do I need to increase test coverage here?

And, during the run I get 

[   75.650644] [Xenomai] watchdog triggered on CPU #0 -- runaway thread 'test' signaled
[   75.658601] sched: RT throttling activated

Is that good, bad, upgly, or expected?

Greetz
-- 
———————————————
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———————————————
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548 

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

Re: Testing of 4.4/Ipipe + Xenomai 3.0.X on ARM32

[Jan Kiszka]

On 28.11.18 13:40, Josef Holzmayr wrote:
> Hi Jan,
> 
> On Mon, Nov 26, 2018 at 03:40:38PM +0100, Jan Kiszka wrote:
>> On 26.11.18 15:30, Josef Holzmayr wrote:
>>> On Fri, Nov 23, 2018 at 01:48:27PM +0100, Jan Kiszka wrote:
>>>> On 23.11.18 13:27, Josef Holzmayr via Xenomai wrote:
>>>>> - only one BSP layer so far, namely the Beaglebone. This was chosen for
>>>>>      two major reasons: a) it is supported well enough in 4.4. to not need
>>>>>      additional patches which might introduce new issues, and b) it is
>>>>>      hardware that I have here ready for testing.
>>>>
>>>> I was thinking about which ARMv7 board to add to xenomai-images (enabling
>>>> qemu will be first, though), and that is a good candidate there as well.
>>>>
>>>> Another half-done topic here: CI builds. For that, the BB defconfig could be
>>>> useful too.
>>>
>>> My local tinkering of xenoami-images to create a qemu-armhf build is
>>> still in progress. But yes, we should have a build there too. But I
>>
>> Oh, we might have worked in parallel, sorry: I've qemu-armhf for
>> xenomai-images locally already (just started today). Will post later.
> 
> Saw that, thanks. Given my limited time investment, I'm happy to see it
> happening, and thats it.
> 
>>
>>> don't think the BB defconfig I'm using at the moment is really suited
>>> for xenomai testing. I'll certainly need to tinker with it some more.
>>
>> Yes, configs is a good topic. I was playing with them a lot today, to get
>> some output first, then to find some reasonable debug setup. Considering to
>> have a "release" (measurement) and "debug" profile for configs.
>>
>>>
>>>>
>>>>> - no higher automation like a kas cofiguration so far. Yet this probably
>>>>>      will be the first limitation to be gotten rid of.
> 
> kas files are now in place, equivalent to the ones in xenomai-images
> 
>>>>> Preliminary results to kick off things:
>>>>> - xeno-test completes successfully
>>>>> - latency -t0 under load maxes at ~58µs
>>>>> - latency -t2 under load maxes at ~18µs
>>>>>
>>>>
>>>> Great! According to [1], we could then tag 63637800 also for ARM? Or do you
>>>> want to run more of the tests you have in mind first?
>>>
>>> Given my current testing experience, I would like to not say yes or no,
>>> as I'm not knowledgeable enough to judge. So please decide yourself upon
>>> the given information, with those additional "hints":
>>> - xeno-test "only" runs for 15minutes by default.
>>> - the latency tests I did were not really more long-lived, I don't think
>>>     any one exceeded 30minutes.
>>> - it will be at least two more weeks until I have the long-run results.
>>>     Could also be three. So if you want to tag rather soon, I can't rally
>>>     help more.
>>
>> OK, then I will not hurry.
> 
> Digging deeper, I now have a couple of questions. xeno-test gives me
> 
> net_packet_dgram skipped (no kernel support)
> net_packet_raw skipped (no kernel support)
> net_udp skipped (no kernel support)

That should be

CONFIG_XENO_DRIVERS_NET=m
CONFIG_XENO_DRIVERS_NET_RTIPV4_UDP=m
CONFIG_XENO_DRIVERS_NET_RTPACKET=m

at least. But you may see crashes then (reminds me of that open issue).

> ...
> mutex_trylock not supported

Hmm, I don't recall ATM what triggers this... need to dig.

> ...
> sched_quota skipped (no kernel support)
> sched_tp skipped (no kernel support)
> ...

CONFIG_XENO_OPT_SCHED_CLASSES=y & Co.

> sigdebug "SIGDEBUG_MIGRATE_PRIOINV" skipped (no kernel support)

CONFIG_XENO_OPT_DEBUG_MUTEX_SLEEP=y

> 
> So what do I need to increase test coverage here?
> 
> And, during the run I get
> 
> [   75.650644] [Xenomai] watchdog triggered on CPU #0 -- runaway thread 'test' signaled
> [   75.658601] sched: RT throttling activated
> 
> Is that good, bad, upgly, or expected?

Expected warning: We willingly let the watchdog bark, and then also Linux 
detects that this test ran too long.

Jan

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

Re: Testing of 4.4/Ipipe + Xenomai 3.0.X on ARM32

[Jan Kiszka]

On 28.11.18 15:42, Jan Kiszka wrote:
> On 28.11.18 13:40, Josef Holzmayr wrote:
>> Digging deeper, I now have a couple of questions. xeno-test gives me
>>
>> net_packet_dgram skipped (no kernel support)
>> net_packet_raw skipped (no kernel support)
>> net_udp skipped (no kernel support)
> 
> That should be
> 
> CONFIG_XENO_DRIVERS_NET=m
> CONFIG_XENO_DRIVERS_NET_RTIPV4_UDP=m
> CONFIG_XENO_DRIVERS_NET_RTPACKET=m
> 
> at least. But you may see crashes then (reminds me of that open issue).
> 
>> ...
>> mutex_trylock not supported
> 
> Hmm, I don't recall ATM what triggers this... need to dig.
> 

Philippe can likely recall this. Comparing stable to next, where this message
disappeared, leads to commit 43d383cc that says: "At this chance, the lock
stealing test is also fixed."

Probably means we cannot do better than "not supported" over stable.

Jan

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

Re: Testing of 4.4/Ipipe + Xenomai 3.0.X on ARM32

[Philippe Gerum]

On 11/28/18 1:40 PM, Josef Holzmayr via Xenomai wrote:
> Hi Jan,
> 
> On Mon, Nov 26, 2018 at 03:40:38PM +0100, Jan Kiszka wrote:
>> On 26.11.18 15:30, Josef Holzmayr wrote:
>>> On Fri, Nov 23, 2018 at 01:48:27PM +0100, Jan Kiszka wrote:
>>>> On 23.11.18 13:27, Josef Holzmayr via Xenomai wrote:
>>>>> - only one BSP layer so far, namely the Beaglebone. This was chosen for
>>>>>     two major reasons: a) it is supported well enough in 4.4. to not need
>>>>>     additional patches which might introduce new issues, and b) it is
>>>>>     hardware that I have here ready for testing.
>>>>
>>>> I was thinking about which ARMv7 board to add to xenomai-images (enabling
>>>> qemu will be first, though), and that is a good candidate there as well.
>>>>
>>>> Another half-done topic here: CI builds. For that, the BB defconfig could be
>>>> useful too.
>>>
>>> My local tinkering of xenoami-images to create a qemu-armhf build is
>>> still in progress. But yes, we should have a build there too. But I
>>
>> Oh, we might have worked in parallel, sorry: I've qemu-armhf for
>> xenomai-images locally already (just started today). Will post later.
> 
> Saw that, thanks. Given my limited time investment, I'm happy to see it
> happening, and thats it.
> 
>>
>>> don't think the BB defconfig I'm using at the moment is really suited
>>> for xenomai testing. I'll certainly need to tinker with it some more.
>>
>> Yes, configs is a good topic. I was playing with them a lot today, to get
>> some output first, then to find some reasonable debug setup. Considering to
>> have a "release" (measurement) and "debug" profile for configs.
>>
>>>
>>>>
>>>>> - no higher automation like a kas cofiguration so far. Yet this probably
>>>>>     will be the first limitation to be gotten rid of.
> 
> kas files are now in place, equivalent to the ones in xenomai-images
> 
>>>>> Preliminary results to kick off things:
>>>>> - xeno-test completes successfully
>>>>> - latency -t0 under load maxes at ~58µs
>>>>> - latency -t2 under load maxes at ~18µs
>>>>>
>>>>
>>>> Great! According to [1], we could then tag 63637800 also for ARM? Or do you
>>>> want to run more of the tests you have in mind first?
>>>
>>> Given my current testing experience, I would like to not say yes or no,
>>> as I'm not knowledgeable enough to judge. So please decide yourself upon
>>> the given information, with those additional "hints":
>>> - xeno-test "only" runs for 15minutes by default.
>>> - the latency tests I did were not really more long-lived, I don't think
>>>    any one exceeded 30minutes.
>>> - it will be at least two more weeks until I have the long-run results.
>>>    Could also be three. So if you want to tag rather soon, I can't rally
>>>    help more.
>>
>> OK, then I will not hurry.
> 
> Digging deeper, I now have a couple of questions. xeno-test gives me
> 
> net_packet_dgram skipped (no kernel support)
> net_packet_raw skipped (no kernel support)
> net_udp skipped (no kernel support)
> ...
> mutex_trylock not supported
> ...
> sched_quota skipped (no kernel support)
> sched_tp skipped (no kernel support)
> ...
> sigdebug "SIGDEBUG_MIGRATE_PRIOINV" skipped (no kernel support)
> 
> So what do I need to increase test coverage here?

You need to enable a set of Xenomai kernel options, something like:

CONFIG_XENO_OPT_SCHED_CLASSES=y
CONFIG_XENO_OPT_SCHED_WEAK=y
CONFIG_XENO_OPT_SCHED_TP=y
CONFIG_XENO_OPT_SCHED_TP_NRPART=4
CONFIG_XENO_OPT_SCHED_SPORADIC=y
CONFIG_XENO_OPT_SCHED_SPORADIC_MAXREPL=8
CONFIG_XENO_OPT_SCHED_QUOTA=y
CONFIG_XENO_OPT_SCHED_QUOTA_PERIOD=10000
CONFIG_XENO_OPT_SCHED_QUOTA_NR_GROUPS=32
CONFIG_XENO_OPT_PIPE=y
CONFIG_XENO_OPT_MAP=y
CONFIG_XENO_OPT_EXTCLOCK=y
CONFIG_XENO_OPT_PIPE_NRDEV=32
CONFIG_XENO_DRIVERS_TIMERBENCH=y
CONFIG_XENO_DRIVERS_SWITCHTEST=y
CONFIG_XENO_DRIVERS_HEAPCHECK=y
CONFIG_XENO_DRIVERS_RTDMTEST=m
CONFIG_XENO_DRIVERS_NET=m
CONFIG_XENO_DRIVERS_NET_RX_FIFO_SIZE=32
CONFIG_XENO_DRIVERS_NET_ETH_P_ALL=y
CONFIG_XENO_DRIVERS_NET_RTIPV4=m
CONFIG_XENO_DRIVERS_NET_RTIPV4_ICMP=y
CONFIG_XENO_DRIVERS_NET_RTIPV4_HOST_ROUTES=32
CONFIG_XENO_DRIVERS_NET_RTIPV4_UDP=m
CONFIG_XENO_DRIVERS_NET_RTPACKET=m
CONFIG_XENO_DRIVERS_NET_RTMAC=m
CONFIG_XENO_DRIVERS_NET_TDMA=m
CONFIG_XENO_DRIVERS_NET_TDMA_MASTER=y
CONFIG_XENO_DRIVERS_NET_RTCFG=m
CONFIG_XENO_DRIVERS_NET_DRV_LOOPBACK=m
CONFIG_XENO_DRIVERS_NET_ADDON_RTCAP=m
CONFIG_XENO_DRIVERS_NET_ADDON_PROXY=m
CONFIG_XENO_DRIVERS_NET_ADDON_PROXY_ARP=y
CONFIG_XENO_DRIVERS_RTIPC=y
CONFIG_XENO_DRIVERS_RTIPC_XDDP=y
CONFIG_XENO_DRIVERS_RTIPC_IDDP=y
CONFIG_XENO_OPT_IDDP_NRPORT=32
CONFIG_XENO_DRIVERS_RTIPC_BUFP=y
CONFIG_XENO_OPT_BUFP_NRPORT=32
CONFIG_XENO_OPT_DEBUG_USER=y
CONFIG_XENO_OPT_DEBUG_MUTEX_RELAXED=y
CONFIG_XENO_OPT_WATCHDOG=y

> 
> And, during the run I get 
> 
> [   75.650644] [Xenomai] watchdog triggered on CPU #0 -- runaway thread 'test' signaled
> [   75.658601] sched: RT throttling activated
> 
> Is that good, bad, upgly, or expected?
> 

If that happens with the 'sigdebug' test, then this is good and
expected: this means that Cobalt did pull the break when detecting a
runaway thread, which is what this test verifies.

If you get -EPROTO (out of quota) with the sched_quota smoke test, this
may not be a real issue if the error margin is within 1%. The test
currently complains about a deviation above 0.5%, which might be a bit
too strict on some (SMP) platforms - triggers on 0.7% have been observed
here.

-- 
Philippe.