Re: [Xenomai-help] isolating unwanted mode switch

[Jeff Weber <jweber@domain.hid>]

A correction to my previous post on this problem: the memory in question was 
previously allocated heap, that was apparently not yet paged in.  The pointer 
to the memory was in bss, so, at the time, I assumed the page fault memory 
was in bss as well.  I have a "solution" which is working for now, to write 
(zero out)  dynamically allocated memory before first use.  (The dynamic 
allocation is after the mlockall() ).

My application is a legacy C++ program, which has an initialization phase: 
where all RT tasks are created and all memory is allocated; and a run phase: 
where the task T_WARNSW mode is enabled, to report unwanted modes switches.  
I am in the process of porting this application from Linux-2.4.27+rtai-3.1.0 
to Linux-2.6.17.14+Xenomai-2.2.4.  (As a side note, it has now become 
interesting to consider how and if page faults were affectinging the 
Linux-2.4+RTAI version of this application.)

From the discussions in this thread, there will always be a non-zero 
probability that my application will still encounter future page faults. So 
I've decided to enable T_WARNSW for the applicaion while under development, 
but T_WARNSW will not be enabled for deployed applications.  Instead, I may 
periodically parse /proc/xenomai/faults, and /proc/xenomai/stat .

	Jeff

On Thursday 25 January 2007 04:50, Philippe Gerum wrote:

> Gilles is working on a patch that solves a number of on-demand mapping
> issues initially observed on ARM and ppc, but generic enough to affect
> other archs; I'll merge it into the I-pipe 1.7 series for x86 in a near
> future.