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
