Re: [RTnet-developers] Kernel module for smc91111

[Gilles C. <gil...@xe...>]

On 09/20/2011 08:54 AM, Hinko Kocevar wrote:
> On 09/16/2011 10:04 AM, Jan Kiszka wrote:
>> On 2011-09-16 09:33, Hinko Kocevar wrote:
>>> On 09/16/2011 08:32 AM, Jan Kiszka wrote:
>>>> On 2011-09-14 12:18, Hinko Kocevar wrote:
> 
>>> [   36.443975] BUG: sleeping function called from invalid context at
>>> arch/arm/mm/fault.c:312
>>> [   36.452177] in_atomic(): 0, irqs_disabled(): 128, pid: 192, name: sh
>>> [   36.458539] Backtrace:
>>> [   36.461050] [<c0022a88>] (dump_backtrace+0x0/0x118) from [<c0022bd4>]
>>> (dump_stack+0x18/0x1c)
>>> [   36.469510]  r7:c3d5fca0 r6:c3d7b960 r5:c3d7b994 r4:c3dc6000
>>> [   36.475242] [<c0022bbc>] (dump_stack+0x0/0x1c) from [<c002cb20>]
>>> (__might_sleep+0xd8/0xfc)
>>> [   36.483558] [<c002ca48>] (__might_sleep+0x0/0xfc) from [<c002603c>]
>>> (do_page_fault+0x124/0x294)
>>> [   36.492276]  r4:00000000
>>> [   36.494865] [<c0025f18>] (do_page_fault+0x0/0x294) from [<c001e320>]
>>> (do_DataAbort+0x40/0x134)
>>> [   36.503520] [<c001e2e0>] (do_DataAbort+0x0/0x134) from [<c001ef84>]
>>> (ret_from_exception+0x0/0x40)
>>> [   36.512412] Exception stack(0xc3dc7fb0 to 0xc3dc7ff8)
>>> [   36.517490] 7fa0:                                     40018350
>>> 00000000 00000000 000000c0
>>> [   36.525709] 7fc0: 40017f68 00000000 000000c0 00000000 000000ce
>>> ffffffff 4017b000 becc20f4
>>> [   36.533917] 7fe0: 40018350 becc20a8 400f54f8 400d090c 60000010 ffffffff
>>> [   36.540549]  r8:000000ce r7:00000000 r6:000000c0 r5:00000000 r4:ffffffff
> 
> Caught that one!
> 
> It was in my drivers hard_start_xmit() routine, where a macro made a 
> call to local_irq_save()/local_irq_restore(). Another mistake was when 
> setting the skb->xmit_stamp in the same function..
> 
> Now I can get past the above issue and stumbled across another .. This 
> time it happens when trying to rtping 127.0.0.1.
> 
> 
> I've added some debugging in icmp.c:
> 
>      rtdm_printk("%s: skb->h.icmph->un.echo.id == cmd->args.ping.id: %d 
> == %d\n", __FUNCTION__, skb->h.icmph->un.echo.id , cmd->args.ping.id);
> 	rtdm_printk("%s: ntohs(skb->h.icmph->un.echo.sequence) == 
> cmd->args.ping.sequence: %d == %d\n", __FUNCTION__, 
> ntohs(skb->h.icmph->un.echo.sequence), cmd->args.ping.sequence);
> 	rtdm_printk("%s: skb->len == cmd->args.ping.msg_size: %d == %d\n", 
> __FUNCTION__, skb->len, cmd->args.ping.msg_size);
> 	rtdm_printk("%s: skb->len >= sizeof(nanosecs_abs_t): %d >= %d\n", 
> __FUNCTION__, skb->len, sizeof(nanosecs_abs_t));
> 	rtdm_printk("%s: cmd->args.ping.rtt = %lld\n", __FUNCTION__, 
> rtdm_clock_read() - *((nanosecs_abs_t *)skb->data));
> 
> just before:
> 
>      if ((skb->h.icmph->un.echo.id == cmd->args.ping.id) &&
>          (ntohs(skb->h.icmph->un.echo.sequence) == 
> cmd->args.ping.sequence) &&
>          skb->len == cmd->args.ping.msg_size) {
>          if (skb->len >= sizeof(nanosecs_abs_t))
>              cmd->args.ping.rtt =
>                  rtdm_clock_read() - *((nanosecs_abs_t *)skb->data);
>          rtpc_complete_call(call, sizeof(struct icmphdr) + skb->len);
>      } else
>          rtpc_complete_call(call, 0);
> 
> This is the output I get on the console:
> 
> root@xcep:~# /usr/local/rtnet/sbin/rtping 127.0.0.1
> Real-time PING 127.0.0.1 56(84) bytes of data.
> [  285.365729] rt_icmp_send_echo: pre rt_icmp_send_request()
> [  285.374080] rt_icmp_send_request: pre rt_ip_build_xmit()
> [  285.379452] rt_ip_build_xmit: pre rtdev_xmit()
> [  285.383906] rtdev_xmit: pre rtdev->start_xmit()
> [  285.388462] rt_icmp_rcv:
> [  285.390998] rt_icmp_rcv: pre icmpHdr->type 8
> [  285.395276] rt_icmp_echo_request:
> [  285.398679] rt_icmp_send_reply:
> [  285.401910] rt_icmp_send_reply: pre rt_ip_build_xmit()
> [  285.407074] rt_ip_build_xmit: pre rtdev_xmit()
> [  285.411554] rtdev_xmit: pre rtdev->start_xmit()
> [  285.416118] rt_icmp_rcv:
> [  285.418653] rt_icmp_rcv: pre icmpHdr->type 0
> [  285.422941] rt_icmp_echo_reply:
> [  285.426172] rt_icmp_echo_reply: pre rtpc_get_priv()
> [  285.431059] rt_icmp_echo_reply: port rtpc_get_priv()
> [  285.436035] rt_icmp_echo_reply: skb->h.icmph->un.echo.id == 
> cmd->args.ping.id: 58826 == 58826
> [  285.444596] rt_icmp_echo_reply: ntohs(skb->h.icmph->un.echo.sequence) 
> == cmd->args.ping.sequence: 1 == 1
> [  285.454107] rt_icmp_echo_reply: skb->len == cmd->args.ping.msg_size: 
> 56 == 56
> [  285.461260] rt_icmp_echo_reply: skb->len >= sizeof(nanosecs_abs_t): 
> 56 >= 8
> [  285.468241] Xenomai: suspending kernel thread bf011030 ('rtnet-rtpc') 
> at 0xbf01e4ec after exception #0x8
> 
> 
> The last debug line is not printed, what make to conclude that I'm 
> hitting some issue in rtdm_clock_read().
> 
> As I pointed out before I'm running this on PXA255 based CPU, this time 
> on 2.6.37.6 and latest Xenomai v2.6.0-rc3. I used this Xenomai 
> configuration options:
> 
> [sbox-itech-sf-armel-kek: ~/xxx] > 
> ./xenomai-2.6.0-rc3/scripts/prepare-kernel.sh 
> --linux=/home/hinko/xxx/linux-2.6.37.6
> 
> [sbox-itech-sf-armel-kek: ~/xxx/xenomai-2.6.0-rc3] > ./configure 
> CFLAGS="-march=armv4t" LDFLAGS="-march=armv4t" --enable-debug 
> --prefix=/home/hinko/xxx/out
> 
> Should I consider using '--enable-arm-tsc' switch, maybe?

pxa are armv5, not armv4. No, you do not want to pass --enable-arm-tsc

-- 
					    Gilles.