Thread: [RTnet-developers] Kernel module for smc91111
Brought to you by:
bet-frogger,
kiszka
Menu
▾
▴
rtnet-developers
|
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-16 06:32:57
Attachments:
signature.asc
|
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-16 07:34:19
Attachments:
rt_smc91111.c
rt_smc91111.h
|
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 08:05:29
Attachments:
signature.asc
|
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 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: 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: 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 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 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: 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: 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: 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-30 13:12:23
Attachments:
rt_smc91111.c
rt_smc91111.h
|
Here is the smc91x driver port to RTnet. Tested on XCEP PXA255 based board. It is not complete work, but maybe someone can benefit from it.. someday.. It compiles and runs! NOTE: I had problems with dereferencing and casting to 64-bit on my platform, hence the two 32-bit casts in the smc_hardware_send_pkt().. Also I'm not sure if skb->xmit_stamp is handled properly. Thanks to Gilles & Jan for their input! 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X