On 03/09/2013 06:22 AM, Matt Shaver wrote:
> On Sat, Mar 9, 2013 at 2:02 AM, Matt Shaver wrote:
> To be clear: you can use libzmq (and any other 0MQ project with the
> same license) in a GPLv2 project, both as a dynamic library, and in a
> static link. If you make patches, you need to publish them
On 02/14/2013 01:37 PM, Gilles Chanteperdrix wrote:
> On 02/14/2013 07:05 PM, John Morris wrote:
>> On 02/14/2013 06:15 AM, Gilles Chanteperdrix wrote:
>> I'm hoping that someone else will volunteer to take over package
>> maintenance once the dust settles a little.
>
On 02/14/2013 06:15 AM, Gilles Chanteperdrix wrote:
> On 02/14/2013 08:24 AM, John Morris wrote:
>
>> Hello emc-dev and xenomai lists,
>>
>> I'm very pleased to announce the availability of one-size-fits-all
>> Xenomai kernel packages for x86 arch. These packag
Hello emc-dev and xenomai lists,
I'm very pleased to announce the availability of one-size-fits-all
Xenomai kernel packages for x86 arch. These packages have been
successfully tested on umpteen motherboards at this point, and are ready
for wider testing.
* Beta status *
Distros: Ubuntu Precise a
On 02/06/2013 09:45 AM, Charles Steinkuehler wrote:
> [...] you can run a machine with a PREEMPT_RT kernel, and one is
> available pre-packaged in Debian Wheezy (and perhaps other
> distributions, as well). Performance is not as good as RTAI or
> Xenomai, but using a distribution provided kernel i
On 02/06/2013 09:45 AM, Charles Steinkuehler wrote:
> On 2/6/2013 8:15 AM, Eric Keller wrote:
>> will it run a machine on a generic kernel? The closest would be
>> an rt-preempt kernel, is that standard with any distributions ? I
>> will admit to be confused, this discussion doesn't seem to talk
On 02/04/2013 08:43 AM, Michael Haberler wrote:
> Am 04.02.2013 um 14:11 schrieb EBo:
>> On Feb 4 2013 4:18 AM, Michael Haberler wrote:
>>> Am 04.02.2013 um 11:29 schrieb EBo:
In the past, and I can read it between the lines now, that the
invasiveness of the modifications will take so muc
would be great if someone wanted to wrap it up in python and provide
docs to make it more user friendly. It would also be nice to have an
init script and a config file to make settings configurable and
persistent across boots. Volunteers? ;)
John
On 02/05/2013 01:31 PM, John Morris wrote:
2.1
sudo update-initramfs -u -k 3.5.7-xenomai-2.6.2.1
Thanks!
John
On 01/29/2013 09:59 PM, John Morris wrote:
> This time, a new tack: atop the old vanilla 3.5.7 + 2.6.2.1 Xenomai,
> apply the vanilla 3.5.7 to stock ubuntu lts-3.5.0-23.35 diffs. Thanks
> to cradek for the i
-devel for many iterations of testing
multiple kernels on multiple systems today!
John
On 01/27/2013 09:03 PM, John Morris wrote:
> New xenomai packages in the repo fix the dlopen-skins problem Chris
> George found and a timer problem Michael Haberler found.
>
> Both kernel
New xenomai packages in the repo fix the dlopen-skins problem Chris
George found and a timer problem Michael Haberler found.
Both kernel and xenomai packages are at package release 3.
# update repo metadata
sudo apt-get update
# update xenomai packages
sudo apt-get install libxenomai-dev
Hi Chris,
On 01/27/2013 12:17 PM, Chris George wrote:
> I've downloaded and installed your package, following the directions at
> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?XenomaiKernel on a 64-bit Ubuntu
> 12.04 install. I then followed the directions at
> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?
The Xenomai developers have helped fix numerous problems compiling
Xenomai kernels using distro kernel package .configs and build tools.
After WAYYY too much time and headache learning to package kernels for
Debian/Ubuntu, I hope my alpha-quality Xenomai kernel package PPA is
finally ready for bold
Hi folks,
On 01/16/2013 08:15 AM, Michael Haberler wrote:
> x86 kernels:
>
> from the 'it doesnt boot on my machine' perspective it seems we're
> through the worst with this kernel:
> http://static.mah.priv.at/public/xenomai-debs/linux-image-3.2.21-xenomai+_0.4_i386.deb
> . However, John is work
Hi fellers,
On 12/28/2012 02:48 PM, Michael Haberler wrote:
> the background of the question was: for the userland thread styles
> and minimal privileges for rtapi_app functionality, the 'forking
> helper program' is actually not helpful at all (it is needed and
> makes sense for kernel modules).
On 12/22/2012 04:10 PM, Charles Steinkuehler wrote:
> On 12/22/2012 3:49 PM, Michael Haberler wrote:
>> Kernels to try: --- Please see
>> http://www.mail-archive.com/emc-developers@lists.sourceforge.net/msg07851.html
>> Xenomai and RT-PREEMPT kernel debian packages for x86/PC can be
>>
mm, I might have to make
something up
> With luck, there should be a "grand unified" version with my
> usermode-pci changes, John Morris' significant code cleanups, and
> Michael Halberer's unified real-time architecture available Real Soon
> Now!
Unless I'
On 12/11/2012 09:15 PM, Gene Heskett wrote:
> Greetings all;
>
> I had something on the mill that said what was requested and that it was
> 'at speed', but that was 3 or 4 years ago and just made the assumptions I
> believe as I don't recall the progress bar ever turning red. Nothing in
> that
On 12/12/2012 11:49 AM, Michael Haberler wrote:
> Charles managed to get userland PCI working such that it can drive a
> Mesanet 5i25/7i76 - shot from hm2-stepper, 7i76 pins:
>
> http://static.mah.priv.at/public/5i25.jpg
>
> xenomai-user threads build, os=xenomai 3.2.21
>
> I think we owe him a
27;s my 2c... I'll look at this again later tonight.
>
> EBo --
>
>
> On Nov 21 2012 12:30 PM, John Morris wrote:
>> Hi list,
>>
>> On 11/21/2012 07:11 AM, Michael Haberler wrote:
>>> Yes it is time, but we have not ticked off on a key san
Hi list,
On 11/21/2012 07:11 AM, Michael Haberler wrote:
> Yes it is time, but we have not ticked off on a key sanitary non-code
> prerequisites
>
> The GPL2-only situation prevents bringing in outside code which
> requires GPL2+ licenses.
>
> I table this issue again to get this finally resolved,
On 11/17/2012 03:39 AM, Michael Haberler wrote:
> It would be great to get rid of it and reintroduce module versioning,
> but given the RTAI kernel isnt exactly reproducible and other kernel
> thread styles are either already extinct, or will be extinct within
> the relevant time window, I gave it
Hi Michael,
Oh my gosh, what a tremendous amount of work you've done.
On 11/16/2012 06:26 PM, Michael Haberler wrote:
> 4. The rt-preempt-user code by Michael Büsch and many others has been
> integrated by Charles and John, and I did some work on polishing and
> removing duplicated code, some of
On 11/14/2012 03:19 PM, EBo wrote:
> On Nov 14 2012 2:16 PM, John Morris wrote:
>> Hi Kent,
>>
>> On 11/14/2012 12:58 PM, Kent A. Reed wrote:
>> > On 11/14/2012 1:34 PM, John Morris wrote:
>> >> - NVidia GeForce 6100 chipset
>> >> - A su
Hi Kent,
On 11/14/2012 12:58 PM, Kent A. Reed wrote:
> On 11/14/2012 1:34 PM, John Morris wrote:
>> - NVidia GeForce 6100 chipset
>> - A suspicious 'model unknown' AMD Athlon 64-bit single core 2.2GHz
>> 1MB cache I got super cheap in Beijing 2007
>
Hi Kent,
On 11/14/2012 11:57 AM, Kent A. Reed wrote:
> On 11/14/2012 2:19 AM, John Morris wrote:
>> While sitting around waiting for the umpteenth time for the Xenomai
>> kernel to build, this time with Michael's config just to help narrow
>> things down, I compile
On 11/14/2012 07:00 AM, andy pugh wrote:
> On 14 November 2012 09:35, Michael Haberler wrote:
>
>> note operative word 'compile':
>>
>> I didnt get the GUI's to run because of some Python OpenGL support missing
>
> Any luck with mini, or tklinuxcnc, or even (desperation) keystick?
>
What are you
On 11/12/2012 11:27 PM, John Morris wrote:
> I'm going back to try to recreate your setup. Found your kernel config
> file. If you have one around, please send a LinuxCNC build log to help
> guess what the differences might be.
While sitting around waiting for the umpteenth time f
Hi Kent, I'll take a stab at this.
On 11/13/2012 01:04 PM, Kent A. Reed wrote:
> I've had a long-standing issue with building multiple configurations of
> LinuxCNC using sources from the git repositories which has come to a
> head with Michael's single codebase.
Funny, me too!
> What's an econom
[ 260.204015] [] sysenter_do_call+0x12/0x16
> [ 260.204015] Code: 00 00 8b 93 e8 00 00 00 8b b3 e0 00 00 00 89 34 24 e8 1f
> e3 ff ff 8b 83 80 01 00 00 85 c0 74 19 31 f6 8d 76 00 8b 83 7c 01 00 00
> 14 b0 83 c6 01 3b b3 80 01 00 00 72 ec 8b 83 d4 00 00 00 85
> [ 260.204015] EIP: []
Hi Michael,
I've been whacking away ('hacking' is too glamorous a term for my clumsy
bumbling) at getting xenomai-kernel to work today. I did make some
progress; there's a new commit that fixes a problem where symbols in
xeno_math.ko are not being shared with other modules, resulting in
rtapi
Hi John,
On 11/06/2012 01:06 PM, John Kasunich wrote:
> On Tue, Nov 6, 2012, at 12:52 PM, John Morris wrote:
>
>> Astonishingly, asciidoc, which LinuxCNC requires v. 8.5 or higher, is
>> still at v. 8.4.5 for even fedora rawhide, and the package hasn't been
>>
On 11/02/2012 04:08 PM, John Morris wrote:
Hi Michael,
On 11/02/2012 10:18 AM, Michael Haberler wrote:
I have now integrated the RT-PREEMPT branch as provided by Charles,
added the now-working Xenomai-userland thread style, and massaged
configure to deal with all of this. The Xenomai-kernel
Hi Kent, and the list in general,
On 11/02/2012 04:53 PM, Kent A. Reed wrote:
> RTAI - 1ms servo thread/25us base thread - max jitter 4401ns/2378ns
> after 3 hours
>
> Xenomai/kernel - 1ms servo thread/25us base thread - max jitter appeared
> to be running roughly 1ns/1ns after 45 minutes
Hi Michael,
On 11/02/2012 10:18 AM, Michael Haberler wrote:
> I have now integrated the RT-PREEMPT branch as provided by Charles, added the
> now-working Xenomai-userland thread style, and massaged configure to deal
> with all of this. The Xenomai-kernel branch I reported about yesterday is
> f
[Sent from wrong address on the 23rd & rejected; resending]
Hi Michael,
On 10/23/2012 12:00 AM, Michael Haberler wrote:
>
> Am 23.10.2012 um 06:22 schrieb John Morris:
>
>> So when's the ETA on the working preempt-rt version of LinuxCNC? Will
>> it be all pac
[Sent from wrong address on the 23rd & rejected; resending]
On 10/22/2012 11:22 PM, John Morris wrote:
> Hi Charles,
>
> On 10/20/2012 08:28 AM, Charles Steinkuehler wrote:
>> I think I have most everything I could collect committed to the
>> rt-preempt-integration-
Hi Charles,
On 10/20/2012 08:28 AM, Charles Steinkuehler wrote:
> I think I have most everything I could collect committed to the
> rt-preempt-integration-initial branch in Michael Haberler's git
> repository.
>
> John: One thing I _am_ missing is some of your earlier patches, only
> the latest on
Hi Charles,
On 10/08/2012 01:14 PM, Charles Steinkuehler wrote:
> Then around 2009 it appears Michael Büsch continued things with a
> patch set posted at:
> http://bu3sch.de/patches/emc-linux-rt
>
> *THIS PATCH IS LOST*, at least I couldn't find it online or via
> archive.org. Can anyone provide
On 09/12/2012 09:08 PM, Dave wrote:
> I'm starting to understand why I can't buy a Raspberry Pi in this
> country the UK guys are hogging them, making up mainframes etc.
Actually, everyone on this list is guilty. It's open hardware. By now
we should've programmed EMC to mill Raspberry Pi
Sorry, my search terms were 'linuxcnc live cd'
John
On 05/09/2012 12:50 AM, John Morris wrote:
> Worse yet, do a google for 'linuxcnc'. If you see what I do, there's a
> message in the google search results:
>
> This site may be compromised.
>
>
Worse yet, do a google for 'linuxcnc'. If you see what I do, there's a
message in the google search results:
This site may be compromised.
And in the list of popular links,
Buy Cialis Soft Online, Cialis
John
On 05/02/2012 06:26 PM, andy pugh wrote:
> Pointed out by a guy on t
Hi Jan,
> In Africa we certainly talk much faster, and LOUDER after a good
> refreshment!
> (And we talk very well as it is, you know that. In fact I wonder wether we
> do anything else)
Our Texas drawls prevent us from talking faster, but we do talk loudly
and a lot after a few long-necks.
> N
John
On 05/04/2012 04:07 PM, John Morris wrote:
> Hi list,
>
> I'm simultaneously happy and embarrassed to present a possible fix,
> which I have tested about 3 times only.
>
>> My suspicions are one of the following is true (certainly the last):
>> - thread 2&
Hi Charles,
> I also don't really care much about the new huge stack-size. I might at
> some point, but right now I'm running on systems with 4-12G of RAM, most
> of which is just sitting around idle. :)
Can I have some of that idle RAM?
I suppose that 2x-4x the original setting might possibly
ol belt!
If this fix is confirmed to work, then I'll make good on the bounty!
John
commit 4c0e4ddef8337c47ab998257e98260204f2340ac
Author: John Morris
Date: Fri May 4 15:57:16 2012 -0500
Increase HAL_STACKSIZE (thread stacksize) for PREEMPT_RT to stop segfaults
The p
Hi Jan,
> This is what happens when you sleep late every day: The sun starts to get
> slow also! In Africa we get up early, so we get to drink the beer early! As
> the sun gets hot, that is the right time.
Africa, not Europe, sorry. Not quite like Africa, but in Texas, the sun
gets hot, and we
Hi Charles,
> Here's a stack trace for two different cases:
>
> * Running rtapi_app using electric fence
>
> * Running hal_cmd and following the child on fork (the crash happens in
> rtapi_app, launched by hal_cmd)
>
> Of possible interest:
> If you run rtapi_app on it's own without electric fence
Hi Jan,
> I seem to miss the stacktrace leading up to the crash in the
> reports.
Have you compiled with -g (and maybe -O0)? That'll get you the
stacktrace for the LinuxCNC code. Your distro should have packages that
provide the debug symbols for binary packages. On Fedora these are
Hi Charles,
>> If you run with electric fence, you'll get a segfault well before the
>> malloc crash, where one of the debug writes to stderr is stepping on
>> memory that it shouldn't (which is likely what is eventually causing
>> malloc to barf). Looking at what might be corrupting the stderr
>
Hi EBo,
> Usually when malloc wedges up like this it is caused by just a coupe of
> things 1) a double free of the same allocated block, 2) writing past the
> end of a block, or 3) freeing up memory that was allocated by one
> process but still accessing it in a different one. Anyway that is my
>
Hi Andy,
> RTAI is< 10 uS. Are you sure you have your units correct? 30mS is
> going to be unusable for CNC.
Whoops, you're right, wrong units. My system's been much worse than
30uS during all this testing. That'll be my next challenge if we can
finally squash this bug. :P
John
-
Hi Andy,
>> Recycled memory chunks are split for a new malloc(),
>
> not kmalloc?
>
>> My only thought about the cause is funkiness with gdb record
>
> Are you absolutely sure that you can gdb kernel code? I thought it was
> impossible. But I am frequently wrong.
I'm not sure if one can gdb kerne
Hi Jan,
> I have a very valid (I hope) question though:
> RTAI knows to run real time sections in kernel space, later on they also
> got RT in user space to go. So where does the original RT section of LCNC
> run -- in userspace or in kernel space?
I'm sorry, but I'm still confused about the 'RT'
Hi Charles,
> I haven't been able to get the record feature of gdb to do much of
> anything useful, because it keeps stopping on an unsupported instruction
> (0xc5). I don't know if this is related to the crashing or not. :-/
I spent a good 10 hours on this and have narrowed things down to
wei
Hi EBo,
>> I think that the spare time problem is a common ailment. Whatever
>> the case, with more people doing nothing more than watching this
>> thread, sooner or later a light bulb will go on and we'll have our
>> solution.
>
> true... Any more ideas?
Yep! I discovered the 'record' feature
Hi Abel,
I just saw that you have resurrected the rt-preempt patches.
Very very cool!
>>
>> Yes, very cool! I feared nobody would be interested, since the patches
>> have languished so long, but there's been quite a lot of interest, and
>> best of all help. ;)
>
> I still need it for m
> Only other modifications to the instructions, since we're now working
> with HEAD, be sure to s/emc/linuxcnc/g.
Oops, emc-environment becomes rip-environment, not linuxcnc-environment. ;)
John
--
Live Securit
Hi Abel and Charles,
On 05/01/2012 07:34 AM, Charles Steinkuehler wrote:
>> I just saw that you have resurrected the rt-preempt patches.
>> Very very cool!
Yes, very cool! I feared nobody would be interested, since the patches
have languished so long, but there's been quite a lot of interest, a
Hi Charles,
> I have verified that the "fix" works not just immediately after the
> 8868436313c34eaf60a14f5c930f0f2035b9ee48 commit, but also on HEAD with
> the bitopts-fix patch.
Yep, it's 'working' for me, too.
> Interestingly, even when I send all rtapi output to stdout, I am
> *STILL* not se
Hi Charles,
> The AMAZING thing is I can now "sudo scripts/latency-test" and IT WORKS!!!
So wait, by 'IT WORKS!!!' you mean 'IT WORKS!!!'? I can't believe it!
It's our kid's first Mother's Day, so no testing until late for me.
I'd sure like to fix the Makefile so that when you change e.g.
rta
Hi folks,
- Use the debugger to understand why test_and_set_bit returns 0. I
don't know what the 'tsbbl' instruction is, and haven't figured out how
to examine memory yet.
I finally muddled my way through gdb and newer kernel sources to
understand this one.
The reason hal_init was seemingl
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 o
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 tho
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
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 p
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 n
t the root of the problem!
John
On 04/26/2012 12:39 AM, John Morris wrote:
> 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 iss
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,
erlund wrote:
> Any git repo I can pull from and give it a spin ?
>
> / regards, Lars Segerlund.
>
> 2012/4/23 John Morris:
>> Hi Jon,
>>
>>>> If the rt-preempt route doesn't work, I'll try applying RTAI to a
>>>> kernel RPM. It would b
Hi,
The attached patches fix two small problems I ran into on non-RTAI
Fedora 16. I'm working from the master branch. They document themselves.
Thanks-
John
This silences output like the following:
checking for adeos... find: `/home/john/src/linuxcnc-dev/lib/emc2/modules': No such
Hi Michael,
> where ? master? which commit?
master branch, commit 20cb3efccc87d424342ff1177ec9e6234c5139e4
Thanks-
John
> Am 24.04.2012 um 20:05 schrieb John Morris:
>
>> Someone with commit access might want to clean this one up:
>>
>> src/emc/r
Someone with commit access might want to clean this one up:
src/emc/rs274ngc/interp_check.cc.rej
John
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat la
Hi Charles,
>> Would you mind pasting the messages indicating that rt-preempt is
>> detected?
>
> I'll have to re-create that. I've blown away and re-started from
> scratch several times now. IIRC, there was a configure step as part
> of grabbing the Debian build-depends that recognized the linu
Hi Andy,
>> The closest I got was to compile mathtest.c as though it were a
>> kernel module. That failed during compile, since floating point
>> operations are disallowed in the kernel (they use the SSE register,
>> which must stay clean for userspace),
>
> Is that an RT-Preempt limitation? Ther
Hi Charles,
Glad I'm not alone working on this!
> I had lots of failed hunks when I applied this patch to the latest
> LinuxCNC from git, but I didn't sort through to see how serious they
> were to try and fix. Did the patch apply cleanly for you?
The patch didn't apply cleanly, but most failed
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 be
Hi, I'm playing with getting LinuxCNC working under Fedora. Here's a
quickie patch for the ./configure check of the dblatex version.
I'm starting by getting all the dependencies working & writing a
specfile. Michael Buesch's rt-preempt patches
(http://thread.gmane.org/gmane.linux.distributio
101 - 178 of 178 matches
Mail list logo
