Cyril Wallois wrote:
> Hi Jan,
>
> My problem appears in the function :
>
> /***
> * rt_icmp_release
> */
> void rt_icmp_release(void)
> {
> rt_icmp_cleanup_echo_requests();
> rt_inet_del_protocol(&icmp_protocol);
> rt_bare_socket_cleanup(&icmp_socket);
> }
>
> in the function rt_bare_socket_cleanup() which called rtskb_pool_release()
>
> I don't know if there enough information to solve the problem,
>
> Best regards,
>
> WALLOIS Cyril
>
>
>
> Xenomai: suspending kernel thread bf0270e0 ('rtnet-rtpc') at 0xbf02b814 after
> exception #8
>
> kernel thread bf0270e0 :
> /proc/kallsyms :
> bf0270e0 b dispatch_task [rtnet]
>
> 0xbf02b814
> /proc/kallsyms :
> bf02b790 -> rt_icmp_echo_reply [rtipv4]
> bf02b790 t $a [rtipv4]
> 0xbf02b814
> bf02b8d8 t $d [rtipv4]
>
>
> (begin of the module rt_ipv4 : 0x029000 , 0xbf02b814 should correspond to
> 2814)
What does "grep rtipv4 /proc/modules" report as base address? Really
0xbf029000?
>
> With arm-linux-gnueabi-objdump -dSr rtipv4.ko I can solve the adress
> 0xbf02b814 (line 2814) :
>
>
>
> /***
> * rt_icmp_release
> */
> void rt_icmp_release(void)
> {
> 2610: e1a0c00d mov ip, sp
> 2614: e92dd800 stmdb sp!, {fp, ip, lr, pc}
> 2618: e24cb004 sub fp, ip, #4 ; 0x4
> rt_icmp_cleanup_echo_requests();
> 261c: ebfffffe bl 2584 <rt_icmp_cleanup_echo_requests>
> 261c: R_ARM_CALL rt_icmp_cleanup_echo_requests
> rt_inet_del_protocol(&icmp_protocol);
> 2620: e59f000c ldr r0, [pc, #12] ; 2634 <.text+0x2634>
> 2624: ebfffffe bl ac8 <rt_inet_del_protocol>
> 2624: R_ARM_CALL rt_inet_del_protocol
> unsigned int priority, unsigned int pool_size);
>
> static inline void rt_bare_socket_cleanup(struct rtsocket *sock)
> {
> rtskb_pool_release(&sock->skb_pool);
> 2628: e59f0008 ldr r0, [pc, #8] ; 2638 <.text+0x2638>
> 262c: ebfffffe bl 0 <__rtskb_pool_release>
> 262c: R_ARM_CALL __rtskb_pool_release
> rt_bare_socket_cleanup(&icmp_socket);
> }
>
> ...
> static inline int test_bit(int nr, const volatile unsigned long *addr)
> {
> return 1UL & (addr[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));
> 27f0: e59c3000 ldr r3, [ip]
> * both statuses, assuming that the lowest bit is always set in
> * the truth value (if this is wrong, the failed optimization will
> * be caught in __ipipe_restore_pipeline_head() if
> * CONFIG_DEBUG_KERNEL is set). */
> if ((x ^ test_bit(IPIPE_STALL_FLAG, &ipipe_head_cpudom_var(status))) & 1)
> 27f4: e2033001 and r3, r3, #1 ; 0x1
> 27f8: e1500003 cmp r0, r3
> 27fc: 0a000000 beq 2804 <rt_icmp_echo_reply+0x74>
> __ipipe_restore_pipeline_head(x);
> 2800: ebfffffe bl 0 <__ipipe_restore_pipeline_head>
> 2800: R_ARM_CALL __ipipe_restore_pipeline_head
> 2804: e5973028 ldr r3, [r7, #40]
> 2808: e2856024 add r6, r5, #36 ; 0x24
> 280c: e3a00000 mov r0, #0 ; 0x0
> 2810: e593300c ldr r3, [r3, #12]
> 2814: e3a01000 mov r1, #0 ; 0x0
Makes no sense yet. This is moving an immediate into register r1 -
nothing where misaligned memory access can happen.
Please validate your calculations, maybe also adding some printks to the
lines under suspect.
> 2818: e1c602f0 strd r0, [r6, #32]
> 281c: e5863010 str r3, [r6, #16]
> 2820: e5973024 ldr r3, [r7, #36]
> 2824: e1d621b4 ldrh r2, [r6, #20]
> 2828: e1d330b4 ldrh r3, [r3, #4]
> 282c: e1530002 cmp r3, r2
> 2830: 1a000024 bne 28c8 <rt_icmp_echo_reply+0x138>
> 2834: ea000005 b 2850 <rt_icmp_echo_reply+0xc0>
> * @addr: Address to start counting from
> */
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
------------------------------------------------------------------------------
_______________________________________________
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
