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 besides: I have a theoretical understanding of the issues, but little practical exposure. At the same time I am a professional faultfinder (my wife agrees with that statement ;), also plenty experience doing it by remote control. So that is why I took the liberty to impose myself. It is of course not to sit here and feel good about commenting on yr work. Only if you experience it as helpful. You think you could blog your doings on zultron.com, then I will volonteer to go through it with a fine comb to see what might surface. And believe it or not: THE SUN SHINES TODAY! cheers j. On Thu, Apr 26, 2012 at 9:49 AM, John Morris <j...@zultron.com> 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 introduced between v2.4.7 and v2.5.0, and also between v2.5.0-pre0 > and v2.5.0-pre1. > > 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. > > For the first time, I'm actually *sad* to report that it seems not to be > my error at 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 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 replicated what Charles has done > > exactly. :) > > > >> What I'm seeing in the debugger is while going through hal_init the > >> hal_data->mutex bit is getting set and is visible in the memory > >> display window after rtapi_mutex_get is called. However after calling > >> rtapi_mutex_give, the mutex bit is *STILL SET* in my debugger memory > >> display. > > > > Yep, same here. > > > >> I don't know if this is a fundamental problem with the rtapi code or > >> something to do with running from the debugger with breakpoints and > >> whatnot. It does seem odd that this would be due to system libraries, > >> as the relevant code seems to be entirely within the linuxcnc rtapi > >> tree. There could be some other issue with the memory mapping or > >> something system related, I suppose. > >> > >> I do, however, get identical results when running the code normally > >> from the command line and then attaching to it with the debugger (the > >> code is looping waiting to acquire the hal_data->mutex that will never > >> become available). > >> > >> Also, the 2.4.4 patched version from bitmuster compiles and runs fine > >> on this same system, so if there is a library issue, it's likely > >> related to the changes from 2.4 to 2.5. > > > > Same here with 2.4.4, I think. I'm unsure because the first compile was > > behaving like my forward-ported patches, but it started working after I > > recompiled with -g. Hrm. > > > >> Did anything major change in the hal shared-memory usage between 2.4 > >> and 2.5? > > > > Wonder how hard to start bisecting.... ;) > > > > Anyway, up to now I've only managed to reproduce your results. I'll get > > back if I learn anything new. > > > > John > > > > > > > ------------------------------------------------------------------------------ > > 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 > ------------------------------------------------------------------------------ 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
