Hi Jan, On 05/01/2012 01:55 PM, Jan de Kruyf wrote: > "Ein Zimmermann am Straßenrand vergnügt die Zuschauer." they say in Holland. > > but also: > Die Axt im Haus erspart den Zimmermann. [Friedrich Schiller: Wilhelm Tell] > > In other words: feel most welcome to the party.
Thanks :) > > The problem seems in the porting to the present HEAD. And since you are > much more knowledgable then we are on the subject: > > On and off the people report some funny hangups, so I would like to ask: > > 1. Could it be a case of priority inversion in the mutexes? Did you take > care of that? Or does the system do that automatically? I haven't managed to look at the code yet, but when I remember right rt-mutexes should have build-in priority inheritance (http://www.mjmwired.net/kernel/Documentation/rt-mutex.txt). This should be the best option. > 2. I think I have identified at least one area where a new shared memory > resource has been introduced since your port, which I think needs > protection. Yes, I have used that feature to talk to other real-time processes. That's also why I've updated semaphore support. Maybe we also need other additional protection. > 3. Did you, at the time, check that all RT memory was locked in place? > since there are some funny paging faults at times. Not really :) . I've also seen these pagefaults, maybe in combination with missed deadlines. Do the pagefaults also occur when you run with slower cycle times? > > Other than that your offer of serverspace is most welcome. And I might want > to ask you some technical questions at odd times if I may. Feel free :) > I can read linux C much better lately, but some of the fine details evade > me at times. And I am on a steep learning curve regarding RT. The tool cyclictest is not only a good test tool but also a good reference for a simple real-time program. Maybe it helps to understand rt-preempt ... See: git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git > Thanks again, > > j. Greetings Michael > > > > On Tue, May 1, 2012 at 12:09 PM, Abel Michael < > michael.a...@isw.uni-stuttgart.de> wrote: > >> Hi there, >> >> I just saw that you have resurrected the rt-preempt patches. >> Very very cool! >> >> I'd like to reproduce your results and help bug-fixing, but I'm not >> exactly sure how to patch everything together. >> If I've understood right this procedure might do it: >> >> 1) Follow these instructions: >> http://www.zultron.com/static/2012/04/linuxcnc-bitmuster-bisect.tgz >> 2) Apply this patch: >> linuxcnc-bitops-fix.patch >> 3) Apply the patch Charles send two posts ago to fix the rtapi message >> levels >> (Please correct me if I'm wrong). >> >> If somebody is in the mood for using git format-patch and send a patch, >> I would be also very happy. I'd like to push a branch to my repository >> at http://gitorious.org/emc-rt-preempt afterwards. >> So that everybody is able to pull. The repository is intended to toy >> around with rt-preempt and for a later merge upstream when it is running >> stable. >> >> Thanks in advance >> >> With best regards >> >> Michael Abel >> Aka the bitmuster guy >> >> On 04/30/2012 05:11 AM, Charles Steinkuehler wrote: >>> On 4/29/2012 11:53 AM, John Morris wrote: >>>> 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 have verified that the "fix" works not just immediately after the >>> 8868436313c34eaf60a14f5c930f0f2035b9ee48 commit, but also on HEAD with >>> the bitopts-fix patch. >>> >>> Interestingly, even when I send all rtapi output to stdout, I am >>> *STILL* not seeing any of the expected rtapi_msg_handler messages on >>> the console. I _really_ think this is the core issue, and moving >>> messages from stderr to stdout just avoids the crash (or more likely >>> delays it until much later). >>> >>> I was advised by Andy Pugh to "echo 5 > /proc/rtapi/debug", however >>> there *IS* no /proc/rtapi/<anything> as I am building using >>> --with-realtime=linux and there are no kernel modules getting loaded. >>> I am unsure what the equivalent setting would be for the linux >>> preempt_rt patch set, but AFAIK with either setting (rtapi_msg_handler >>> data being sent to stderr or stdout) *SOMETHING* should be showing up >>> on the console, and I'm still not seeing _any_ of these messages. >>> >>> This makes me think there is something wacky going on in the rtapi >>> debugging output that is trashing memory when running using preempt_rt >>> instead of the "expected" kernel module. I have looked around a bit, >>> but still do not understand the code enough to know what might need to >>> be fixed in the linux-* files to avoid trashing memory and to be able >>> to properly output rtapi debugging information. >>> >>> It seems like this may have been a bug in the linux-preempt_rt patches >>> for some time, but for whatever reason didn't cause serious problems >>> until the changes to the rtapi output scheme. >>> >>>> Congrats, Charles. If you fix it by tonight, I'll paypal you a >>>> beer. ;) >>> >>> >>> Well, as a rule I never turn down free beer, but I'm not sure it's >>> deserved in this case. Instead of a programmer or engineer, I feel >>> more like a nuclear physicist playing with genetic algorithms: blowing >>> things up and trying to figure out what happened based on the >>> resulting pieces...then if it doesn't make sense I randomly change >>> something and blow it up again. :) >>> >>> Also, I hesitate to consider the issue fixed, even though the >>> latency-test from HEAD is now running for me under stock Debian Wheezy >>> with a 3.2.0-rt kernel. It feels like there's something that needs to >>> be fixed properly by someone who understands the code better than I do >>> before this will be stable long-term. >>> >>> >>> >> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Emc-developers mailing list >>> Emc-developers@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/emc-developers >> >> -- >> -------------------------------------------------------------- >> Dipl.-Ing. Michael Abel >> >> Graduate School of advanced Manufacturing Engineering >> GSaME - Universität Stuttgart >> >> Institut für Steuerungstechnik >> der Werkzeugmaschinen und Fertigungseinrichtungen >> ISW - Universität Stuttgart >> >> Seidenstr. 36 >> 70174 Stuttgart >> >> Tel.: ++49 (0) 711 685-82532 >> Fax : ++49 (0) 711 685-82808 >> >> michael.a...@isw.uni-stuttgart.de >> michael.a...@gsame.uni-stuttgart.de >> >> www.gsame.uni-stuttgart.de >> www.isw.uni-stuttgart.de >> -------------------------------------------------------------- >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Emc-developers mailing list >> Emc-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-developers >> > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers -- ---------------------------------------------------------------- Dipl.-Ing. Michael Abel Graduate School advanced Manufacturing Engineering GSaME - Universität Stuttgart Institut für Steuerungstechnik der Werkzeugmaschinen und Fertigungseinrichtungen ISW - Universität Stuttgart Seidenstr. 36 70174 Stuttgart Tel.: ++49 (0) 711 685-82532 Fax : ++49 (0) 711 685-82808 michael.a...@isw.uni-stuttgart.de michael.a...@gsame.uni-stuttgart.de www.isw.uni-stuttgart.de www.gsame.uni-stuttgart.de
<<attachment: michael_abel.vcf>>
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
