On Monday 16 April 2007 15:43, Gilles Chanteperdrix wrote:
> If the fault you observe is due to an access to some memory after a call
> to fork or one of its derivative (such as system, popen, etc...), the
> patch would have copied the whole real-time process address space at
> fork time instead of setting up COW mappings.
No process forks are involved. Though mlockall() was called from Linux
main(), and the page fault was encountered by a separate Xenomai task.
Here's the task history:
static constructor allocates buffer from heap
enter main()
call mlockall(), verify return status == 0
buffer is forcibly cleared using memset(buffer, 0, sizeof(buffer))
main calls rt_task_shadow() to create Xenomai startup task
startup task spawns Xenomai communications task via rt_task_start()
communications task encounters page fault
Let me know if you are able to spot the source of the page faults.
thanks,
Jeff
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
