> ....
>
> Ok. I was able to reproduce the same message with the following test
> application:
>
> #include <sys/mman.h>
>
> #include <native/task.h>
> #include <native/mutex.h>
>
> RT_MUTEX mx;
>
> int main(void)
> {
> RT_TASK t;
>
> mlockall(MCL_CURRENT | MCL_FUTURE);
>
> rt_task_shadow(&t, "test_fault", 1, 0);
>
> rt_mutex_acquire(&mx, TM_INFINITE);
> }
>
> Namely: trying to acquire a mutex which is not initialized. The address
> 0xffff0fbc is off-by 4, the real fault address is 0xffff0fc0, the
> kernel
> helper used by the mutex implementation for the
> atomic-compare-and-exchange operation.
>
> --
> Gilles.
Gilles, that is very helpful. I looked at the code from the app guys and was
not able to decipher the fairly complicated C++ task logic, but passed this
info to them. I will keep track of their efforts and make sure that we close on
it. As far as trying the other examples, I need to do some catch-up. The
embedded target does not have gdb running on it as they haltingly make do with
gdbsever and gdb/Eclipse on the host. And I _still_ have not been able to coax
any detailed output from the kernel with CONFIG_DEBUG_USER and user_debug=29. I
know that this is declared because an added printk shows that it is executing
the function user_debug_setup in arch/arm/kernel/traps.c which is dependent on
CONFIG_DEBUG_USER. But no additional info shows after the fault, including the
fault from your test application.
George
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
