Re: [Emc-developers] Fw: RTAI Package Building Failure
I haven't been following the docs issue too closely but this is all dead code
from what I gather:
debian/configure:
while test $# -ne 0; do
case "$1" in
noauto) BUILD_AUTO=false ;;
rtai) BUILD_RTAI=true ;;
rtai=*) BUILD_RTAI=true; RTAI_DEV=${1#rtai=} ;;
xenomai) BUILD_XENOMAI=true ;;
no-docs) unset ENABLE_BUILD_DOCUMENTATION ;;
*) echo 1>&2 "Unknown feature: $1"; exit 99 ;;
esac
shift
done
So I made this patch:
https://github.com/NTULINUX/linuxcnc-rtai-gnu11/commit/aadd9b81ee03b5054774df8ee55fffa6f91381ca
Now when I run:
./debian/configure -r nodocs
Docs don't get built but the build still fails to due examples missing:
# `.../doc/linuxcnc`) because that's where the
# `linuxcnc` launcher script looks for them, and that's
# inconvenient to change.
dh_installdocs --doc-main-package=linuxcnc --package=linuxcnc
install -m0755 -d debian/linuxcnc/usr/share/doc/linuxcnc
install -p -m0644 debian/copyright
debian/linuxcnc/usr/share/doc/linuxcnc/copyright
mkdir -p debian/linuxcnc/usr/share/doc/linuxcnc
mv debian/linuxcnc/usr/share/doc/linuxcnc/examples
debian/linuxcnc/usr/share/doc/linuxcnc
mv: cannot stat 'debian/linuxcnc/usr/share/doc/linuxcnc/examples': No such file
or directory
make[1]: *** [debian/rules:88: override_dh_installdocs-arch] Error 1
make[1]: Leaving directory '/home/ntu/linuxcnc-rtai-gnu11'
make: *** [debian/rules:43: binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit
status 2
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Fw: RTAI Package Building Failure
Updated results: Runtest: 259 tests run, 256 successful, 3 failed + 0 expected, 1 skipped Failed: /home/ntu/linuxcnc/tests/pyhal /home/ntu/linuxcnc/tests/realtime-math /home/ntu/linuxcnc/tests/symbols.0 realtime-math failed only because: + set -xe + halcompile --install rtmath.comp + halrun dotest.hal halrun: Realtime already running. Use 'halrun -U' to stop existing realtime session. I'm going to take a wild guess and say it's because the test before it, pyhal failed and LinuxCNC didn't clean it up properly so I manually invoked it: halcompile --install tests/realtime-math/rtmath.comp halrun tests/realtime-math/dotest.hal cat tests/realtime-math/result: make KBUILD_EXTRA_SYMBOLS=/home/ntu/linuxcnc/rtlib/Module.symvers -C /lib/modules/5.4.258-rtai-amd64/build M=/tmp/tmpulx4m1mf CC=gcc V=0 modules make[1]: Entering directory '/usr/src/linux-headers-5.4.258-rtai-amd64' CC [M] /tmp/tmpulx4m1mf/rtmath.o Building modules, stage 2. MODPOST 1 modules CC [M] /tmp/tmpulx4m1mf/rtmath.mod.o LD [M] /tmp/tmpulx4m1mf/rtmath.ko make[1]: Leaving directory '/usr/src/linux-headers-5.4.258-rtai-amd64' cp rtmath.ko /home/ntu/linuxcnc/rtlib/ Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Fw: RTAI Package Building Failure
He shoots HE SCORES!!! SUBDIRS was being used again when it shouldn't be, I didn't remove all the instances I guess. M= is the way to go, and I fixed the tests. Commit: https://github.com/NTULINUX/linuxcnc-rtai-gnu11/commit/867ac21bfa2138988d1fd800126be23cb3d4cb60 CHEERS! Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Fw: RTAI Package Building Failure
Error for personalities_mod: cat /home/ntu/linuxcnc/tests/halcompile/personalities_mod/stderr + set -e + halcompile --personalities=2 --install lincurve_test.comp mkdir: cannot create directory '.tmp_41640': Permission denied blah blah blah mkdir: cannot create directory ‘.tmp_41846’: Permission denied scripts/kconfig/conf.c:700:1: fatal error: opening dependency file scripts/kconfig/.conf.o.d: Permission denied 700 | } | ^ compilation terminated. make[3]: *** [scripts/Makefile.host:124: scripts/kconfig/conf.o] Error 1 make[2]: *** [Makefile:597: syncconfig] Error 2 make[1]: *** [Makefile:703: include/config/auto.conf.cmd] Error 2 make[1]: *** [include/config/auto.conf.cmd] Deleting file 'include/config/tristate.conf' make[1]: unlink: include/config/tristate.conf: Permission denied make: *** [/home/ntu/linuxcnc/src/Makefile.modinc:92: modules] Error 2 Error for rtapi-app-main-fails: cat /home/ntu/linuxcnc/tests/module-loading/rtapi-app-main-fails/stderr + halcompile --install rtapi_app_main_fails.comp mkdir: cannot create directory '.tmp_71498': Permission denied blah blah blah mkdir: cannot create directory ‘.tmp_71704’: Permission denied scripts/kconfig/conf.c:700:1: fatal error: opening dependency file scripts/kconfig/.conf.o.d: Permission denied 700 | } | ^ compilation terminated. make[3]: *** [scripts/Makefile.host:124: scripts/kconfig/conf.o] Error 1 make[2]: *** [Makefile:597: syncconfig] Error 2 make[1]: *** [Makefile:703: include/config/auto.conf.cmd] Error 2 make[1]: *** [include/config/auto.conf.cmd] Deleting file 'include/config/tristate.conf' make[1]: unlink: include/config/tristate.conf: Permission denied make: *** [/home/ntu/linuxcnc/src/Makefile.modinc:92: modules] Error 2 + halrun -v setup.hal setup.hal:1: Can't find module 'rtapi_app_main_fails' in /home/ntu/linuxcnc/rtlib + RETVAL=1 + '[' 1 -eq 0 ']' + echo 'the module failed to load, just like it should' + exit 0 Same kind of error for realtime-math: cat /home/ntu/linuxcnc/tests/realtime-math/stderr + set -xe + halcompile --install rtmath.comp mkdir: cannot create directory '.tmp_76537': Permission denied blah blah blah mkdir: cannot create directory ‘.tmp_76743’: Permission denied scripts/kconfig/conf.c:700:1: fatal error: opening dependency file scripts/kconfig/.conf.o.d: Permission denied 700 | } | ^ compilation terminated. make[3]: *** [scripts/Makefile.host:124: scripts/kconfig/conf.o] Error 1 make[2]: *** [Makefile:597: syncconfig] Error 2 make[1]: *** [Makefile:703: include/config/auto.conf.cmd] Error 2 make[1]: *** [include/config/auto.conf.cmd] Deleting file 'include/config/tristate.conf' make[1]: unlink: include/config/tristate.conf: Permission denied make: *** [/home/ntu/linuxcnc/src/Makefile.modinc:92: modules] Error 2 Final result: Running test: /home/ntu/linuxcnc/tests/uspace/spawnv-root Runtest: 260 tests run, 250 successful, 10 failed + 0 expected, 1 skipped Failed: /home/ntu/linuxcnc/tests/halcompile/personalities_mod /home/ntu/linuxcnc/tests/halcompile/relative-header /home/ntu/linuxcnc/tests/halcompile/serial-out-of-tree /home/ntu/linuxcnc/tests/lowlevel/mutex /home/ntu/linuxcnc/tests/module-loading/rtapi-app-main-fails /home/ntu/linuxcnc/tests/pyhal /home/ntu/linuxcnc/tests/realtime-math /home/ntu/linuxcnc/tests/rtapi-shmem /home/ntu/linuxcnc/tests/symbols.0 /home/ntu/linuxcnc/tests/symbols.1 Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Fw: RTAI Package Building Failure
Accidentally sent this directly to Andy instead of the mailing list.. Yes, SUBDIRS was deprecated a long time ago and then eventually removed, in favor of M. The fix I made before was so 5.4 builds would work, however that was only for the classic ./configure ; make method. Using M=$(PWD) doesn't work for building debs, and using M=$(PWD)/src doesn't work for ./configure ; make M=$(BASEPWD) satisfies both. I published a commit in my previous email that fixes the build however it's based off of master, not 2.9. The commit itself will merge into both branches but it'd have to be cherry-picked. My fork of LinuxCNC only has master, and I already have a PR submitted from awhile ago. I'd have to delete my fork I think and start over for me to do it right.. In case you missed it: https://github.com/NTULINUX/linuxcnc-rtai-gnu11/commit/e8ece4358c5d90b3b64ce43f23522b55de16518f Alec On Monday, October 23, 2023 at 06:09:37 AM CDT, andy pugh wrote: On Mon, 23 Oct 2023 at 09:08, andy pugh wrote: > > > As for the failing modules, the problem is that when you build LinuxCNC > > Debian packages, you're in the top directory of LinuxCNC, _not_ the src > > directory. In linuxcnc/src/Makefile, the value of M is $(PWD) however when > > you build Debian packages, this value now needs to be M="$(PWD)/src" > > > > How to conditionally set M=$(PWD) vs. M=$(PWD)/src depending on whether > > building a Debian package or not is beyond me, but that's the issue. After a but of digging, this was last changed by you: https://github.com/LinuxCNC/linuxcnc/commit/9695eb6b1104a54c9087947acd27f76dbb63be9d All changes prior to that date from when RTAI was the only game in town, so presumably worked then https://github.com/LinuxCNC/linuxcnc/commit/fc949aa523f9ede1d7c059fa00171691c8cafe1f -- 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, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI Package Building Failure
I thought my local changes to prevent docs from building if `no-docs` is set was the reason for this breakage, but I reverted my doc changes and I still get this error: # `.../doc/linuxcnc`) because that's where the # `linuxcnc` launcher script looks for them, and that's # inconvenient to change. dh_installdocs --doc-main-package=linuxcnc --package=linuxcnc install -m0755 -d debian/linuxcnc/usr/share/doc/linuxcnc install -p -m0644 debian/copyright debian/linuxcnc/usr/share/doc/linuxcnc/copyright mkdir -p debian/linuxcnc/usr/share/doc/linuxcnc mv debian/linuxcnc/usr/share/doc/linuxcnc/examples debian/linuxcnc/usr/share/doc/linuxcnc mv: cannot stat 'debian/linuxcnc/usr/share/doc/linuxcnc/examples': No such file or directory make[1]: *** [debian/rules:88: override_dh_installdocs-arch] Error 1 make[1]: Leaving directory '/home/ntu/linuxcnc-rtai-gnu11' make: *** [debian/rules:43: binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 Andy, you can probably get that one! Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI Package Building Failure
By using BASEPWD, there's some magic I don't quite understand but here it is: ifeq ($(BASEPWD),) BASEPWD := $(shell pwd) export BASEPWD include Makefile.inc else include $(BASEPWD)/Makefile.inc endif M=$(PWD)/src needs to be set if you're building LinuxCNC kernel modules from the top directory of LinuxCNC. You need to be at the top level in order for the debian/ files to work properly. M=$(PWD) needs to be the one set instead if you're already inside the src directory, otherwise you'll get: linuxcnc/src/src not found. M=$(BASEPWD) satisfies both worlds, meaning it works from both the top level of the LinuxCNC directory, and inside src/ Cheers! Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI Package Building Failure
The problem has to do with Kbuild, and I think I just found the right magic. uspace doesn't use the M= value at all nor builds any kernel modules. M=$(BASEPWD) seems to satisfy both ./configure builds and Debian packages. Commit: https://github.com/NTULINUX/linuxcnc-rtai-gnu11/commit/e8ece4358c5d90b3b64ce43f23522b55de16518f Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI Package Building Failure
I mostly figured this out, both the docs issue and the module building issue. As for docs, the `nodocs` option is completely ignored. When I fixed that, I get: # some clean-up rm -f /home/ntu/linuxcnc/debian/tmp/usr/share/doc/linuxcnc/examples/sample-configs/*/*position*.txt make[1]: Leaving directory '/home/ntu/linuxcnc' debian/rules override_dh_installdocs-arch make[1]: Entering directory '/home/ntu/linuxcnc' # Sample configs go in `usr/share/doc/linuxcnc` (not # `.../doc/linuxcnc`) because that's where the # `linuxcnc` launcher script looks for them, and that's # inconvenient to change. dh_installdocs --doc-main-package=linuxcnc --package=linuxcnc install -m0755 -d debian/linuxcnc/usr/share/doc/linuxcnc install -p -m0644 debian/copyright debian/linuxcnc/usr/share/doc/linuxcnc/copyright mkdir -p debian/linuxcnc/usr/share/doc/linuxcnc mv debian/linuxcnc/usr/share/doc/linuxcnc/examples debian/linuxcnc/usr/share/doc/linuxcnc mv: cannot stat 'debian/linuxcnc/usr/share/doc/linuxcnc/examples': No such file or directory make[1]: *** [debian/rules:88: override_dh_installdocs-arch] Error 1 make[1]: Leaving directory '/home/ntu/linuxcnc' make: *** [debian/rules:43: binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 So I'm leaving the always-on documentation build alone for now. As for the failing modules, the problem is that when you build LinuxCNC Debian packages, you're in the top directory of LinuxCNC, _not_ the src directory. In linuxcnc/src/Makefile, the value of M is $(PWD) however when you build Debian packages, this value now needs to be M="$(PWD)/src" How to conditionally set M=$(PWD) vs. M=$(PWD)/src depending on whether building a Debian package or not is beyond me, but that's the issue. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI Package Building Failure
One thing to try, revert 3ee51e306bbe93d424dcdcc8429feaf0b9d6ef02 Thanks for the command lines, will dig soon. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI Package Building Failure
What on the command line do you pass to trigger building LinuxCNC against RTAI? I'll need the full ./debian/configure stuff and the dpkg-buildpackage strings and whatever else is required. Treat me like I'm a total Debian noob :) Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI Package Building Failure
I have hardly any experience writing Debian packages, and the ones for LinuxCNC are quite complicated. I will try building your tree on my Debian system soon and see if I can help at all. I hope someone else can chime in. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI Package Building Failure
I have no idea where your problem might be coming from but I'm guessing it might be missing the "M" argument. i.e. $(PYTHON) modsilent.py $(MAKE) KBUILD_EXTRA_SYMBOLS=$(moduledir)/Module.symvers -C $(KERNELDIR) M=$(PWD) CC=$(CC) V=$(BUILD_VERBOSE) modules For the record, I have been able to build and run LinuxCNC against RTAI GNU11 and the new libm-kbuild branch by doing a classic ./configure rip install. Your problem must be stemming from the debian/ directory in LinuxCNC. As a sanity check, have you done the same to ensure your RTAI environment is all good? Just a quick run-in-place install for testing. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Moved musl libm library into Kbuild
Hey, I ironed out the last few bugs with the gnu11-libm-kbuild branch. Andy, when you start on RTAI again, use that branch as your starting point. I already reverted LinuxCNC commit 3d926d87f14ada9dea313c2989ee8f24f0e54e0c locally and it builds fine. 100% Kbuild is the way to go if it works. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Moved musl libm library into Kbuild
I haven't tested this on real CNC hardware, just the sim axis, but I made an attempt to move the musl libm library into Kbuild. This is so the harmless undefined symbols in modules during the RTAI build (not LinuxCNC) are gone. Originally, RTAI's build system would build musl's libm math library outside of the kernel build system, then would get linked against rtai_math.ko at the end of the build. Because it would happen at the end, technically, they're all undefined for a _very_ brief moment. By moving libm into Kbuild, each module (i.e. fabs, atan2 etc) all gets built along with rtai_math together. It's in it's own branch called, gnu11-libm-kbuild Tree: https://github.com/NTULINUX/RTAI/tree/gnu11-libm-kbuild If you want to play with it, go ahead! No more RTAI warnings. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
Whelp, pull request submitted. Just be sure to test the math! https://github.com/LinuxCNC/linuxcnc/pull/2685 The 2.9 branch will be broken with newer RTAI without this, so if it works in master I'd cherry-pick it. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
I can't tell because my C skills are pretty bad but looking at fmax and fmin,
I'm worried that the X and Y axis might be flipped for example:
LinuxCNC from rtapi_math.h:
extern __inline double fmax(double __y, double __x) {
return __y > __x || __builtin_isnan(__x) ? __y : __x;
}
extern __inline double fmin(double __y, double __x) {
return __y < __x || __builtin_isnan(__x) ? __y : __x;
}
RTAI from musl/libm/f{max,min}.c:
double fmax(double x, double y)
{
if (isnan(x))
return y;
if (isnan(y))
return x;
/* handle signed zeros, see C99 Annex F.9.9.2 */
if (signbit(x) != signbit(y))
return signbit(x) ? y : x;
return x < y ? y : x;
}
double fmin(double x, double y)
{
if (isnan(x))
return y;
if (isnan(y))
return x;
/* handle signed zeros, see C99 Annex F.9.9.2 */
if (signbit(x) != signbit(y))
return signbit(x) ? x : y;
return x < y ? x : y;
}
Or maybe everything will just work perfectly fine! :-)
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
I can make a pull request, I'm pretty sure the appropriate fix is indeed the correct fix. I think it'd be important to test the implementations of atan, asin, acos, fmax and fmin to make sure all is well. LinuxCNC will report errors if any of the math is wrong, yes? Say for example the accuracy of atan is off by a few decimal points, how will the user know if there's a problem? I'm fairly certain this will be a non-issue but I just want to make sure switching from GNU89 to GNU11 doesn't come with any regressions. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
I don't exactly know why switching to GNU11 causes this issue, maybe the GNU11 standard already defines these, but I removed LinuxCNC's definitions of the following functions: atan asin acos fmax fmin from rtapi_math.h and had to remove -Werror=frame-larger-than=2560 from LinuxCNC's Makefile and everything seems to be working now. commit: https://github.com/NTULINUX/linuxcnc-rtai-gnu11/commit/f436cfbc1514f9b52f29486648c1fca8ffcc7d5f Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
Oh crap, I'm seeing these too. This might be because of the gnu11 changes but I'll have to look into this more. Yes, trig errors everywhere. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
Not a problem, I will build RTAI 5.4.256 kernel packages and rtai-modules with the `gnu11` branch. Just be sure to revert the gnu89 commit for limit_axis when testing the debs. I'm not sure when I'll exactly get around to this but I got it. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
I would do a `make mrproper` and follow these steps for the kernel build: https://github.com/NTULINUX/RTAI/blob/gnu11/README.INSTALL Then skip to line 92, Creating RTAI Debian packages That's a really odd problem that I've never before. I was able to build RTAI kernel and module packages on Debian 12, forget my exact release. If it fails again, I'll host the deb packages on my Github. Following those instructions though you should have no problems. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
Yes, use the gnu11 branch in my RTAI tree and pick either 4.19.294 or or 5.4.256 As an additional layer of testing, revert the C89 commit in LinuxCNC to make sure GNU11 `for` loops actually work as intended: https://github.com/LinuxCNC/linuxcnc/commit/3d926d87f14ada9dea313c2989ee8f24f0e54e0c If there is a way to test limit_axis.ko please do so. If all is well, I'll merge everything together into the RTAI `master` branch. Thanks Andy! It's always fun squashing bugs with you. Alec On Thursday, September 28, 2023 at 12:46:23 AM UTC, andy pugh wrote: Do I need to re-build RTAI? My current git pull is master from https://github.com/NTULINUX/RTAI.git -- 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, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
Hi all, Rene said I should switch RTAI to GNU11: https://github.com/LinuxCNC/linuxcnc/commit/3d926d87f14ada9dea313c2989ee8f24f0e54e0c#commitcomment-128557906 I suppose the above commit could be reverted. Would anyone be able to test LinuxCNC against the changes I'll be making to RTAI? I can only test the sims, I don't have any actual CNC hardware available. I can make deb packages for the kernel, headers and rtai-modules but LinuxCNC still doesn't support building RTAI deb packages so it will need to be run-in-place. Kernels will be 4.19.294 and 5.4.256 genserkins still doesn't build though due to stack frame size being too large, the value from 2560 needs to be larger (-Werror=frame-larger-than=2560) That value comes from LinuxCNC/src/Makefile in EXTRA_CFLAGS: https://github.com/LinuxCNC/linuxcnc/blob/master/src/Makefile#L891 Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
Moving forward, I can merge that C11 patch into RTAI so we don't have to worry about C89/gnu89 anymore and you can just code how you please :-) I haven't noticed any regressions with the little testing I did but there could be something down road. I guess it depends on how often/how much C11 code is expected to be written in LinuxCNC. I don't know but I'm fine making that change. Hey Andy, just want to say it's always fun working with you on these things. Have you been able to build genserkins just fine btw against RTAI? Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
I don't know if this code is right, I just copied and pasted the 32 versions and made 64 versions where required. https://github.com/LinuxCNC/linuxcnc/pull/2650 Undefined symbols are gone, please review before merging! Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
So, there are two ways of building kernel modules with GNU11 instead of gnu89 or C99. 1.) Do it in RTAI: https://github.com/NTULINUX/RTAI/commit/a649bbb40fad9299ba31285276d9204df2f222d9 2.) Do it in LinuxCNC: https://github.com/NTULINUX/linuxcnc/commit/a76b69f7e66f7a3831be655ea3dde4590502a175 The first commit builds both the RTAI math module (rtai_math.ko) and musl with GNU11 (thorough explanation in git message.) The second is more conservative; building only the LinuxCNC modules with GNU11. I think it makes more sense doing this in RTAI so everything just matches. I hacked away at the LinuxCNC sources to try and get a successful build going but now I'm getting this: Reading 205/205 dependency files Done reading dependencies MAKEFLAGS="" \ /usr/bin/python3.11 modsilent.py make KBUILD_EXTRA_SYMBOLS=/usr/realtime/modules/Module.symvers -C /lib/modules/4.19.294-rtai-amd64/build M=/home/ntu/linuxcnc/src CC=gcc V=0 modules make[1]: Entering directory '/usr/src/linux-headers-4.19.294-rtai-amd64' Building modules, stage 2. MODPOST 213 modules WARNING: "hal_param_u64_new" [/home/ntu/linuxcnc/src/hal_lib.ko] undefined! WARNING: "hal_param_s64_newf" [/home/ntu/linuxcnc/src/hal_lib.ko] undefined! WARNING: "hal_param_u64_newf" [/home/ntu/linuxcnc/src/hal_lib.ko] undefined! WARNING: "hal_param_s64_new" [/home/ntu/linuxcnc/src/hal_lib.ko] undefined! make[1]: Leaving directory '/usr/src/linux-headers-4.19.294-rtai-amd64' dmesg when trying to start latency-test: [ 6404.916638] hal_lib: Unknown symbol hal_param_s64_new (err -2) [ 6404.916646] hal_lib: Unknown symbol hal_param_u64_newf (err -2) [ 6404.916660] hal_lib: Unknown symbol hal_param_s64_newf (err -2) [ 6404.91] hal_lib: Unknown symbol hal_param_u64_new (err -2) Any help is greatly appreciated. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
Since the fix is as simple as moving an, "i" around, I say we just do that. Problem solved. Even with a Xenomai 4/Dovetail/EVL port, you can't mix C library userspace headers with kernel space. The musl C library port I did with RTAI's current infrastructure is special because without it, you can't do floating-point in kernel space. It is a practice that should by all means be avoided. If there is no way to have raster.comp not depend on userspace headers, it should simply be excluded in the RTAI build. I'm using 2.9 and master. Note that without RTAI, you will not see the problem. Andy, you hit the nail on the head: >I think that the problem is that folk writing HAL components for >LinuxCNC don't realise that they are writing "Kernel sources for >kernel 4.19" and if they compile, build and test on uspace they won't >see any problems. They are indeed writing kernel modules. :-) Alec On Wednesday, September 20, 2023 at 09:47:14 AM UTC, Rod Webster wrote: I don't see why limit_axis.comp can't be revised to declare the int i; at the top of the procedure which I was taught was best practice anyway. That would solve the C11/C89 issue. raster.comp needs stdlib.h for some of the conversion functions. It also should include string.h for strchr() so it's still a bit sloppy. Surely your compiler library includes could be modified or set in the ENV to include these. What version of linuxcnc are you using? I could not see the size error in genserfuncs.c in master branch. We really should not be taking responsibility for the RTAI kernel compatibility. That has to be their problem, not ours. The Linux Kernel 6.5 has been released so that seems to be 11 versions ahead of the last RTAI compatible kernel. When do we accept that RTAI is really yesterday's technology? Where is the port to Xenomai 4? Rod Webster *1300 896 832* +61 435 765 611 Vehicle Modifications Network www.vehiclemods.net.au On Wed, 20 Sept 2023 at 18:27, andy pugh wrote: > On Wed, 20 Sept 2023 at 01:17, Alec Ari wrote: > > > Seriously though, the proper way to fix this is to not use c11/gnu11 > with 4.19 or 5.4 kernel sources. > > I think that the problem is that folk writing HAL components for > LinuxCNC don't realise that they are writing "Kernel sources for > kernel 4.19" and if they compile, build and test on uspace they won't > see any problems. > > Is there any fundamental reason that _our_ kernel modules can't be > compiled with gnu11 ? > > > -- > 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, 1912 > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
See the links I posted, they link to the lines in the kernel Makefile, that's where the gnu89 is coming from. Seriously though, the proper way to fix this is to not use c11/gnu11 with 4.19 or 5.4 kernel sources. It probably won't even work and shouldn't be tried. 4.19 and 5.4 use gnu89. https://stackoverflow.com/questions/29338206/error-for-loop-initial-declarations-are-only-allowed-in-c99-mode Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
The kernel switched to GNU11 with 5.18. RTAI is still 4.19 and 5.4, meaning all kernel space needs to be gnu89: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Makefile?h=linux-4.19.y=dd5638bc06a6bf3f5ca1a134960911dc49484386#n375 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Makefile?h=linux-4.19.y=dd5638bc06a6bf3f5ca1a134960911dc49484386#n445 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Makefile?h=linux-5.4.y=0c2544add9fc25c0e54a2167d6a2cfd2e696cf58#n412 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Makefile?h=linux-5.4.y=0c2544add9fc25c0e54a2167d6a2cfd2e696cf58#n487 https://www.phoronix.com/news/Linux-5.18-Does-C11 LinuxCNC may set -std=gnu11 however that covers userspace only (i.e. PREEMPT_RT builds.) All kernel modules are still gnu89. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] RTAI broken again with LinuxCNC
Upon make: Reading 205/205 dependency files Done reading dependencies MAKEFLAGS="" \ /usr/bin/python3.11 modsilent.py make KBUILD_EXTRA_SYMBOLS=/usr/realtime-4.19.294-rtai-amd64/modules/Module.symvers -C /usr/src/linux-headers-4.19.294-rtai-amd64 M=/home/ntu/linuxcnc/src CC=gcc V=0 modules make[1]: Entering directory '/usr/src/linux-headers-4.19.294-rtai-amd64' CC [M] /home/ntu/linuxcnc/src/objects/hal/components/limit_axis.o hal/components/limit_axis.comp: In function ‘_’: hal/components/limit_axis.comp:67:3: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode hal/components/limit_axis.comp:67:3: note: use option ‘-std=c99’, ‘-std=gnu99’, ‘-std=c11’ or ‘-std=gnu11’ to compile your code make[2]: *** [scripts/Makefile.build:304: /home/ntu/linuxcnc/src/objects/hal/components/limit_axis.o] Error 1 make[1]: *** [Makefile:1566: _module_/home/ntu/linuxcnc/src] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-4.19.294-rtai-amd64' make: *** [Makefile:547: modules] Error 2 After using `make -ki` to keep going and ignore errors: CC [M] /home/ntu/linuxcnc/src/objects/hal/components/raster.o /home/ntu/linuxcnc/src/objects/hal/components/raster.c:14:10: fatal error: stdlib.h: No such file or directory 14 | #include | ^~ compilation terminated. make[2]: [scripts/Makefile.build:304: /home/ntu/linuxcnc/src/objects/hal/components/raster.o] Error 1 (ignored) LD [M] /home/ntu/linuxcnc/src/raster.o ld: cannot find /home/ntu/linuxcnc/src/objects/hal/components/raster.o: No such file or directory make[2]: [scripts/Makefile.build:516: /home/ntu/linuxcnc/src/raster.o] Error 1 (ignored) As for this one, if you just set CONFIG_FRAME_WARN in the kernel config, it should go away: CC [M] /home/ntu/linuxcnc/src/emc/kinematics/genserfuncs.o /home/ntu/linuxcnc/src/emc/kinematics/genserfuncs.c: In function ‘genserKinematicsInverse’: /home/ntu/linuxcnc/src/emc/kinematics/genserfuncs.c:564:1: error: the frame size of 2576 bytes is larger than 2560 bytes [-Werror=frame-larger-than=] 564 | } | ^ cc1: some warnings being treated as errors make[2]: [scripts/Makefile.build:304: /home/ntu/linuxcnc/src/emc/kinematics/genserfuncs.o] Error 1 (ignored) CC [M] /home/ntu/linuxcnc/src/libnml/posemath/gomath.o LD [M] /home/ntu/linuxcnc/src/genserkins.o ld: cannot find /home/ntu/linuxcnc/src/emc/kinematics/genserfuncs.o: No such file or directory make[2]: [scripts/Makefile.build:516: /home/ntu/linuxcnc/src/genserkins.o] Error 1 (ignored) I suppose you could also set -Wno-error=frame-larger-than as part of the CFLAGS for the last one too. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
Meant to say, if you set CONFIG_FRAME_WARN to 0, the last error I posted should go away. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
What's really odd is that src/objects/hal/components/raster.c:14:10: fatal error: stdlib.h: No such file or directory stdlib.h is part of the C library, it shouldn't be looking for stdlib.h in kernel space, at all, ever. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Bookworm
Thank you!! Alec On Wednesday, June 7, 2023 at 11:38:14 PM UTC, Sebastian Kuzminsky wrote: On 6/7/23 14:29, Alec Ari via Emc-developers wrote: > 2.9 branch is still missing any recent Clang fixes, just throwing that out > there as a reminder. > > https://github.com/LinuxCNC/linuxcnc/pull/2214/commits Too bad that was merged into master - our published policy is to merge fixes into the oldest active stable branch. <http://linuxcnc.org/docs/2.9/html/code/contributing-to-linuxcnc.html#_use_of_git_in_the_linuxcnc_project> I'll backport it to 2.9. -- Sebastian Kuzminsky ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Bookworm
2.9 branch is still missing any recent Clang fixes, just throwing that out there as a reminder. https://github.com/LinuxCNC/linuxcnc/pull/2214/commits Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Unable to build LinuxCNC (ld error)
I fixed the Gentoo package for now to fix the Clang 16 error, sed oneliner: 's#-Wl,--version-script,objects/\$\*.ver ##' Just temporary until it gets fixed the right way. ebuild: https://github.com/NTULINUX/ntu_overlay/tree/main/sci-electronics/linuxcnc Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Unable to build LinuxCNC (ld error)
Just my two cents, I use Gentoo for everything. When dealing with ARM64 boards I start with a fully custom kernel and U-Boot image, and do the root filesystem myself. I steer away from Debian due to poor performance. Gentoo isn't as user-friendly so that's the trade off. At least for AMD64 platforms, I have an installer now that works. Rene, what was your -export-symbols-regex line? You said it doesn't work for all modules yet, I think I can get it going and finish it up. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Unable to build LinuxCNC (ld error)
Rene, Thanks! I just came across the same thing! I opened up the version files and saw garbage in them. I was able to narrow this down by using the BFD linker instead and saw errors like: /usr/bin/x86_64-pc-linux-gnu-ld.bfd:objects/debounce.ver:4: ignoring invalid character `\017' in script /usr/bin/x86_64-pc-linux-gnu-ld.bfd:objects/debounce.ver:4: ignoring invalid character `\037' in script /usr/bin/x86_64-pc-linux-gnu-ld.bfd:objects/debounce.ver:4: ignoring invalid character `@' in script /usr/bin/x86_64-pc-linux-gnu-ld.bfd:objects/debounce.ver:4: syntax error in VERSION script Just curious, how did you get clang-16 working on your end? Even Debian Sid is still on 14. I'm using Gentoo so I can pick and choose quite easily lol. Alec On Friday, May 26, 2023 at 02:53:03 PM UTC, Rene Hopf wrote: I can reproduce the problem, and working on a fix. https://github.com/LinuxCNC/linuxcnc/issues/2509 as a workaround you can just remove the version script, it isnt actually needed. Rene On 26.05.23 02:50, Alec Ari via Emc-developers wrote: > Yes but it's been awhile, I've actually done some U-Boot development in the > past. This problem with the linker is not kernel related though. > > Alec > > > > > > > On Friday, May 26, 2023 at 12:00:10 AM UTC, gene heskett > wrote: > > > > > > On 5/25/23 19:13, Alec Ari via Emc-developers wrote: >> 16.0.4 >> >> Just throwing this out there; I can write up the docs on how to use it, push >> the image to Github, finalize the installer and then anyone can try getting >> the last bits sorted out hands on. Latency and system performance surpasses >> Debian by a mile, there's also four different PREEMPT_RT kernels to choose >> from. Some kernels may have lower latency than others depending on the >> platform (i.e. Intel vs AMD) which is why I made a few. Adjustments include >> changes to RCU/CPU time keeping and IOMMU support. >> >> Alec >> > > Have you tested any kernels on u-booting arm64's? > > Cheers, Gene Heskett. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Unable to build LinuxCNC (ld error)
Oh, I see, I read the Github issue you posted: https://apt.llvm.org/ Heh, that's pretty cool! Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Unable to build LinuxCNC (ld error)
Yes but it's been awhile, I've actually done some U-Boot development in the past. This problem with the linker is not kernel related though. Alec On Friday, May 26, 2023 at 12:00:10 AM UTC, gene heskett wrote: On 5/25/23 19:13, Alec Ari via Emc-developers wrote: > 16.0.4 > > Just throwing this out there; I can write up the docs on how to use it, push > the image to Github, finalize the installer and then anyone can try getting > the last bits sorted out hands on. Latency and system performance surpasses > Debian by a mile, there's also four different PREEMPT_RT kernels to choose > from. Some kernels may have lower latency than others depending on the > platform (i.e. Intel vs AMD) which is why I made a few. Adjustments include > changes to RCU/CPU time keeping and IOMMU support. > > Alec > Have you tested any kernels on u-booting arm64's? 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, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/> ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Unable to build LinuxCNC (ld error)
16.0.4 Just throwing this out there; I can write up the docs on how to use it, push the image to Github, finalize the installer and then anyone can try getting the last bits sorted out hands on. Latency and system performance surpasses Debian by a mile, there's also four different PREEMPT_RT kernels to choose from. Some kernels may have lower latency than others depending on the platform (i.e. Intel vs AMD) which is why I made a few. Adjustments include changes to RCU/CPU time keeping and IOMMU support. Alec On Thursday, May 25, 2023 at 10:26:25 PM UTC, Rene Hopf wrote: > On 26. May 2023, at 00:11, Alec Ari via Emc-developers > wrote: > > Right, that's why I'm here. I don't know what's going on and need help. This > is the last step then my Gentoo work is done and I can publish everything. > LinuxCNC compiled before on Gentoo a few months ago and this is basically the > same build, just a newer version of Clang and LLD than before. Which clang and lld version? > > Alec > > > > > > > On Thursday, May 25, 2023 at 10:50:44 AM UTC, renehopf--- via Emc-developers > wrote: > > > > > > clang should work fine, there is a github ci job compiling with clang. > >> On 25.05.23 12:04, Alec Ari via Emc-developers >> wrote: >> Hello, >> >> I think this might be because I'm using Clang+LLD 16 but I'm not sure.. >> These look like syntax errors, not an environment/cache issue. >> >> Alec >> >>> ld.lld: error: objects/enum.ver:4: ; expected, but got >>>>>> @; >>>>>> ^ >>> clang-16: error: linker command failed with exit code 1 (use -v to >>> see invocation) >>> make: *** [Makefile:1234: ../rtlib/enum.so] Error 1 >>> ld.lld: error: objects/counter.ver:4: ; expected, but got >>>>>> @; >>>>>> ^ >>> ld.lld: error: objects/encoder_ratio.ver:4: ; expected, but got >>>>>> @; >>>>>> ^ >>> ld.lld: error: objects/stepgen.ver:4: ; expected, but got >>>>>> @; >>>>>> ^ >>> clang-16: clang-16: error: error: linker command failed with exit >>> code 1 (use -v to see invocation) >>> linker command failed with exit code 1 (use -v to see invocation) >>> clang-16: error: linker command failed with exit code 1 (use -v to >>> see invocation) >>> make: *** [Makefile:1234: ../rtlib/counter.so] Error 1 >>> make: *** [Makefile:1234: ../rtlib/encoder_ratio.so] Error 1 >>> make: *** [Makefile:1234: ../rtlib/stepgen.so] Error 1 >>> ld.lld: error: objects/lcd.ver:4: ; expected, but got >>>>>> @; >>>>>> ^ >>> clang-16: error: linker command failed with exit code 1 (use -v to >>> see invocation) >>> make: *** [Makefile:1234: ../rtlib/lcd.so] Error 1 >>> 1 warning generated. >> >> >> ___ >> Emc-developers mailing list >> Emc-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-developers > >> > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Unable to build LinuxCNC (ld error)
Right, that's why I'm here. I don't know what's going on and need help. This is the last step then my Gentoo work is done and I can publish everything. LinuxCNC compiled before on Gentoo a few months ago and this is basically the same build, just a newer version of Clang and LLD than before. Alec On Thursday, May 25, 2023 at 10:50:44 AM UTC, renehopf--- via Emc-developers wrote: clang should work fine, there is a github ci job compiling with clang. On 25.05.23 12:04, Alec Ari via Emc-developers wrote: > Hello, > > I think this might be because I'm using Clang+LLD 16 but I'm not sure.. These > look like syntax errors, not an environment/cache issue. > > Alec > > > ld.lld: error: objects/enum.ver:4: ; expected, but got > >>>> @; > >>>> ^ > > clang-16: error: linker command failed with exit code 1 (use -v to > > see invocation) > > make: *** [Makefile:1234: ../rtlib/enum.so] Error 1 > > ld.lld: error: objects/counter.ver:4: ; expected, but got > >>>> @; > >>>> ^ > > ld.lld: error: objects/encoder_ratio.ver:4: ; expected, but got > >>>> @; > >>>> ^ > > ld.lld: error: objects/stepgen.ver:4: ; expected, but got > >>>> @; > >>>> ^ > > clang-16: clang-16: error: error: linker command failed with exit > > code 1 (use -v to see invocation) > > linker command failed with exit code 1 (use -v to see invocation) > > clang-16: error: linker command failed with exit code 1 (use -v to > > see invocation) > > make: *** [Makefile:1234: ../rtlib/counter.so] Error 1 > > make: *** [Makefile:1234: ../rtlib/encoder_ratio.so] Error 1 > > make: *** [Makefile:1234: ../rtlib/stepgen.so] Error 1 > > ld.lld: error: objects/lcd.ver:4: ; expected, but got > >>>> @; > >>>> ^ > > clang-16: error: linker command failed with exit code 1 (use -v to > > see invocation) > > make: *** [Makefile:1234: ../rtlib/lcd.so] Error 1 > > 1 warning generated. > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Unable to build LinuxCNC (ld error)
Hello, I think this might be because I'm using Clang+LLD 16 but I'm not sure.. These look like syntax errors, not an environment/cache issue. Alec > ld.lld: error: objects/enum.ver:4: ; expected, but got > > > > @; > > > > ^ > clang-16: error: linker command failed with exit code 1 (use -v to > see invocation) > make: *** [Makefile:1234: ../rtlib/enum.so] Error 1 > ld.lld: error: objects/counter.ver:4: ; expected, but got > > > > @; > > > > ^ > ld.lld: error: objects/encoder_ratio.ver:4: ; expected, but got > > > > @; > > > > ^ > ld.lld: error: objects/stepgen.ver:4: ; expected, but got > > > > @; > > > > ^ > clang-16: clang-16: error: error: linker command failed with exit > code 1 (use -v to see invocation) > linker command failed with exit code 1 (use -v to see invocation) > clang-16: error: linker command failed with exit code 1 (use -v to > see invocation) > make: *** [Makefile:1234: ../rtlib/counter.so] Error 1 > make: *** [Makefile:1234: ../rtlib/encoder_ratio.so] Error 1 > make: *** [Makefile:1234: ../rtlib/stepgen.so] Error 1 > ld.lld: error: objects/lcd.ver:4: ; expected, but got > > > > @; > > > > ^ > clang-16: error: linker command failed with exit code 1 (use -v to > see invocation) > make: *** [Makefile:1234: ../rtlib/lcd.so] Error 1 > 1 warning generated. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Unable to build LinuxCNC (ld error)
Hi everyone, I have built the Gentoo image for LinuxCNC, real-time kernel and all with WiFi+wired ethernet support for many of the common USB NICs but now running into trouble building LinuxCNC itself: `make -j17`: config.status: creating ../scripts/setup_designer 1 warning generated. Creating shared library liblinuxcnchal.so.0 Linking rtapi_app 1 warning generated. Syntax checking python script halcompile Linking liblinuxcnc.a tooldata: depends: objects/emc/tooldata/tooldata_mmap.o objects/emc/tooldata/tooldata_common.o objects/emc/tooldata/tooldata_db.o tooldata: Linking: libtooldata.so.0 Linking linuxcnc_module_helper Linking python module _togl.so Linking python module lineardeltakins.so clang++ -std=gnu++17 -L/home/ntu/linuxcnc/lib -Wl,-rpath,/home/ntu/linuxcnc/lib -ltirpc -shared -o ../lib/python/lineardeltakins.so objects/emc/kinematics/lineardeltakins.o -lboost_python311 Copying python script halcompile Linking python module rotarydeltakins.so Linking ../rtlib/boss_plc.so clang++ -std=gnu++17 -L/home/ntu/linuxcnc/lib -Wl,-rpath,/home/ntu/linuxcnc/lib -ltirpc -shared -o ../lib/python/rotarydeltakins.so objects/emc/kinematics/rotarydeltakins.o -lboost_python311 Linking ../rtlib/debounce.so Linking ../rtlib/encoder.so Linking ../rtlib/enum.so 1 warning generated. grep: (standard input): binary file matches 1 warning generated. grep: (standard input): binary file matches grep: (standard input): binary file matches Linking ../rtlib/counter.so grep: (standard input): binary file matches Linking ../rtlib/encoder_ratio.so Linking ../rtlib/stepgen.so ld.lld: error: objects/boss_plc.ver:4: ; expected, but got >>> @; >>> ^ ld.lld: error: objects/debounce.ver:4: ; expected, but got >>> @; >>> ^ ld.lld: error: objects/encoder.ver:4: ; expected, but got >>> @; >>> ^ clang-16: error: linker command failed with exit code 1 (use -v to see invocation) Linking ../rtlib/lcd.so grep: (standard input): binary file matches clang-16: error: linker command failed with exit code 1 (use -v to see invocation) clang-16: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [Makefile:1231: ../rtlib/boss_plc.so] Error 1 make: *** Waiting for unfinished jobs 1 warning generated. make: *** [Makefile:1234: ../rtlib/debounce.so] Error 1 make: *** [Makefile:1234: ../rtlib/encoder.so] Error 1 grep: (standard input): binary file matches 1 warning generated. grep: (standard input): binary file matches grep: (standard input): binary file matches ld.lld: error: objects/enum.ver:4: ; expected, but got >>> @; >>> ^ clang-16: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [Makefile:1234: ../rtlib/enum.so] Error 1 ld.lld: error: objects/counter.ver:4: ; expected, but got >>> @; >>> ^ ld.lld: error: objects/encoder_ratio.ver:4: ; expected, but got >>> @; >>> ^ ld.lld: error: objects/stepgen.ver:4: ; expected, but got >>> @; >>> ^ clang-16: clang-16: error: error: linker command failed with exit code 1 (use -v to see invocation) linker command failed with exit code 1 (use -v to see invocation) clang-16: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [Makefile:1234: ../rtlib/counter.so] Error 1 make: *** [Makefile:1234: ../rtlib/encoder_ratio.so] Error 1 make: *** [Makefile:1234: ../rtlib/stepgen.so] Error 1 ld.lld: error: objects/lcd.ver:4: ; expected, but got >>> @; >>> ^ clang-16: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [Makefile:1234: ../rtlib/lcd.so] Error 1 1 warning generated. Adding `-v` to LDFLAGS gives me: Reading 262/262 realtime dependency files Done reading realtime dependencies Linking ../rtlib/abs.so grep: (standard input): binary file matches clang version 16.0.4 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/16/bin Configuration file: /etc/clang/clang.cfg System configuration file directory: /etc/clang Selected GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/13 Candidate multilib: .;@m64 Selected multilib: .;@m64 "/usr/lib/llvm/16/bin/ld.lld" --hash-style=gnu --eh-frame-hdr -m elf_x86_64 -shared -o ../rtlib/abs.so /usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../lib64/crti.o /usr/lib/llvm/16/bin/../../../../lib/clang/16/lib/linux/clang_rt.crtbegin-x86_64.o -L/home/ntu/linuxcnc/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/13 -L/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/lib -L/lib -L/usr/lib -rpath /home/ntu/linuxcnc/lib -ltirpc --version-script objects/abs.ver objects/rtobjects/hal/components/abs.o -lm /usr/lib/llvm/16/bin/../../../../lib/clang/16/lib/linux/libclang_rt.builtins-x86_64.a --as-needed -lunwind --no-as-needed -lc /usr/lib/llvm/16/bin/../../../../lib/clang/16/lib/linux/libclang_rt.builtins-x86_64.a --as-needed -lunwind --no-as-needed
Re: [Emc-developers] Debian deadline.
Just a heads up, Clang fixes still missing in 2.9.. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Can the Clang fixes be added to the 2.9 branch?
Currently, the fixes for Clang are only in master, can these be merged into 2.9? TIA, Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Unable to start LinuxCNC: TypeError: 'NoneType' object is not callable
Will give it a shot soon! Thanks! On Friday, January 13, 2023 at 08:40:41 AM UTC, Sebastian Kuzminsky wrote: Does this work around the problem? https://github.com/LinuxCNC/linuxcnc/issues/2264#issuecomment-1380954324 -- Sebastian Kuzminsky ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Unable to start LinuxCNC: TypeError: 'NoneType' object is not callable
Running Gentoo, just trying to get the sim axis window working again (not a real-time kernel, just quick test) ntu@ntu ~ $ linuxcnc LINUXCNC - 2.10.0~pre0 Machine configuration directory is '/home/ntu/linuxcnc/configs/sim.axis' Machine configuration file is 'axis.ini' Starting LinuxCNC... linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod Note: Using POSIX non-realtime Found file(lib): /usr/share/linuxcnc/hallib/core_sim.hal Found file(lib): /usr/share/linuxcnc/hallib/sim_spindle_encoder.hal Found file(lib): /usr/share/linuxcnc/hallib/axis_manualtoolchange.hal Found file(lib): /usr/share/linuxcnc/hallib/simulated_home.hal Found file(lib): /usr/share/linuxcnc/hallib/check_xyz_constraints.hal link (updating variable file): No such file or directory note: MAXV max: 5.000 units/sec 300.000 units/min note: LJOG max: 5.000 units/sec 300.000 units/min note: LJOG default: 0.250 units/sec 15.000 units/min note: jog_order='XYZ' note: jog_invert=set() Traceback (most recent call last): File "/usr/lib/python3.10/site-packages/OpenGL/latebind.py", line 43, in __call__ return self._finalCall( *args, **named ) TypeError: 'NoneType' object is not callable During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/bin/axis", line 3964, in get_coordinate_font(vars.dro_large_font.get()) File "/usr/bin/axis", line 3842, in get_coordinate_font glnav.use_pango_font(coordinate_font, 0, 128) File "/usr/lib/python3.10/site-packages/glnav.py", line 65, in use_pango_font glBitmap(0, 0, 0, 0, 0, h-d, ''.encode()) File "/usr/lib/python3.10/site-packages/OpenGL/latebind.py", line 47, in __call__ return self._finalCall( *args, **named ) File "/usr/lib/python3.10/site-packages/OpenGL/wrapper.py", line 700, in wrapperCall raise err File "/usr/lib/python3.10/site-packages/OpenGL/wrapper.py", line 693, in wrapperCall result = wrappedOperation( *cArguments ) File "/usr/lib/python3.10/site-packages/OpenGL/platform/baseplatform.py", line 415, in __call__ return self( *args, **named ) File "/usr/lib/python3.10/site-packages/OpenGL/error.py", line 230, in glCheckError raise self._errorClass( OpenGL.error.GLError: GLError( err = 1285, description = b'out of memory', baseOperation = glBitmap, pyArgs = (0, 0, 0, 0, 0, 13.0, b''), cArgs = (0, 0, 0, 0, 0, 13.0, b''), cArguments = (0, 0, 0, 0, 0, 13.0, b'') ) Shutting down and cleaning up LinuxCNC... task: 473 cycles, min=0.04, max=0.001062, avg=0.001019, 0 latency excursions (> 10x expected cycle time of 0.001000s) Note: Using POSIX non-realtime LinuxCNC terminated with an error. You can find more information in the log: /home/ntu/linuxcnc_debug.txt and /home/ntu/linuxcnc_print.txt as well as in the output of the shell command 'dmesg' and in the terminal ntu@ntu ~ $ cat linuxcnc*.txt 23766 23816 Stopping realtime threads Unloading hal components RUN_IN_PLACE=no LINUXCNC_DIR= LINUXCNC_BIN_DIR=/usr/bin LINUXCNC_TCL_DIR=/usr/lib/tcltk/linuxcnc LINUXCNC_SCRIPT_DIR= LINUXCNC_RTLIB_DIR=/usr/lib/linuxcnc/modules LINUXCNC_CONFIG_DIR= LINUXCNC_LANG_DIR=/usr/lib/tcltk/linuxcnc/msgs INIVAR=inivar HALCMD=halcmd LINUXCNC_EMCSH=/usr/bin/wish8.6 INIFILE=/home/ntu/linuxcnc/configs/sim.axis/axis.ini VERSION=1.1 PARAMETER_FILE=sim.var TPMOD= HOMEMOD= TASK=milltask HALUI=halui DISPLAY=axis COORDINATES=X Y Z KINEMATICS=trivkins Starting LinuxCNC server program: linuxcncsvr Loading Real Time OS, RTAPI, and HAL_LIB modules Starting LinuxCNC IO program: io Starting HAL User Interface program: halui Starting TASK program: milltask Starting DISPLAY program: axis Removing HAL_LIB, RTAPI, and Real Time OS modules Removing NML shared memory segmentsTypeError: 'NoneType' object is not callable On this test system, it is fully hardened (lots of security features throughout) not sure if related.. Any ideas on what's wrong? Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Broken master 06jan23
Yes it is! uvcvideo! Thanks! Alec On Sunday, January 8, 2023 at 06:12:33 PM UTC, gene heskett wrote: On 1/8/23 01:42, Alec Ari via Emc-developers wrote: > Oh hey! Speaking of cameras, I'm working on a Gentoo image for LinuxCNC, it's > like 90% of the way there, I have an installer and everything, just need to > test it on CNC hardware.. Are the cameras you guys use for camview fall under > UVC (USB_VIDEO_CLASS / uvcvideo) or something else? Trying to avoid 500+ > kernel modules lol. > let me see if I can find what dmesg says about this one. brb. [487365.330077] uvcvideo: Found UVC 1.00 device USB 2.0 PC Camera (058f:5608) Is that helpful. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Broken master 06jan23
Oh hey! Speaking of cameras, I'm working on a Gentoo image for LinuxCNC, it's like 90% of the way there, I have an installer and everything, just need to test it on CNC hardware.. Are the cameras you guys use for camview fall under UVC (USB_VIDEO_CLASS / uvcvideo) or something else? Trying to avoid 500+ kernel modules lol. Thanks! Alec On Saturday, January 7, 2023 at 11:28:58 PM UTC, gene heskett wrote: And of course the camera on the go704 doesn't work making qt upset at init time for about 40 seconds of . spew. It only worked for 3 or 4 days a couple/three months back. With cheese it Just Works. This is upsetting, it works for 2 or 4 upgrades, then disappears again for 6 months until I start pestering the list again. I'm as tired of that as you all are reading about my camera woes. It never works long enough for me to get the align kit from our wiki fully calibrated. Yet it works with cheese on any machine I plug it into. Thank you. Take care, stay warm & well Dewey. Cheers, Gene Heskett. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Bug#1025433: Bug#1025433: Copyright issue
Both of these files are different, all authors are arguably correct. Paolo doesn't work on LinuxCNC, he didn't write the one in LinuxCNC. The LinuxCNC one is based off other work, and Paolo's as well. My vote is on not a bug, not an issue. Alec On Monday, December 5, 2022 at 08:37:28 AM CST, andy pugh wrote: On Mon, 5 Dec 2022 at 14:14, Adam Ant wrote: > Source: linuxcnc > > src/rtapi/procfs_macros.h incorrectly attributes copyright. > > The original file can be found here: > > http://svn.savannah.gnu.org/viewvc/rtai/magma/base/include/rtai_proc_fs.h?view=markup At what point does a file become a new file? The file in LinuxCNC appears to be a sub-set of an original file contributed to RTAI by Erwin Roll. So who would be the correct copyright holder? It is possibly not Paulo either, -- 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, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Your comment editor for the forums sucks for posting commands
Subject ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
Ah, let me rephrase. There has been talk of automatic testing of RTAI not being feasible unless done manually but this is not true according to Seb. i.e earlier in the thread and: https://github.com/LinuxCNC/linuxcnc/issues/2052#issuecomment-1315787542 Speaking of Xenomai, I think it'd be awesome if LinuxCNC actually supported Dovetail/EVL instead. IPIPE is basically discontinued, there won't be anymore kernels beyond the 5.4 series which will be added (unless someone else does it.) I gave it a go with the 5.10 series and was able to port a large portion of it, fixed about ~30 conflicts but would need help finishing it up, most notably the assembly/asm-offset bits. Kernel source: https://source.denx.de/Xenomai/xenomai4/linux-evl/-/tree/next-evl-rebase libevl: https://source.denx.de/Xenomai/xenomai4/libevl/-/tree/next Alec On Wednesday, November 23, 2022 at 06:12:08 PM CST, andy pugh wrote: On Wed, 23 Nov 2022 at 21:10, Alec Ari via Emc-developers wrote: > > Ok, with that being said, we should stop saying RTAI cannot/will not be > tested. I keep reading that among/amongst the mailing list. No, I for one remain keen on retaining RTAI support (and Xenomai too) -- 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, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
Ok, with that being said, we should stop saying RTAI cannot/will not be tested. I keep reading that among/amongst the mailing list. Alec On Wednesday, November 23, 2022 at 02:44:43 PM CST, Sebastian Kuzminsky wrote: On 11/23/22 12:19, Alec Ari via Emc-developers wrote: > OK, so that should work with the Github CI/CD too then, right? Yes. Here's a recent run of our CI in Github Actions: https://github.com/LinuxCNC/linuxcnc/actions/runs/3500716822 This is the script that controls it: https://github.com/LinuxCNC/linuxcnc/blob/master/.github/workflows/ci.yml As you can see we currently build run-in-place and run the test suite, we build the html docs, and we build & test debs on multiple debian distros (Buster, Bullseye, Bookworm, and Sid). All this is done on Github's runners, which are all amd64 with vanilla kernels. So it exercises amd64 uspace pretty well but doesn't exercise any other CPU architecture, and doesn't exercise RTAI. Our mesaflash build uses a different (3rd-party) action to test building debs on multiple CPU architectures, using docker: https://github.com/LinuxCNC/mesaflash/actions/runs/3422479631 https://github.com/LinuxCNC/mesaflash/blob/master/.github/workflows/ci.yml#L43-L47 -- Sebastian Kuzminsky ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
OK, so that should work with the Github CI/CD too then, right? Alec On Wednesday, November 23, 2022 at 10:45:58 AM CST, Sebastian Kuzminsky wrote: On 11/23/22 09:02, Alec Ari via Emc-developers wrote: > With CI/CD, can't you have it do a `runtests` in a run-in-place > environment? I could also write a simple RTAI test program (even more > simple than the testsuite/built-in latency test) that'll just load > and exit. Yes, the full test suite can run (using `runtests`) in a run-in-place build (for both RTAI and uspace), as documented here: <http://linuxcnc.org/docs/devel/html/code/building-linuxcnc.html#Quick-Start> This is how the buildbot currently runs the tests on RTAI: <http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/7201> Of course this only works on a CI/CD machine running an RTAI kernel, and with sufficient capabilities/permissions to load and unload kernel modules. -- Sebastian Kuzminsky ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
With CI/CD, can't you have it do a `runtests` in a run-in-place environment? I could also write a simple RTAI test program (even more simple than the testsuite/built-in latency test) that'll just load and exit. Alec On Wednesday, November 23, 2022 at 04:38:42 AM CST, Jérémie Tarot wrote: Hello friends :) Found it back ! https://github.com/rpatterson/github-apt-repos So, if I understood correctly, except for *testing* RTAI builds which need loading/unloading kernel modules, we could have a full GH workflow up to repository hosting :) This may not have all the bells and whistles of other integrated scenarios, but may surely be the most straightforward to implement. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] RTAI 5.3.3 Delta release for LinuxCNC (kernel 5.4 debs available)
RTAI kernel 5.4 Debian packages are up! https://github.com/NTULINUX/RTAI/releases/tag/v5.3.3-delta If these check out OK for you guys, I'll mark it as stable and merge this into my `master` branch. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
I can make sure RTAI works with LinuxCNC myself, no need for Seb's stuff or anyone's VMs for that matter. Adding back in RTAI support though to the LinuxCNC Debian configure script would be helpful. I started on it but it's not finished. https://github.com/LinuxCNC/linuxcnc/issues/2052 In case the link gets truncated, it's issue 2052 on the LinuxCNC Github. The most I'll need is someone with Intel hardware to test my changes but all of that has already been tested thanks to Rainer Stelzer. Alec On Monday, November 14, 2022 at 07:57:21 PM CST, m...@mattshaver.com wrote: On 2022-11-14 15:54, Sebastian Kuzminsky wrote: > In order to support testing LinuxCNC on RTAI the buildbot uses custom > VMs which i created a long time ago and maintain poorly. It all runs > on hardware in my house, on my local network, so I am reluctant to > open it up to a more collaborative mode of development/maintenance. Is there some way of replicating your home based setup (or obtaining a compatible hardware/software environment) by contracting with a commercial hosting company, or co-location facility, or something like that? If this could be done for a reasonable amount of money, I'd be happy to pay for it, or at least chip in. I can't do much to help, but I can spend money! Thanks, Matt ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
I don't mind building LinuxCNC RTAI packages but the problem is actually a license problem. LinuxCNC keeps complaining after the ./configure about how it's a non-distributable build, but that flag has to be set due to the readline GPL-v2/LGPL starting with Debian Bullseye, otherwise the configure will fail. Building RTAI kernel debs for LinuxCNC is easy, it's literally download source, patch, make -j`nproc` bindeb-pkg and voila. https://www.mail-archive.com/emc-developers@lists.sourceforge.net/msg23329.html Curious, how are you guys legally hosting LinuxCNC Debian packages for Bullseye or Bookworm? I'm going to be working with Paolo on getting RTAI and PREEMPT_RT on the same kernel, I have 99.9% of the code done (all the kernel code itself is done) but I'm stuck on literally one line of C in the RTAI mailbox driver. You could theoretically even patch LinuxCNC to let you choose at runtime or in the settings somewhere what you want, RTAI or PREEMPT_RT, cutting the need for two different LinuxCNC packages. Just a thought. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
It'd be nice if people got off their high horse and just shared the keys with you. I don't know what's going on anymore with LinuxCNC. Alec On Friday, November 11, 2022 at 07:07:40 PM CST, andy pugh wrote: I can't do it. Previously the buildbot was integral to the process, but the buildbot only builds for Buster- and I have no control over it. LinuxCNC is being built into Debian Bookworm, but I have no involvement in this process, and no access rights. Debian Bullseye would be the logical release platform for 2.9. I could set up my own build-farm (I have enough hardware) but that would be a lot of work in an area in which I have no expertise. I have asked what the release platform should be, and there wasn't a single reply. I will continue as a user and I will continue to offer my support on the forum and mailing lists, I am not going anywhere, but I am both ignorant of what the release policy should be and incapable of performing the release manager role with the accesses and expertise that I have. -- 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, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9-pre1
I'll be happy to maintain Bookworm RTAI Debian packages too. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9-pre1
Well devices being added to the driver won't add overhead by itself.
Adding new Realtek devices usually looks like:
[RTL_GIGA_MAC_VER_31] = {"RTL8168dp/8111dp"},
[RTL_GIGA_MAC_VER_51] = {"RTL8168ep/8111ep"},
static void rtl8168dp_driver_start(struct rtl8169_private *tp)
{
r8168dp_oob_notify(tp, OOB_CMD_DRIVER_START);
rtl_loop_wait_high(tp, _dp_ocp_read_cond, 1, 10);
}
static void rtl8168ep_driver_start(struct rtl8169_private *tp)
{
r8168ep_ocp_write(tp, 0x01, 0x180, OOB_CMD_DRIVER_START);
r8168ep_ocp_write(tp, 0x01, 0x30, r8168ep_ocp_read(tp, 0x30) | 0x01);
rtl_loop_wait_high(tp, _ep_ocp_read_cond, 1, 10);
}
static void rtl8168_driver_start(struct rtl8169_private *tp)
{
if (tp->dash_type == RTL_DASH_DP)
rtl8168dp_driver_start(tp);
else
rtl8168ep_driver_start(tp);
}
Such code will not decrease performance for other chips.
8125 support commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?h=v6.1-rc4=02bf642b188a32b63e2406ed61e940dd80e5b1c7
Such code will not impact other devices. If performance issues are occurring on
newer kernels, it's probably because of the kernel hardening/security features
and/or Debian enabling kernel debugging options. If Debian hurts performance by
enabling features via Kconfig, then that's more of a Debian issue moreso than
an upstream kernel issue.
Alec
On Wednesday, November 9, 2022 at 08:27:31 PM CST, Rod Webster
wrote:
Alec, the RT8169 hardware may be ok but the same driver is used for a host
of other hardware and it does not work as well. The RT8168-dkms driver
covers some of them and can be used to replace the RT8169.
https://packages.debian.org/buster/r8168-dkms. Read the notes on the repo
page
I had the RT8168 driver working once perfectly with a RT8111 on Bullseye
but could never do it again on a reinstall. It seems too many devices are
being supported by the one driver and performance suffers.
I think this is a real issue because the average new user should not be
expected to compile the kernel and it severely limits the available
hardware that will work with linuxcnc. For all its faults, Bookworm will be
the easiest path for users when 2.9 releases in the absence of buildbot
images. You can't install the bookworm packages on Bullseye. I tried...
Bullseye currently requires lcnc to be installed from source so not a
good candidate if it can be avoided. Bullseye (kernel 5.10) is not immune
from the error finishing read but I suspect the very first versions are
OK. Maybe your 5.4 kernel is OK. Note that predates support for the Realtek
8125 2.5 gb NIC used in the Odroid and an increasing number of SFF PC's
(support was added in 5.9) So maybe that's when they reworked it.
I've never had any delays with bookworm booting. Its pretty speedy here...
Rod Webster
*1300 896 832*
+61 435 765 611
Vehicle Modifications Network
www.vehiclemods.net.au
On Thu, 10 Nov 2022 at 11:24, Alec Ari via Emc-developers <
emc-developers@lists.sourceforge.net> wrote:
> Rod,
>
> RTAI Debian packages exist for Bullseye, I packaged them myself. RTAI will
> never and has never been deployed in upstream Debian. I have an r8169 NIC
> and don't have any issues with network latency. 5.4 kernel debs would also
> work for Bookworm but it takes 5+ minutes to reach my desktop screen after
> booting Bookworm on my 4+ GHz 8-core/16-thread Ryzen CPU so I'm steering
> clear of it. Bookworm is a total joke right now, I ran sid for years and
> never had a problem, now both testing/Bookworm and unstable/sid are
> absolute turds.
>
>
> > Is this using the RTAI helper package and the uspace build, or some other
> > sorcery?
>
> Andy,
>
> For LinuxCNC, a 5.4 RTAI+PREEMPT_RT kernel would work, in theory, with a
> LinuxCNC RTAI+uspace build, but currently having issues compiling RTAI's
> mailbox (mbx) module against the RTAI+PREEMPT_RT kernel due to "pointer
> type stuff." Need someone with more basic knowledge of C to fix problem.
>
> Alec
>
>
>
> On Wednesday, November 9, 2022 at 06:11:33 PM CST, Rod Webster <
> r...@vehiclemods.net.au> wrote:
>
>
>
>
>
> It's not useful to have RTAI in Bullseye as we don't have any debs for that
> platform. It needs to target Bookworm so it is deployed to the Debian
> repos.
>
> Also, on the topic of kernels, there is a significant issue with the 5.x
> and 6.x kernels in Debian which have excessive network latency
> mostly/possibly only with Realtek NIC's) .
> This causes an "Error finishing read" on Mesa ethernet devices which
> disables communications to the board. Some of the NIC drivers in Debian are
> 15-30% slower than the original Realtek drivers according to some external
> sources.
> Some users have found that compiling the 6.1 PREEMPT_RT ker
Re: [Emc-developers] 2.9-pre1
Rod, RTAI Debian packages exist for Bullseye, I packaged them myself. RTAI will never and has never been deployed in upstream Debian. I have an r8169 NIC and don't have any issues with network latency. 5.4 kernel debs would also work for Bookworm but it takes 5+ minutes to reach my desktop screen after booting Bookworm on my 4+ GHz 8-core/16-thread Ryzen CPU so I'm steering clear of it. Bookworm is a total joke right now, I ran sid for years and never had a problem, now both testing/Bookworm and unstable/sid are absolute turds. > Is this using the RTAI helper package and the uspace build, or some other > sorcery? Andy, For LinuxCNC, a 5.4 RTAI+PREEMPT_RT kernel would work, in theory, with a LinuxCNC RTAI+uspace build, but currently having issues compiling RTAI's mailbox (mbx) module against the RTAI+PREEMPT_RT kernel due to "pointer type stuff." Need someone with more basic knowledge of C to fix problem. Alec On Wednesday, November 9, 2022 at 06:11:33 PM CST, Rod Webster wrote: It's not useful to have RTAI in Bullseye as we don't have any debs for that platform. It needs to target Bookworm so it is deployed to the Debian repos. Also, on the topic of kernels, there is a significant issue with the 5.x and 6.x kernels in Debian which have excessive network latency mostly/possibly only with Realtek NIC's) . This causes an "Error finishing read" on Mesa ethernet devices which disables communications to the board. Some of the NIC drivers in Debian are 15-30% slower than the original Realtek drivers according to some external sources. Some users have found that compiling the 6.1 PREEMPT_RT kernel resolves the issue. Sometimes using a NIC different driver fixes it but rarely. Forum Ref: https://forum.linuxcnc.org/27-driver-boards/46911-mesa-hm2-hm2-7i96s-0-error-finishing-read?start=110 <https://forum.linuxcnc.org/27-driver-boards/46911-mesa-hm2-hm2-7i96s-0-error-finishing-read?start=110> So this issue now rules out all of the popular USFF I am attempting to build deb files of this kernel today, but it's too early to say if it will succeed or if I can even install them. If a resolution is found, consideration should also be given to shipping a PREEMPT_RT kernel deb with 2.9. Rod Webster *1300 896 832* +61 435 765 611 Vehicle Modifications Network www.vehiclemods.net.au On Thu, 10 Nov 2022 at 07:55, andy pugh wrote: > On Wed, 9 Nov 2022 at 21:38, Alec Ari via Emc-developers < > emc-developers@lists.sourceforge.net> wrote: > > > Since there's been great progress with RTAI developments, can RTAI Debian > > package support for Bullseye be a milestone before 2.9.0 makes it's > initial > > stable release? > > > I would like to see that, yes. > > > > I was hoping to have PREEMPT_RT and RTAI work together with the 5.4 > kernel > > so one LinuxCNC package will work on all, but I don't think this is going > > to happen due to about ~5 lines of C code I don't understand. Making 5.4 > > RTAI-only kernel debs will be pretty easy once I have the Kconfig changes > > sorted out for Bullseye. > > > > Is this using the RTAI helper package and the uspace build, or some other > sorcery? > > > -- > 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, 1912 > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9-pre1
Since there's been great progress with RTAI developments, can RTAI Debian package support for Bullseye be a milestone before 2.9.0 makes it's initial stable release? I was hoping to have PREEMPT_RT and RTAI work together with the 5.4 kernel so one LinuxCNC package will work on all, but I don't think this is going to happen due to about ~5 lines of C code I don't understand. Making 5.4 RTAI-only kernel debs will be pretty easy once I have the Kconfig changes sorted out for Bullseye. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Fw: Attempt at RTAI and PREEMPT_RT (sort of off-topic)
Hello,
I posted this to the RTAI mailing list, was wondering if any of you guys could
check this out. I got PREEMPT_RT and RTAI patched to the same kernel but having
trouble building RTAI itself. I was hoping I could maybe get some help here so
we can have LinuxCNC switch between real-time POSIX threads and RTAI on the
same kernel removing the need to reboot. Not really a LinuxCNC question though,
please no ban.
Alec
- Forwarded Message -
From: Alec Ari
To: Rtai
Sent: Sunday, November 6, 2022 at 07:01:45 PM CST
Subject: Attempt at RTAI and PREEMPT_RT (same kernel)
Hello,
I patched the 5.4 PREEMPT_RT kernel source with IPIPE. The kernel boots and
PREEMPT_RT latency is under 20 microseconds, however upon building RTAI, I get
this:
make[4]: Entering directory '/home/ntu/RTAI/src/ipc/mbx'
CC [M] /home/ntu/RTAI/src/ipc/mbx/mbx.o
In file included from /home/ntu/RTAI/include/rtai_schedcore.h:42,
from /home/ntu/RTAI/src/ipc/mbx/mbx.c:40:
/home/ntu/RTAI/src/ipc/mbx/mbx.c: In function ‘rt_typed_mbx_init’:
./include/linux/spinlock_rt.h:17:16: error: passing argument 1 of
‘rt_typed_sem_init’ from incompatible pointer type
[-Werror=incompatible-pointer-types]
17 | rt_mutex_init(&(slock)->lock); \
| ^~
| |
| struct rt_mutex *
/home/ntu/RTAI/include/rtai_sem.h:244:58: note: in definition of macro
‘rt_mutex_init’
244 | #define rt_mutex_init(mtx) rt_typed_sem_init(mtx, 1, RES_SEM)
| ^~~
/home/ntu/RTAI/src/ipc/mbx/mbx.c:316:2: note: in expansion of macro
‘spin_lock_init’
316 | spin_lock_init(>lock);
| ^~
/home/ntu/RTAI/include/rtai_sem.h:113:47: note: expected ‘SEM *’ {aka ‘struct
rt_semaphore *’} but argument is of type ‘struct rt_mutex *’
113 | RTAI_SYSCALL_MODE void rt_typed_sem_init(SEM *sem,
| ~^~~
cc1: some warnings being treated as errors
make[6]: *** [scripts/Makefile.build:262: /home/ntu/RTAI/src/ipc/mbx/mbx.o]
Error 1
make[5]: *** [Makefile:1739: /home/ntu/RTAI/src/ipc/mbx] Error 2
The code in question in mbx.c is this line:
spin_lock_init(>lock);
from this function:
RTAI_SYSCALL_MODE int rt_typed_mbx_init(MBX *mbx, int size, int type)
{
if (!(mbx->bufadr = rt_malloc(size))) {
return -ENOMEM;
}
rt_typed_sem_init(&(mbx->sndsem), 1, type & 3 ? type : BIN_SEM | type);
rt_typed_sem_init(&(mbx->rcvsem), 1, type & 3 ? type : BIN_SEM | type);
mbx->magic = RT_MBX_MAGIC;
mbx->size = mbx->frbs = size;
mbx->owndby = mbx->waiting_task = NULL;
mbx->fbyte = mbx->lbyte = mbx->avbs = 0;
spin_lock_init(>lock);
#ifdef CONFIG_RTAI_RT_POLL
mbx->poll_recv.pollq.prev = mbx->poll_recv.pollq.next =
&(mbx->poll_recv.pollq);
mbx->poll_send.pollq.prev = mbx->poll_send.pollq.next =
&(mbx->poll_send.pollq);
mbx->poll_recv.pollq.task = mbx->poll_send.pollq.task = NULL;
spin_lock_init(&(mbx->poll_recv.pollock));
spin_lock_init(&(mbx->poll_send.pollock));
#endif
return 0;
}
This was spin_lock_init() from the vanilla kernel source:
#define spin_lock_init(_lock) \
do { \
spinlock_check(_lock); \
raw_spin_lock_init(&(_lock)->rlock); \
} while (0)
And this is spin_lock_init() from PREEMPT_RT:
#define spin_lock_init(slock) \
do { \
static struct lock_class_key __key; \
\
rt_mutex_init(&(slock)->lock); \
__rt_spin_lock_init(slock, #slock, &__key); \
} while (0)
How do I fix the pointer type?
It would be nice to have RTAI and PREEMPT_RT work together so one kernel can do
it all, no rebooting. I'm also curious if RTAI latency improves.
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RT preempt on Rockchip rk3328?
I could build a Gentoo image with PREEMPT_RT and hardware 3D acceleration with LinuxCNC using this: https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/log/?h=linux-6.1.y-rt=grep=rk3328 Coupled with a bleeding edge X.org stack (mesa etc) with all the codecs. The RK3328 uses a Mali-450MP4 which would fall under the Mesa3D Utgard driver: https://docs.mesa3d.org/drivers/lima.html Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI 5.3.3 Beta release for LinuxCNC (Needs testing, esp on Intel) Intel latency histo screenshots
Rainer, Thank you so much! I will add back in the ACPI power states for software shutdown capability and then roll out the 5.4 kernels. The crashing bug was actually fixed by Jepler, excessively unloading and reloading RTAI would cause crashes. Glad my FPU changes work on Intel! Alec On Friday, November 4, 2022 at 12:40:06 PM CDT, Rainer Stelzer wrote: screenshots have been stripped, i guess because of the size . I put them here: https://www.ibstelzer.de/startseite/linux-rtai-latency-tests cheers Rainer > Hi Alec, > first thank you for your time and effort. > really appreciate it. > > I tested with 6 Intel (3x I5 & 3x Atoms) and 1 AMD CPU on > motherboards from different vendors. > (I've one further Fujitsu Industrial ITX board with a Pentium J5005 > here, but this insists of booting with UEFI.) > Attached the histogram screenshots. > > I started linuxcnc RIP and picked latency histogram from the menu. > > Works fine so far, but in rare cases elapsed time counter stopped > increasing, while the other program functions still work. > So i was able to exit and restart. > > Whats very nice, that on all machines starting, stopping and restating > programs that use RTAI is no problem anymore. > That wasn't the case in the past. > Back then in most cases the machine freezes and had to be rebooted. > annoying when doing RTAI depending development. > > My own RIP Source didn't compile against the new kernel, but it has > not been synced to the master for roughly one year. > Fixing this will be may next task and then I'll switch to the new kernel. > > Thanks again. > > Rainer > > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] RTAI 5.3.3 Beta release for LinuxCNC (Needs testing, esp on Intel)
Hi everyone, I'll be working on kernel 5.4 RTAI packages for Debian Bullseye soon, just want to test these changes on different hardware before it rolls out. Please test rebooting and shutdown. I removed ACPI power states, this should improve performance but may require holding power button down after the system is halted as software shutdown may not work properly. Is this a problem for anyone and is software shutdown required? Debian packages: https://github.com/NTULINUX/RTAI/releases/tag/v5.3.3-beta To test LinuxCNC against it, you have to build from source for now: cd linuxcnc-git-tree/src ./autogen.sh ./configure --enable-non-distributable make sudo make setuid cd .. . ./scripts/rip-environment Then: latency-histogram Or: linuxcnc Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Hosting LinuxCNC Bullseye packages with non-distrib flag?
Hi Andy, That's fine if someone else packages LinuxCNC but they'll need to do against my latest debs (which I have yet to build.) I just wanted to help out so I'm not relying on other people's development time just for some testing. The plan is to move to the 5.4 kernel so the 4.19 debs would be just a final test before I roll out RTAI kernel 5.4 packages. Alec On Saturday, October 29, 2022 at 10:59:40 AM CDT, andy pugh wrote: On Sat, 29 Oct 2022 at 08:02, Alec Ari via Emc-developers wrote: > Hi everyone, > > So I'm trying to host LinuxCNC + RTAI packages for Bullseye but I have to use > --enable-non-distributable=yes and there is no libreadline-gplv2-dev package > in Bullseye. Is it really an issue to post a LGPL/GPL mixed package? Who > would actually be upset by a conflicting GPL/LGPL license compatibility thing? I don't know the answer to the licensing question. But would it be an answer to backport (frontport?) the Buster version via your repository? Also, would it make sense to host the packages on the LinuxCNC repository instead? -- 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, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Hosting LinuxCNC Bullseye packages with non-distrib flag?
Hi everyone, So I'm trying to host LinuxCNC + RTAI packages for Bullseye but I have to use --enable-non-distributable=yes and there is no libreadline-gplv2-dev package in Bullseye. Is it really an issue to post a LGPL/GPL mixed package? Who would actually be upset by a conflicting GPL/LGPL license compatibility thing? I made some changes to the 4.19 kernel and just want to make sure they work right on everyone's hardware interested in RTAI before working on the kernel 5.4 RTAI Debian packages. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI support for kernel 5.4 works so far, pending musl/math test
Firmware is always separate from kernel unless you build the firmware into the kernel image. Usually, you would only do this for kernel options that you decide to have built-in (i.e. CONFIG_DRM_I915=y) instead of as modules (=m) however distributions don't do this and instead build as modules. When building firmware into the kernel image, you still need to have the firmware installed separately, then after the image is built, you can discard the firmware files. Reasons you may want to do this is so you can have a high resolution kernel console available before the kernel is able to load modules (i.e. before udev is loaded but you want kernel modesetting) but if you're not a kernel hacker, really no need. Probably too much info but now you know! Alec On Monday, October 24, 2022 at 10:43:52 PM UTC, Jon Elson wrote: On 10/24/22 15:28, Alec Ari via Emc-developers wrote: > Jon, > > You can actually grab the sid 6.0 kernel and drop it on Bullseye and perhaps > even Buster: > Yes, I actually did this on a Bullseye install. I also had to install the firmware files that didn't come in along with the new kernel for some reason. Now, the graphics all works! Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI support for kernel 5.4 works so far, pending musl/math test
Jon, You can actually grab the sid 6.0 kernel and drop it on Bullseye and perhaps even Buster: https://packages.debian.org/sid/linux-image-6.0.0-2-amd64 Firmware: https://packages.debian.org/sid/firmware-misc-nonfree Install: sudo dpkg -i linux-image-6.0.0-2-amd64_6.0.3-1_amd64.deb sudo dpkg -i firmware-misc-nonfree_20210818-1_all.deb The problem you may run into though is that the X.org driver stack may not be new enough. libdrm, mesa and xserver-xorg-video-intel Dropping kernels and firmware from other Debian releases shouldn't be a problem, if it doesn't work, you can just choose a different one on boot and remove it later. Once you start grabbing things like: https://packages.debian.org/sid/libgl1-mesa-dri Then you may start have issues. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI support for kernel 5.4 works so far, pending musl/math test
Warnings for 5.4 kernel, note: [-Wvla]
Reading 0/204 dependency files
Done reading dependencies
Reading 0/204 dependency files
Done reading dependencies
In file included from hal/utils/halcmd_commands.cc:40:
hal/utils/halcmd_commands.cc: In function ‘int do_loadrt_cmd(char*, char**)’:
./config.h:49:24: warning: ISO C++ forbids converting a string constant to
‘char*’ [-Wwrite-strings]
49 | #define EMC2_RTLIB_DIR "/home/ntu/linuxcnc/rtlib"
| ^~
hal/utils/halcmd_commands.cc:1110:30: note: in expansion of macro
‘EMC2_RTLIB_DIR’
1110 | static char *rtmod_dir = EMC2_RTLIB_DIR;
| ^~
hal/utils/halcmd_commands.cc:1130:22: warning: comparison of integer
expressions of different signedness: ‘int’ and ‘long unsigned int’
[-Wsign-compare]
1130 | } else if (r >= sizeof(mod_path)) {
| ~~^~~
emc/usr_intf/emclcd.cc: In function ‘int main(int, char**)’:
emc/usr_intf/emclcd.cc:494:52: warning: ‘%s’ directive output may be truncated
writing up to 3679 bytes into a region of size 1013 [-Wformat-truncation=]
494 | snprintf(sockStr, sizeof(sockStr), "widget_add %s %s %s\n",
widgets[i].screenName,
| ^~
In file included from /usr/include/stdio.h:867,
from emc/usr_intf/emclcd.cc:30:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:67:35: note:
‘__builtin___snprintf_chk’ output 15 or more bytes (assuming 3694) into a
destination of size 1024
67 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
| ~^~~
68 | __bos (__s), __fmt, __va_arg_pack ());
| ~
hal/components/carousel.comp: In function ‘_’:
hal/components/carousel.comp:329:15: warning: this statement may fall through
[-Wimplicit-fallthrough=]
hal/components/carousel.comp:330:5: note: here
hal/components/carousel.comp:367:15: warning: this statement may fall through
[-Wimplicit-fallthrough=]
hal/components/carousel.comp:368:5: note: here
hal/components/carousel.comp:440:15: warning: this statement may fall through
[-Wimplicit-fallthrough=]
hal/components/carousel.comp:441:5: note: here
hal/components/mesa_pktgyro_test.comp: In function ‘receive’:
hal/components/mesa_pktgyro_test.comp:74:2: warning: ISO C90 forbids variable
length array ‘Replyd3’ [-Wvla]
hal/components/mesa_pktgyro_test.comp: In function ‘extra_setup’:
hal/components/mesa_pktgyro_test.comp:177:2: warning: ISO C90 forbids variable
length array ‘read1’ [-Wvla]
hal/components/mesa_pktgyro_test.comp:178:2: warning: ISO C90 forbids variable
length array ‘read1_sizes’ [-Wvla]
In file included from /home/ntu/linuxcnc/src/rtapi/rtai_rtapi.c:76:
/home/ntu/linuxcnc/src/rtapi/rtapi_vsnprintf.h: In function ‘rtapi_vsnprintf’:
/home/ntu/linuxcnc/src/rtapi/rtapi_vsnprintf.h:426:12: warning: this statement
may fall through [-Wimplicit-fallthrough=]
426 | flags |= LARGE;
| ^
/home/ntu/linuxcnc/src/rtapi/rtapi_vsnprintf.h:427:2: note: here
427 | case 'x':
| ^~~~
/home/ntu/linuxcnc/src/hal/components/lcd.c: In function ‘write_one’:
/home/ntu/linuxcnc/src/hal/components/lcd.c:349:35: warning: this statement may
fall through [-Wimplicit-fallthrough=]
349 | inst->buff[1] = 0;
| ~~^~~
/home/ntu/linuxcnc/src/hal/components/lcd.c:351:17: note: here
351 | default: //check for hex
| ^~~
/home/ntu/linuxcnc/src/hal/components/lcd.c:373:16: warning: this statement may
fall through [-Wimplicit-fallthrough=]
373 | if (retval >= 0) {
| ^
/home/ntu/linuxcnc/src/hal/components/lcd.c:379:9: note: here
379 | default:
| ^~~
/home/ntu/linuxcnc/src/hal/components/lcd.c: In function ‘parse_fmt’:
/home/ntu/linuxcnc/src/hal/components/lcd.c:426:20: warning: this statement may
fall through [-Wimplicit-fallthrough=]
426 | if (c < 0 && d == 0){
| ^
/home/ntu/linuxcnc/src/hal/components/lcd.c:430:13: note: here
430 | case '1':
| ^~~~
/home/ntu/linuxcnc/src/hal/components/lcd.c:465:22: warning: this statement may
fall through [-Wimplicit-fallthrough=]
465 | base = 16;
| ~^~~~
/home/ntu/linuxcnc/src/hal/components/lcd.c:466:13: note: here
466 | case 'o':
| ^~~~
/home/ntu/linuxcnc/src/hal/components/lcd.c:467:20: warning: this statement may
fall through [-Wimplicit-fallthrough=]
467 | if (base == 10) base = 8;
| ^
/home/ntu/linuxcnc/src/hal/components/lcd.c:468:13: note: here
468 | case 'u':
| ^~~~
Re: [Emc-developers] RTAI support for kernel 5.4 works so far, pending musl/math test
To clarify, you still need to use M instead of SUBDIRS, but the "FATAL: parse error in symbol dump file" was 100% PEBKAC lol. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI support for kernel 5.4 works so far, pending musl/math test
Scratch that, I did a dumb thing with my build system. LinuxCNC works with RTAI 5.4 now, screenshot attached. WOOO! Alec___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI support for kernel 5.4 works so far, pending musl/math test
All the LinuxCNC kernel modules build now against 5.4 albeit with several VLA (variable length array) warnings and this fatal error at the very end: MODPOST 185 modules FATAL: parse error in symbol dump file make[2]: *** [scripts/Makefile.modpost:95: __modpost] Error 1 make[1]: *** [Makefile:1650: modules] Error 2 make[1]: Leaving directory '/home/ntu/linux-5.4.y' make: *** [Makefile:539: modules] Error 2 Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI support for kernel 5.4 works so far, pending musl/math test
Found the problem: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/Makefile?h=v5.4.219=7e35b42591c058b91282f95ce3b2cf0c05ffe93d Fix: diff --git a/src/Makefile b/src/Makefile index 96eba38334..047419d4bc 100644 --- a/src/Makefile +++ b/src/Makefile @@ -537,8 +537,8 @@ ifeq ($(BUILD_SYS),kbuild) modules: MAKEFLAGS="$(filter-out --warn-undefined-variables,$(MAKEFLAGS))" \ - $(PYTHON) modsilent.py $(MAKE) KBUILD_EXTRA_SYMBOLS=$(moduledir)/Module.symvers -C $(KERNELDIR) SUBDIRS=`pwd ` CC=$(CC) V=$(BUILD_VERBOSE) modules - -cp Module.symvers *$(MODULE_EXT) ../rtlib/ + $(PYTHON) modsilent.py $(MAKE) KBUILD_EXTRA_SYMBOLS=$(moduledir)/Module.symvers -C $(KERNELDIR) M=`pwd` CC=$ (CC) V=$(BUILD_VERBOSE) modules + -cp $(moduledir)/Module.symvers $(moduledir)/*$(MODULE_EXT) ../rtlib/ endif # These rules clean things up. 'modclean' cleans files generated by 'modules' ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI support for kernel 5.4 works so far, pending musl/math test
This error: > cp Module.symvers *.ko ../rtlib/ > cp: cannot stat 'Module.symvers': No such file or directory Is a red herring. Fix: diff --git a/src/Makefile b/src/Makefile index 96eba38334..374b4bf35d 100644 --- a/src/Makefile +++ b/src/Makefile @@ -538,7 +538,7 @@ ifeq ($(BUILD_SYS),kbuild) modules: MAKEFLAGS="$(filter-out --warn-undefined-variables,$(MAKEFLAGS))" \ $(PYTHON) modsilent.py $(MAKE) KBUILD_EXTRA_SYMBOLS=$(moduledir)/Module.symvers -C $(KERNELDIR) SUBDIRS=`pwd` CC=$(CC) V=$(BUILD_VERBOSE) modules - -cp Module.symvers *$(MODULE_EXT) ../rtlib/ + -cp $(moduledir)/Module.symvers $(moduledir)/*$(MODULE_EXT) ../rtlib/ endif # These rules clean things up. 'modclean' cleans files generated by 'modules' LinuxCNC doesn't initialize the build process for the kernel modules at all, that's what's wrong: Reading 204/204 dependency files Done reading dependencies MAKEFLAGS="" \ /usr/bin/python3.9 modsilent.py make KBUILD_EXTRA_SYMBOLS=/usr/realtime/modules/Module.symvers -C /lib/modules/5.4.219-rtai-amd64+/build SUBDIRS=`pwd` CC=gcc V=0 modules make[1]: Entering directory '/home/ntu/linux-5.4.y' CALL scripts/checksyscalls.sh CALL scripts/atomic/check-atomics.sh Building modules, stage 2. MODPOST 33 modules make[1]: Leaving directory '/home/ntu/linux-5.4.y' cp /usr/realtime/modules/Module.symvers /usr/realtime/modules/*.ko ../rtlib/ You now need to run 'sudo make setuid' in order to run in place. What do? Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI support for kernel 5.4 works so far, pending musl/math test
I can't use 2.8 because master has all of the things I need. I'll try a few things though, thanks! Alec On Friday, October 21, 2022 at 04:53:24 PM UTC, andy pugh wrote: On Fri, 21 Oct 2022 at 17:38, Alec Ari via Emc-developers wrote: > cp Module.symvers *.ko ../rtlib/ > cp: cannot stat 'Module.symvers': No such file or directory Seems to be here: https://github.com/LinuxCNC/linuxcnc/blob/master/src/Makefile#L539 Poking about in configure.ac it looks like you can specify MODULE_DIR (and hence moduldir) with --with-module-dir in the configure command. This looks like a hangover from the removal of RTAI, so the easiest way for your current testing might well be to compile 2.8 instead? -- 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, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI support for kernel 5.4 works so far, pending musl/math test
Trying to build LinuxCNC right now against the 5.4 kernel but ran into this, stuck now: Reading 204/204 dependency files Done reading dependencies MAKEFLAGS="ik -j4 --jobserver-auth=3,4" \ make KBUILD_EXTRA_SYMBOLS=/usr/realtime/modules/Module.symvers -C /home/ntu/linux-5.4.y SUBDIRS=`pwd` CC=gcc V=0 modules make[1]: Entering directory '/home/ntu/linux-5.4.y' CALL scripts/atomic/check-atomics.sh CALL scripts/checksyscalls.sh CHK include/generated/compile.h Building modules, stage 2. MODPOST 397 modules make[1]: Leaving directory '/home/ntu/linux-5.4.y' cp Module.symvers *.ko ../rtlib/ cp: cannot stat 'Module.symvers': No such file or directory cp: cannot stat '*.ko': No such file or directory make: [Makefile:540: modules] Error 1 (ignored) You now need to run 'sudo make setuid' in order to run in place. ntu@ntu:~/linuxcnc/src$ stat ~/linux-5.4.y/Module.symvers File: /home/ntu/linux-5.4.y/Module.symvers Size: 534944 Blocks: 1048 IO Block: 4096 regular file Device: 806h/2054d Inode: 831382 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ ntu) Gid: ( 1000/ ntu) Access: 2022-10-21 11:16:59.828423939 -0500 Modify: 2022-10-21 11:14:36.349885329 -0500 Change: 2022-10-21 11:14:36.349885329 -0500 Birth: 2022-10-21 11:14:34.429892605 -0500 ntu@ntu:~/linuxcnc/src$ stat /usr/realtime/modules/Module.symvers File: /usr/realtime/modules/Module.symvers Size: 25155 Blocks: 56 IO Block: 4096 regular file Device: 806h/2054d Inode: 830595 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2022-10-21 11:18:14.981231215 -0500 Modify: 2022-10-21 11:18:14.981231215 -0500 Change: 2022-10-21 11:18:14.981231215 -0500 Birth: 2022-10-21 11:18:14.981231215 -0500 Any ideas? Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] RTAI support for kernel 5.4 works so far, pending musl/math test
Success log: https://mail.rtai.org/pipermail/rtai/2022-October/028319.html I need to patch my RTAI repository to account for the 5.4 changes and test musl in kernel space. Intensive floating point arithmetic in the 5.4 kernel has yet to be tested. LinuxCNC may require some changes as well. I will let the LinuxCNC development team know when it's all set! Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] RTAI FPU re-write testing
I took the initiative of re-writing the RTAI FPU handling code and removing what bits I found unnecessary. I'd like these changes to be tested on other systems, the FPU seems to work fine here. I made a new branch called `fpu-rewrite` and contains the following changes: https://github.com/NTULINUX/RTAI/commit/a2ca854881137db4d951a1cb44999f7bb53c292f https://github.com/NTULINUX/RTAI/commit/84afa92a5890f7933eb875154c37931f13f795b2 The point of this was to simplify the FPU code so porting it to 5.4 would be much easier, however some of this may be very fragile so requires testing. Thanks! Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC + LXRT (RTAI) results
Ah ok! Haha, yeah Jeff asked me the same thing. Alrighty! On Tuesday, October 11, 2022 at 05:18:13 PM CDT, andy pugh wrote: On Tue, 11 Oct 2022 at 02:07, Alec Ari via Emc-developers wrote: > > Why were people asking me to test LXRT? Was it not working for other people, > or just poor latency? Who asked? I see that I did, on the 11th of September. I think I was just curious if it worked with your new kernel or if it was in some way dependent on the older one. -- 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, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC + LXRT (RTAI) results
C'mon guys, I'm on pins and needles over here. On Monday, October 10, 2022 at 08:04:48 PM CDT, Alec Ari via Emc-developers wrote: Why were people asking me to test LXRT? Was it not working for other people, or just poor latency? Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC + LXRT (RTAI) results
Why were people asking me to test LXRT? Was it not working for other people, or just poor latency? Alec On Monday, October 10, 2022 at 09:08:58 AM UTC, andy pugh wrote: On Mon, 10 Oct 2022 at 01:06, Alec Ari via Emc-developers wrote: > > Oh! Once RTAI is installed (both kernel and modules) and you're booted into > your RTAI kernel, when you build LinuxCNC, you just force to use uspace on > the ./configure line: > > ./configure --with-realtime=uspace You can also use the pre-built uspace packages (built on the preempt-rt kernel) if you install the linuxcnc-usapce-rtai pre-built package too. -- 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, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC + LXRT (RTAI) results
Oh! Once RTAI is installed (both kernel and modules) and you're booted into your RTAI kernel, when you build LinuxCNC, you just force to use uspace on the ./configure line: ./configure --with-realtime=uspace This way, LinuxCNC will not build modules (.ko) against your kernel, but rather use LXRT. RTAI Debian packages: http://linuxcnc.org/dists/bullseye/base/binary-amd64/ Or: https://github.com/NTULINUX/RTAI/releases/tag/v5.3.2 For this test, I bumped the kernel to 4.19.261 and made a minor Kconfig change to prevent some possible build errors but I don't think this really matters. I also loaded the Debian Buster 4.19 kernel config instead of Stretch. I think new debs should be published though to reflect these changes as minor as it may be. I'll get around to it. Alec On Sunday, October 9, 2022 at 08:09:54 AM CDT, Thomas J Powderly wrote: Thx Alec I was just prodding you, don't worry about it. i don't know how to build using the info you posted since my bench if full I'll wait for a howto ( at best i found out that hansu was not Chinese :-) tomp On 10/9/22 2:30 PM, Alec Ari via Emc-developers wrote: > I can do more extensive testing. I wasn't sure what the problem was before > that people were having but it at least runs for me. > > > Alec > > > > > > > On Sunday, October 9, 2022 at 12:08:51 AM CDT, Thomas J Powderly > wrote: > > > > > > wow > > but 61 secs? > > from missouri > > :-) > > still impressive > > tomp > > On 10/9/22 11:32 AM, Alec Ari via Emc-developers wrote: >> Note: Using LXRT realtime >> >> Pic attached (not sure if mailing list accepts pictures, CC'ing to Bari to >> post on forums if necessary) >> >> Alec >> >> >> ___ >> Emc-developers mailing list >> Emc-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-developers > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC + LXRT (RTAI) results
I can do more extensive testing. I wasn't sure what the problem was before that people were having but it at least runs for me. Alec On Sunday, October 9, 2022 at 12:08:51 AM CDT, Thomas J Powderly wrote: wow but 61 secs? from missouri :-) still impressive tomp On 10/9/22 11:32 AM, Alec Ari via Emc-developers wrote: > Note: Using LXRT realtime > > Pic attached (not sure if mailing list accepts pictures, CC'ing to Bari to > post on forums if necessary) > > Alec > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] LinuxCNC + LXRT (RTAI) results
Note: Using LXRT realtime Pic attached (not sure if mailing list accepts pictures, CC'ing to Bari to post on forums if necessary) Alec___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC + LXRT (RTAI) results
Final note, sorry for all the emails, is that I compiled LinuxCNC myself using the following params: ./configure --with-realtime=uspace --enable-non-distributable=yes On LinuxCNC commit: c66ae6dfa56a4ce20f8ffa5e4e1aa55aabdf4bf5 Merge pull request #2084 from hansu/man-ascii-images Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC + LXRT (RTAI) results
One of the things I keep having to do is run `sudo rmmod rtai_sched rtai_hal rtai_math` because `halrun -U` doesn't work and LinuxCNC/latency-histogram keeps saying RTAI is already loaded. While annoying, it _does_ work fine for me, and this is without having to add back in liblxrt to my RTAI tree. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC 2.8.2 Debian 10 Buster PREEMPT-RT ISO can't install Grub
Sorry for all the emails, just wanted to clarify, `isohybrid` comes from the `syslinux-utils` package: https://packages.debian.org/bullseye/amd64/syslinux-utils/filelist -> /usr/bin/isohybrid Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC 2.8.2 Debian 10 Buster PREEMPT-RT ISO can't install Grub
`isohybrid -s 63 -h 255 ` will dual boot. -s 63 -h 255 is to ensure compatibility and proper sector/head (geometry) alignment. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC 2.8.2 Debian 10 Buster PREEMPT-RT ISO can't install Grub
I should note that if you boot systemrescuecd, to boot using UEFI (not legacy) otherwise the ISO will not be able to change the UEFI boot loader either. `isohybrid --uefi ` then disabling CSM in BIOS settings is a good way to make sure legacy is not used. If you installed Debian using legacy (not UEFI) then installing GRUB-PC (grub-i386 or whatever) the old fashioned way will suffice: grub-install --no-floppy --recheck /dev/sda (change /dev/sda to your block device, do not specify partition) If doing through systemrescuecd with legacy BIOS, you just need to make sure /dev /sys /proc and /boot (if applicable) are mounted, none of these need to be recursive if legacy (bind is fine, no need for rbind) Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC 2.8.2 Debian 10 Buster PREEMPT-RT ISO can't install Grub
In short, PREEMPT_RT disabled EFI runtime, meaning efibootmgr does not work. GRUB uses efibootmgr to set the UEFI boot loader to itself and manages this internally by `grub-install` 1.) Set `efi=runtime` on kernel command line (not required if using systemrescuecd) 2.) Boot into Debian. If you do not have access to the Debian system due to boot loader not being installed correctly or missing, then: 2b.) Boot systemrescuecd 2c.) Mount Debian root filesystem, EFI partition and boot partition. i.e. /dev/sda1 - 100MB - EFI system partition (/efi) /dev/sda2 - 2GB - Linux filesystem (/boot) /dev/sda3 - 100GB - Linux root filesystem (x86-64) (/) With the above partition layout (`fdisk -l` to print current table) chroot and mount like so: mkdir -p /mnt/debian mount /dev/sda3 /mnt/debian mount /dev/sda1 /mnt/debian/efi mount /dev/sda2 /mnt/debian/boot mount -t proc none /mnt/debian/proc mount --rbind /dev /mnt/debian/dev mount --rbind /sys /mnt/debian/sys mount --bind /run /mnt/debian/run chroot /mnt/debian /bin/bash source /etc/profile && ldconfig Note `bind` for /run and `rbind` for /dev and /sys this is so /dev and /sys and mounted recursively (i.e. /sys/firmware and /sys/firmware/efivars are mounted too) 3.) Install GRUB with UEFI: grub-install --target=x86_64-efi --efi-directory=/efi 4.) Generate GRUB config file: grub-mkconfig -o /boot/grub/grub.cfg Change EFI path and all partitions accordingly. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Time to split 2.9 and master?
To clarify, I wasn't implying it meant anything different. The SIGFPE problem is fixed anyway so disregard my previous email. Alec On Wednesday, September 21, 2022 at 10:47:34 AM CDT, andy pugh wrote: On Wed, 21 Sept 2022 at 15:05, Chris Morley wrote: > I think we should make the branch now. Making the branch does not preclude > doing finishing work in the branch. Indeed, it just makes "master" back into more of a testing playground. -- 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, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Time to split 2.9 and master?
Ah, it's already fixed: https://github.com/LinuxCNC/linuxcnc/commit/9471c059d133f7d14363f6a7cdcf87a4de4666e6 On Wednesday, September 21, 2022 at 03:55:44 AM UTC, Alec Ari via Emc-developers wrote: I think fixing the SIGFPE (signal 8 error, floating point exception) should be fixed as well prior to the branch point. Can RTAI be a milestone before the final 2.9 release btw? Thanks, Alec On Wednesday, September 21, 2022 at 02:21:16 AM UTC, Phill Carter wrote: > On 21 Sep 2022, at 6:59 am, andy pugh wrote: > > Is it time to split 2.9 off as a stable-ish branch with a 2.9.0~pre0 tag? I have some plasmac work that I would like to push before that happens. It should be completed by the end of this month. I also have a question regarding packaging. Is there any good reason that we have a separate "-dev" package ? Cheers, Phill > -- > 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, 1912 > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Time to split 2.9 and master?
I think fixing the SIGFPE (signal 8 error, floating point exception) should be fixed as well prior to the branch point. Can RTAI be a milestone before the final 2.9 release btw? Thanks, Alec On Wednesday, September 21, 2022 at 02:21:16 AM UTC, Phill Carter wrote: > On 21 Sep 2022, at 6:59 am, andy pugh wrote: > > Is it time to split 2.9 off as a stable-ish branch with a 2.9.0~pre0 tag? I have some plasmac work that I would like to push before that happens. It should be completed by the end of this month. I also have a question regarding packaging. Is there any good reason that we have a separate "-dev" package ? Cheers, Phill > -- > 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, 1912 > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI 5.3.2 release for LinuxCNC (Debian packages already available)
Thank you! I opened up a LinuxCNC bug report in regards to commit 6f285604ac1a1b58b2d65d5904ffec3998a833ef https://github.com/LinuxCNC/linuxcnc/issues/2052 Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] linuxcnc on raspberry pi bullseye?
Yeah, with Gentoo you could really get that latency down especially with a custom 6.0 kernel, but too many people are focused on mocking compiling times. On Friday, September 16, 2022 at 05:03:42 PM UTC, Sebastian Kuzminsky wrote: On 9/14/22 15:35, Rod Webster wrote: > > https://raspi.debian.net/tested-images/ This is awesome! I tried the "2022-08-08" Bookworm image for Raspberry Pi 4. The image is for the arm64 architecture. Everything seems to work fine on a Raspberry Pi 4B, including wifi, GUI, and the serial console. After `apt-get install linuxcnc-uspace linux-image-rt-arm64` and a little bit of tweaking, I'm now getting latencies around 150 µs, which is not as good as the Raspbian Buster armhf image at linuxcnc.org (~70 µs latency) but probably acceptable. It's neat that there are several easy(-ish), usable options for LinuxCNC on Raspberry Pi now. -- Sebastian Kuzminsky ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] linuxcnc on raspberry pi bullseye?
I would just build from source so I can fine tune for the lowest latency, and have the latest 3D support. Note the following: https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/log/drivers/gpu/drm/v3d?h=linux-6.0.y-rt 6.0-rc5-rt7 has: drm/v3d: Add support for bcm2711 However: https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/log/drivers/gpu/drm/v3d?h=v5.15-rt Does not: https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/log/drivers/gpu/drm/v3d?h=v5.15-rt=grep=bcm2711 Go 6.0! Alec On Wednesday, September 14, 2022 at 06:55:18 PM UTC, Sebastian Kuzminsky wrote: Hi folks, with all the attention that newer distros have been getting lately, I'm looking in to running LinuxCNC On the Bullseye version of Raspberry Pi OS (aka Raspbian) on a Raspberry Pi 4B. It looks super straight-forward, except for the realtime kernel (as usual). I don't see a modern kernel built with Preempt-RT enabled in the raspbian bullseye package archive... Does anyone know if there's a well-liked pre-built official or community-supported Rpi4 realtime kernel somewhere? Or do I have to reconfigure & rebuild the "official" kernel? -- Sebastian Kuzminsky ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
