Hi ,
I was going to try 2.5 but I am getting this error, after
downloading and patching.
Compiling realtime hal/drivers/hal_ax5214h.c
hal/drivers/hal_ax5214h.c:104:20: error: asm/io.h: Filen eller
katalogen finns inte
can't find the file or catalog ... what I am interested in is that I
Hi Lars,
I was going to try 2.5 but I am getting this error, after
downloading and patching.
Compiling realtime hal/drivers/hal_ax5214h.c
hal/drivers/hal_ax5214h.c:104:20: error: asm/io.h: Filen eller
katalogen finns inte
Can you trace the steps you took to get here? I can
Okie, I will have a look, it might be mu include files or links
One thing, I have a version that is 2.6~pre so I might have
messed up my pull from git . I believe I should have a 2.5
The patches applied though ...
/ regards ... and thanks ...
2012/4/28 andy pugh
Hi Charles,
I
have been unable to figure out the problem, but I can replicate your
results here. The previous commit works, while this one fails.
I did try running under valgrind and with MALLOC_CHECK_ set to 3, but
didn't get anything useful (to my eyes, anyway). Interestingly, I did
Hi Lars,
On 04/28/2012 01:26 PM, Lars Segerlund wrote:
Okie, I will have a look, it might be mu include files or links
One thing, I have a version that is 2.6~pre so I might have
messed up my pull from git . I believe I should have a 2.5
The patches applied though
Hi list,
This works nicely to reproduce the problem, except it does something
weird for me:
[blah blah blah]
Stops working for me. I'm probably missing something obvious
Something obvious, indeed:
halcmd -h
[...]
-RRelease mutex (for crash recovery only).
Now to go find out
On 4/28/2012 2:53 PM, John Morris wrote:
Hi Charles,
I
have been unable to figure out the problem, but I can replicate your
results here. The previous commit works, while this one fails.
I did try running under valgrind and with MALLOC_CHECK_ set to 3, but
didn't get anything useful (to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/28/2012 1:53 PM, John Morris wrote:
snip
From the debugging side, neither of my tacks have gotten very far.
I've never done anything terribly difficult with C, gdb or
assembly before, so I've been reading docs at every step.
I'm in the
Hard-working priests of the god IBM,
Here is my news:
I had a very hard look at the diff between the 2 commits that John so
diligently found by bisecting
the non-working one has basically only one addition:
Jeff Eppler did this (the commit message):
defer
I started looking at funnydiff.txt and found something funny with it:
The man page for stdarg (man stdarg) says (in part):
=
va_start
The va_start() macro initializes ap for subsequent use by
va_arg() and
va_end(), and must be called first.
=
The
thanks, Ken
I am not such a C light to spot these things instantly.
there are probably also some mutex problems in the combination of this with
the rt-preempt patch.
(by the way this is the UNPATCHED patch, if you see what I mean)
And now it is bedtime for little children.
Cheers all of you,
Sorry. False alarm.
That the va_start is called on the ap argument before this function is
called.
:-{
Ken
On 4/28/2012 6:09 PM, Jan de Kruyf wrote:
thanks, Ken
I am not such a C light to spot these things instantly.
there are probably also some mutex problems in the combination of this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/26/2012 2:38 PM, John Morris wrote:
The commit where the problem begins is
8868436313c34eaf60a14f5c930f0f2035b9ee48.
After saying this was not a problem I introduced, I'm not so sure
anymore. The biggest hunk of the forward-ported
Well, no solution yet, and only narrowed things a little bit:
Continuing Charles's work, I merged the bitmuster-patched v2.4.4
forward. Whatever changes are causing the problem Charles describes
were introduced between v2.4.7 and v2.5.0, and also between v2.5.0-pre0
and v2.5.0-pre1.
That
hi,
sounds good. The work will deminish with more insight.
I thought I was going to set up a system this weekend, but at the moment I
lean to rather digging the code and the diffs.
Since I do not think that me repeating your and Charles' findings will
help, unless you think different.
As a
I wonder if this might be related to our problem.
Deadlocking mutexes .. perhaps we should ask on the rt-linux mailing list ?
Right now I am a bit undsure about userspace mutexes but I'll
look at the code when I get home, it just sounds familiar, but might
be out of context.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/26/2012 2:49 AM, John Morris wrote:
Well, no solution yet, and only narrowed things a little bit:
Continuing Charles's work, I merged the bitmuster-patched v2.4.4
forward. Whatever changes are causing the problem Charles
describes were
On 26 April 2012 08:49, John Morris j...@zultron.com wrote:
That sounds encouraging until you look at git and see that span between
v2.5.0-pre0 and -pre1 is over a year, 833 files and 120k+ insertions,
and that v2.5.0-pre0 is more closely related to v2.4.0 than v2.4.4.
git bisect will
I dont seem to get 'rtapi_shmem_new()' and friends in ./rtapi/linux_rtapi.c
which presumably is the rtapi interface in the case of rt_preempt.
j.
On Thu, Apr 26, 2012 at 6:47 PM, Charles Steinkuehler
char...@steinkuehler.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm still working on figuring those out as well. :)
Near as I can tell, since there's no kernel space vs. user space with
the preempt-rt patch (everything runs in user-space), the realtime and
user-mode functions can be the same so the functions
I was going to bring that issue up as well, that is indeed my understanding
of preempt_rt, from reading the docs.
I am not sure though that this has caused the mutex drama. That can only be
if there is an unbalanced mutex or if the inheritance mechanism has not
worked properly, or perhaps if some
By the way: there is somewhere a note in the software about some pagefaults
at startup that probably dont need fixing!
I forget at the moment where I saw it. Keep your eyes popped for that. It
also explains Lars' experience.
j.
On Thu, Apr 26, 2012 at 9:32 PM, Jan de Kruyf
Hi Andy,
git bisect will probably allow you to narrow things down a lot more
quickly than you imagine.
I was so anxious to get a head start on your suggestion that I began
yesterday!
The commit where the problem begins is
8868436313c34eaf60a14f5c930f0f2035b9ee48.
After saying this was
Hey just go and sell it to that investor, and just make double sure to
please your family. So you will be all fresh when you come back.
I will put in some more code reading and see what gives. (and please my
wife off course!)
j.
On Thu, Apr 26, 2012 at 9:38 PM, John Morris j...@zultron.com
check out the RT wiki ... there are some examples, usually you
prefault the stacks, for threads and then do a mlock on all of the
memory for the process.
2012/4/26 Jan de Kruyf jan.de.kr...@gmail.com:
By the way: there is somewhere a note in the software about some pagefaults
at startup that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/26/2012 2:32 PM, Jan de Kruyf wrote:
I was going to bring that issue up as well, that is indeed my
understanding of preempt_rt, from reading the docs. I am not sure
though that this has caused the mutex drama. That can only be if
there is an
Here's a link to the latest patches:
http://www.zultron.com/static/2012/04/linuxcnc-buesch-rt-patches-forward-port-2012-04-25.tgz
The README explains how to compile them on FC16.
A few changes from the last version:
- Now three patches 001-003 that parallel Michael's original patches. I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/25/2012 3:17 AM, John Morris wrote:
Here's a link to the latest patches:
http://www.zultron.com/static/2012/04/linuxcnc-buesch-rt-patches-forward-port-2012-04-25.tgz
I
get the same results as with the previous set, still hanging in
Charles, John,
This is just a stab in the dark, but Debian uses EGLIBC while I think
Fedora is still on normal GLIBC.
And there were some mutex priority issues in eglibc, quite a long time ago
though.
John can you repeat Charles' problem in your setup?
j.
On Wed, Apr 25, 2012 at 10:41 AM,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/25/2012 10:46 AM, Jan de Kruyf wrote:
Charles, John,
This is just a stab in the dark, but Debian uses EGLIBC while I
think Fedora is still on normal GLIBC. And there were some mutex
priority issues in eglibc, quite a long time ago though.
Hi Charles and Jan,
This is just a stab in the dark, but Debian uses EGLIBC while I
think Fedora is still on normal GLIBC. And there were some mutex
priority issues in eglibc, quite a long time ago though.
John can you repeat Charles' problem in your setup?
Fedora uses glibc, yes, and I've
Any git repo I can pull from and give it a spin ?
/ regards, Lars Segerlund.
2012/4/23 John Morris j...@zultron.com:
Hi Jon,
If the rt-preempt route doesn't work, I'll try applying RTAI to a
kernel RPM. It would be neat to get LinuxCNC working with linux-rt,
of course, but from what I've
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/24/2012 4:01 AM, Lars Segerlund wrote:
Any git repo I can pull from and give it a spin ?
You can pull a PREEMPT_RT patched version of EMC 2.4.4 from the git
archive referenced at http://www.bitmuster.org/projects/emc.html
I've got crude
Hi Jon,
If the rt-preempt route doesn't work, I'll try applying RTAI to a
kernel RPM. It would be neat to get LinuxCNC working with linux-rt,
of course, but from what I've found on the list and the irc logs,
there's only a small amount of interest ATM, though that might
increase because of
34 matches
Mail list logo
