Hi Jan,
My stupid comments will never end :)
So, since using the 3.5.3 ipipe kernel for powerpc from DENX, I'm getting the
following error during the first rtnet startup phase:
*** RTnet 0.9.13 - built on Nov 29 2012 23:23:23 ***
RTnet: initialising real-time networking
rt_e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k-rt
rt_e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
rt_e1000e 0000:01:00.0: Disabling ASPM L0s
RTnet: registered rteth0
rt_e1000e: (PCI Express:2.5GT/s:Width x1) 68:05:ca:0b:48:d8
rt_e1000e: Intel(R) PRO/1000 Network Connection
rt_e1000e: MAC: 3, PHY: 8, PBA No: E46981-007
RTcfg: init real-time configuration distribution protocol
RTmac: init realtime media access control
RTmac/TDMA: init time division multiple access control mechanism
/usr/local/rtnet/sbin/rtcfg rteth0 server
/usr/local/rtnet/sbin/rtifconfig rteth0 up 10.2.0.1 netmask 255.255.255.0
------------[ cut here ]------------
WARNING: at arch/powerpc/kernel/ipipe.c:113
Modules linked in: tdma(O) rtmac(O) rtcfg(O) rtpacket(O) rtudp(O) rt_e1000e(O)
rtipv4(O) rtnet(O) snd_usb_audio snd_pcm snd_timer snd_page_alloc snd_hwdep
snd_usbmidi_lib snd_rawmidi snd_seq_device snd soundcore gspca_zc3xx gspca_main
videodev
NIP: c000d8bc LR: c000d828 CTR: 00000000
REGS: ef1c7c60 TRAP: 0700 Tainted: G O (3.5.3-ipipe-xenomai)
MSR: 00029000 <CE,EE,ME> CR: 44008082 XER: 20000000
TASK = ee5023e0[2107] 'rtifconfig' THREAD: ef1c6000 CPU: 0
GPR00: 00000001 ef1c7d10 ee5023e0 ee0b1d80 0000001a 00000000 ef5585cc 00000000
GPR08: 00000000 c0710000 ee0b1d80 fffffffa 24004088 1001a3c0 00000000 00000000
GPR16: 100d3188 100f0000 100f0000 100ec7b0 100ec6b4 0a0200ff 100021d0 00000001
GPR24: ef558560 100021c8 ef558044 ef5580dc ef558648 ef558000 ef1c7d48 ee0b1d80
NIP [c000d8bc] ipipe_set_irq_affinity+0xb4/0xf4
LR [c000d828] ipipe_set_irq_affinity+0x20/0xf4
Call Trace:
[ef1c7d10] [c000d828] ipipe_set_irq_affinity+0x20/0xf4 (unreliable)
[ef1c7d30] [c009eb80] xnintr_attach+0x40/0x358
[ef1c7d80] [c012a6c8] rtdm_irq_request+0x48/0x98
[ef1c7d90] [f32bfe08] e1000_request_irq+0xe8/0x360 [rt_e1000e]
[ef1c7db0] [f32c1b5c] e1000_open+0xcc/0x3a8 [rt_e1000e]
[ef1c7de0] [f2ecc0cc] rtdev_open+0x34/0xa4 [rtnet]
[ef1c7df0] [f2eccc20] rtnet_core_ioctl+0x50c/0x7c8 [rtnet]
[ef1c7e70] [f2ecc674] rtnet_ioctl+0x13c/0x1dc [rtnet]
[ef1c7ea0] [c017edf4] do_vfs_ioctl+0xa0/0x760
[ef1c7f10] [c017f4f4] sys_ioctl+0x40/0x70
[ef1c7f40] [c000ed78] ret_from_syscall+0x0/0x3c
--- Exception: c01 at 0xff16bf8
LR = 0xffae300
Instruction dump:
80010024 81810014 bbc10018 7c0803a6 7d808120 38210020 4e800020 39200000
4bffffc8 3d20c071 8809dc29 68000001 <0f000000> 2f800000 419effc8 38000001
---[ end trace 3c2097b571c2d7b6 ]---
e1000e: rteth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
/usr/local/rtnet/sbin/tdmacfg rteth0 master 225
/usr/local/rtnet/sbin/tdmacfg rteth0 slot 0 0
/usr/local/rtnet/sbin/rtcfg rteth0 add 10.2.0.2 -stage1 -
Waiting for all slaves.../usr/local/rtnet/sbin/rtcfg rteth0 wait
/usr/local/rtnet/sbin/rtcfg rteth0 ready
But the communication works... Just fyi.
Cheers,
Michael
Am Montag, 03. Dezember 2012 17:31 CET, Jan Kiszka <jan.kis...@siemens.com>
schrieb:
> On 2012-12-03 17:18, Michael Morscher wrote:
> > Hi Jan,
> >
> > I ran into another or the same problem again. I switched platform to two
> > Freescale P2020RDB and two Intel e1000e PCI-Express Adapters (Desktop CT).
> > I think the TDMA problem occurs because the buffer of the card explodes. Il
> > receive those messages when I connect both systems with a 1:1 connection.
> > During the loading of the rt_e1000e module, the Link goes down. I think the
> > master then tries to start the calibration phase but the Link isn't up
> > again because the second system also unloaded the module... So RTnet writes
> > pakets into the card's buffer which cannot be sent due to the missing
> > link...
>
> I see - that indeed makes sense.
>
> >
> > When I connect both systems over a switch, it works perfectly! Sometimes it
> > also work over a 1:1 connection, but not really often. Tried it for half an
> > hour and got it working twice... The calibration time on 1:1 is 10us and
> > over my HP 1810-24G around 12-13us.
>
> OK.
>
> BTW, I meanwhile stumbled over an I-pipe bug in 2.6.x kernels that
> causes interrupt loss after rebinding a PCI adapter from Xenomai to
> Linux - that's what latest RTnet does in its shutdown script. Here is a
> fix for 2.6.38 (3.x do not suffer from that problem due to changes in
> Linux):
>
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> index b79ec1d..aeb8cc1 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -878,7 +878,7 @@ __set_irq_handler(unsigned int irq, irq_flow_handler_t
> handle, int is_chained,
> desc->name = name;
>
> if (handle != handle_bad_irq && is_chained) {
> - desc->status &= ~IRQ_DISABLED;
> + desc->status &= ~(IRQ_DISABLED | IRQ_MASKED);
> desc->status |= IRQ_NOREQUEST | IRQ_NOPROBE;
> desc->depth = 0;
> desc->irq_data.chip->irq_startup(&desc->irq_data);
> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index 9033c1c..57fdf57 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -785,7 +785,7 @@ __setup_irq(unsigned int irq, struct irq_desc *desc,
> struct irqaction *new)
>
> if (!(desc->status & IRQ_NOAUTOEN)) {
> desc->depth = 0;
> - desc->status &= ~IRQ_DISABLED;
> + desc->status &= ~(IRQ_DISABLED | IRQ_MASKED);
> desc->irq_data.chip->irq_startup(&desc->irq_data);
> } else
> /* Undo nested disables: */
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
> Corporate Competence Center Embedded Linux
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> BUILD Helping you discover the best ways to construct your parallel projects.
> http://goparallel.sourceforge.net
> _______________________________________________
> RTnet-users mailing list
> RTnet-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rtnet-users
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
