rtnet-developers Mailing List for RTnet - Real-Time Networking for Linux (Page 5)
Brought to you by:
bet-frogger,
kiszka
Menu
▾
▴
rtnet-developers — development-related list
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
(12) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(13) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(7) |
Jun
(13) |
Jul
(6) |
Aug
(15) |
Sep
(1) |
Oct
(3) |
Nov
(2) |
Dec
(11) |
| 2006 |
Jan
(2) |
Feb
|
Mar
(13) |
Apr
|
May
(6) |
Jun
(7) |
Jul
(8) |
Aug
(13) |
Sep
(28) |
Oct
(5) |
Nov
(17) |
Dec
(5) |
| 2007 |
Jan
(2) |
Feb
(18) |
Mar
(22) |
Apr
(5) |
May
(4) |
Jun
(2) |
Jul
(5) |
Aug
(22) |
Sep
|
Oct
(3) |
Nov
(4) |
Dec
(2) |
| 2008 |
Jan
|
Feb
(3) |
Mar
(15) |
Apr
(7) |
May
(2) |
Jun
(18) |
Jul
(19) |
Aug
(6) |
Sep
(7) |
Oct
(2) |
Nov
(3) |
Dec
(1) |
| 2009 |
Jan
(8) |
Feb
(2) |
Mar
|
Apr
(3) |
May
(4) |
Jun
(2) |
Jul
(7) |
Aug
|
Sep
(2) |
Oct
(8) |
Nov
(16) |
Dec
(16) |
| 2010 |
Jan
(5) |
Feb
(2) |
Mar
|
Apr
(16) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(8) |
Oct
(20) |
Nov
|
Dec
(10) |
| 2011 |
Jan
(15) |
Feb
(33) |
Mar
(5) |
Apr
(8) |
May
(5) |
Jun
|
Jul
|
Aug
(2) |
Sep
(21) |
Oct
(21) |
Nov
(12) |
Dec
(7) |
| 2012 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(5) |
Oct
|
Nov
|
Dec
(2) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2014 |
Jan
|
Feb
(3) |
Mar
(5) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(2) |
Nov
(8) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Arnout V. (Essensium/Mind) <ar...@mi...> - 2011-09-28 09:35:10
|
From: "Arnout Vandecappelle (Essensium/Mind)" <ar...@mi...> autoconf 2.68 doesn't produce a newline at the end of AS_IF(). Therefore, the 'done' of the for loop gets concatenated with the 'fi' of AS_IF(). Adding an explicit newline fixes it. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <ar...@mi...> --- config/m4/bs.m4 | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/config/m4/bs.m4 b/config/m4/bs.m4 index 9f767e5..7d98ec4 100644 --- a/config/m4/bs.m4 +++ b/config/m4/bs.m4 @@ -113,6 +113,7 @@ BS_CHECK_KHEADER($ac_header, [AC_DEFINE_UNQUOTED(AS_TR_CPP(HAVE_$ac_header)) $2], [$3], [$4])dnl + done ])# BS_CHECK_KHEADERS -- 1.7.6.3 |
|
From: Arnout V. (Essensium/Mind) <ar...@mi...> - 2011-09-28 09:33:21
|
From: "Arnout Vandecappelle (Essensium/Mind)" <ar...@mi...>
If we use ccache, CROSS_COMPILE will be something like "ccache gccprefix".
If we don't quote the argument, then the sub-make will use "ccache" as the
cross-compile prefix and will try to build "gccprefix"
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <ar...@mi...>
---
configure.ac | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 81107f5..86a72fd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -608,7 +608,7 @@ else
fi; \
done; \
\$(MAKE) -C $RTEXT_LINUX_DIR \
- CROSS_COMPILE=\$(CROSS_COMPILE) \
+ CROSS_COMPILE=\"\$(CROSS_COMPILE)\" \
ARCH=\$(RTNET_TARGET_ARCH) \
M=\"\`pwd\`\" \
V=\$(V) \
@@ -664,7 +664,7 @@ AC_SUBST(RTNET_KBUILD_CLEAN)
AC_SUBST(RTNET_KBUILD_DISTCLEAN)
bs_kmodext=$RTNET_MODULE_EXT
-bs_kcompile="make -C $RTEXT_LINUX_DIR ARCH=$RTNET_TARGET_ARCH CROSS_COMPILE=$CROSS_COMPILE V=1 M=`pwd` SUBDIRS=`pwd` modules"
+bs_kcompile="make -C $RTEXT_LINUX_DIR ARCH=$RTNET_TARGET_ARCH CROSS_COMPILE=\"$CROSS_COMPILE\" V=1 M=`pwd` SUBDIRS=`pwd` modules"
dnl ======================================================================
--
1.7.6.3
|
|
From: Jan K. <jan...@we...> - 2011-09-27 08:01:34
|
On 2011-09-27 09:50, Arnout Vandecappelle wrote: > Hoi all, > > I'm adding support for Intel's 82574L, 82574LA and 82583V chips to RTnet > (based on the 2.6.35 e1000e driver). Should I add this to the rt_e1000 driver > or the experimental rt_e1000_new driver? Where it fits better from your POV, I've no overview ATM. Petr can comment on this likely, he worked on this recently as well. Petr, can you subscribe and repost your patches? Jan |
|
From: Arnout V. <ar...@mi...> - 2011-09-27 07:51:29
|
Hoi all, I'm adding support for Intel's 82574L, 82574LA and 82583V chips to RTnet (based on the 2.6.35 e1000e driver). Should I add this to the rt_e1000 driver or the experimental rt_e1000_new driver? Regards, Arnout -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286540 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 31BB CF53 8660 6F88 345D 54CC A836 5879 20D7 CF43 |
|
From: Hinko K. <hin...@i-...> - 2011-09-21 12:02:38
|
On 09/14/2011 12:18 PM, Hinko Kocevar wrote:
> Hi all,
>
> I'm trying to use smc91111 RT driver provided in RTnet package (git
> sources) on my ARM PXA253 board. The modules compiles against linux
> 2.6.35.9 and Xenomai 2.5.6, but when it is loaded it produces oops.
>
Success at porting the smc91x kernel driver at last!!
root@xcep:~# /usr/local/rtnet/sbin/rtping 127.0.0.1
Real-time PING 127.0.0.1 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 time=86.0 us
64 bytes from 127.0.0.1: icmp_seq=2 time=87.6 us
64 bytes from 127.0.0.1: icmp_seq=3 time=78.7 us
64 bytes from 127.0.0.1: icmp_seq=4 time=76.5 us
The story continues ..
While rtping does seem to work to 127.0.0.1, I can't seem to persuade
the neighboring PC to reply to pings. PC is using e100 eth driver, and
is running Linux 2.6.35.9 with Xenomai 2.5.6. I can confirm that on the
PC rtping to 127.0.0.1 works, too.
Also when using regular network driver modules on both systems, ping
from one to another does work. There are only these two nodes
interconnected over the hub on a dedicated subnet. What happens is that
the nodes do not seem to discover each other ..
Attached are both rtnet.conf files, and some sh -x output of the rtnet
start. In this setup I'm trying to use my embedded target (xcep) as
RTnet master, and PC as slave. I've tried the other way around to no avail.
Here are outputs of rtifconfig too.
root@xcep:~# /usr/local/rtnet/sbin/rtifconfig
rteth0 Medium: Ethernet Hardware address: 00:D0:50:31:11:87
IP address: 192.168.2.2 Broadcast address: 192.168.2.255
UP BROADCAST RUNNING MTU: 1500
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:184100 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
RX bytes:0 (0.0 b) TX bytes:7778916 (7.4 Mb)
rtlo Medium: Local Loopback
IP address: 127.0.0.1
UP LOOPBACK RUNNING MTU: 1500
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
workshop@workshop-Compaq-EVO:~$ sudo /usr/local/rtnet/sbin/rtifconfig
rteth0 Medium: Ethernet Hardware address: 00:04:23:34:09:59
IP address: 192.168.2.1 Broadcast address: 192.168.2.255
UP BROADCAST RUNNING MTU: 1500
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
rtlo Medium: Local Loopback
IP address: 127.0.0.1
UP LOOPBACK RUNNING MTU: 1500
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
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: hin...@i-...
http://www.i-tech.si - When your users demand stability
|
|
From: Hinko K. <hin...@i-...> - 2011-09-20 11:29:26
|
On 09/20/2011 11:47 AM, Gilles Chanteperdrix wrote:
> On 09/20/2011 11:02 AM, Hinko Kocevar wrote:
>> I stand corrected - the problem is in the second part of that line, what
>> was proven by two more debug lines:
>>
>> rtdm_printk("%s: rtdm_clock_read() = %lld\n", __FUNCTION__,
>> rtdm_clock_read());
>> rtdm_printk("%s: *((nanosecs_abs_t *)skb->data) = %lld\n", __FUNCTION__,
>
> This is wrong: skb->data is a char *, you cast it to nanosecs_abs_t *
> which has a strongest alignment requirement, so you get...
>
>> [ 226.206024] Xenomai: suspending kernel thread bf011030 ('rtnet-rtpc')
>> at 0xbf01e66c after exception #0x8
>
> ... an alignment trap.
>
What I've done is take the lines of code from the existing RTnet GIT
source and just try to print out the value.
The offending line can be seen in icmp.c:241,
http://rtnet.git.sourceforge.net/git/gitweb.cgi?p=rtnet/rtnet;a=blob;f=stack/ipv4/icmp.c;h=2dbd3315dfa60e9fa02332cd8a203661130db8de;hb=a3bc0758ee33980836f1ca54ada9ccee762e24ad#l241
Maybe this is not an issue on non-arm (pxa255) targets?
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: hin...@i-...
http://www.i-tech.si - When your users demand stability
|
|
From: Hinko K. <hin...@i-...> - 2011-09-20 11:26:03
|
On 09/20/2011 11:44 AM, Gilles Chanteperdrix wrote: > 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: >> > > pxa are armv5, not armv4. No, you do not want to pass --enable-arm-tsc > Ups, my bad. Will recompile with armv5. 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: hin...@i-... http://www.i-tech.si - When your users demand stability |
|
From: Gilles C. <gil...@xe...> - 2011-09-20 10:26:56
|
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.
|
|
From: Gilles C. <gil...@xe...> - 2011-09-20 10:26:49
|
On 09/20/2011 11:02 AM, Hinko Kocevar wrote:
> I stand corrected - the problem is in the second part of that line, what
> was proven by two more debug lines:
>
> rtdm_printk("%s: rtdm_clock_read() = %lld\n", __FUNCTION__,
> rtdm_clock_read());
> rtdm_printk("%s: *((nanosecs_abs_t *)skb->data) = %lld\n", __FUNCTION__,
This is wrong: skb->data is a char *, you cast it to nanosecs_abs_t *
which has a strongest alignment requirement, so you get...
> [ 226.206024] Xenomai: suspending kernel thread bf011030 ('rtnet-rtpc')
> at 0xbf01e66c after exception #0x8
... an alignment trap.
--
Gilles.
|
|
From: Hinko K. <hin...@i-...> - 2011-09-20 09:02:22
|
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:
...
> 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);
>
...
>
>
> The last debug line is not printed, what make to conclude that I'm
> hitting some issue in rtdm_clock_read().
>
I stand corrected - the problem is in the second part of that line, what
was proven by two more debug lines:
rtdm_printk("%s: rtdm_clock_read() = %lld\n", __FUNCTION__,
rtdm_clock_read());
rtdm_printk("%s: *((nanosecs_abs_t *)skb->data) = %lld\n", __FUNCTION__,
*((nanosecs_abs_t *)skb->data));
console output:
[ 226.199979] rt_icmp_echo_reply: rtdm_clock_read() = 220200016476
[ 226.206024] Xenomai: suspending kernel thread bf011030 ('rtnet-rtpc')
at 0xbf01e66c after exception #0x8
Packet skb->data contents:
[ 226.116158] rt_icmp_echo_reply: ICMP pkt >>>>>:
[ 226.120722] e072 e944 3300 0000 0001 0203 0405 0607
[ 226.125757] 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617
[ 226.130818] 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627
[ 226.135852] 2829 2a2b 2c2d 2e2f
[ 226.139118] rt_icmp_echo_reply: ICMP pkt <<<<<
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: hin...@i-...
http://www.i-tech.si - When your users demand stability
|
|
From: Hinko K. <hin...@i-...> - 2011-09-20 06:54:48
|
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: hin...@i-...
http://www.i-tech.si - When your users demand stability
|
|
From: Hinko K. <hin...@i-...> - 2011-09-16 08:14:13
|
On 09/16/2011 10:04 AM, Jan Kiszka wrote:
<..>
>> 255.255.255.0
>> + /usr/local/rtnet/sbin/tdmacfg rteth0 master 5000
>> + /usr/local/rtnet/sbin/tdmacfg rteth0 slot 0 0
>> [ 36.417588] I-pipe: Detected illicit call from domain 'Xenomai'
>> [ 36.417626]<3> into a service reserved for domain 'Linux' and
>> below.
>> [ 36.432007] Backtrace:
>> [ 36.434313] Xenomai: suspending kernel thread c3e51940 ('rtnet-tdma')
>> at 0xc0022b6c after exception #0
>
> Many overlapping errors, but this line is likely the root. Check that
> code address (0xc0022b6c) to see if something could oops there.
>
System.map has these:
c0022910 t dump_instr
c0022a50 T __bad_xchg
c0022a88 t dump_backtrace <<----- offending function
c0022ba0 T show_stack
c0022bbc T dump_stack
c0022bd8 T __div0
c0022bf8 T unregister_undef_hook
c0022c68 t dump_mem
c0022ddc T die
c0022fb8 T bad_mode
Probably dump_backtrace is not what I'm looking for :S
<..>
>
> If spinlocks included IRQ disabling, you need to keep that. Still, this
> approach is not a good idea as you lose critical section marks - and the
> spinning part of those locks is a nop on UP anyway.
Will revise, thank you!
Best regards,
Hinko
--
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: hin...@i-...
http://www.i-tech.si - When your users demand stability
|
|
From: Jan K. <jan...@we...> - 2011-09-16 08:05:29
|
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:
>>> Hi all,
>>>
>>> I'm trying to use smc91111 RT driver provided in RTnet package (git
>>> sources) on my ARM PXA253 board. The modules compiles against linux
>>> 2.6.35.9 and Xenomai 2.5.6, but when it is loaded it produces oops.
>>>
>>> What is the state of this module?
>>>
>>> OTOH, I might also try to port the stock kernel driver smc91x we are
>>> currently using to RTnet. It is quite similar to the one in RTnet but
>>> with more features and support for many ARM based boards.
>>
>> The rt_smc91111 is probably not prepared for your hardware. Note that
>> there is both smc91x ans smc911x in upstream while rt_smc9111 was based
>> on the latter (IIRC).
>>
>
> Thank you for response.
>
> I have done some porting of the smc91x driver as found in 2.6.35.9
> vanilla kernel to RTnet. The driver compiles and loads fine, my network
> card is also detected. Once started with "./rtnet start" I get this :
>
> [ 36.417588] I-pipe: Detected illicit call from domain 'Xenomai'
> [ 36.417626] <3> into a service reserved for domain 'Linux' and
> below.
>
>
> Complete dump:
>
> root@xcep:~# sh -x /usr/local/rtnet/sbin/rtnet start
> + prefix=/usr/local/rtnet
> + RTNETCFG=/usr/local/rtnet/etc/rtnet.conf
> + '[' start = -cf ']'
> + '[' -r /usr/local/rtnet/etc/rtnet.conf ']'
> + . /usr/local/rtnet/etc/rtnet.conf
> ++ prefix=/usr/local/rtnet
> ++ exec_prefix=/usr/local/rtnet
> ++ RTNET_MOD=/usr/local/rtnet/modules
> ++ RTIFCONFIG=/usr/local/rtnet/sbin/rtifconfig
> ++ RTCFG=/usr/local/rtnet/sbin/rtcfg
> ++ TDMACFG=/usr/local/rtnet/sbin/tdmacfg
> ++ MODULE_EXT=.ko
> ++ RT_DRIVER=rt_smc91111
> ++ RT_DRIVER_OPTIONS=
> ++ IPADDR=127.0.0.2
> ++ NETMASK=255.255.255.0
> ++ RT_LOOPBACK=yes
> ++ RT_PROTOCOLS=udp packet
> ++ RTCAP=no
> ++ STAGE_2_SRC=
> ++ STAGE_2_DST=
> ++ STAGE_2_CMDS=
> ++ TDMA_MODE=master
> ++ TDMA_SLAVES=127.0.0.1
> ++ TDMA_CYCLE=5000
> ++ TDMA_OFFSET=200
> + '[' start = -v ']'
> + '[' start = -c ']'
> + NETMASK_OPT=
> + '[' '!' 255.255.255.0 = '' ']'
> + NETMASK_OPT=netmask 255.255.255.0
> + init_rtnet
> + insmod /usr/local/rtnet/modules/rtnet.ko
> [ 32.975902]
> [ 32.975935] *** RTnet 0.9.12 - built on Sep 14 2011 15:06:10 ***
> [ 32.975952]
> [ 32.985177] RTnet: initialising real-time networking
> + insmod /usr/local/rtnet/modules/rtipv4.ko
> + insmod /usr/local/rtnet/modules/rt_smc91111.ko
> [ 33.958026] smc91x.c: v1.1-RTnet, sep 13 2011 by Hinko Kocevar
> <hin...@i-...>
> [ 33.976603] RTnet: registered rteth0
> [ 33.980392] rteth0: SMC91C11xFD (build 1316009442) (rev 2) at
> c4b2c300 IRQ 8 DMA 8 [nowait]
> [ 33.988842] rteth0: Ethernet addr: 00:d0:50:31:11:6c
> + insmod /usr/local/rtnet/modules/rtudp.ko
> + insmod /usr/local/rtnet/modules/rtpacket.ko
> + '[' yes = yes ']'
> + insmod /usr/local/rtnet/modules/rt_loopback.ko
> [ 34.457924] initializing loopback...
> [ 34.462746] RTnet: registered rtlo
> + '[' no = yes ']'
> + '[' yes = yes ']'
> + /usr/local/rtnet/sbin/rtifconfig rtlo up 127.0.0.1
> + '[' no = yes ']'
> + insmod /usr/local/rtnet/modules/rtcfg.ko
> [ 35.218000] RTcfg: init real-time configuration distribution protocol
> + insmod /usr/local/rtnet/modules/rtmac.ko
> [ 35.728923] RTmac: init realtime media access control
> + insmod /usr/local/rtnet/modules/tdma.ko
> [ 36.209592] RTmac/TDMA: init time division multiple access control
> mechanism
> + '[' master = master ']'
> + start_master
> + /usr/local/rtnet/sbin/rtcfg rteth0 server
> [ 36.253994] RTcfg: rtcfg_do_main_event() rtdev=1,
> event=RTCFG_CMD_SERVER, state=RTCFG_MAIN_OFF
> [ 36.262661] RTcfg: next main state=RTCFG_MAIN_SERVER_RUNNING
> + STAGE_2_OPT=
> + '[' '!' '' = '' ']'
> + '[' '!' 127.0.0.1 = '' ']'
> + /usr/local/rtnet/sbin/rtifconfig rteth0 up 127.0.0.2 netmask
> 255.255.255.0
> + /usr/local/rtnet/sbin/tdmacfg rteth0 master 5000
> + /usr/local/rtnet/sbin/tdmacfg rteth0 slot 0 0
> [ 36.417588] I-pipe: Detected illicit call from domain 'Xenomai'
> [ 36.417626] <3> into a service reserved for domain 'Linux' and
> below.
> [ 36.432007] Backtrace:
> [ 36.434313] Xenomai: suspending kernel thread c3e51940 ('rtnet-tdma')
> at 0xc0022b6c after exception #0
Many overlapping errors, but this line is likely the root. Check that
code address (0xc0022b6c) to see if something could oops there.
> [ 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
> + OFFSET=200
> + echo '$TDMACFG rteth0 slot 0 200;ifconfig vnic0 up $IPADDR $NETMASK_OPT'
> + /usr/local/rtnet/sbin/rtcfg rteth0 add 127.0.0.1 -stage1 -
> [ 36.621182] RTcfg: rtcfg_do_main_event() rtdev=1,
> event=RTCFG_CMD_ADD, state=RTCFG_MAIN_SERVER_RUNNING
> + OFFSET=400
> + ifconfig vnic0 up 127.0.0.2 netmask 255.255.255.0
> + echo -n 'Waiting for all slaves...'
> Waiting for all slaves...+ /usr/local/rtnet/sbin/rtcfg rteth0 wait
> [ 36.681875] RTcfg: rtcfg_do_main_event() rtdev=1,
> event=RTCFG_CMD_WAIT, state=RTCFG_MAIN_SERVER_RUNNING
>
> ^C
> root@xcep:~# ifconfig
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:20 errors:0 dropped:0 overruns:0 frame:0
> TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:1256 (1.2 KiB) TX bytes:1256 (1.2 KiB)
>
> vnic0 Link encap:Ethernet HWaddr 00:D0:50:31:11:6C
> inet addr:127.0.0.2 Bcast:127.0.0.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MTU:1496 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>
> Later on these lines start to appear on console:
>
> [ 69.254013] RTcfg: error -105 while sending stage 1 frame
> [ 70.254016] RTcfg: error -105 while sending stage 1 frame
> [ 71.254015] RTcfg: error -105 while sending stage 1 frame
> [ 72.254017] RTcfg: error -105 while sending stage 1 frame
> [ 73.254017] RTcfg: error -105 while sending stage 1 frame
> [ 74.254018] RTcfg: error -105 while sending stage 1 frame
> [ 75.254020] RTcfg: error -105 while sending stage 1 frame
> [ 76.254019] RTcfg: error -105 while sending stage 1 frame
> [ 77.254020] RTcfg: error -105 while sending stage 1 frame
> [ 78.254022] RTcfg: error -105 while sending stage 1 frame
> [ 79.254022] RTcfg: error -105 while sending stage 1 frame
>
>
> I feel I'm quite close to working version, so I'm attaching the driver
> sources too, if you are interested and have some time to look at
> (probably not :).
>
> Note that I used the same file names (rt_smc91111.{c,h}), while the code
> is different, for the sake of simplicity of compiling smc91x driver
> under RTnet. Hopefully of the guidelines of the README.drvporting were
> addressed. I also removed spinlocks where possible since my HW is not
> SMP capable.
If spinlocks included IRQ disabling, you need to keep that. Still, this
approach is not a good idea as you lose critical section marks - and the
spinning part of those locks is a nop on UP anyway.
Jan
|
|
From: Hinko K. <hin...@i-...> - 2011-09-16 07:34:19
|
On 09/16/2011 08:32 AM, Jan Kiszka wrote:
> On 2011-09-14 12:18, Hinko Kocevar wrote:
>> Hi all,
>>
>> I'm trying to use smc91111 RT driver provided in RTnet package (git
>> sources) on my ARM PXA253 board. The modules compiles against linux
>> 2.6.35.9 and Xenomai 2.5.6, but when it is loaded it produces oops.
>>
>> What is the state of this module?
>>
>> OTOH, I might also try to port the stock kernel driver smc91x we are
>> currently using to RTnet. It is quite similar to the one in RTnet but
>> with more features and support for many ARM based boards.
>
> The rt_smc91111 is probably not prepared for your hardware. Note that
> there is both smc91x ans smc911x in upstream while rt_smc9111 was based
> on the latter (IIRC).
>
Thank you for response.
I have done some porting of the smc91x driver as found in 2.6.35.9
vanilla kernel to RTnet. The driver compiles and loads fine, my network
card is also detected. Once started with "./rtnet start" I get this :
[ 36.417588] I-pipe: Detected illicit call from domain 'Xenomai'
[ 36.417626] <3> into a service reserved for domain 'Linux' and
below.
Complete dump:
root@xcep:~# sh -x /usr/local/rtnet/sbin/rtnet start
+ prefix=/usr/local/rtnet
+ RTNETCFG=/usr/local/rtnet/etc/rtnet.conf
+ '[' start = -cf ']'
+ '[' -r /usr/local/rtnet/etc/rtnet.conf ']'
+ . /usr/local/rtnet/etc/rtnet.conf
++ prefix=/usr/local/rtnet
++ exec_prefix=/usr/local/rtnet
++ RTNET_MOD=/usr/local/rtnet/modules
++ RTIFCONFIG=/usr/local/rtnet/sbin/rtifconfig
++ RTCFG=/usr/local/rtnet/sbin/rtcfg
++ TDMACFG=/usr/local/rtnet/sbin/tdmacfg
++ MODULE_EXT=.ko
++ RT_DRIVER=rt_smc91111
++ RT_DRIVER_OPTIONS=
++ IPADDR=127.0.0.2
++ NETMASK=255.255.255.0
++ RT_LOOPBACK=yes
++ RT_PROTOCOLS=udp packet
++ RTCAP=no
++ STAGE_2_SRC=
++ STAGE_2_DST=
++ STAGE_2_CMDS=
++ TDMA_MODE=master
++ TDMA_SLAVES=127.0.0.1
++ TDMA_CYCLE=5000
++ TDMA_OFFSET=200
+ '[' start = -v ']'
+ '[' start = -c ']'
+ NETMASK_OPT=
+ '[' '!' 255.255.255.0 = '' ']'
+ NETMASK_OPT=netmask 255.255.255.0
+ init_rtnet
+ insmod /usr/local/rtnet/modules/rtnet.ko
[ 32.975902]
[ 32.975935] *** RTnet 0.9.12 - built on Sep 14 2011 15:06:10 ***
[ 32.975952]
[ 32.985177] RTnet: initialising real-time networking
+ insmod /usr/local/rtnet/modules/rtipv4.ko
+ insmod /usr/local/rtnet/modules/rt_smc91111.ko
[ 33.958026] smc91x.c: v1.1-RTnet, sep 13 2011 by Hinko Kocevar
<hin...@i-...>
[ 33.976603] RTnet: registered rteth0
[ 33.980392] rteth0: SMC91C11xFD (build 1316009442) (rev 2) at
c4b2c300 IRQ 8 DMA 8 [nowait]
[ 33.988842] rteth0: Ethernet addr: 00:d0:50:31:11:6c
+ insmod /usr/local/rtnet/modules/rtudp.ko
+ insmod /usr/local/rtnet/modules/rtpacket.ko
+ '[' yes = yes ']'
+ insmod /usr/local/rtnet/modules/rt_loopback.ko
[ 34.457924] initializing loopback...
[ 34.462746] RTnet: registered rtlo
+ '[' no = yes ']'
+ '[' yes = yes ']'
+ /usr/local/rtnet/sbin/rtifconfig rtlo up 127.0.0.1
+ '[' no = yes ']'
+ insmod /usr/local/rtnet/modules/rtcfg.ko
[ 35.218000] RTcfg: init real-time configuration distribution protocol
+ insmod /usr/local/rtnet/modules/rtmac.ko
[ 35.728923] RTmac: init realtime media access control
+ insmod /usr/local/rtnet/modules/tdma.ko
[ 36.209592] RTmac/TDMA: init time division multiple access control
mechanism
+ '[' master = master ']'
+ start_master
+ /usr/local/rtnet/sbin/rtcfg rteth0 server
[ 36.253994] RTcfg: rtcfg_do_main_event() rtdev=1,
event=RTCFG_CMD_SERVER, state=RTCFG_MAIN_OFF
[ 36.262661] RTcfg: next main state=RTCFG_MAIN_SERVER_RUNNING
+ STAGE_2_OPT=
+ '[' '!' '' = '' ']'
+ '[' '!' 127.0.0.1 = '' ']'
+ /usr/local/rtnet/sbin/rtifconfig rteth0 up 127.0.0.2 netmask 255.255.255.0
+ /usr/local/rtnet/sbin/tdmacfg rteth0 master 5000
+ /usr/local/rtnet/sbin/tdmacfg rteth0 slot 0 0
[ 36.417588] I-pipe: Detected illicit call from domain 'Xenomai'
[ 36.417626] <3> into a service reserved for domain 'Linux' and
below.
[ 36.432007] Backtrace:
[ 36.434313] Xenomai: suspending kernel thread c3e51940 ('rtnet-tdma')
at 0xc0022b6c after exception #0
[ 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
+ OFFSET=200
+ echo '$TDMACFG rteth0 slot 0 200;ifconfig vnic0 up $IPADDR $NETMASK_OPT'
+ /usr/local/rtnet/sbin/rtcfg rteth0 add 127.0.0.1 -stage1 -
[ 36.621182] RTcfg: rtcfg_do_main_event() rtdev=1,
event=RTCFG_CMD_ADD, state=RTCFG_MAIN_SERVER_RUNNING
+ OFFSET=400
+ ifconfig vnic0 up 127.0.0.2 netmask 255.255.255.0
+ echo -n 'Waiting for all slaves...'
Waiting for all slaves...+ /usr/local/rtnet/sbin/rtcfg rteth0 wait
[ 36.681875] RTcfg: rtcfg_do_main_event() rtdev=1,
event=RTCFG_CMD_WAIT, state=RTCFG_MAIN_SERVER_RUNNING
^C
root@xcep:~# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:20 errors:0 dropped:0 overruns:0 frame:0
TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1256 (1.2 KiB) TX bytes:1256 (1.2 KiB)
vnic0 Link encap:Ethernet HWaddr 00:D0:50:31:11:6C
inet addr:127.0.0.2 Bcast:127.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MTU:1496 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Later on these lines start to appear on console:
[ 69.254013] RTcfg: error -105 while sending stage 1 frame
[ 70.254016] RTcfg: error -105 while sending stage 1 frame
[ 71.254015] RTcfg: error -105 while sending stage 1 frame
[ 72.254017] RTcfg: error -105 while sending stage 1 frame
[ 73.254017] RTcfg: error -105 while sending stage 1 frame
[ 74.254018] RTcfg: error -105 while sending stage 1 frame
[ 75.254020] RTcfg: error -105 while sending stage 1 frame
[ 76.254019] RTcfg: error -105 while sending stage 1 frame
[ 77.254020] RTcfg: error -105 while sending stage 1 frame
[ 78.254022] RTcfg: error -105 while sending stage 1 frame
[ 79.254022] RTcfg: error -105 while sending stage 1 frame
I feel I'm quite close to working version, so I'm attaching the driver
sources too, if you are interested and have some time to look at
(probably not :).
Note that I used the same file names (rt_smc91111.{c,h}), while the code
is different, for the sake of simplicity of compiling smc91x driver
under RTnet. Hopefully of the guidelines of the README.drvporting were
addressed. I also removed spinlocks where possible since my HW is not
SMP capable.
Best regards,
Hinko
--
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: hin...@i-...
http://www.i-tech.si - When your users demand stability
|
|
From: Jan K. <jan...@we...> - 2011-09-16 06:32:57
|
On 2011-09-14 12:18, Hinko Kocevar wrote: > Hi all, > > I'm trying to use smc91111 RT driver provided in RTnet package (git > sources) on my ARM PXA253 board. The modules compiles against linux > 2.6.35.9 and Xenomai 2.5.6, but when it is loaded it produces oops. > > What is the state of this module? > > OTOH, I might also try to port the stock kernel driver smc91x we are > currently using to RTnet. It is quite similar to the one in RTnet but > with more features and support for many ARM based boards. The rt_smc91111 is probably not prepared for your hardware. Note that there is both smc91x ans smc911x in upstream while rt_smc9111 was based on the latter (IIRC). Jan |
|
From: Hinko K. <hin...@i-...> - 2011-09-14 10:18:35
|
Hi all,
I'm trying to use smc91111 RT driver provided in RTnet package (git
sources) on my ARM PXA253 board. The modules compiles against linux
2.6.35.9 and Xenomai 2.5.6, but when it is loaded it produces oops.
What is the state of this module?
OTOH, I might also try to port the stock kernel driver smc91x we are
currently using to RTnet. It is quite similar to the one in RTnet but
with more features and support for many ARM based boards.
OOPS message:
root@xcep:~# sh -x /usr/local/rtnet/sbin/rtnet start
+ prefix=/usr/local/rtnet
+ RTNETCFG=/usr/local/rtnet/etc/rtnet.conf
+ '[' start = -cf ']'
+ '[' -r /usr/local/rtnet/etc/rtnet.conf ']'
+ . /usr/local/rtnet/etc/rtnet.conf
++ prefix=/usr/local/rtnet
++ exec_prefix=/usr/local/rtnet
++ RTNET_MOD=/usr/local/rtnet/modules
++ RTIFCONFIG=/usr/local/rtnet/sbin/rtifconfig
++ RTCFG=/usr/local/rtnet/sbin/rtcfg
++ TDMACFG=/usr/local/rtnet/sbin/tdmacfg
++ MODULE_EXT=.ko
++ RT_DRIVER=rt_smc91111
++ RT_DRIVER_OPTIONS=
++ IPADDR=127.0.0.2
++ NETMASK=255.255.255.0
++ RT_LOOPBACK=yes
++ RT_PROTOCOLS=tcp udp packet
++ RTCAP=no
++ STAGE_2_SRC=
++ STAGE_2_DST=
++ STAGE_2_CMDS=
++ TDMA_MODE=master
++ TDMA_SLAVES=127.0.0.1
++ TDMA_CYCLE=5000
++ TDMA_OFFSET=200
+ '[' start = -v ']'
+ '[' start = -c ']'
+ NETMASK_OPT=
+ '[' '!' 255.255.255.0 = '' ']'
+ NETMASK_OPT=netmask 255.255.255.0
+ init_rtnet
+ insmod /usr/local/rtnet/modules/rtnet.ko
[ 121.108061]
[ 121.108095] *** RTnet 0.9.12 - built on Sep 14 2011 10:21:23 ***
[ 121.108113]
[ 121.117320] RTnet: initialising real-time networking
+ insmod /usr/local/rtnet/modules/rtipv4.ko
+ insmod /usr/local/rtnet/modules/rt_smc91111.ko
[ 121.964911] LAN91C111: You shouldn't use auto-probing with insmod!
[ 121.972389] Unable to handle kernel NULL pointer dereference at
virtual address 0000020e
[ 121.980720] pgd = c3e94000
[ 121.983449] [0000020e] *pgd=a3dbc031, *pte=00000000, *ppte=00000000
[ 121.989784] Internal error: Oops: 17 [#1]
[ 121.993802] last sysfs file:
[ 121.996773] Modules linked in: rt_smc91111(+) rtipv4 rtnet [last
unloaded: smc91x]
[ 122.004411] CPU: 0 Not tainted (2.6.35.9-rtnet #2)
[ 122.009618] PC is at smc_probe+0x3c/0x47c [rt_smc91111]
[ 122.014854] LR is at 0x20f
[ 122.017582] pc : [<bf02c03c>] lr : [<0000020f>] psr: a0000013
[ 122.017600] sp : c3e5feb8 ip : c0290594 fp : c3e5ff04
[ 122.029092] r10: bf02c4fc r9 : 00000000 r8 : c02a32e0
[ 122.034329] r7 : 4012c008 r6 : 00000200 r5 : c3e3a000 r4 : 00000000
[ 122.040873] r3 : ffffffff r2 : 00000000 r1 : c3d8a520 r0 : c3d8a520
[ 122.047423] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment user
[ 122.054581] Control: 0000397f Table: a3e94000 DAC: 00000015
[ 122.060343] Process insmod (pid: 198, stack limit = 0xc3e5e270)
[ 122.066280] Stack: (0xc3e5feb8 to 0xc3e60000)
[ 122.070653] fea0:
00000000 c3e3a000
[ 122.078869] fec0: c3e5feec c3e5fed0 bf00b40c c00639c8 c3e5fef0
00000000 bf02998c c3e3a000
[ 122.087088] fee0: 00000004 00012008 4012c008 c02a32e0 00000000
bf02c4fc c3e5ff1c c3e5ff08
[ 122.095302] ff00: bf02c4cc bf02c00c bf029b40 bf029a1c c3e5ff3c
c3e5ff20 bf02c590 bf02c488
[ 122.103521] ff20: 00000000 00000000 00000000 bf029a1c c3e5ff7c
c3e5ff40 c001e478 bf02c508
[ 122.111732] ff40: 00000000 00000000 bf029a1c 00012008 4012c008
00000000 bf029a1c 00012008
[ 122.119946] ff60: 4012c008 c001f890 c3e5e000 00900080 c3e5ffa4
c3e5ff80 c005cf1c c001e424
[ 122.128164] ff80: c3e5ffa4 c3e5ff90 4001de14 4012c008 00000003
00000080 00000000 c3e5ffa8
[ 122.136378] ffa0: c001f020 c005ce8c 4001de14 4012c008 4012c008
0002ab8d 00012008 00020000
[ 122.144597] ffc0: 4001de14 4012c008 00000003 befbfa6c 00040000
00000000 00012008 00000000
[ 122.152810] ffe0: 400d05d0 befbfa5c 00008d28 400d05dc 60000010
4012c008 aaaaaaaa aaaaaaaa
[ 122.161005] Backtrace:
[ 122.163514] [<bf02c000>] (smc_probe+0x0/0x47c [rt_smc91111]) from
[<bf02c4cc>] (smc_init+0x50/0x80 [rt_smc91
111])
[ 122.173850] [<bf02c47c>] (smc_init+0x0/0x80 [rt_smc91111]) from
[<bf02c590>] (init_module+0x94/0x170 [rt_smc
91111])
[ 122.184308] r5:bf029a1c r4:bf029b40
[ 122.187976] [<bf02c4fc>] (init_module+0x0/0x170 [rt_smc91111]) from
[<c001e478>] (do_one_initcall+0x60/0x1a4
)
[ 122.197908] r5:bf029a1c r4:00000000
[ 122.201560] [<c001e418>] (do_one_initcall+0x0/0x1a4) from
[<c005cf1c>] (sys_init_module+0x9c/0x1bc)
[ 122.210658] [<c005ce80>] (sys_init_module+0x0/0x1bc) from
[<c001f020>] (ret_fast_syscall+0x0/0x2c)
[ 122.219635] r7:00000080 r6:00000003 r5:4012c008 r4:4001de14
[ 122.225347] Code: eb4034f5 e1500004 03e0400f 0a0000f1 (e1d630be)
[ 122.231533] ---[ end trace 4ea5a86e114726cf ]---
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: hin...@i-...
http://www.i-tech.si - When your users demand stability
|
|
From: Jan K. <jan...@we...> - 2011-09-05 21:52:55
|
On 2011-09-05 10:12, Sebastian Smolorz wrote:
>
> Signed-off-by: Sebastian Smolorz <sm...@rt...>
> ---
> configure | 2 +-
> configure.ac | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/configure b/configure
> index 8612fd4..83fcc59 100755
> --- a/configure
> +++ b/configure
> @@ -11827,7 +11827,7 @@ _ACEOF
> { $as_echo "$as_me:$LINENO: result: ${XENO_VERSION}" >&5
> $as_echo "${XENO_VERSION}" >&6; }
> ;;
> - 2.5.[2-9]*)
> + 2.5.[2-9]*|2.6*)
> CONFIG_RTNET_RTEXT_VERSION=xeno-252
>
> cat >>confdefs.h <<\_ACEOF
> diff --git a/configure.ac b/configure.ac
> index 3520426..81107f5 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -323,7 +323,7 @@ else
> AC_DEFINE(CONFIG_XENO_2_1x, 1, [We build for Xenomai 2.x])
> AC_MSG_RESULT([${XENO_VERSION}])
> ;;
> - 2.5.[[2-9]]*)
> + 2.5.[[2-9]]*|2.6*)
> CONFIG_RTNET_RTEXT_VERSION=xeno-252
> AC_DEFINE(CONFIG_XENO_2_1x, 1, [We build for Xenomai 2.x])
> AC_MSG_RESULT([${XENO_VERSION}])
Thanks, applied.
Jan
|
|
From: Sebastian S. <sm...@rt...> - 2011-09-05 08:34:09
|
Signed-off-by: Sebastian Smolorz <sm...@rt...>
---
configure | 2 +-
configure.ac | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 8612fd4..83fcc59 100755
--- a/configure
+++ b/configure
@@ -11827,7 +11827,7 @@ _ACEOF
{ $as_echo "$as_me:$LINENO: result: ${XENO_VERSION}" >&5
$as_echo "${XENO_VERSION}" >&6; }
;;
- 2.5.[2-9]*)
+ 2.5.[2-9]*|2.6*)
CONFIG_RTNET_RTEXT_VERSION=xeno-252
cat >>confdefs.h <<\_ACEOF
diff --git a/configure.ac b/configure.ac
index 3520426..81107f5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -323,7 +323,7 @@ else
AC_DEFINE(CONFIG_XENO_2_1x, 1, [We build for Xenomai 2.x])
AC_MSG_RESULT([${XENO_VERSION}])
;;
- 2.5.[[2-9]]*)
+ 2.5.[[2-9]]*|2.6*)
CONFIG_RTNET_RTEXT_VERSION=xeno-252
AC_DEFINE(CONFIG_XENO_2_1x, 1, [We build for Xenomai 2.x])
AC_MSG_RESULT([${XENO_VERSION}])
--
1.5.2.4
|
|
From: dxg <dx...@gm...> - 2011-08-29 13:08:05
|
On Mon, 29 Aug 2011 20:28:49 +1000 Sergey Davydov <ser...@gm...> wrote: > Hello, > > Could you please tell why there is no drivers for Wireless network > adapters? What is the problem in creating them? > > thanks, > Sergey. Hello Sergey, there is a rtwlan driver called rt2500. You can find it under driver/experimental/rt2500. It is about Ralink PCI chipsets. Writing drivers for other chipsets shouldn't be a problem too, except that you have to mitigate hard real time constraints. Regards, Daniel |
|
From: Sergey D. <ser...@gm...> - 2011-08-29 10:28:55
|
Hello,
Could you please tell why there is no drivers for Wireless network
adapters? What is the problem in creating them?
thanks,
Sergey.
|
|
From: luxInteg <lux...@bt...> - 2011-05-12 20:51:15
|
On Wednesday 11 May 2011 20:50:39 Jan Kiszka wrote: > On 2011-05-11 17:10, luxInteg wrote: > > Greetings > > > > I compiled rtnet-0.9.12 to on a computer with a) dual-core amd64 cpu, > > b) cblfs 64-bit linux, rtai-3.8.1, gcc-4.4.2 c) linux-2.6.32 > > successfully some weeks ago. > > I switched to a box with A) dual-core amd64 cpu, cblfs B)64-bit linux, > > rtai/magma-cvs, gcc-4.5.2 C) linux-2.6.35.9 and attempting to compile > > rtnet-0.9.12 results in the following:- > > > > ------------ > > make[3]: Entering directory `/usr/src/linux-2.6.35.9RT' > > > > CC [M] /usr/src/rtnet-0.9.12/stack/rtdev.o > > > > In file included from /usr/src/rtnet-0.9.12/stack/rtdev.c:32:0: > > /usr/src/rtnet-0.9.12/stack/include/rtnet_internal.h: In function > > 'RTNET_MOD_INC_USE_COUNT_EX': > > /usr/src/rtnet-0.9.12/stack/include/rtnet_internal.h:152:5: error: > > implicit declaration of function 'local_inc' > > /usr/src/rtnet-0.9.12/stack/include/rtnet_internal.h:152:5: error: > > implicit declaration of function '__module_ref_addr' > > make[4]: *** [/usr/src/rtnet-0.9.12/stack/rtdev.o] Error 1 > > make[3]: *** [_module_/usr/src/rtnet-0.9.12/stack] Error 2 > > ----------- > > > > help wpuld be appreciated > > Please retry with latest git version. > > Jan thanks it worked |
|
From: Jan K. <jan...@we...> - 2011-05-11 19:52:31
|
On 2011-05-11 17:10, luxInteg wrote: > Greetings > > I compiled rtnet-0.9.12 to on a computer with a) dual-core amd64 cpu, b) > cblfs 64-bit linux, rtai-3.8.1, gcc-4.4.2 c) linux-2.6.32 successfully some > weeks ago. > I switched to a box with A) dual-core amd64 cpu, cblfs B)64-bit linux, > rtai/magma-cvs, gcc-4.5.2 C) linux-2.6.35.9 and attempting to compile > rtnet-0.9.12 results in the following:- > > ------------ > make[3]: Entering directory `/usr/src/linux-2.6.35.9RT' > CC [M] /usr/src/rtnet-0.9.12/stack/rtdev.o > In file included from /usr/src/rtnet-0.9.12/stack/rtdev.c:32:0: > /usr/src/rtnet-0.9.12/stack/include/rtnet_internal.h: In function > 'RTNET_MOD_INC_USE_COUNT_EX': > /usr/src/rtnet-0.9.12/stack/include/rtnet_internal.h:152:5: error: implicit > declaration of function 'local_inc' > /usr/src/rtnet-0.9.12/stack/include/rtnet_internal.h:152:5: error: implicit > declaration of function '__module_ref_addr' > make[4]: *** [/usr/src/rtnet-0.9.12/stack/rtdev.o] Error 1 > make[3]: *** [_module_/usr/src/rtnet-0.9.12/stack] Error 2 > ----------- > > help wpuld be appreciated Please retry with latest git version. Jan |
|
From: luxInteg <lux...@bt...> - 2011-05-11 15:06:23
|
Greetings I compiled rtnet-0.9.12 to on a computer with a) dual-core amd64 cpu, b) cblfs 64-bit linux, rtai-3.8.1, gcc-4.4.2 c) linux-2.6.32 successfully some weeks ago. I switched to a box with A) dual-core amd64 cpu, cblfs B)64-bit linux, rtai/magma-cvs, gcc-4.5.2 C) linux-2.6.35.9 and attempting to compile rtnet-0.9.12 results in the following:- ------------ make[3]: Entering directory `/usr/src/linux-2.6.35.9RT' CC [M] /usr/src/rtnet-0.9.12/stack/rtdev.o In file included from /usr/src/rtnet-0.9.12/stack/rtdev.c:32:0: /usr/src/rtnet-0.9.12/stack/include/rtnet_internal.h: In function 'RTNET_MOD_INC_USE_COUNT_EX': /usr/src/rtnet-0.9.12/stack/include/rtnet_internal.h:152:5: error: implicit declaration of function 'local_inc' /usr/src/rtnet-0.9.12/stack/include/rtnet_internal.h:152:5: error: implicit declaration of function '__module_ref_addr' make[4]: *** [/usr/src/rtnet-0.9.12/stack/rtdev.o] Error 1 make[3]: *** [_module_/usr/src/rtnet-0.9.12/stack] Error 2 ----------- help wpuld be appreciated sincerely luxInteg |
|
From: Jan K. <jan...@we...> - 2011-05-07 07:03:38
|
On 2011-05-06 17:03, Jesper Christensen wrote:
> Hi
>
> I have seen a crash in connection with closing an AF_PACKET socket:
>
> Oops: Kernel access of bad area, sig: 11 [#1]
> PREEMPT SMP NR_CPUS=2 CPCI6200
> Modules linked in: tt_vupgm rtpacket rtudp rtipv4 rt_gfar rt_loopback rtnet
> NIP: b9118ee4 LR: b9188a4c CTR: b9188998
> REGS: ae8edd50 TRAP: 0300 Not tainted (2.6.29.6)
> MSR: 00021000 <ME,CE> CR: 22000842 XER: 00000000
> DEAR: 00000000, ESR: 00800000
> TASK = afba6b50[723] 'upgmu' THREAD: ae8ec000 CPU: 0
> GPR00: 00100100 ae8ede00 afba6b50 ae91b3b8 afba6b50 ae8edf50 00000000
> 8056a9f0
> GPR08: 00000001 00000000 00000001 00000000 42000848 1005366c 00000040
> 8056ce50
> GPR16: 805bc2c0 00010000 00000000 8056a9f0 00000010 00029000 80591f74
> 8056ce50
> GPR24: 805bc2c0 ae8edf50 b1023c08 ae91b300 00000000 ae91b300 ae91b320
> 00000000
> NIP [b9118ee4] rtdev_remove_pack+0xbc/0x144 [rtnet]
> LR [b9188a4c] rt_packet_close+0xb4/0x24c [rtpacket]
> Call Trace:
> [ae8ede00] [800ed3fc] generic_file_aio_write+0x74/0xf0 (unreliable)
> [ae8ede10] [b9188a4c] rt_packet_close+0xb4/0x24c [rtpacket]
> [ae8ede50] [800e41b4] __rt_dev_close+0x2c8/0x6d8
> [ae8ede80] [800e8274] sys_rtdm_close+0x18/0x28
> [ae8ede90] [800a08d4] losyscall_event+0x110/0x35c
> [ae8eded0] [8007b494] __ipipe_dispatch_event+0x128/0x2d0
> [ae8edf30] [8000b204] __ipipe_syscall_root+0x8c/0x13c
> [ae8edf40] [80012ad0] DoSyscall+0x20/0x5c
> Instruction dump:
> 409efff4 7c421378 4bffffcc a803000a 3be0fff5 2f800000 41bd0030 81630004
> 3c000010 81230000 60000100 3be00000 <912b0000> 90030000 3c000020 60000200
>
>
>
> I believe the problem arises when opening a socket with protocol type
> set to 0, and then binding the socket with a non-zero packet type.
> Because sock->protocol remains 0 the new protocol type is not
> registered. However in rt_packet_close(), pt->type is checked for
> "non-zeroness" and then deregistered, leading to a list_del on a node
> that isn't inserted.
Good catch! That is indeed broken.
> I propose following patch:
>
> Index: af_packet.c
> ===================================================================
> RCS file:
> /usr/cvs/sw/3rd_party/XM-Linux/rtnet-0.9.12/stack/packet/af_packet.c,v
> retrieving revision 1.1
> diff -r1.1 af_packet.c
> 108c108
> < pt->type = new_type;
> ---
>> pt->type = sock->protocol = new_type;
>
>
> My sincere apologies for using cvs.
>
Well, I bet that wasn't your "wise" decision. :) But using unified diff
format (-u) would have been nice nevertheless.
Anyway, this is a more appropriate fix:
diff --git a/stack/packet/af_packet.c b/stack/packet/af_packet.c
index 5ca69e5..937e917 100644
--- a/stack/packet/af_packet.c
+++ b/stack/packet/af_packet.c
@@ -109,7 +109,7 @@ int rt_packet_bind(struct rtsocket *sock, const
struct sockaddr *addr,
sock->prot.packet.ifindex = sll->sll_ifindex;
/* if protocol is non-zero, register the packet type */
- if (sock->protocol != 0) {
+ if (new_type != 0) {
pt->handler = rt_packet_rcv;
pt->err_handler = NULL;
sock->protocol should remain untouched, it's the default protocol of
this socket. This fix is now also available through git.
Thanks for reporting!
Jan
|
|
From: Jesper C. <jb...@th...> - 2011-05-06 15:18:58
|
Hi I have seen a crash in connection with closing an AF_PACKET socket: Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT SMP NR_CPUS=2 CPCI6200 Modules linked in: tt_vupgm rtpacket rtudp rtipv4 rt_gfar rt_loopback rtnet NIP: b9118ee4 LR: b9188a4c CTR: b9188998 REGS: ae8edd50 TRAP: 0300 Not tainted (2.6.29.6) MSR: 00021000 <ME,CE> CR: 22000842 XER: 00000000 DEAR: 00000000, ESR: 00800000 TASK = afba6b50[723] 'upgmu' THREAD: ae8ec000 CPU: 0 GPR00: 00100100 ae8ede00 afba6b50 ae91b3b8 afba6b50 ae8edf50 00000000 8056a9f0 GPR08: 00000001 00000000 00000001 00000000 42000848 1005366c 00000040 8056ce50 GPR16: 805bc2c0 00010000 00000000 8056a9f0 00000010 00029000 80591f74 8056ce50 GPR24: 805bc2c0 ae8edf50 b1023c08 ae91b300 00000000 ae91b300 ae91b320 00000000 NIP [b9118ee4] rtdev_remove_pack+0xbc/0x144 [rtnet] LR [b9188a4c] rt_packet_close+0xb4/0x24c [rtpacket] Call Trace: [ae8ede00] [800ed3fc] generic_file_aio_write+0x74/0xf0 (unreliable) [ae8ede10] [b9188a4c] rt_packet_close+0xb4/0x24c [rtpacket] [ae8ede50] [800e41b4] __rt_dev_close+0x2c8/0x6d8 [ae8ede80] [800e8274] sys_rtdm_close+0x18/0x28 [ae8ede90] [800a08d4] losyscall_event+0x110/0x35c [ae8eded0] [8007b494] __ipipe_dispatch_event+0x128/0x2d0 [ae8edf30] [8000b204] __ipipe_syscall_root+0x8c/0x13c [ae8edf40] [80012ad0] DoSyscall+0x20/0x5c Instruction dump: 409efff4 7c421378 4bffffcc a803000a 3be0fff5 2f800000 41bd0030 81630004 3c000010 81230000 60000100 3be00000 <912b0000> 90030000 3c000020 60000200 I believe the problem arises when opening a socket with protocol type set to 0, and then binding the socket with a non-zero packet type. Because sock->protocol remains 0 the new protocol type is not registered. However in rt_packet_close(), pt->type is checked for "non-zeroness" and then deregistered, leading to a list_del on a node that isn't inserted. I propose following patch: Index: af_packet.c =================================================================== RCS file: /usr/cvs/sw/3rd_party/XM-Linux/rtnet-0.9.12/stack/packet/af_packet.c,v retrieving revision 1.1 diff -r1.1 af_packet.c 108c108 < pt->type = new_type; --- > pt->type = sock->protocol = new_type; My sincere apologies for using cvs. -- /Jesper |
4 messages has been excluded from this view by a project administrator.
