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?
Thank you!
--
Hinko Kocevar
Technical support software engineer
Instrumentation Technologies d.d.
Velika pot 22, SI-5250 Solkan - Slovenia
T:+386 5 3352600, F:+386 5 3352601
mailto: [email protected]
http://www.i-tech.si - When your users demand stability
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
RTnet-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rtnet-developers
