Re: [Xenomai] ARM, exception #0 ?

["George Pontis" <GPontis@z9.com>]

> ....
> 
> 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