From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <478DD90B.6020302@domain.hid> Date: Wed, 16 Jan 2008 11:14:35 +0100 From: "Bernhard Michael" MIME-Version: 1.0 References: <47891672.4050409@domain.hid> <2ff1a98a0801140525y2bc4a198o97967585f6de0f7c@domain.hid> <478B8249.90303@domain.hid> <2ff1a98a0801140752y5e6e47e2tb9980bfb344522a4@domain.hid> <478CAB5F.70208@domain.hid> <2ff1a98a0801150509w2dae4826r4696cd95c21aecb3@domain.hid> <478CBD27.4020501@domain.hid> <2ff1a98a0801150610n4404224bl98be4fcbccba70b7@domain.hid> In-Reply-To: <2ff1a98a0801150610n4404224bl98be4fcbccba70b7@domain.hid> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Xenomai problems on pxa List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: xenomai@xenomai.org Gilles Chanteperdrix wrote: > To solve the problem about unaligned accesses, the solution is to put > some print_symbol or show_stack(NULL, NULL) in xnpod_trap_fault. Once > we get the exact location of an unaligned access, disassemble the > kernel or a module at the given location and try and understand why > there is an unaligned access. Well, even though I've never done that before I couldn't resist to try it out. I put a 'show_stack(NULL,NULL)' in 'xnpod_trap_fault' and got following stack traces: ---- [] (show_stack+0x0/0x5c) from [] (xnpod_trap_fault+0x50/0x1e0 [xeno_nucleus]) [] (xnpod_trap_fault+0x0/0x1e0 [xeno_nucleus]) from [] (xnarch_trap_fault+0x20/0x28 [xeno_nucleus]) r6 = C01EFFE0 r5 = 00000000 r4 = 58454E4F [] (xnarch_trap_fault+0x0/0x28 [xeno_nucleus]) from [] (exception_event+0x58/0x70) [] (exception_event+0x0/0x70) from [] (__ipipe_dispatch_event+0x124/0x1ec) r5 = 00000000 r4 = 00000100 [] (__ipipe_dispatch_event+0x0/0x1ec) from [] (do_alignment+0x1a4/0x410) [] (do_alignment+0x0/0x410) from [] (do_DataAbort+0x3c/0x13c) [] (do_DataAbort+0x0/0x13c) from [] (__dabt_svc+0x4c/0x60) [] (rt_timer_inquire+0x0/0xb0 [xeno_native]) from [] (__rt_timer_inquire+0x20/0x7c [xeno_native]) r7 = BF01C2A4 r6 = C308BEA4 r5 = 00000000 r4 = C308BFB0 [] (__rt_timer_inquire+0x0/0x7c [xeno_native]) from [] (hisyscall_event+0x1ac/0x2b8 [xeno_nucleus]) r6 = C3C2F100 r5 = 00000000 r4 = C308BFB0 [] (hisyscall_event+0x0/0x2b8 [xeno_nucleus]) from [] (__ipipe_dispatch_event+0x124/0x1ec) [] (__ipipe_dispatch_event+0x0/0x1ec) from [] (__ipipe_syscall_root+0x5c/0x108) [] (__ipipe_syscall_root+0x0/0x108) from [] (vector_swi+0x5c/0x98) Xenomai: Switching sampling-763 to secondary mode after exception #8 in kernel-space at 0xbf028e94 (pid 765) [] (show_stack+0x0/0x5c) from [] (xnpod_trap_fault+0x50/0x1e0 [xeno_nucleus]) [] (xnpod_trap_fault+0x0/0x1e0 [xeno_nucleus]) from [] (xnarch_trap_fault+0x20/0x28 [xeno_nucleus]) r6 = C01EFFE0 r5 = 00000000 r4 = 58454E4F [] (xnarch_trap_fault+0x0/0x28 [xeno_nucleus]) from [] (exception_event+0x58/0x70) [] (exception_event+0x0/0x70) from [] (__ipipe_dispatch_event+0x124/0x1ec) r5 = 00000000 r4 = 00000100 [] (__ipipe_dispatch_event+0x0/0x1ec) from [] (do_alignment+0x1a4/0x410) [] (do_alignment+0x0/0x410) from [] (do_DataAbort+0x3c/0x13c) [] (do_DataAbort+0x0/0x13c) from [] (__dabt_svc+0x4c/0x60) [] (__rt_task_set_periodic+0x0/0x11c [xeno_native]) from [] (losyscall_event+0xc8/0x1ac [xeno_nucleus]) r6 = C308BFB0 r5 = 00000001 r4 = 00000022 [] (losyscall_event+0x0/0x1ac [xeno_nucleus]) from [] (__ipipe_dispatch_event+0x124/0x1ec) [] (__ipipe_dispatch_event+0x0/0x1ec) from [] (__ipipe_syscall_root+0x5c/0x108) [] (__ipipe_syscall_root+0x0/0x108) from [] (vector_swi+0x5c/0x98) Xenomai: Switching sampling-763 to secondary mode after exception #8 in kernel-space at 0xbf02a8b0 (pid 765) latency: failed to set periodic, code -110 warming up... [] (show_stack+0x0/0x5c) from [] (xnpod_trap_fault+0x50/0x1e0 [xeno_nucleus]) [] (xnpod_trap_fault+0x0/0x1e0 [xeno_nucleus]) from [] (xnarch_trap_fault+0x20/0x28 [xeno_nucleus]) r6 = C01EFFE0 r5 = 00000000 r4 = 58454E4F [] (xnarch_trap_fault+0x0/0x28 [xeno_nucleus]) from [] (exception_event+0x58/0x70) [] (exception_event+0x0/0x70) from [] (__ipipe_dispatch_event+0x124/0x1ec) r5 = 00000000 r4 = 00000100 [] (__ipipe_dispatch_event+0x0/0x1ec) from [] (do_alignment+0x1a4/0x410) [] (do_alignment+0x0/0x410) from [] (do_DataAbort+0x3c/0x13c) [] (do_DataAbort+0x0/0x13c) from [] (__dabt_svc+0x4c/0x60) [] (__rt_sem_p+0x0/0xc0 [xeno_native]) from [] (losyscall_event+0xc8/0x1ac [xeno_nucleus]) r6 = C3B33FB0 r5 = 00000001 r4 = 00000006 [] (losyscall_event+0x0/0x1ac [xeno_nucleus]) from [] (__ipipe_dispatch_event+0x124/0x1ec) [] (__ipipe_dispatch_event+0x0/0x1ec) from [] (__ipipe_syscall_root+0x5c/0x108) [] (__ipipe_syscall_root+0x0/0x108) from [] (vector_swi+0x5c/0x98) Xenomai: Switching display-763 to secondary mode after exception #8 in kernel-space at 0xbf02afd4 (pid 764) latency: failed to pend on semaphore, code -1 ---- In the first unaligned access, data abort occurs in 'rt_timer_inquire'. In this function I put a 'printk' after each C-line. If I didn't mess the things up this way, data abort occurs at the assignment: info->period = period; Looking at the assembler, instruction 'strd' is used to store this 'long long' variable. Interestingly, structure 'info' is allocated on the stack in function '__rt_timer_inquire' which calls 'rt_timer_inquire' and passes 'info' as an argument. I'm not sure but the problem could be that 'long long' variables need to be 8-byte aligned in order to allow 'strd' and 'ldrd' instructions. See: http://groups.google.ch/group/comp.sys.arm/browse_thread/thread/a4ed79328671521d/2e3bb93e5a59f785 However, I don't know how to make 'info' to be allocated at an 8-byte boundary. Looking at the assembler of the two other catches (in '__rt_task_set_periodic' and '__rt_sem_p') shows that both function use also 'strd' and 'ldrd' instructions. I didn't check if data abort occurred at these instructions however. > You can do this yourself if you are in a > hurry, or let me do it if I am able to reproduce the bug on AT91, but > I need to generate a full image with EABI enabled, so it will take > some time. OK, I started with it but I'd like to let you work on this now. I don't have the knowledge to fiddle with compiler options or using macros or whatever to solve this problem. Today, I don't have access to the hardware. When needed I can run tests on an other day. -- Michael