John,
some incoherent thinking ---
which link was that: rt.wiki.kernel?
dietlibc will be wrong until proven right, unfortunately. I scanned through
the website but did not find any mention of it.
What is the great urge anyway? Are you going to build on embedded?
I understand we must just have no ioctl, printf and friends in the
realtime parts to solve the problem you experienced.
OK I got my thinking confused again, I thought Epler did it right and ze
germans muddled it. But I just looked in funny.diff and saw that with that
diff the muddle came.
This is the right way:
- /* call the normal library vnsprintf() */
- vsnprintf(buffer, BUFFERLEN, fmt, args);
- rtapi_msg_handler(RTAPI_MSG_ALL, buffer);
and this was made of it:
+ rtapi_msg_handler(RTAPI_MSG_ALL, fmt, args);
and the messagehandler is then a printf friend that causes sheit. The
trolls were over it again.
that is why the stdout/stderr fix worked, there should have been no need
for that.
OK so
1. the message handling must be fixed.
Please make a specification proposal, duly taking into consideration
the fifo construction Epler introduced for operator errors.
And taking into account that we URGENTLY need to LOG all errors with
time of occurence. So the human interface might have a button to recall the
log.
2. The MUTEX construction needs to be checked. Michael Abel believes they
should do the right thing automatically, but I have reason to believe that
I am not sure at all. I spend the aftenoon finding the right 'pthread.h', I
hope: http://linux.die.net/include/pthread.h
The way my modern brain reads this ancient code is that it is left to the
user to ask for priority inherance. (this is also the prob with dietglibc,
we do not know if they even provide that feature)
3. The Epler fifo, I would think, needs mutexes here and there, cause there
will be more threads capable of spitting out error messages simultaneously
I would say.
4. Please read the osadl.org wite-up on tuning your system/kernel. there
are some useful hints there about processor speed and sleepstates that you
need to take into consideration.
I got excellent latencies running the osadl test, until I looked the next
morning: DISGUSTING. The thing must have dozed of and had a rude awakening
that took a bit more time than usual.
So now I will continue to set up my system and your patches, and otherwise
consolidate: collect my thoughts and put them into some order
and all that.
And tomorrow I will go and sing in the choir. And not about computers or
beer for that matter ;) Hey it will be so beautiful!
cheers
j.
On Sat, May 5, 2012 at 7:31 PM, John Morris <j...@zultron.com> wrote:
> 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.
>
>
> Now for the scary stuff:
>> there IS a PROBLEM with ulibc and PREEMPT_RT.
>>
>
> Yep, nice link. Wonder about dietlibc? That's a completely unrelated
> code base according to something I read.
>
>
> The stack problem is well known in literature, but normally the other way
>> round: You run out of memory space assigning too many and too big.
>> So John since you are soo good with yr toolbelt: rip out the dynamic stack
>> measuring tool and measure, than double the size.
>> Or maybe how about tripling the old size (since it worked a while back
>> still)
>>
>
> Well, after all that work, I still don't have a good handle on
> understanding where things are in the stack and how full it is.
>
> You're right that it probably needn't be too much bigger. As you point
> out, the change that put things over the edge was switching from vsnprintf;
> fputs; to vfprintf;. In the old version, the formatting routine and
> printing routine were serialized, so they didn't occupy the stack
> simultaneously. In the new version, vfprintf takes care of both functions,
> and worse, when it sees stderr is unbuffered, it creates a buffer and
> essentially calls itself again. I'd bet 4x/64k would do it.
>
>
> And lastly I think that the whole business of error reporting by the
>> program needs careful consideration. the problem came about when Epler
>> broke out the error reporting to the operator and through a fifo to the
>> user interface so he/we can internationalize it. Which is good off
>> course.
>> So here is a thought:
>> Why is not all error reporting done that way! Some errors are then just
>> marked "system error xx" which would almost automatically cause a bug
>> report to be filed.
>>
>
> Yes, this sounds like the right way to do it. Also, the Buesch patches
> have some plain ol' 'printf' statements in there, not indented properly,
> not running through the rtapi msg facility. I bet those were debugging
> statements that weren't removed.
>
>
> Last question to you experts: what latencies are you measuring?
>>
>
> 50uS on my x86_64 workstation with no tuning whatsoever. USB keyboard, no
> BIOS settings, etc. I'll report back when it's running on the intended
> production machine.
>
> 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
