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)
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
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
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
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)
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
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
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:
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
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
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
___
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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/Linux
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
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
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
/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
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
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
>
:
> 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 Gento
.
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 Cla
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
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.
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
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
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
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...
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 ins
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
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
Subject
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
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 (an
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,
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
> environm
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
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
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
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
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
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
F
> 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
>
, 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
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
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
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
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
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
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
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
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
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
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**)’:
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
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
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]: ***
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 @@
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)
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:
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`
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
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:
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,
>
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
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
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 s
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
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
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
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
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
`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
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
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
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
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
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
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
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:
>
>
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
1 - 100 of 272 matches
Mail list logo
