I don't think that qtpyvcp is going anywhere anytime soon. It's great!
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
You can always try pci=nomsi
Please see this guide:
https://github.com/NTULINUX/RTAI/blob/master/README.INSTALL
And note the following message:
IMPORTANT: The RTAI kernel packages, RTAI modules and LinuxCNC itself must all
be built against each other. If any modification is made to the
It's a common mistake! RTAI looks good now.
On Tuesday, September 13, 2022 at 07:43:33 AM UTC, Betibeteka Beranduetxea
wrote:
Ooops... turns out the machine was started with another non-RTAi
kernel. Rebooted and this is what it gives after some 10 minutes:
OVL min: -462 OVL max: 10620
`dmesg | grep -e "rtai" -e "RTAI"` because now I forget the exact case lol
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
That usually means RTAI isn't configured right, are you sure you built the RTAI
kernel modules against your currently running kernel?
What does `dmesg | grep "rtai"` return when you try and load the testsuite?
Alec
On Tuesday, September 13, 2022 at 02:12:02 AM CDT, Betibeteka Beranduetxea
/usr/realtime*/testsuite/run I think it is.
`find /usr/realt*/* -name "run"` to be safe lol
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
I used an asterisk as a wild card. I forget what it is off hand but there's
more text after the "realtime"
i.e.
`find /usr -name "realtime" -type d`
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
Did you install my packages or build from source btw?
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Just curious, what results do you get when you run the RTAI testsuite?
`/usr/realtime*/bin/run` with root privileges? After a few minutes, what's the
max latency?
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
999570 ns max servo jitter should never happen with PREEMPT_RT or RTAI.
Have you looked over this and your BIOS settings?
https://github.com/NTULINUX/RTAI/blob/master/README.BIOS
Alec
___
Emc-developers mailing list
I have not, I'll try recompiling LinuxCNC at some point. ./configure
--with-realtime=uspace right?
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Hello everyone!
I have updated RTAI to kernel 4.19.257 and have generated all new Debian
Bullseye/11 packages and they are hosted on Github:
https://github.com/NTULINUX/RTAI/releases/tag/v5.3.2
The only files you really need are:
linux-image-4.19.257-rtai-amd64_4.19.257-rtai-amd64-1_amd64.deb
via Emc-developers wrote:
> Just wanted to let everyone know that this is now fixed. RTAI on Debian
> Bullseye/11 will be pretty easy now.
>
> Alec
>
>
> ___
> Emc-developers mailing list
> Emc-developers@li
Just wanted to let everyone know that this is now fixed. RTAI on Debian
Bullseye/11 will be pretty easy now.
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
I made this modification:
diff --git a/src/Makefile b/src/Makefile
index a11d9e379f..7bb960f105 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -539,7 +539,7 @@ ifeq ($(BUILD_SYS),kbuild)
modules:
MAKEFLAGS="$(filter-out --warn-undefined-variables,$(MAKEFLAGS))" \
- $(PYTHON)
RTAI build output with `make V=1`, note the following messages:
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (
\
echo >&2; \
echo >&2 " ERROR: Kernel configuration is invalid."; \
echo >&2 "
LinuxCNC build output with `make -ki`:
ntu@ntu-debian:~/linuxcnc/src$ make -ki
Reading 204/204 dependency files
Done reading dependencies
MAKEFLAGS="ik" \
/usr/bin/python3.10 modsilent.py make
KBUILD_EXTRA_SYMBOLS=/usr/realtime/modules/Module.symvers -C /home/ntu/linux
SUBDIRS=`pwd` CC=gcc V=0
Error with `make V=1` within LinuxCNC:
ntu@ntu-debian:~/linuxcnc/src$ make V=1
Reading 204/204 dependency files
Done reading dependencies
Linking python module linuxcnc.so
g++ -L/home/ntu/linuxcnc/lib -Wl,-rpath,/home/ntu/linuxcnc/lib -ltirpc -shared
-o ../lib/python/linuxcnc.so
You can try adding pci=nomsi to the kernel command line / parameters.
i.e.:
GRUB: linux /boot/vmlinuz-4.19-195-rtai root=/dev/blahblah pci=nomsi
Cheers!
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
Fixed, thanks!
https://github.com/NTULINUX/ntu_overlay/commit/a396ce3b87d5dcb9c67d56a53cfac17a0941a85e
LinuxCNC now starts consistently!
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
Configs show up now, but now there's a new problem:
ntu@ryzen ~ $ linuxcnc
LINUXCNC - 2.9.0~pre0
Machine configuration directory is '/home/ntu/linuxcnc/configs/sim.axis'
Machine configuration file is 'axis.ini'
can't find package Linuxcnc
while executing
"package require Linuxcnc "
(file
Ah.. Gentoo compresses all documentation by default:
ntu@ryzen ~ $ ls /usr/share/doc/linuxcnc/examples/sample-configs/sim/axis/
README.bz2 foam ini_with_includes
ldelta_demo_es.txt.bz2 rdelta.ini.bz2
README_es.bz2 gantry
So I fixed the symlink but none of the other configs are actually showing up,
this is what I added:
https://github.com/NTULINUX/ntu_overlay/commit/5e07d93a625f2acd459c85e7a6c427718f857457
Does anything look odd here?
ntu@ryzen ~/ntu_overlay $ ls -la /usr/share/doc/linuxcnc/examples/*/*
I think the problem here is actually a symlink to nc_files that the Gentoo
package manager is breaking somehow rather than the .ini files in
/usr/share/doc.
Need to figure out where it wants it and what's missing.
Current installation:
ntu@ryzen ~ $ ls -la
I have a LinuxCNC ebuild now for Gentoo but there's a problem. All of the
config files are missing (i.e. sim axis) so these need to be forced to be
installed in the ebuild. Gentoo doesn't like it and there's going to be a lot
of QA notices by the time the ebuild is finished because
via Emc-developers:
> I get the same error on Debian with both iopl and ioperm function tests...
> Not sure how LinuxCNC is working anymore on anything..
>
> Alec
___
Emc-developers mailing list
Emc-developers@lists.sourcefor
Hi Andy,
Having CONFIG_X86_IOPL_IOPERM disabled was the problem, took me a bit to figure
it out.
Hi Tom,
5.19-rc7-rt7 was the kernel version (PREEMPT_RT linux-rt-devel git sources,
custom kernel on Gentoo, amd64 architecture) RTAI on ARM hasn't been touched
since around 2011 (at least in
I ran `uname -r` after the iopl and ioperm example tests failed and saw it
booted my custom Debian kernel.. I reboot, select the Debian 5.18 bpo
(backported) kernel and the tests return:
status: 255
So I thought OK... Either something changed between 5.18 and 5.19 or I'm
missing something in
I get the same error on Debian with both iopl and ioperm function tests... Not
sure how LinuxCNC is working anymore on anything..
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
The example code I pasted earlier didn't compile, and I made a few changes.
/*
* iopl.c: very simple example of port I/O
*
* This code does nothing useful, just a port write, a pause,
* and a port read. Compile with `gcc -O2 iopl.c -o iopl.o',
* and run as root with `./iopl.o'.
*/
#include
Hey everyone,
I've been at this all day and I'm stuck.. I run `sudo make setuid` after
compiling LinuxCNC master branch and then I run latency-test and then I get
this error (the latency-test window still comes up):
cannot gain I/O privileges - forgot 'sudo make setuid' or using secure boot?
Oh, one more thing! You can only build the Linux kernel right now with LTO
(either Full LTO or ThinLTO) using Clang. Pretty cool stuff!
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
Hah! I actually maintained Arch Linux packages for LinuxCNC in the AUR! I
switched to Gentoo years ago and never looked back!
So QtPyVCP can find everything through pip if need be?
As for Clang vs. GCC, AMD uses an internal fork of Clang as their own compiler
(AOCC) and I actually have an
I'll be working on a LinuxCNC git ebuild (Gentoo package) soon. qtpyvcp has a
LOT of dependencies, many of which may not even be included in Gentoo but I
haven't dug into this yet. I'd like to have both so people can make their own
GUIs on Gentoo as long as it doesn't mean I need to host 20+
Runtests results continued after hitting Ctrl+C on the hung:
/home/ntu/linuxcnc/tests/motion/g0
Running test: /home/ntu/linuxcnc/tests/motion/g0
^C*** /home/ntu/linuxcnc/tests/motion/g0: XFAIL: test run exited with 130
Running test: /home/ntu/linuxcnc/tests/motion/jogwheel-axis
Running test:
Side note: I also forced CC="clang" CXX="clang++" and LD="ld.lld" on my `make`
line as well, not sure if required but I did it on both that and `./configure`
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
Hey everyone,
Fantastic news! I've been getting LinuxCNC going on Gentoo, I had to port
yapps2 over and I applied the latest changes from Debian sid in my yapps2 fork:
https://github.com/NTULINUX/yapps2
The changes in 2.2.1-3.1 are in this commit:
No idea if this is related but the LinuxCNC for RTAI branch removes "liblxrt"
but not the main LXRT functions such as rtai_lxrt.h
Removed:
https://svn.savannah.gnu.org/viewvc/rtai/vulcano/base/sched/liblxrt/touchall.c?revision=4=markup
Ayoo,
There is no x86_64/amd64 in the kernel, x86 covers both:
64-bit assembly:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/x86/entry/entry_64.S?h=v4.19.251
32-bit:
Well, this is the kernel changelog:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/?id=v4.19.250=v4.19.195=2
3204 files changed, 33867 insertions, 16959 deletions
I'll update it and see what happens I guess!
Alec
___
Just pinging the thread again,
If I update the RTAI tree with the latest 4.19 kernel, would it be worth
anyone's while?
Thanks,
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
I just find it odd that you did this yet you're so eager to back-pedal on this
decision. Can you share your reasoning, I'm genuinely intrigued.
Thanks,
Alec
On Tuesday, June 28, 2022 at 12:48:05 PM UTC, Jeff Epler
wrote:
>You stated your preference at the time to not make the change and I
I think commit 6f285604ac1a1b58b2d65d5904ffec3998a833ef should be reverted and
then andypugh can make new RTAI debs as he is one of our most active
RTAI+LinuxCNC users/devs.
Andy, I should be able to bump the RTAI kernel to 4.19.249 (or whatever the
latest release will be when I get around to
Hello,
Just wanted to share this:
OpenGL is provided by mesa: https://packages.debian.org/source/sid/mesa
i.e.: https://packages.debian.org/sid/libgl1-mesa-dri (main package)
`glxgears` is provided by mesa-demos/mesa-utils:
https://packages.debian.org/source/sid/mesa-demos
i.e.:
gomath.c says the header is for providing `memset` but that function isn't in
rtapi_string.h:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/rtapi/rtapi_string.h
But rather inside the C library:
https://sourceware.org/git/?p=glibc.git;a=blob;f=include/string.h
I would submit pull requests on Github. Basically, fork LinuxCNC, make a commit
to your fork, then there's a button for make pull request:
https://www.digitalocean.com/community/tutorials/how-to-create-a-pull-request-on-github
Adding Clang support in LinuxCNC may be a way to detect previously
If it's easier for people to get RTAI working, I think that's great! Just note
that RTAI will still crash with the halrun/halcmd stress test after several
hundred runs. On a production system, this means every several hundred or so
LinuxCNC instances, the machine might hang. Maybe put a note
Oh, thanks Andy!
On Monday, August 16, 2021, 10:46:49 PM UTC, andy pugh
wrote:
On Mon, 16 Aug 2021 at 19:58, Alec Ari via Emc-developers
wrote:
>
> RTAI 5.3.1 for LinuxCNC is running pretty good right now with kernel
> 4.19.195. If you need lower latency, that is my sugg
RTAI 5.3.1 for LinuxCNC is running pretty good right now with kernel 4.19.195.
If you need lower latency, that is my suggestion. I don't know anything about
USC and it may not be compatible with the LinuxCNC RTAI hal drivers, throwing
this out there on a whim.
On Sunday, August 15, 2021,
It's a good thing I don't have commit rights because I'd have a hard time not
making a `tucker-carlson` branch just for kicks.
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
I'm fine with anything but `dev` is probably the best choice due to a better
representation of the purpose that branch serves. I fully agree.
Alec
On Thursday, July 29, 2021, 01:30:46 AM UTC, andy pugh
wrote:
I also object to "Main" as it isn't.
Neither name accurately describes the
Hi everyone,
Are there plans to switch the master branch to main? Just curious. I saw they
changed it for the Mesa3D git repo and that's the default now for Github.
https://cgit.freedesktop.org/mesa/mesa/
Cheers,
Alec
___
Emc-developers mailing
Hello,
Just curious, how would LinuxCNC detect a lack of precision in floating point?
There are trivial x86_64 specific math instructions which would probably be
faster than what LinuxCNC has used since the beginning but if these
instructions happened to be off by a few decimals somewhere, how
Oh cool, thanks!
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
One thing I noticed:
https://www.linuxcnc.org/dists/buster/base/binary-amd64/
linux-image-4.14.174..> 2020-09-04 11:30 29M
linux-image-4.19.195..> 2021-06-27 14:23 6.2M
Any idea why the 4.19.195 kernel is 23MB smaller? Maybe they switched to XZ
compression for bzImage and
Hi Andy,
Just wanted to check in and see how the debs are doing.
Thanks!
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Kirk said:
"In my view, the LinuxCNC user list has been too toxic to be involved
with for the last few years. It has been toxic long enough that the
usual suspects have grown used to their habits and don't know any
better. Fortunately for me, I have learned enough to fix whatever goes
wrong
> The problem is with what is perceived as acceptable and by whom.
> Different people perceive things differently based on their
> background,
> experiences, education, parenting, intelligence, age, environment,
> country they live in, etc. etc.
I'd like to add to this. If I was Kirk and
Is it considered harassment if I said you spent too much time on this instead
of doing something actually productive? I don't know where the line is and I
don't really want to read a whole page about not being a total dick. I help
people out with LinuxCNC and dedicated a lot of time on RTAI for
Lots of options are labeled as NEW even when then they've been in there for an
extremely long time, don't go by that all. When you reload a config, a lot of
those options will no longer say NEW. That's a menuconfig thing, not an actual
change to Kconfig source. I just ignore all of those.
The Multi-IO and PC-style hardware drivers date back at least to 2.6.12-rc2
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/parport/Kconfig?=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Alec
___
Emc-developers mailing list
Andy,
Which drivers? How new are we talking, like 5.4 kernel drivers?
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Heh! I will add PARPORT and PPDEV to the Kconfig patch the (0003 kernel patch)
to make sure this won't happen again.
Thanks!
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
So what was the PARPORT fix for you? What was the issue? Were they just turned
off? If you loaded the debian kernel config, then did debian actually disable
PARPORT in their upstream kernel?
Alec
___
Emc-developers mailing list
One more thing,
I believe PARPORT and PPDEV need to be built as modules only.
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Hi Andy,
LinuxCNC with RTAI always depends on CONFIG_PPDEV which depends on
CONFIG_PARPORT
That error is expected if that driver is off, previous versions it's the same
thing. For some reason, CONFIG_PARPORT and CONFIG_PPDEV are disabled. In the
past, you had those on hence no compiling
pugh wrote:
On Mon, 21 Jun 2021 at 13:34, Alec Ari via Emc-developers
wrote:
> I think that boils down to how important it is that it may crash after
> several hundred or a few thousand runs.
I don't think that is the question. The existing 4.14.174 kernel
package that we have availabl
Hi Andy!
>I am happy to build a new kernel + RTAI deb for the LinuxCNC repo if
>you think that 5.3.1 is worth it?
I think that boils down to how important it is that it may crash after several
hundred or a few thousand runs. If the abs.0 stress test is enough to steer you
away from RTAI then
I did the abs.0 stress test and it still dies out after about 300+ runs but
latency is lower for me without using `isolcpus` at all. The 5.4 kernel may fix
the abs issue but I've been busy with work so I don't have time to go through
that. RTAI 5.3.1 is stable with LinuxCNC in my opinion.
Hi everyone,
It's been awhile since I've worked on RTAI, I pushed a new release that comes
with a lot of bug fixes and clean-ups. The Xenomai developers have fixed a lot
of issues in IPIPE and Paolo recently added 5.4 kernel support to RTAI SVN. I
know there were some issues with the build bot
Hi Andy,
That's how a properly written dev package is supposed to work. linuxcnc-dev
should solve all build dependencies. Some may argue disk usage, but you'd run
Gentoo instead of Debian if that was your concern.
Alec
On Sunday, May 23, 2021, 10:21:36 PM UTC, andy pugh wrote:
Is
I am 100% for this. Please no more EOL Python 2 and EOL GTK+2.
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
I just wanted to put this out there that vanilla Mesa3D and PREEMPT_RT from
kernel.org support rpi4 GPU accel:
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/commit/?h=linux-5.10.y-rt=f437bc1ec731d3c8e45daecec7d89fc82bb76d12
Is there a particular reason to use that git tree over this:
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/log/?h=linux-5.10.y-rt
Just wondering, thanks!
Alec
___
Emc-developers mailing list
How far along is the Python 3 port? Is managing both the 2.8 and 2.9 branch
feasible considering the differences between Python 2 and 3?
Thanks,
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
What do you mean by overnight run? It ran the whole night then crashed at 29
when you restarted it? I'm going to try the abs test tomorrow, Tom_L had no
issues with the load/unload test and reached a little over 10,000 iterations
then called it a night. I'll also make deb packages with the
It seems the latest 4.19 IPIPE kernel patch has not only fixed the latency
spikes on my Ryzen hardware but the loading/unloading test is fixed as well.
Nothing is crashing anymore, can someone test out my latest changes?
I will still work on kernel 5.4 support but 4.19 is working perfect for
Hey everyone,
I know awhile back there was some issues with RTAI causing kernel panics, I'll
be working on kernel 5.4 support to see if the problem goes away. In the mean
time, the 4.19 kernel patch has been updated with the latest IPIPE code from
Xenomai.
Alec
>On the other hand, do we lose the LateX / texlive dependencies?
I would hope so, texlive is enormous.
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
xarchiver is very tiny and works very well, just my suggestion.
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Debugging can hurt latency, but that option is most likely fine so the "depends
on !IPIPE" line in lib/Kconfig.debug for "config DYNAMIC_DEBUG" can be removed.
Dynamic printk doesn't depend on DEBUG_KERNEL so that's easy to fix. When I get
around to it, I'll push that to the 4.19 and 4.14
Hi everyone,
Andy had trouble building Paolo's RTAI as-is so I'm taking over and re-creating
everything Paolo has on his end.
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
Paolo just emailed me and can't recreate the RTAI crash on his end. I asked
about his configuration and I'll be trying a few more things.
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
If you are "deterred from trying linuxcnc because its so dated" then go use
Mach4 so I don't need to listen to your complaining :)
X.org was old, so Wayland was invented. Sysvinit was old so SystemD was
invented. If you don't like the GUI for LinuxCNC because it looks old, you can
make your
Well, how often are isos made? If it's every 5 years or something like that,
then I'd say what's a few more weeks or a month? If Paolo doesn't respond or
can't figure it out in time for us, and there's a big need for a new iso right
away, then leaving it out of the disc image wouldn't be a bad
Thanks Andy. It would be a shame if all of the RTAI support in LinuxCNC
disappeared because of a bug. Has Paolo looked into this? Has anyone asked him?
On a side note, if your machine has a problem, do you just junk it or try to
work through it?
___
So there are a few people here that care about my efforts, which is great and I
thank you for that, but if RTAI support gets removed from LinuxCNC, it all
becomes meaningless, and it will most likely never enter the tree again after
that point. Paolo is not aware of this bug yet, and I don't
If the crash happens with this, then Poalo would definitely look into it:
#!/bin/bash
for PASS in $(seq 1 10); do
echo starting pass ${PASS}
insmod /usr/realtime-4.14.174-rtai-amd64/modules/rtai_hal.ko
insmod /usr/realtime-4.14.174-rtai-amd64/modules/rtai_sched.ko
rmmod
I want what I want because I'm five and I want it now. I spent 6 years working
my ass off on RTAI and none of you could give a fuck less.
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
Slackware may not have Slackbuilds for all the LinuxCNC dependencies but you
can try the following:
https://slackbuilds.org/repository/14.2/libraries/PyOpenGL/
This may not be it or offer any benefit, you're going to need to do some
research or some compiling on your own.
LinuxCNC's
LinuxCNC + FreeBSD + grbl/Arduino? That would be the only way, right?
Alec
On Sunday, April 26, 2020, 6:56:40 PM CDT, Sebastian Kuzminsky
wrote:
On 4/26/20 5:30 AM, andy pugh wrote:
> A question raised in issue #695
> https://github.com/LinuxCNC/linuxcnc/issues/695
>
> LinuxCNC
Kconfig fixed, pull request merged (doc fixes for 4.19) all is looking good
now. Woo!
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
I made the fix look like more sense:
https://github.com/NTULINUX/RTAI/commit/69e687f5e13bbf8197453bb12b5c28f39268dfc4
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
Sure, I can forcibly disable that without a problem! So glad that Paolo was
able to figure out what was going on. I pushed the fix into the tree, and made
it look like it makes more sense.
Alec
___
Emc-developers mailing list
The fix works here!
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Paolo has a fix, I will try this! Yay!
Alec
- Forwarded Message -
From: Paolo Mantegazza
To: Alec Ari ; RTAI RTAI
Sent: Friday, April 17, 2020, 2:59:20 PM CDT
Subject: RE: [Rtai] Fw: [Emc-developers] Kernel 4.19 series now added to RTAI
for LinuxCNC
The fix should be this:
---
Do _not_ put any 4.19 RTAI stuff in 2.8 branch!
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Yes, now what do we do about it? I need ideas!
Alec
On Tuesday, April 14, 2020, 8:40:40 PM CDT, andy pugh
wrote:
if (rtapi_data == (rtapi_data_t*)-1) rtapi_print_msg(RTAPI_MSG_ERR,
"rtapi_data* = -1\n");
is printing, to -1 is coming back from rtai_malloc (we were there a
few days
I've been working away trying to figure it out, and I can't. Are we sure this
is an invalid pointer? I'm going to try running a shared memory test from
RTAI's showroom and see if it works there.
If it doesn't work, then maybe I can figure this out as it'll be an RTAI
problem.
If it does work,
Well, this is a problem..
latency-test:
RTAPI: ERROR: could not open shared memory (Bad address)
HAL: ERROR: could not initialize RTAPI
halcmd: hal_init() failed: -22
NOTE: 'rtapi' kernel module must be loaded
RTAPI: ERROR: could not open shared memory (Bad address)
HAL: ERROR: could not
101 - 200 of 272 matches
Mail list logo
