[Xenomai] rtskbs gone missing in 3.0.x stable versions, breaking most of RTnet

[Xenomai] rtskbs gone missing in 3.0.x stable versions, breaking most of RTnet

[LOYAU, Florian]

Hello,

We've been attempting to run RTnet/Xenomai 3 for a school project
Our targets are 3.18.20 on a generic amd64,
and a patched 3.14.54 kernel on an I.MX6Q-SABRESD board (ARMv7HF)

We first attempted to run the i.MX6 with Xenomai 3.0-RC7 as that was the
latest available at the time.
However, i noticed options to build the ARM RT FEC driver had been dropped
from drivers' Kconfig, and attempted to re-enable it. This required minor
changes to two function calls whose signatures had been modified.

This was met with mixed success:
While on the one hand, the card did work with the built rt_fec module,
after about ~200 packets sent the driver runs out of rtskbs and outputs
"Memory squeeze: dropping packet" messages.

We proceeded to build the newer 3.0.1 Xenomai release onto the amd64
machine, this time without any modification, either on Xenomai or Linux
side,
and again have been met with strange results:

 * loopback and e1000 drivers do not work at all,
   throwing an EAGAIN when attempting to send packets.
   after a bit of printk'ing around, we determined this was due, again,
   to rtskb starvation in the device pool for some reason.

 * rt_e1000e works as expected, and we could test this, both with the
   i.MX6 running RC7, and looping back on the second port of our card.

Thinking we just broke the first one,
and had plain bad luck on the second one,
we pulled 3.0.x-stable branch and rebuilt it for the i.MX6.

The results were coherent with 3.0.1 :
 FEC doesn't work at all either, returning EAGAIN
 on packet sending due to rtskb starvation.
 We haven't tested yet with rt_igb and rt_e1000...

We're majorly confused regarding the state of the support of the different
drivers at present, and what looks like compat-breaking changes between
RTnet 1.7, Xenomai 3 RC, and Xenomai 3 stable. Can you provide us with
some information on the state of support and pointers on what can be done
to fix these problems ?

Thanks in advance,

Florian Loyau,
ESIEE Paris, E5FR Network & Communications branch

Re: [Xenomai] rtskbs gone missing in 3.0.x stable versions, breaking most of RTnet

[Gilles Chanteperdrix]

On Tue, Jan 19, 2016 at 04:00:17PM +0100, LOYAU, Florian wrote:
> (...)
> We're majorly confused regarding the state of the support of the different
> drivers at present, and what looks like compat-breaking changes between
> RTnet 1.7, Xenomai 3 RC, and Xenomai 3 stable. Can you provide us with
> some information on the state of support and pointers on what can be done
> to fix these problems ?

First, Xenomai 3 made a lot of compat-breaking changes, so much that
there is a web page documenting them:
https://xenomai.org/migrating-from-xenomai-2-x-to-3-x/

The plan with RTnet is to modernize its core, while finding a way to
reuse more easily the mainline ethernet drivers core.

To this end, RTnet was merged in 3.0 and the most obvious problems
were fixed rapidly, like some ugly infinite loops replaced with
reference counting. The changes to reference counting broke loopback
in 3.0.1, which is a special case, and was fixed by allocating a
pool for that device, and should currently be fixed (which you
failed to mention). The result of that merge was tested on a few
drivers, including loopback, igb, e1000e, macb and r8169.

FEC was disabled because it did not compile, and I would rather have
it disabled than not compiling, and would prefer trying to re-user
mainline code when RTnet has been reworked than trying to fix what
we have. But if you have some patches to fix what we have, I am
interested.

After this merge, I did not work on RTnet during almost a year, but
the work resumed recently with the addition of a testsuite, the plan
is for the "big rework" to happen in the 3.x branch, while checking
with the teststuite that we have no regression.

If you have some precise bug reports to provide, maybe we can fix
them by working together.

Regards.

-- 
					    Gilles.
https://click-hack.org