Re: [Emc-developers] RTAI new libm support is now complete! (Based off of musl)

[Gene Heskett]

On Friday 01 November 2019 20:58:55 Alec Ari via Emc-developers wrote:

> Greetings RTAI users! TESTERS WANTED!
>
> I have just finished completely re-working the math functions in
> kernel space for RTAI.
>
> Instead of putting nearly an entire C library in kernel space, I have
> trimmed the living hell out of musl and have ported it for use with
> RTAI.
>
> The amount of (COMPLETELY SAFE) warnings of undefined symbols have
> been shortened dramatically, and you are welcome to start playing with
> the new branch here:
>
> https://github.com/NTULINUX/RTAI/tree/new-libm
>
> All of the math functions in rtapi_math.h located in the LinuxCNC
> source tree are fully supported. The following are:
>
> acos
> asin
> atan
> atan2
> ceil
> cos
> exp
> fabs
> floor
> fmax
> fmin
> fmod
> pow
> round
> scalbn
> sin
> sqrt
> tan
>
> 53 changed files, 4,173 additions, 714 deletions -- Big commit, lots
> of changes, needs testing.
>
> Previously, the RTAI build system would do a fresh git clone every
> time during `make` and all files were git ignored. This is no longer
> the case, musl is now included in RTAI, but only the parts required
> for LinuxCNC and RTAI functionality.
>
> The result is less warnings, and less junk in kernel space. In order
> to make the warnings go away entirely, all of the new libm code would
> need to be ported to Kbuild, and I do not have the time nor the skill.
> These warnings are also present in mainline RTAI as the rtai_math.ko
> exports symbols which are not already defined. Instead, less than a
> second later, these symbols come statically linked from the just-built
> musl libm.a, defining all of the symbols that were previously
> undefined.
>
> In short:
>
> 1.) RTAI build system compiles musl's libm (creates libm.a)
>
> 2.) RTAI build system compiles rtai_math.ko (separately, these are
> where the warnings come in)
>
> 3.) RTAI build system statically links rtai_math.ko to libm.a which
> defines all of those symbols.
>
> With Kbuild, everything happens at once. The libm from musl and
> rtai_math.ko get built together, all in one module.
>
> Starting Monday I will be very busy and will not have time for RTAI
> anymore. If this new branch checks out OK with andypugh, Tom, and
> other users/testers, I will merge the `new-libm` branch into master,
> and bump the version to 5.2.4. After that, feel free to make a Debian
> release as this is the preferred way to use RTAI math support
> (although putting all of this cool new stuff in Kbuild is obviously a
> better option)
>
> andypugh, you will have to refork your RTAI tree as it is currently
> out of sync. I broke that tree when I was first starting out and went
> back and fixed some commits. Also, please do not make debs with the
> no-calibration branch as this was only a test for your system, and
> yours only.
>
> The focus now with RTAI is making sure the `new-libm` branch is
> working for everyone, as this is better, cleaner, and more robust than
> the approach on RTAI mainline, and with less warnings. This just needs
> testing before the merge into `master` but everything should check out
> OK.
>
> Thank you everyone!
>
> Alec

And many thanks to you for forking rtai and bringing it into the next 
decade if not even more. I'm getting a new aortic valve Tuesday so I 
won't pester until they're thru with me. Probably at least a week.
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Stretch and its preempt-rt kernel

[Gene Heskett]

On Friday 01 November 2019 19:57:07 Peter C. Wallace wrote:

> On Fri, 1 Nov 2019, Gene Heskett wrote:
> > Date: Fri, 1 Nov 2019 19:32:38 -0400
> > From: Gene Heskett 
> > Reply-To: EMC developers 
> > To: EMC Developers 
> > Subject: [Emc-developers] Stretch and its preempt-rt kernel
> >
> > I'm loggng that eth0 has a possible GRO (whatever that is)
> > infection, and that tcp performance might be degraded.
>
> Probably OK to just just turn off GRO in the driver via ethtool
>
Which I had to install.

You will have to show me how, as sudo ethtool -h doesn't mention gro.

>From the man page, this does not give an error return, is it correct?

gene@coyote:~$ sudo ethtool -K eth0 gro off
gene@coyote:~$

If not correct, how do I query it.

Everything else is running wheezy yet, or the rpi4 is running raspbian 
10.1.  So I've 3 machines still on wheezy.

> > from dmesg:
> >
> > TCP: eth0: Driver has suspect GRO implementation, TCP performance
> > may be compromised.
> >
> > Doing a net searh it seems to be a feature of the
> > Linux coyote 4.9.0-11-rt-amd64
> > kernel being used.
> >
> > Scutllebut on the net says its not a show stopper, and can be fixed
> > with most any later build. Could this be updated?
> >
> > Cheers, Gene Heskett
> > --
> > "There are four boxes to be used in defense of liberty:
> > soap, ballot, jury, and ammo. Please use in that order."
> > -Ed Howdershelt (Author)
> > If we desire respect for the law, we must first make the law
> > respectable. - Louis D. Brandeis
> > Genes Web page 
> >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>
> Peter Wallace
> Mesa Electronics
>
> (\__/)
> (='.'=) This is Bunny. Copy and paste bunny into your
> (")_(") signature to help him gain world domination.
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] RTAI new libm support is now complete! (Based off of musl)

[Alec Ari via Emc-developers]

Greetings RTAI users! TESTERS WANTED!

I have just finished completely re-working the math functions in kernel space 
for RTAI.

Instead of putting nearly an entire C library in kernel space, I have trimmed 
the living hell out of musl and have ported it for use with RTAI.

The amount of (COMPLETELY SAFE) warnings of undefined symbols have been 
shortened dramatically, and you are welcome to start playing with the new 
branch here:

https://github.com/NTULINUX/RTAI/tree/new-libm

All of the math functions in rtapi_math.h located in the LinuxCNC source tree 
are fully supported. The following are:

acos
asin
atan
atan2
ceil
cos
exp
fabs
floor
fmax
fmin
fmod
pow
round
scalbn
sin
sqrt
tan

53 changed files, 4,173 additions, 714 deletions -- Big commit, lots of 
changes, needs testing.

Previously, the RTAI build system would do a fresh git clone every time during 
`make` and all files were git ignored. This is no longer the case, musl is now 
included in RTAI, but only the parts required for LinuxCNC and RTAI 
functionality.

The result is less warnings, and less junk in kernel space. In order to make 
the warnings go away entirely, all of the new libm code would need to be ported 
to Kbuild, and I do not have the time nor the skill. These warnings are also 
present in mainline RTAI as the rtai_math.ko exports symbols which are not 
already defined. Instead, less than a second later, these symbols come 
statically linked from the just-built musl libm.a, defining all of the symbols 
that were previously undefined.

In short:

1.) RTAI build system compiles musl's libm (creates libm.a)

2.) RTAI build system compiles rtai_math.ko (separately, these are where the 
warnings come in)

3.) RTAI build system statically links rtai_math.ko to libm.a which defines all 
of those symbols.

With Kbuild, everything happens at once. The libm from musl and rtai_math.ko 
get built together, all in one module.

Starting Monday I will be very busy and will not have time for RTAI anymore. If 
this new branch checks out OK with andypugh, Tom, and other users/testers, I 
will merge the `new-libm` branch into master, and bump the version to 5.2.4. 
After that, feel free to make a Debian release as this is the preferred way to 
use RTAI math support (although putting all of this cool new stuff in Kbuild is 
obviously a better option)

andypugh, you will have to refork your RTAI tree as it is currently out of 
sync. I broke that tree when I was first starting out and went back and fixed 
some commits. Also, please do not make debs with the no-calibration branch as 
this was only a test for your system, and yours only.

The focus now with RTAI is making sure the `new-libm` branch is working for 
everyone, as this is better, cleaner, and more robust than the approach on RTAI 
mainline, and with less warnings. This just needs testing before the merge into 
`master` but everything should check out OK.

Thank you everyone!

Alec


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Stretch and its preempt-rt kernel

[Peter C. Wallace]

On Fri, 1 Nov 2019, Gene Heskett wrote:


Date: Fri, 1 Nov 2019 19:32:38 -0400
From: Gene Heskett 
Reply-To: EMC developers 
To: EMC Developers 
Subject: [Emc-developers] Stretch and its preempt-rt kernel

I'm loggng that eth0 has a possible GRO (whatever that is) infection, and
that tcp performance might be degraded.



Probably OK to just just turn off GRO in the driver via ethtool




from dmesg:

TCP: eth0: Driver has suspect GRO implementation, TCP performance may be
compromised.

Doing a net searh it seems to be a feature of the
Linux coyote 4.9.0-11-rt-amd64
kernel being used.

Scutllebut on the net says its not a show stopper, and can be fixed with
most any later build. Could this be updated?

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page 


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Stretch and its preempt-rt kernel

[Gene Heskett]

I'm loggng that eth0 has a possible GRO (whatever that is) infection, and 
that tcp performance might be degraded.

from dmesg:

TCP: eth0: Driver has suspect GRO implementation, TCP performance may be 
compromised.

Doing a net searh it seems to be a feature of the 
Linux coyote 4.9.0-11-rt-amd64
kernel being used.

Scutllebut on the net says its not a show stopper, and can be fixed with 
most any later build. Could this be updated?

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] round is unused math variable?

[Alec Ari via Emc-developers]

Thanks Andy! I will add round into musl libm kernel space.
Alec

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] round is unused math variable?

[andy pugh]

On Fri, 1 Nov 2019 at 04:04, Alec Ari via Emc-developers
 wrote:

> One of the things I noticed in LinuxCNC is that in src/rtapi/rtapi_math.h 
> there is this line:
> extern double round(double);
> But this apparently isn't used anywhere. If you comment it out, nothing 
> happens (it _will_ fail if a driver needs it) secondly, in kernel space, I 
> didn't add in the round function. This would be an undefined symbol in one of 
> the LinuxCNC modules.
> round from rtapi_math.h looks safe to be removed.

rtapi_math isn't just a list of what is used, though, it is a list of
functions that _could_ be used.
I think that round should stay in, there is no way to know if it is
being used in a custom component somewhere.
Looking on the forum there is a mention of it being used here:
https://forum.linuxcnc.org/24-hal-components/26679-xhc-hb04-wireless-mpg-pendant-hal-module?start=40#36849

And also this interesting post:
https://forum.linuxcnc.org/24-hal-components/30647-round-function-not-work#72110

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers