Re: [RTnet-users] (no subject)
On 12/29/2012 09:42 PM, Wim Meeussen wrote: > Hi, > > I have a host with two identical ethernet devices (Intel 82573L). > Both devices work great with the e1000e module, and with the rt_e1000e > module. I would like to use the first ethernet device with the e1000e > module to connect to the LAN, and the second ethernet device with the > rt_e1000e module to communicate with an EtherCAT slave. > > The problem I run into is that when I load the e1000e module, the > kernel logs show that it detects and registers both ethernet devices. > But when I load the rt_e1000e module after that, the kernel logs show > that it does not detect any devices any more. When I swap the order, > and first load the rt_e1000e module, it detects and registers both > ethernet devices, but then the e1000e module can't find any devices > any more. So pretty much, whichever module I load first claims both > devices. This behavior is confirmed by both the kernel logs and by > running (rt_)ifconfig. > > Is there a way to limit a module to a single device at load time, so > it would not claim both devices at once? Or should I be looking at a > different type of solution? Any help is appreciated! You can bind a device to or unbind from a driver using the SysFS "bind" and "unbind" files. e.g.: # echo ":04:00.0" > /sys/class/net/eth0/device/driver/unbind Then insmod "rt_e1000e.ko" and it will probe that device. Wolfgang. -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] PCI and Startup behaviour
On 12/05/2012 02:36 PM, Michael Morscher wrote: > 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 :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: > REGS: ef1c7c60 TRAP: 0700 Tainted: G O (3.5.3-ipipe-xenomai) > MSR: 00029000 CR: 44008082 XER: 2000 > TASK = ee5023e0[2107] 'rtifconfig' THREAD: ef1c6000 CPU: 0 > GPR00: 0001 ef1c7d10 ee5023e0 ee0b1d80 001a ef5585cc > GPR08: c071 ee0b1d80 fffa 24004088 1001a3c0 > GPR16: 100d3188 100f 100f 100ec7b0 100ec6b4 0a0200ff 100021d0 0001 > 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 3920 > 4bc8 3d20c071 8809dc29 6801 <0f00> 2f80 419effc8 3801 > ---[ 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. Could you show your .config? Wolfgang. -- 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
Re: [RTnet-users] Useful way to measure bandwidth?
Hi Michael, On 10/09/2012 12:15 PM, Michael Morscher wrote: > Hi there, > > What is the best way to measure the bandwidth between two RT Nodes? I've a > setup running two clients and as I'm playing with configuration values for > window sizes etc. I need a way to measure the available bandwidth. ( to get a > better understanding/tuning for my project) I would take a simple network benchmark program, e.g. ttcp and port it to RTnet. Should not be a big deal, think. > Tried the known ways like iperf but actually I think the produced traffic is > encapsulated and not send at its optimum. So I only get something between 2 > and 6 Mbit/s on E1000 driver/PCI cards which is not what I need. What protocol do you use? Wolfgang. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Embedded Evaluation Boards & NIC drivers
On 09/11/2012 10:59 AM, Michael Morscher wrote: > > > > Hi there, > > I'm curently preparing to write my final seminar paper in university with the > subject of real time ethernet video broadcasting. > I've already played around with two virtual machines and RTNet, but as the > seminar paper has a focus on automotive design, the goal is to use embedded > hardware like ARM oder PowerPC. After checking the git repository for drivers > and comparing them with available Evaluation Kits I found out, that nearly > any of them is support - and most of the boards (of course) have no expansion > headers like PCI or PCI-Express, where I can plug in an e1000 compatible NIC. That's mostely true for ARM-Eval-Board but a lot of the MPC-Eval-Ports from Freescale do have PCI or even PCIe slots. > Has anyone an embedded platform with enough speed up and running with RTNet? > > Some guy before me used an PowerPC M8313E (where I have two samples of) for > that and added an PCI e1000 card. He was stuck at 150Mbit/s while streaming > video, so the idea was to get some more power for higher bandwidth or > possible video compression. The MPC8313E does have very powerful ethernet controllers on chip, which are for networking products. Also a E1000-NIC should work at full speed. Therefore I assume that the 150 MBit/s are due to software. What has been used? RTnet UDP, TDMA, ...? > A platform I really like to use is the FreeScale i.MX53 or i.MX6 as they are > already completly automotive tested and compliant - but either the boards > don't use the FreeScale FEC or they have just 10/100M, not Gigabit. The i.MX6 has a GETH controller on chip but not really a good one. Wolfgang. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Problems with rtifconfig
Jan Kiszka wrote:
> Wolfgang Grandegger wrote:
>> Gilles Chanteperdrix wrote:
>>> Wolfgang Grandegger wrote:
>>>> Hi Jan,
>>>>
>>>> I'm testing RTnet on ARM and I get the following error message:
>>>>
>>>> # strace rtifconfig rteth0 up 172.16.0.20
>>>> ...
>>>> open("/dev/rtnet", O_RDWR) = 3
>>>> ioctl(3, 0x4050, 0x12858) = -1 ENOMEM (Cannot allocate
>>>> memory)
>>>> ...
>>>> ioctl: Cannot allocate memory
>>>>
>>>> Before I dig deeper, are there any knwon issues with head of Xenomai-2.5?
>>> /dev/rtnet is not a Xenomai device. So, if this issue is unrelated to
>>> Xenomai, at first sight.
>> Yes,
>>
>>> Are you sure you are using the latest release of RTnet? A structure
>>> layout was fixed for ARM.
>> I think it's a configuration issue. The RTnet tools are not linked
>> properly using the Xenomai libraries. Maybe my fault. It's a long time
>> ago that I developed with RTnet.
>
> Management tools aren't linked against Xenomai, they are plain Linux apps.
Meaning, --with-rtext-config is not needed at all.
> You may want to check if there is a regression related to recent IOCTL
> control structure refactorings. Start the bisect before 6cee71bd00.
OK, I was aware of RTDM changes and that's why I asked.
More soon...
Thanks,
Wolfgang.
--
___
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Problems with rtifconfig
Gilles Chanteperdrix wrote:
> Wolfgang Grandegger wrote:
>> Hi Jan,
>>
>> I'm testing RTnet on ARM and I get the following error message:
>>
>> # strace rtifconfig rteth0 up 172.16.0.20
>> ...
>> open("/dev/rtnet", O_RDWR) = 3
>> ioctl(3, 0x4050, 0x12858) = -1 ENOMEM (Cannot allocate memory)
>> ...
>> ioctl: Cannot allocate memory
>>
>> Before I dig deeper, are there any knwon issues with head of Xenomai-2.5?
>
> /dev/rtnet is not a Xenomai device. So, if this issue is unrelated to
> Xenomai, at first sight.
Yes,
> Are you sure you are using the latest release of RTnet? A structure
> layout was fixed for ARM.
I think it's a configuration issue. The RTnet tools are not linked
properly using the Xenomai libraries. Maybe my fault. It's a long time
ago that I developed with RTnet.
Wolfgang.
--
___
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
[RTnet-users] Problems with rtifconfig
Hi Jan,
I'm testing RTnet on ARM and I get the following error message:
# strace rtifconfig rteth0 up 172.16.0.20
...
open("/dev/rtnet", O_RDWR) = 3
ioctl(3, 0x4050, 0x12858) = -1 ENOMEM (Cannot allocate memory)
...
ioctl: Cannot allocate memory
Before I dig deeper, are there any knwon issues with head of Xenomai-2.5?
Wolfgang.
--
___
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Problems building RTnet 0.9.11 on Xenomai 2.4.8 with PPC Kernel 2.4.25
Hello Thomas,
thomas.de...@manroland.com wrote:
> Hello,
>
> I am just trying to build the latest Rtnet release 0.9.11 on my PPC
> system with Xenomai 2.4.8 and kernel 2.4.25. I use the following shell
> script to configure it, but it fails with the error message below when
> make'ing it. Do you have any ideas?
>
> ./configure --host=ppc-linux \
> --with-linux=$KERNELDIR --prefix=$INSTALLDIR \
> --with-rtext-config=$XENODIR/bin/xeno-config \
> --disable-e1000 --disable-8139 --disable-8139too \
> --enable-mpc52xx-fec --disable-eepro100 \
> --enable-proxy --enable-proxy-udp --enable-proxy-arp \
> --enable-net-routing --disable-icmp --enable-rtcap
>
>
> In file included from rtdev.c:33:
> ../stack/include/rtskb.h: In function `rtskb_queue_init':
> ../stack/include/rtskb.h:289: error: parse error before '{' token
> ../stack/include/rtskb.h: At top level:
> ../stack/include/rtskb.h:290: error: parse error before '->' token
> ../stack/include/rtskb.h: In function `rtskb_prio_queue_init':
> ../stack/include/rtskb.h:301: error: parse error before '{' token
> rtdev.c: In function `rtdev_alloc':
> rtdev.c:243: error: parse error before '{' token
> make[2]: *** [libkernel_rtnet_a-rtdev.o] Fehler 1
> make[2]: Leaving directory `/home/rtnet/src/stack'
> make[1]: *** [install-recursive] Fehler 1
> make[1]: Leaving directory `/home/rtnet/src/stack'
> make: *** [install-recursive] Fehler 1
> develo...@linux-devbox:~/rtnet/src>
This distribution (rtnet-0.9.11.tar.bz2) seems to be broken, e.g. the
file "drivers/mpc52xx_fec/rt_mpc52xx_fec.h" is missing, but I was able
to build RTnet's head of the GIT repository with your configuration with
the patch below. I did not see the problems you listed above, though.
Wolfgang.
[PATCH] Fix build problems with Linux 2.4.25.
Signed-off-by: Wolfgang Grandegger
---
stack/ipv4/udp.c |1 +
1 file changed, 1 insertion(+)
Index: rtnet/stack/ipv4/udp.c
===
--- rtnet.orig/stack/ipv4/udp.c
+++ rtnet/stack/ipv4/udp.c
@@ -33,6 +33,7 @@
#include
#include
+#include
#include
#include
#include
--
___
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
[RTnet-users] [PATCH] RTnet statistics for rt_mpc52xx_fec
This patch adds support for RTnet statistics.
Index: drivers/mpc52xx_fec/rt_mpc52xx_fec.c
===
--- drivers/mpc52xx_fec/rt_mpc52xx_fec.c(revision 1179)
+++ drivers/mpc52xx_fec/rt_mpc52xx_fec.c(working copy)
@@ -75,8 +75,8 @@
static int mpc5xxx_fec_interrupt(rtdm_irq_t *irq_handle);
static int mpc5xxx_fec_receive_interrupt(rtdm_irq_t *irq_handle);
static int mpc5xxx_fec_transmit_interrupt(rtdm_irq_t *irq_handle);
+static struct net_device_stats *mpc5xxx_fec_get_stats(struct rtnet_device
*dev);
#ifdef ORIGINAL_CODE
-static struct rtnet_device_stats *mpc5xxx_fec_get_stats(struct rtnet_device *);
static void mpc5xxx_fec_set_multicast_list(struct rtnet_device *dev);
#endif /* ORIGINAL_CODE */
static void mpc5xxx_fec_reinit(struct rtnet_device* dev);
@@ -96,9 +96,7 @@
static int mpc5xxx_mdio_read(struct rtnet_device *dev, int phy_id, int
location);
#endif
-#ifdef ORIGINAL_CODE
static void mpc5xxx_fec_update_stat(struct rtnet_device *);
-#endif /* ORIGINAL_CODE */
/* MII processing. We keep this as simple as possible. Requests are
* placed on the list (if there is room). When the request is finished
@@ -1098,9 +1096,7 @@
* Read MIB counters in order to reset them,
* then zero all the stats fields in memory
*/
-#ifdef ORIGINAL_CODE
mpc5xxx_fec_update_stat(dev);
-#endif /* ORIGINAL_CODE */
#ifdef CONFIG_RTNET_USE_MDIO
if (reinit) {
@@ -1636,9 +1632,7 @@
}
#endif
-#ifdef ORIGINAL_CODE
mpc5xxx_fec_get_stats(dev);
-#endif /* ORIGINAL_CODE */
return 0;
}
@@ -1651,16 +1645,14 @@
return ret;
}
-#ifdef ORIGINAL_CODE
/*
* Get the current statistics.
* This may be called with the card open or closed.
*/
-static struct rtnet_device_stats *
-mpc5xxx_fec_get_stats(struct rtnet_device *dev)
+static struct net_device_stats *mpc5xxx_fec_get_stats(struct rtnet_device *dev)
{
struct mpc5xxx_fec_priv *priv = (struct mpc5xxx_fec_priv *)dev->priv;
- struct rtnet_device_stats *stats = &priv->stats;
+ struct net_device_stats *stats = &priv->stats;
struct mpc5xxx_fec *fec = priv->fec;
stats->rx_bytes = in_be32(&fec->rmon_r_octets);
@@ -1705,7 +1697,7 @@
mpc5xxx_fec_update_stat(struct rtnet_device *dev)
{
struct mpc5xxx_fec_priv *priv = (struct mpc5xxx_fec_priv *)dev->priv;
- struct rtnet_device_stats *stats = &priv->stats;
+ struct net_device_stats *stats = &priv->stats;
struct mpc5xxx_fec *fec = priv->fec;
out_be32(&fec->mib_control, MPC5xxx_FEC_MIB_DISABLE);
@@ -1716,6 +1708,7 @@
mpc5xxx_fec_get_stats(dev);
}
+#ifdef ORIGINAL_CODE
/*
* Set or clear the multicast filter for this adaptor.
*/
@@ -1985,14 +1978,14 @@
dev->stop = mpc5xxx_fec_close;
dev->hard_start_xmit= mpc5xxx_fec_hard_start_xmit;
//FIXME dev->hard_header= &rt_eth_header;
+ dev->get_stats = mpc5xxx_fec_get_stats;
#ifdef ORIGINAL_CODE
dev->do_ioctl = mpc5xxx_fec_ioctl;
- dev->get_stats = mpc5xxx_fec_get_stats;
dev->set_mac_address= mpc5xxx_fec_set_mac_address;
dev->set_multicast_list = mpc5xxx_fec_set_multicast_list;
dev->tx_timeout = mpc5xxx_fec_tx_timeout;
- dev->watchdog_timeo = MPC5xxx_FEC_WATCHDOG_TIMEOUT;
+ dev->watchdog_timeo = MPC5xxx_FEC_WATCHDOG_TIMEOUT;
#endif /* ORIGINAL_CODE */
dev->flags &= ~IFF_RUNNING;
@@ -2016,13 +2009,11 @@
*(u16 *)&dev->dev_addr[4] = in_be16((u16*)&fec->paddr2);
}
-#ifdef ORIGINAL_CODE
/*
* Read MIB counters in order to reset them,
* then zero all the stats fields in memory
*/
mpc5xxx_fec_update_stat(dev);
-#endif /* ORIGINAL_CODE */
return 0;
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] [PATCH/RFC v2 0/5] RTnet-Proxy extensions
Jan Kiszka wrote: > Wolfgang Grandegger wrote: >> Hello, >> >> here is my second version of patches for extending the RTnet-Proxy. >> The following issues have been addressed: >> >> - UDP is now supported by default by the RTnet proxy. >> - Kconfig support for the configurable options >> - Remove #define FRAG_DBG >> - Avoid RTnet answering the ARP request if >> CONFIG_RTNET_ADDON_PROXY_ARP=y >> - Fix bug with rtdev_dereference(rtskb->rtdev) >> - IOCTL request to get routing information for the specified host >> without timeout. >> >> Hope it's OK now. > > Thanks for the patches, all merged now. Some with minor cleanups, the > third one with build fixes (tss, tss... :) ). For my purpose I cross compiled it for Linux 2.4.25 on a MPC5200 and didn't care about 2.6 and x86, sorry. Thanks, Wolfgang. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
[RTnet-users] [PATCH/RFC v2 5/5] RTnet-Proxy: Update documentation of the extened RTnet-Proxy
Signed-off-by: Wolfang Grandegger <[EMAIL PROTECTED]> Index: rtnet/Documentation/README.rtnetproxy === --- rtnet.orig/Documentation/README.rtnetproxy +++ rtnet/Documentation/README.rtnetproxy @@ -1,59 +1,74 @@ README.rtnetproxy === 08-Nov-2002, Mathias Koehrer <[EMAIL PROTECTED]> +02-May-2008, Wolfgang Grandegger <[EMAIL PROTECTED]> -rtnetproxy can be used to share a single network adapter for both - realtime -and non-realtime ethernet traffic. TCP/IP can be used via rtnet (of course -not in realtime!) +RTnetproxy can be used to share a single network adapter for both - realtime +and non-realtime ethernet traffic. TCP/IP, UDP and ARP can be used via RTnet +(of course not in realtime!) -rtnetproxy represents a network device to standard linux and can be used -as any other linux network device (ifconfig for configuration), the name +RTnetproxy represents a network device to standard Linux and can be used +as any other Linux network device (ifconfig for configuration), the name the network device is "rtproxy". Setup: -Get your rtnet working first! All IP addresses you are interested in have +Get your RTnet working first! All IP addresses you are interested in have to be set via "rtifconfig ethX route solicit IP_ADDRESS"! insmod rtnetproxy.o -Now, you have a network device "rtproxy" ready to be used with linux. +Now, you have a network device "rtproxy" ready to be used with Linux. Configure this network device using "ifconfig": + Example: + ifconfig rtproxy up 192.168.10.10 netmask 255.255.255.0 That's it! -Restrictions: --- -rtnetproxy is restricted to IP-based protocols (TCP/IP!!!). -Incoming frames from ICMP and UDP are interpreted directly by rtnet and are -not forwarded to rtnetproxy => UDP works only with outgoing frames from linux -context. Of course UDP works with rtnet! +Configuration options: + +--enable-proxy: this enables RTnetproxy support, which is by default +restricted to IP-based protocols (TCP/IP!!!). Incoming frames from +ICMP are interpreted directly by RTnet and are not forwarded to the +RTnetproxy. UDP packets are forwarded if they are not requested by +an RTnet application. + +--enable-proxy-arp: this option enables ARP support for the rtproxy Linux +network device. Incoming ARP replys are delivered to both, the RTnet +and the Linux network stack. The rtproxy then gets attached to the +corresponding RTnet device, rteth0 by default. + +--disable-icmp: this option disables the RTnet IPv4 ICMP support. ICMP +will then be handled by the Linux network stack via the rtproxy Linux +network device. +Important note: +- It is highly recommended to strictly separate realtime LAN traffic and non- -realtime LAN traffic. For a configuration/setup phase, TCP/IP is sometimes +realtime LAN traffic. For a configuration/setup phase, TCP/IP is sometimes very useful, buf for realtime data exchange the LAN should be reserved for the realtime traffic using UDP! How it works internally: -- -rtnetproxy works on top of rtnet. -All data to be sent out or received is actually copied between rtnet and -rtnetproxy => The performance is not as good as with the standard linux +RTnetproxy works on top of RTnet. +All data to be sent out or received is actually copied between RTnet and +RTnetproxy => The performance is not as good as with the standard Linux network drivers. All incoming IPv4 frames, having a IP protocol ID that is not handled by -rtnet are passed to rtnetproxy. -Incoming frames, that are passed to rtnetproxy (TCP frames) slow down the +RTnet are passed to RTnetproxy. +Incoming frames, that are passed to RTnetproxy (TCP frames) slow down the realtime stuff a little bit - as all this is done in realtime mode context! Possible enhancements: --- -Pass incoming frames to rtnetproxy not only by checking the protocol ID but -by actual checking, if a certain frame has been processed by rtnet or not. -This leads to a couple of changes in the rtnet implementation... +Pass incoming frames to RTnetproxy not only by checking the protocol ID but +by actual checking, if a certain frame has been processed by RTnet or not. +This leads to a couple of changes in the RTnet implementation... -- - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
[RTnet-users] [PATCH/RFC v2 2/5] RTnet-Proxy: ARP support
This patch enables ARP support for the RT-Proxy Linux device.
Incoming ARP replys are delivered to both, the RTnet and the
Linux network stack. The RT-Proxy then gets attached to the
corresponding RTnet device, rteth0 by default. Currently only
one RT-Proxy device is supported. This feature can be enabled
with the configure option "--enable-proxy-arp" or the Kconfig
option CONFIG_RTNET_ADDON_PROXY_ARP.
Note: this patch requires running "scripts/autogen.sh"
Signed-off-by: Wolfang Grandegger <[EMAIL PROTECTED]>
Index: rtnet/stack/ipv4/arp.c
===
--- rtnet.orig/stack/ipv4/arp.c
+++ rtnet/stack/ipv4/arp.c
@@ -25,6 +25,9 @@
#include
#include
+#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
+#include
+#endif /* CONFIG_RTNET_ADDON_PROXY_ARP */
/***
* arp_send: Create and send an arp packet. If (dest_hw == NULL),
@@ -168,12 +171,20 @@ int rt_arp_rcv(struct rtskb *skb, struct
if (tip == rtdev->local_ip) {
rt_ip_route_add_host(sip, sha, rtdev);
+#ifndef CONFIG_RTNET_ADDON_PROXY_ARP
if (arp->ar_op == __constant_htons(ARPOP_REQUEST))
rt_arp_send(ARPOP_REPLY, ETH_P_ARP, sip, rtdev, tip, sha,
rtdev->dev_addr, sha);
+#endif /* CONFIG_RTNET_ADDON_PROXY_ARP */
}
out:
+#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
+if (rt_ip_fallback_handler) {
+ rt_ip_fallback_handler(skb);
+ return 0;
+}
+#endif /* CONFIG_RTNET_ADDON_PROXY_ARP */
kfree_rtskb(skb);
return 0;
}
Index: rtnet/addons/rtnetproxy.c
===
--- rtnet.orig/addons/rtnetproxy.c
+++ rtnet/addons/rtnetproxy.c
@@ -105,6 +105,14 @@ static rtdm_task_t rtnetproxy_thread;
static rtdm_sem_t rtnetproxy_sem;
+#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
+static char* rtdev_attach = "rteth0";
+module_param(rtdev_attach, charp, 0444);
+MODULE_PARM_DESC(rtdev_attach, "Attach to the specified RTnet device");
+
+struct rtnet_device *rtnetproxy_rtdev;
+#endif
+
/* ***
* Returns the next pointer from the ringbuffer or zero if nothing is
* available
@@ -181,7 +189,10 @@ static inline void send_data_out(struct
{
struct rtskb*rtskb;
+#ifndef CONFIG_RTNET_ADDON_PROXY_ARP
struct dest_route rt;
+int rc;
+#endif
struct skb_data_format
{
@@ -194,7 +205,6 @@ static inline void send_data_out(struct
* thus no spaces are allowed! */
struct skb_data_format *pData;
-int rc;
/* Copy the data from the standard sk_buff to the realtime sk_buff:
* Both have the same length. */
@@ -208,6 +218,17 @@ static inline void send_data_out(struct
pData = (struct skb_data_format*) rtskb->data;
+#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
+rtdev_reference(rtnetproxy_rtdev);
+
+rtskb->rtdev = rtnetproxy_rtdev;
+
+/* Call the actual transmit function */
+rtdev_xmit_proxy(rtskb);
+
+rtdev_dereference(rtnetproxy_rtdev);
+
+#else /* !CONFIG_RTNET_ADDON_PROXY_ARP */
/* Determine the device to use: Only ip routing is used here.
* Non-ip protocols are not supported... */
rc = rt_ip_route_output(&rt, pData->ip_dst, INADDR_ANY);
@@ -244,6 +265,7 @@ static inline void send_data_out(struct
kfree_rtskb(rtskb);
}
+#endif /* CONFIG_RTNET_ADDON_PROXY_ARP */
}
/*
@@ -456,7 +478,11 @@ static int __init rtnetproxy_init(struct
/* Fill in device structure with ethernet-generic values. */
ether_setup(dev);
dev->tx_queue_len = 0;
+#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
+memcpy(dev->dev_addr, rtnetproxy_rtdev->dev_addr, sizeof(dev->dev_addr));
+#else
dev->flags |= IFF_NOARP;
+#endif
dev->flags &= ~IFF_MULTICAST;
return 0;
@@ -479,6 +505,15 @@ static int __init rtnetproxy_init_module
{
int err;
+#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
+if ((rtnetproxy_rtdev = rtdev_get_by_name(rtdev_attach)) == NULL) {
+ printk("Couldn't attach to %s\n", rtdev_attach);
+ return -EINVAL;
+}
+rtdev_dereference(rtnetproxy_rtdev);
+printk("RTproxy attached to %s\n", rtdev_attach);
+#endif
+
/* Initialize the proxy's rtskb pool (JK) */
if (rtskb_pool_init(&rtskb_pool, proxy_rtskbs) < proxy_rtskbs) {
rtskb_pool_release(&rtskb_pool);
Index: rtnet/configure.ac
===
--- rtnet.orig/configure.ac
+++ rtnet/configure.ac
@@ -1189,6 +1189,19 @@ if test "$CONFIG_RTNET_ADDON_PROXY" = "y
AC_DEFINE(CONFIG_RTNET_ADDON_PROXY,1,[rtnetproxy support])
fi
+AC_MSG_CHECKING([whether to enable rtnetproxy ARP support])
+AC_ARG_ENABLE(proxy-arp,
+AS_HELP_STRING([--enable-proxy-arp], [enable ARP support for IP protocol
proxy driver @<:@default=no@:>@]),
+[case "$enableval" in
+y | yes) CONFIG_RTNE
[RTnet-users] [PATCH/RFC v2 4/5] Disable RTnet IPv4 ICMP support
This patch allows to disable the RTnet IPv4 ICMP support, which might
be useful when using the RTnet-Proxy add-on. ICMP will then be handled
by the Linux network stack. ICMP support in RTnet is enabled by default
and it can be disabled with the configure option "--disable-icmp" or
the Kconfig option CONFIG_RTNET_RTIPV4_ICMP.
Note: this patch requires running "scripts/autogen.sh"
Signed-off-by: Wolfang Grandegger <[EMAIL PROTECTED]>
Index: rtnet/stack/ipv4/af_inet.c
===
--- rtnet.orig/stack/ipv4/af_inet.c
+++ rtnet/stack/ipv4/af_inet.c
@@ -79,6 +79,7 @@ static void cleanup_route_solicit(void *
+#ifdef CONFIG_RTNET_RTIPV4_ICMP
static int ping_handler(struct rt_proc_call *call)
{
struct ipv4_cmd *cmd;
@@ -114,6 +115,7 @@ static void ping_complete_handler(struct
usr_cmd->args.ping.ip_addr = cmd->args.ping.ip_addr;
usr_cmd->args.ping.rtt = cmd->args.ping.rtt;
}
+#endif /* CONFIG_RTNET_RTIPV4_ICMP */
@@ -186,6 +188,7 @@ static int ipv4_ioctl(struct rtnet_devic
break;
#endif /* CONFIG_RTNET_RTIPV4_NETROUTING */
+#ifdef CONFIG_RTNET_RTIPV4_ICMP
case IOC_RT_PING:
ret = rtpc_dispatch_call(ping_handler, cmd.args.ping.timeout, &cmd,
sizeof(cmd), ping_complete_handler, NULL);
@@ -196,6 +199,7 @@ static int ipv4_ioctl(struct rtnet_devic
if (ret < 0)
rt_icmp_cleanup_echo_requests();
break;
+#endif /* CONFIG_RTNET_RTIPV4_ICMP */
default:
ret = -ENOTTY;
Index: rtnet/configure.ac
===
--- rtnet.orig/configure.ac
+++ rtnet/configure.ac
@@ -1023,6 +1023,19 @@ if test "$CONFIG_RTNET_RTIPV4" = "y"; th
AC_DEFINE(CONFIG_RTNET_RTIPV4,1,[Real-Time IPv4 support])
fi
+AC_MSG_CHECKING([whether to enable real-time IPv4 ICMP support])
+AC_ARG_ENABLE(icmp,
+AS_HELP_STRING([--enable-icmp], [enable real-time IPv4 ICMP support
@<:@default=yes@:>@]),
+[case "$enableval" in
+y | yes) CONFIG_RTNET_RTIPV4_ICMP=y ;;
+*) CONFIG_RTNET_RTIPV4_ICMP=n ;;
+esac])
+AC_MSG_RESULT([${CONFIG_RTNET_RTIPV4_ICMP:-n}])
+AM_CONDITIONAL(CONFIG_RTNET_RTIPV4_ICMP,[test "$CONFIG_RTNET_RTIPV4_ICMP" =
"y"])
+if test "$CONFIG_RTNET_RTIPV4_ICMP" = "y"; then
+AC_DEFINE(CONFIG_RTNET_RTIPV4_ICMP,1,[Real-Time IPv4 ICMP support])
+fi
+
AC_MSG_CHECKING([whether to enable source IP routing])
AC_ARG_ENABLE(route-src,
AS_HELP_STRING([--enable-route-src], [enable source IP routing
@<:@default=no@:>@]),
Index: rtnet/defconfig
===
--- rtnet.orig/defconfig
+++ rtnet/defconfig
@@ -33,6 +33,7 @@ CONFIG_RTNET_RX_FIFO_SIZE=32
# Protocols
#
CONFIG_RTNET_RTIPV4=y
+CONFIG_RTNET_RTIPV4_ICMP=y
# CONFIG_RTNET_RTIPV4_ROUTE_SRC is not set
# CONFIG_RTNET_RTIPV4_NETROUTING is not set
# CONFIG_RTNET_RTIPV4_ROUTER is not set
Index: rtnet/stack/ipv4/GNUmakefile.am
===
--- rtnet.orig/stack/ipv4/GNUmakefile.am
+++ rtnet/stack/ipv4/GNUmakefile.am
@@ -16,10 +16,13 @@ libkernel_ipv4_a_SOURCES = \
ip_input.c \
ip_sock.c \
udp.c \
- icmp.c \
ip_output.c \
ip_fragment.c
+if CONFIG_RTNET_RTIPV4_ICMP
+libkernel_ipv4_a_SOURCES += icmp.c
+endif
+
OBJS = rtipv4$(modext)
rtipv4.o: libkernel_ipv4.a
Index: rtnet/stack/ipv4/Kconfig
===
--- rtnet.orig/stack/ipv4/Kconfig
+++ rtnet/stack/ipv4/Kconfig
@@ -10,6 +10,15 @@ config RTNET_RTIPV4
For further information see also Documentation/README.routing and
Documentation/README.ipfragmentation.
+config RTNET_RTIPV4_ICMP
+bool "ICMP support"
+depends on RTNET_RTIPV4
+default y
+---help---
+Enables ICMP support of the RTnet Real-Time IPv4 protocol. Disabling it
+might be useful when using the RTnet-Proxy add-on. ICMP will then be
+handled by the Linux network stack.
+
config RTNET_RTIPV4_ROUTE_SRC
bool "Consider source IP for output routing"
depends on RTNET_RTIPV4
Index: rtnet/stack/include/ipv4/icmp.h
===
--- rtnet.orig/stack/include/ipv4/icmp.h
+++ rtnet/stack/include/ipv4/icmp.h
@@ -44,8 +44,13 @@ void rt_icmp_dequeue_echo_request(struct
void rt_icmp_cleanup_echo_requests(void);
int rt_icmp_send_echo(u32 daddr, u16 id, u16 sequence, size_t msg_size);
+#ifdef CONFIG_RTNET_RTIPV4_ICMP
void __init rt_icmp_init(void);
void rt_icmp_release(void);
+#else /* !CONFIG_RTNET_RTIPV4_ICMP */
+#define rt_icmp_init() do {} while (0)
+#define rt_icmp_release() do {} while (0)
+#endif /* CONFIG_RTNET_RTIPV4_ICMP */
#endif /* __RTNET_ICMP_H_ */
--
-
This SF.net email is sponsored by the 2008
[RTnet-users] [PATCH/RFC v2 3/5] IOCTL request to get routing information for the specified host
This patch adds the IOCTL requests IOC_RT_HOST_ROUTE_GET and
IOC_RT_HOST_ROUTE_GET_DEV. On sucess, the requests return the HW address
and the device name for the specified IPv4 host address. This also means,
that the address has been resolved. The rtroute utility supports
these requests and serves as example:
# rtroute get [dev ]
Signed-off-by: Wolfang Grandegger <[EMAIL PROTECTED]>
Index: rtnet/stack/include/ipv4/route.h
===
--- rtnet.orig/stack/include/ipv4/route.h
+++ rtnet/stack/include/ipv4/route.h
@@ -53,6 +53,8 @@ int rt_ip_route_forward(struct rtskb *rt
#ifdef CONFIG_RTNET_RTIPV4_ROUTE_SRC
int __rt_ip_route_del_host(u32 addr, struct rtnet_device *rtdev);
+int __rt_ip_route_get_host(u32 addr, char* if_name, unsigned char *dev_addr,
+ struct rtnet_device *rtdev);
int __rt_ip_route_output(struct dest_route *rt_buf, u32 daddr, u32 saddr);
static inline int rt_ip_route_del_host(u32 addr, struct rtnet_device *rtdev)
@@ -60,6 +62,13 @@ static inline int rt_ip_route_del_host(u
return __rt_ip_route_del_host(addr, rtdev);
}
+static inline int rt_ip_route_get_host(u32 addr, char* if_name,
+ unsigned char *dev_addr,
+ struct rtnet_device *rtdev)
+{
+return __rt_ip_route_get_host(addr, if_name, dev_addr, rtdev);
+}
+
static inline int rt_ip_route_output(struct dest_route *rt_buf, u32 daddr,
u32 saddr)
{
@@ -67,6 +76,7 @@ static inline int rt_ip_route_output(str
}
#else /* !CONFIG_RTNET_RTIPV4_ROUTE_SRC */
int __rt_ip_route_del_host(u32 addr);
+int __rt_ip_route_get_host(u32 addr, char* if_name, unsigned char *dev_addr);
int __rt_ip_route_output(struct dest_route *rt_buf, u32 daddr);
static inline int rt_ip_route_del_host(u32 addr, struct rtnet_device *rtdev)
@@ -74,6 +84,13 @@ static inline int rt_ip_route_del_host(u
return __rt_ip_route_del_host(addr);
}
+static inline int rt_ip_route_get_host(u32 addr, char* if_name,
+ unsigned char *dev_addr,
+ struct rtnet_device *rtdev)
+{
+return __rt_ip_route_get_host(addr, if_name, dev_addr);
+}
+
static inline int rt_ip_route_output(struct dest_route *rt_buf, u32 daddr,
u32 saddr)
{
Index: rtnet/stack/include/ipv4_chrdev.h
===
--- rtnet.orig/stack/include/ipv4_chrdev.h
+++ rtnet/stack/include/ipv4_chrdev.h
@@ -40,6 +40,11 @@ struct ipv4_cmd {
struct {
__u32 ip_addr;
unsigned char dev_addr[DEV_ADDR_LEN];
+} gethost;
+
+struct {
+__u32 ip_addr;
+unsigned char dev_addr[DEV_ADDR_LEN];
} addhost;
struct {
@@ -86,7 +91,12 @@ struct ipv4_cmd {
#define IOC_RT_PING _IOWR(RTNET_IOC_TYPE_IPV4, 5 | \
RTNET_IOC_NODEV_PARAM,\
struct ipv4_cmd)
-#define IOC_RT_HOST_ROUTE_DELETE_DEV_IOW(RTNET_IOC_TYPE_IPV4, 6, \
+#define IOC_RT_HOST_ROUTE_DELETE_DEV_IOW(RTNET_IOC_TYPE_IPV4, 6,\
struct ipv4_cmd)
+#define IOC_RT_HOST_ROUTE_GET _IOWR(RTNET_IOC_TYPE_IPV4, 7 | \
+ RTNET_IOC_NODEV_PARAM,\
+ struct ipv4_cmd)
+#define IOC_RT_HOST_ROUTE_GET_DEV _IOWR(RTNET_IOC_TYPE_IPV4, 8, \
+ struct ipv4_cmd)
#endif /* __IPV4_H_ */
Index: rtnet/stack/ipv4/af_inet.c
===
--- rtnet.orig/stack/ipv4/af_inet.c
+++ rtnet/stack/ipv4/af_inet.c
@@ -162,6 +162,17 @@ static int ipv4_ioctl(struct rtnet_devic
ret = rt_ip_route_del_host(cmd.args.delhost.ip_addr, rtdev);
break;
+case IOC_RT_HOST_ROUTE_GET:
+case IOC_RT_HOST_ROUTE_GET_DEV:
+ ret = rt_ip_route_get_host(cmd.args.gethost.ip_addr,
+ cmd.head.if_name,
+ cmd.args.gethost.dev_addr, rtdev);
+if (ret >= 0) {
+if (copy_to_user((void *)arg, &cmd, sizeof(cmd)) != 0)
+ret = -EFAULT;
+}
+break;
+
#ifdef CONFIG_RTNET_RTIPV4_NETROUTING
case IOC_RT_NET_ROUTE_ADD:
ret = rt_ip_route_add_net(cmd.args.addnet.net_addr,
Index: rtnet/stack/ipv4/route.c
===
--- rtnet.orig/stack/ipv4/route.c
+++ rtnet/stack/ipv4/route.c
@@ -509,6 +509,51 @@ void rt_ip_route_del_all(struct rtnet_de
}
+/***
+ * rt_ip_route_get_host - check if specified host route is resolved
+ */
+int __
[RTnet-users] [PATCH/RFC v2 1/5] RTnet-Proxy: UDP support
With this patch, non-real-time UDP packets a routed to the Linux
network stack as well. It is the users responsibility, to ensure
that UDP port numbers are used unambiguously in RTnet and Linux.
Signed-off-by: Wolfang Grandegger <[EMAIL PROTECTED]>
Index: rtnet/stack/ipv4/ip_input.c
===
--- rtnet.orig/stack/ipv4/ip_input.c
+++ rtnet/stack/ipv4/ip_input.c
@@ -70,6 +70,13 @@ static inline void rt_ip_local_deliver(s
} else {
/* Get the destination socket */
if ((sock = ipprot->dest_socket(skb)) == NULL) {
+#ifdef CONFIG_RTNET_ADDON_PROXY
+if (rt_ip_fallback_handler) {
+__rtskb_push(skb, iph->ihl*4);
+rt_ip_fallback_handler(skb);
+return;
+}
+#endif
kfree_rtskb(skb);
return;
}
Index: rtnet/stack/ipv4/ip_fragment.c
===
--- rtnet.orig/stack/ipv4/ip_fragment.c
+++ rtnet/stack/ipv4/ip_fragment.c
@@ -33,6 +33,9 @@
#include
+#ifdef CONFIG_RTNET_ADDON_PROXY
+#include
+#endif /* CONFIG_RTNET_ADDON_PROXY */
/*
* This defined sets the number of incoming fragmented IP messages that
@@ -185,6 +188,14 @@ static struct rtskb *add_to_collector(st
rtdm_lock_put_irqrestore(&p_coll->frags.lock, context);
}
+#ifdef CONFIG_RTNET_ADDON_PROXY
+if (rt_ip_fallback_handler) {
+ __rtskb_push(skb, iph->ihl*4);
+ rt_ip_fallback_handler(skb);
+ return NULL;
+}
+#endif
+
#ifdef FRAG_DBG
rtdm_printk("RTnet: Unordered IP fragment (saddr:%x, daddr:%x)"
" - dropped\n", iph->saddr, iph->daddr);
@@ -276,6 +287,13 @@ struct rtskb *rt_ip_defrag(struct rtskb
{
/* Get the destination socket */
if ((sock = ipprot->dest_socket(skb)) == NULL) {
+#ifdef CONFIG_RTNET_ADDON_PROXY
+if (rt_ip_fallback_handler) {
+__rtskb_push(skb, iph->ihl*4);
+rt_ip_fallback_handler(skb);
+return NULL;
+}
+#endif
/* Drop the rtskb */
kfree_rtskb(skb);
return NULL;
--
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
[RTnet-users] [PATCH/RFC v2 0/5] RTnet-Proxy extensions
Hello, here is my second version of patches for extending the RTnet-Proxy. The following issues have been addressed: - UDP is now supported by default by the RTnet proxy. - Kconfig support for the configurable options - Remove #define FRAG_DBG - Avoid RTnet answering the ARP request if CONFIG_RTNET_ADDON_PROXY_ARP=y - Fix bug with rtdev_dereference(rtskb->rtdev) - IOCTL request to get routing information for the specified host without timeout. Hope it's OK now. Thanks, Wolfgang. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] [PATCH/RFC 2/5] RTnet-Proxy: ARP support
Jan Kiszka wrote:
> Wolfgang Grandegger wrote:
>> Hi Jan,
>>
>> Jan Kiszka wrote:
>>> [Somehow, my TB hates your mails - it just presents empty bodies to me
>>> when I hit reply. Strange.]
>>>
>>> Wolfgang Grandegger wrote:
>>>> This patch enables ARP support for the RT-Proxy Linux device.
>>>> Incoming ARP replys are delivered to both, the RTnet and the
>>>> Linux network stack. The RT-Proxy then gets attached to the
>>>> corresponding RTnet device, rteth0 by default. You can enable
>>>> this feature with the configure option "--enable-proxy-arp".
>>> Maybe the same question here: Do we need an extra knob for this, or are
>>> all proxy scenarios fine this enabled?
>>>
>>>> Note: this patch requires running "scripts/autogen.sh"
>>>>
>>>> Signed-off-by: Wolfang Grandegger <[EMAIL PROTECTED]>
>>>> Index: rtnet/stack/ipv4/arp.c
>>>> ===
>>>> --- rtnet.orig/stack/ipv4/arp.c
>>>> +++ rtnet/stack/ipv4/arp.c
>>>> @@ -25,6 +25,9 @@
>>>> #include
>>>> #include
>>>>
>>>> +#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
>>>> +#include
>>>> +#endif /* CONFIG_RTNET_ADDON_PROXY_ARP */
>>>>
>>>> /***
>>>> * arp_send: Create and send an arp packet. If (dest_hw == NULL),
>>>> @@ -174,6 +177,12 @@ int rt_arp_rcv(struct rtskb *skb, struct
>>>> }
>>>>
>>>> out:
>>>> +#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
>>>> +if (rt_ip_fallback_handler) {
>>>> + rt_ip_fallback_handler(skb);
>>>> + return 0;
>>>> +}
>>>> +#endif
>>> Hmm, I wonder what prevents ARP requests being answered twice: first by
>>> RTnet (a few lines above this hunk), and then potentially also by Linux.
>> I'm especially concerned about the way out-going packets are routed:
>>
>> #ifdef CONFIG_RTNET_ADDON_PROXY_ARP
>> rtdev_reference(rtnetproxy_rtdev);
>>
>> rtskb->rtdev = rtnetproxy_rtdev;
>>
>> /* Call the actual transmit function */
>> rtdev_xmit_proxy(rtskb);
>>
>> rtdev_dereference(rtnetproxy_rtdev);
>>
>> #else /* !CONFIG_RTNET_ADDON_PROXY_ARP */
>> /* Determine the device to use: Only ip routing is used here.
>> * Non-ip protocols are not supported... */
>> rc = rt_ip_route_output(&rt, pData->ip_dst, INADDR_ANY);
>> if (rc == 0)
>> {
>> struct rtnet_device *rtdev = rt.rtdev;
>> ...
>> }
>> ...
>> #endif /* CONFIG_RTNET_ADDON_PROXY_ARP */
>>
>> For ARP handled by Linux, I forward all out-going packets directly from
>> rtproxy to rteth0, or a device specified with the module parameter
>> rtdev_attach. Side note: as Gilles already mentioned, I would make sense
>> to have an rtproxy* for every rteth*. In the other case the out-going
>> packets are routed according to the RTnet routing table, which is a
>> different use-case. Therefore I tend to make this feature configurable.
>
> Yes, CONFIG_RTNET_ADDON_PROXY_ARP is in fact required to switch between
> two different modes - and also between two different rtproxy mapping. I
> would even say that it is mandatory to have one proxy device per rteth
> device if CONFIG_RTNET_ADDON_PROXY_ARP is on. That avoids the module
> parameters right from the start.
To be done. For the moment, we have just one proxy device.
>
>>>> kfree_rtskb(skb);
>>>> return 0;
>>>> }
>>>> Index: rtnet/addons/rtnetproxy.c
>>>> ===
>>>> --- rtnet.orig/addons/rtnetproxy.c
>>>> +++ rtnet/addons/rtnetproxy.c
>>>> @@ -105,6 +105,14 @@ static rtdm_task_t rtnetproxy_thread;
>>>>
>>>> static rtdm_sem_t rtnetproxy_sem;
>>>>
>>>> +#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
>>>> +static char* rtdev_attach = "rteth0";
>>>> +module_param(rtdev_attach, charp, 0444);
>>>> +MODULE_PARM_DESC(rtdev_attach, "Attach to the specified RTnet device");
>>>> +
>>>> +struct rtnet_device *rtnetproxy_rtdev;
>>>> +#endif
>>>> +
>>>> /* ***
>>>> * Returns the next pointer from the ringbuffer or
Re: [RTnet-users] [PATCH/RFC 2/5] RTnet-Proxy: ARP support
Hi Jan,
Jan Kiszka wrote:
> [Somehow, my TB hates your mails - it just presents empty bodies to me
> when I hit reply. Strange.]
>
> Wolfgang Grandegger wrote:
>> This patch enables ARP support for the RT-Proxy Linux device.
>> Incoming ARP replys are delivered to both, the RTnet and the
>> Linux network stack. The RT-Proxy then gets attached to the
>> corresponding RTnet device, rteth0 by default. You can enable
>> this feature with the configure option "--enable-proxy-arp".
>
> Maybe the same question here: Do we need an extra knob for this, or are
> all proxy scenarios fine this enabled?
>
>> Note: this patch requires running "scripts/autogen.sh"
>>
>> Signed-off-by: Wolfang Grandegger <[EMAIL PROTECTED]>
>> Index: rtnet/stack/ipv4/arp.c
>> ===
>> --- rtnet.orig/stack/ipv4/arp.c
>> +++ rtnet/stack/ipv4/arp.c
>> @@ -25,6 +25,9 @@
>> #include
>> #include
>>
>> +#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
>> +#include
>> +#endif /* CONFIG_RTNET_ADDON_PROXY_ARP */
>>
>> /***
>> * arp_send: Create and send an arp packet. If (dest_hw == NULL),
>> @@ -174,6 +177,12 @@ int rt_arp_rcv(struct rtskb *skb, struct
>> }
>>
>> out:
>> +#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
>> +if (rt_ip_fallback_handler) {
>> +rt_ip_fallback_handler(skb);
>> +return 0;
>> +}
>> +#endif
>
> Hmm, I wonder what prevents ARP requests being answered twice: first by
> RTnet (a few lines above this hunk), and then potentially also by Linux.
I'm especially concerned about the way out-going packets are routed:
#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
rtdev_reference(rtnetproxy_rtdev);
rtskb->rtdev = rtnetproxy_rtdev;
/* Call the actual transmit function */
rtdev_xmit_proxy(rtskb);
rtdev_dereference(rtnetproxy_rtdev);
#else /* !CONFIG_RTNET_ADDON_PROXY_ARP */
/* Determine the device to use: Only ip routing is used here.
* Non-ip protocols are not supported... */
rc = rt_ip_route_output(&rt, pData->ip_dst, INADDR_ANY);
if (rc == 0)
{
struct rtnet_device *rtdev = rt.rtdev;
...
}
...
#endif /* CONFIG_RTNET_ADDON_PROXY_ARP */
For ARP handled by Linux, I forward all out-going packets directly from
rtproxy to rteth0, or a device specified with the module parameter
rtdev_attach. Side note: as Gilles already mentioned, I would make sense
to have an rtproxy* for every rteth*. In the other case the out-going
packets are routed according to the RTnet routing table, which is a
different use-case. Therefore I tend to make this feature configurable.
>> kfree_rtskb(skb);
>> return 0;
>> }
>> Index: rtnet/addons/rtnetproxy.c
>> ===
>> --- rtnet.orig/addons/rtnetproxy.c
>> +++ rtnet/addons/rtnetproxy.c
>> @@ -105,6 +105,14 @@ static rtdm_task_t rtnetproxy_thread;
>>
>> static rtdm_sem_t rtnetproxy_sem;
>>
>> +#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
>> +static char* rtdev_attach = "rteth0";
>> +module_param(rtdev_attach, charp, 0444);
>> +MODULE_PARM_DESC(rtdev_attach, "Attach to the specified RTnet device");
>> +
>> +struct rtnet_device *rtnetproxy_rtdev;
>> +#endif
>> +
>> /* ***
>> * Returns the next pointer from the ringbuffer or zero if nothing is
>> * available
>> @@ -181,7 +189,10 @@ static inline void send_data_out(struct
>> {
>>
>> struct rtskb*rtskb;
>> +#ifndef CONFIG_RTNET_ADDON_PROXY_ARP
>> struct dest_route rt;
>> +int rc;
>> +#endif
>>
>> struct skb_data_format
>> {
>> @@ -194,7 +205,6 @@ static inline void send_data_out(struct
>>* thus no spaces are allowed! */
>>
>> struct skb_data_format *pData;
>> -int rc;
>>
>> /* Copy the data from the standard sk_buff to the realtime sk_buff:
>> * Both have the same length. */
>> @@ -208,6 +218,18 @@ static inline void send_data_out(struct
>>
>> pData = (struct skb_data_format*) rtskb->data;
>>
>> +#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
>> +rtskb->rtdev = rtnetproxy_rtdev;
>> +
>> +/* Call the actual transmit function */
>> +rtdev_xmit_proxy(rtskb);
>> +
>> +/* The rtskb is freed somewhere deep in the driver...
>> + * No need to do it here. */
>
Re: [RTnet-users] [PATCH/RFC 3/5] IOCTL request to check if a host address has been resolved
Jan Kiszka wrote: > Wolfgang Grandegger wrote: >> This patch adds te IOCTL request IOC_RT_HOST_ROUTE_RESOLVED to check >> if an IPv4 host address has been resolved. A timeout can be specified >> to await the address resolution (ARP reply). The rtroute utility >> supports this request and serves as example: >> >> # rtroute solicit dev [wait ] > > I'm fine with the general purpose of this extension, but I do not yet > like the way it is designed in details. > > Why do we have to push the polling loop into kernel space? I don't see a > valid reason for this. What about making the new service even more > useful and defining it as "get host route", ie. make it deliver the > related route or an error if it is not resolvable. Polling can take > place at application/tool level IMHO. The request IOC_RT_GET_HOST_ROUTE was my first idea as well, but than I decided to restrict to the functionality I really need, including polling. Do you have a use-case in mind justifying an IOC_RT_GET_HOST_ROUTE request. Wolfgang. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] [PATCH/RFC 2/5] RTnet-Proxy: ARP support
Jan Kiszka wrote:
> [Somehow, my TB hates your mails - it just presents empty bodies to me
> when I hit reply. Strange.]
>
> Wolfgang Grandegger wrote:
>> This patch enables ARP support for the RT-Proxy Linux device.
>> Incoming ARP replys are delivered to both, the RTnet and the
>> Linux network stack. The RT-Proxy then gets attached to the
>> corresponding RTnet device, rteth0 by default. You can enable
>> this feature with the configure option "--enable-proxy-arp".
>
> Maybe the same question here: Do we need an extra knob for this, or are
> all proxy scenarios fine this enabled?
It's fine for my use-case, at least. But using just the static ARP of
RTnet for Linux networking is a pain, sooner than later.
>> Note: this patch requires running "scripts/autogen.sh"
>>
>> Signed-off-by: Wolfang Grandegger <[EMAIL PROTECTED]>
>> Index: rtnet/stack/ipv4/arp.c
>> ===
>> --- rtnet.orig/stack/ipv4/arp.c
>> +++ rtnet/stack/ipv4/arp.c
>> @@ -25,6 +25,9 @@
>> #include
>> #include
>>
>> +#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
>> +#include
>> +#endif /* CONFIG_RTNET_ADDON_PROXY_ARP */
>>
>> /***
>> * arp_send: Create and send an arp packet. If (dest_hw == NULL),
>> @@ -174,6 +177,12 @@ int rt_arp_rcv(struct rtskb *skb, struct
>> }
>>
>> out:
>> +#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
>> +if (rt_ip_fallback_handler) {
>> +rt_ip_fallback_handler(skb);
>> +return 0;
>> +}
>> +#endif
>
> Hmm, I wonder what prevents ARP requests being answered twice: first by
> RTnet (a few lines above this hunk), and then potentially also by Linux.
Ah, you are right. I think RTnet should not answer the ARP request.
>
>> kfree_rtskb(skb);
>> return 0;
>> }
>> Index: rtnet/addons/rtnetproxy.c
>> ===
>> --- rtnet.orig/addons/rtnetproxy.c
>> +++ rtnet/addons/rtnetproxy.c
>> @@ -105,6 +105,14 @@ static rtdm_task_t rtnetproxy_thread;
>>
>> static rtdm_sem_t rtnetproxy_sem;
>>
>> +#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
>> +static char* rtdev_attach = "rteth0";
>> +module_param(rtdev_attach, charp, 0444);
>> +MODULE_PARM_DESC(rtdev_attach, "Attach to the specified RTnet device");
>> +
>> +struct rtnet_device *rtnetproxy_rtdev;
>> +#endif
>> +
>> /* ***
>> * Returns the next pointer from the ringbuffer or zero if nothing is
>> * available
>> @@ -181,7 +189,10 @@ static inline void send_data_out(struct
>> {
>>
>> struct rtskb*rtskb;
>> +#ifndef CONFIG_RTNET_ADDON_PROXY_ARP
>> struct dest_route rt;
>> +int rc;
>> +#endif
>>
>> struct skb_data_format
>> {
>> @@ -194,7 +205,6 @@ static inline void send_data_out(struct
>>* thus no spaces are allowed! */
>>
>> struct skb_data_format *pData;
>> -int rc;
>>
>> /* Copy the data from the standard sk_buff to the realtime sk_buff:
>> * Both have the same length. */
>> @@ -208,6 +218,18 @@ static inline void send_data_out(struct
>>
>> pData = (struct skb_data_format*) rtskb->data;
>>
>> +#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
>> +rtskb->rtdev = rtnetproxy_rtdev;
>> +
>> +/* Call the actual transmit function */
>> +rtdev_xmit_proxy(rtskb);
>> +
>> +/* The rtskb is freed somewhere deep in the driver...
>> + * No need to do it here. */
>> +
>> +rtdev_dereference(rtskb->rtdev);
>
> I know this pattern is not new, but looking at it I wonder if this isn't
> generation a potential use-after-release (if xmitting causes an
> immediate rtskb release)...
I have to check.
Wolfgang.
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] [PATCH/RFC 1/5] RTnet-Proxy: UDP support
Jan Kiszka wrote:
> [Somehow, my TB hates your mails - it just presents empty bodies to me
> when I hit reply. Strange.]
Hm, I used "quilt mail" to my local mbox first before bouncing it to
the RTnet-useres ML.
> Wolfgang Grandegger wrote:
>> With this patch non-real-time UDP packets a routed to the Linux
>> network stack. You can enable this feature with the configure
>> option "--enable-proxy-udp".
>
> From a first glance, I think we can live without
> CONFIG_RTNET_ADDON_PROXY_UDP, just letting the new code depend on
> CONFIG_RTNET_ADDON_PROXY.
Fine for me. As I don't know the existing use-cases, I made the new
feature configurable.
>
>> Note: this patch requires running "scripts/autogen.sh"
>>
>> Signed-off-by: Wolfang Grandegger <[EMAIL PROTECTED]>
>> Index: rtnet/stack/ipv4/ip_input.c
>> ===
>> --- rtnet.orig/stack/ipv4/ip_input.c
>> +++ rtnet/stack/ipv4/ip_input.c
>> @@ -70,6 +70,13 @@ static inline void rt_ip_local_deliver(s
>> } else {
>> /* Get the destination socket */
>> if ((sock = ipprot->dest_socket(skb)) == NULL) {
>> +#ifdef CONFIG_RTNET_ADDON_PROXY_UDP
>> +if (rt_ip_fallback_handler) {
>> +__rtskb_push(skb, iph->ihl*4);
>> +rt_ip_fallback_handler(skb);
>> +return;
>> +}
>> +#endif
>> kfree_rtskb(skb);
>> return;
>> }
>> Index: rtnet/stack/ipv4/ip_fragment.c
>> ===
>> --- rtnet.orig/stack/ipv4/ip_fragment.c
>> +++ rtnet/stack/ipv4/ip_fragment.c
>> @@ -33,6 +33,11 @@
>>
>> #include
>>
>> +#ifdef CONFIG_RTNET_ADDON_PROXY_UDP
>> +#include
>> +#endif /* CONFIG_RTNET_ADDON_PROXY_UDP */
>> +
>> +#define FRAG_DBG
>
> The last line probably does not want to be in mainline.
Yep.
Wolfgang.
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] [PATCH/RFC 1/5] RTnet-Proxy: UDP support
Gilles Chanteperdrix wrote: > On Mon, May 5, 2008 at 5:06 PM, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: >> Hi Gilles, >> >> >> >> Gilles Chanteperdrix wrote: >> > On Mon, May 5, 2008 at 2:47 PM, Wolfgang Grandegger <[EMAIL PROTECTED]> >> wrote: >> >> With this patch non-real-time UDP packets a routed to the Linux >> >> network stack. You can enable this feature with the configure >> >> option "--enable-proxy-udp". >> > >> > I am interested by this patch since I use a similar feature. Is the >> > rtnet-proxy a per-interface thing, or is there only one rtnet-proxy >> > interface in the system ? >> >> As-is, one Linux network device named rtproxy will be created when >> loading rtnetproxy.ko. All in-coming non-real-time IP packets (TCP or >> UDP) from any RTnet interface will be forwarded to rtproxy. Out-going >> packets will be routed according to the RTnet routing table: >> >> http://www.rts.uni-hannover.de/rtnet/lxr/source/addons/rtnetproxy.c#211 >> >> If using the "[PATCH/RFC 2/5] RTnet-Proxy: ARP support", the rtproxy >> Linux device gets attached directly to the RTnet device specified via >> module parameter "rtdev_attach". >> >> Well, I'm just using one network device and did not think yet further. >> But it might make sense to have more than one rtproxy Linux network >> device and attach them to the corresponding RTnet device. >> >> What is your setup/requirement. > > I already have our setup of RTnet running, so I have no real > requirement. Ok, I know, I really should look for integration of the > modifications we have. That would be nice, indeed. > Our setup is a gateway/router which does NAT via Linux for data > connections and acts as an IPBX (using Xenomai/Rtnet) for voice > connections. OK. > In our setup, we have one non real-time interface per real-time > interface (using the nomac vnics), and bridging and routing is set-up > using these non real-time interfaces. To support multiply rtproxy devices, rtnetproxy needs to be extended. But, as I see it, not much else is missing. > Also, in our setup, the ARP replies to requests sent by Linux are used > by RTnet before passing them to Linux, so that RTnet learns the MAC > addresses we no additional effort. As you already found out, "[PATCH/RFC 2/5] RTnet-Proxy: ARP support" adds that feature. Wolfgang. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] [PATCH/RFC 1/5] RTnet-Proxy: UDP support
Gilles Chanteperdrix wrote: > On Mon, May 5, 2008 at 5:14 PM, Gilles Chanteperdrix > <[EMAIL PROTECTED]> wrote: >> Also, in our setup, the ARP replies to requests sent by Linux are used >> by RTnet before passing them to Linux, so that RTnet learns the MAC >> addresses we no additional effort. > > Ok, I see patch 2/5 is doing the same thing. Yes, and this requires to attach the Linux network device directly to a RTnet device. Wolfgang. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] [PATCH/RFC 1/5] RTnet-Proxy: UDP support
Hi Gilles, Gilles Chanteperdrix wrote: > On Mon, May 5, 2008 at 2:47 PM, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: >> With this patch non-real-time UDP packets a routed to the Linux >> network stack. You can enable this feature with the configure >> option "--enable-proxy-udp". > > I am interested by this patch since I use a similar feature. Is the > rtnet-proxy a per-interface thing, or is there only one rtnet-proxy > interface in the system ? As-is, one Linux network device named rtproxy will be created when loading rtnetproxy.ko. All in-coming non-real-time IP packets (TCP or UDP) from any RTnet interface will be forwarded to rtproxy. Out-going packets will be routed according to the RTnet routing table: http://www.rts.uni-hannover.de/rtnet/lxr/source/addons/rtnetproxy.c#211 If using the "[PATCH/RFC 2/5] RTnet-Proxy: ARP support", the rtproxy Linux device gets attached directly to the RTnet device specified via module parameter "rtdev_attach". Well, I'm just using one network device and did not think yet further. But it might make sense to have more than one rtproxy Linux network device and attach them to the corresponding RTnet device. What is your setup/requirement. Wolfgang. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
[RTnet-users] [PATCH/RFC 3/5] IOCTL request to check if a host address has been resolved
This patch adds te IOCTL request IOC_RT_HOST_ROUTE_RESOLVED to check
if an IPv4 host address has been resolved. A timeout can be specified
to await the address resolution (ARP reply). The rtroute utility
supports this request and serves as example:
# rtroute solicit dev [wait ]
Signed-off-by: Wolfang Grandegger <[EMAIL PROTECTED]>
Index: rtnet/stack/include/ipv4/route.h
===
--- rtnet.orig/stack/include/ipv4/route.h
+++ rtnet/stack/include/ipv4/route.h
@@ -53,6 +53,7 @@ int rt_ip_route_forward(struct rtskb *rt
#ifdef CONFIG_RTNET_RTIPV4_ROUTE_SRC
int __rt_ip_route_del_host(u32 addr, struct rtnet_device *rtdev);
+int __rt_ip_route_host_resolved(u32 addr, struct rtnet_device *rtdev);
int __rt_ip_route_output(struct dest_route *rt_buf, u32 daddr, u32 saddr);
static inline int rt_ip_route_del_host(u32 addr, struct rtnet_device *rtdev)
@@ -60,6 +61,12 @@ static inline int rt_ip_route_del_host(u
return __rt_ip_route_del_host(addr, rtdev);
}
+static inline int rt_ip_route_host_resolved(u32 addr,
+ struct rtnet_device *rtdev)
+{
+return __rt_ip_route_host_resolved(addr, rtdev);
+}
+
static inline int rt_ip_route_output(struct dest_route *rt_buf, u32 daddr,
u32 saddr)
{
@@ -67,6 +74,7 @@ static inline int rt_ip_route_output(str
}
#else /* !CONFIG_RTNET_RTIPV4_ROUTE_SRC */
int __rt_ip_route_del_host(u32 addr);
+int __rt_ip_route_host_resolved(u32 addr);
int __rt_ip_route_output(struct dest_route *rt_buf, u32 daddr);
static inline int rt_ip_route_del_host(u32 addr, struct rtnet_device *rtdev)
@@ -74,6 +82,12 @@ static inline int rt_ip_route_del_host(u
return __rt_ip_route_del_host(addr);
}
+static inline int rt_ip_route_host_resolved(u32 addr,
+ struct rtnet_device *rtdev)
+{
+return __rt_ip_route_host_resolved(addr);
+}
+
static inline int rt_ip_route_output(struct dest_route *rt_buf, u32 daddr,
u32 saddr)
{
Index: rtnet/stack/include/ipv4_chrdev.h
===
--- rtnet.orig/stack/include/ipv4_chrdev.h
+++ rtnet/stack/include/ipv4_chrdev.h
@@ -39,6 +39,11 @@ struct ipv4_cmd {
struct {
__u32 ip_addr;
+int timeout;
+} resolved;
+
+struct {
+__u32 ip_addr;
unsigned char dev_addr[DEV_ADDR_LEN];
} addhost;
@@ -86,7 +91,10 @@ struct ipv4_cmd {
#define IOC_RT_PING _IOWR(RTNET_IOC_TYPE_IPV4, 5 | \
RTNET_IOC_NODEV_PARAM,\
struct ipv4_cmd)
-#define IOC_RT_HOST_ROUTE_DELETE_DEV_IOW(RTNET_IOC_TYPE_IPV4, 6, \
+#define IOC_RT_HOST_ROUTE_DELETE_DEV_IOW(RTNET_IOC_TYPE_IPV4, 6,\
struct ipv4_cmd)
+#define IOC_RT_HOST_ROUTE_RESOLVED _IOW(RTNET_IOC_TYPE_IPV4, 7 | \
+ RTNET_IOC_NODEV_PARAM,\
+ struct ipv4_cmd)
#endif /* __IPV4_H_ */
Index: rtnet/stack/ipv4/af_inet.c
===
--- rtnet.orig/stack/ipv4/af_inet.c
+++ rtnet/stack/ipv4/af_inet.c
@@ -123,6 +123,7 @@ static int ipv4_ioctl(struct rtnet_devic
struct ipv4_cmd cmd;
struct route_solicit_params params;
int ret;
+int timeout;
ret = copy_from_user(&cmd, (void *)arg, sizeof(cmd));
@@ -162,6 +163,17 @@ static int ipv4_ioctl(struct rtnet_devic
ret = rt_ip_route_del_host(cmd.args.delhost.ip_addr, rtdev);
break;
+case IOC_RT_HOST_ROUTE_RESOLVED:
+timeout = jiffies + (cmd.args.resolved.timeout * HZ / 1000);
+while (1) {
+ret = rt_ip_route_host_resolved(cmd.args.resolved.ip_addr,
+ rtdev);
+if (!ret || jiffies >= timeout)
+break;
+schedule_timeout(1);
+}
+break;
+
#ifdef CONFIG_RTNET_RTIPV4_NETROUTING
case IOC_RT_NET_ROUTE_ADD:
ret = rt_ip_route_add_net(cmd.args.addnet.net_addr,
Index: rtnet/stack/ipv4/route.c
===
--- rtnet.orig/stack/ipv4/route.c
+++ rtnet/stack/ipv4/route.c
@@ -509,6 +509,47 @@ void rt_ip_route_del_all(struct rtnet_de
}
+/***
+ * rt_ip_route_host_resolved - check if specified host route is resolved
+ */
+int __rt_ip_route_host_resolved(u32 addr
+#ifdef CONFIG_RTNET_RTIPV4_ROUTE_SRC
+ , struct rtnet_device *rtdev
+#endif /* CONFIG_RTNET_RTIPV4_ROUTE_SRC */
+ )
+{
+rtdm
[RTnet-users] [PATCH/RFC 5/5] RTnet-Proxy: Update documentation of the extened RTnet-Proxy
Signed-off-by: Wolfang Grandegger <[EMAIL PROTECTED]> Index: rtnet/Documentation/README.rtnetproxy === --- rtnet.orig/Documentation/README.rtnetproxy +++ rtnet/Documentation/README.rtnetproxy @@ -1,59 +1,79 @@ README.rtnetproxy === 08-Nov-2002, Mathias Koehrer <[EMAIL PROTECTED]> +02-May-2008, Wolfgang Grandegger <[EMAIL PROTECTED]> -rtnetproxy can be used to share a single network adapter for both - realtime -and non-realtime ethernet traffic. TCP/IP can be used via rtnet (of course -not in realtime!) +RTnetproxy can be used to share a single network adapter for both - realtime +and non-realtime ethernet traffic. TCP/IP, UDP and ARP can be used via RTnet +(of course not in realtime!) -rtnetproxy represents a network device to standard linux and can be used -as any other linux network device (ifconfig for configuration), the name +RTnetproxy represents a network device to standard Linux and can be used +as any other Linux network device (ifconfig for configuration), the name the network device is "rtproxy". Setup: -Get your rtnet working first! All IP addresses you are interested in have +Get your RTnet working first! All IP addresses you are interested in have to be set via "rtifconfig ethX route solicit IP_ADDRESS"! insmod rtnetproxy.o -Now, you have a network device "rtproxy" ready to be used with linux. +Now, you have a network device "rtproxy" ready to be used with Linux. Configure this network device using "ifconfig": + Example: + ifconfig rtproxy up 192.168.10.10 netmask 255.255.255.0 That's it! -Restrictions: --- -rtnetproxy is restricted to IP-based protocols (TCP/IP!!!). -Incoming frames from ICMP and UDP are interpreted directly by rtnet and are -not forwarded to rtnetproxy => UDP works only with outgoing frames from linux -context. Of course UDP works with rtnet! +Configuration options: + +--enable-proxy: this enables RTnetproxy support, which is by default +restricted to IP-based protocols (TCP/IP!!!). Incoming frames from +ICMP and UDP are interpreted directly by RTnet and are not forwarded +to RTnetproxy => UDP works only with outgoing frames from Linux +context. Of course UDP works with RTnet! + +--enabled-proxy-udp: this option enables routing of non-realtime UDP +packets to the Linux network stack (via rtproxy device). It's the +users responsibility to make sure that port numbers used by RTnet +or the Linux network stack are assigned uniquely. + +--enable-proxy-arp: this option enables ARP support for the rtproxy Linux +network device. Incoming ARP replys are delivered to both, the RTnet +and the Linux network stack. The rtproxy then gets attached to the +corresponding RTnet device, rteth0 by default. + +--disable-icmp: this option disables the RTnet IPv4 ICMP support. ICMP +will then be handled by the Linux network stack via the rtproxy Linux +network device. +Important note: +- It is highly recommended to strictly separate realtime LAN traffic and non- -realtime LAN traffic. For a configuration/setup phase, TCP/IP is sometimes +realtime LAN traffic. For a configuration/setup phase, TCP/IP is sometimes very useful, buf for realtime data exchange the LAN should be reserved for the realtime traffic using UDP! How it works internally: -- -rtnetproxy works on top of rtnet. -All data to be sent out or received is actually copied between rtnet and -rtnetproxy => The performance is not as good as with the standard linux +RTnetproxy works on top of RTnet. +All data to be sent out or received is actually copied between RTnet and +RTnetproxy => The performance is not as good as with the standard Linux network drivers. All incoming IPv4 frames, having a IP protocol ID that is not handled by -rtnet are passed to rtnetproxy. -Incoming frames, that are passed to rtnetproxy (TCP frames) slow down the +RTnet are passed to RTnetproxy. +Incoming frames, that are passed to RTnetproxy (TCP frames) slow down the realtime stuff a little bit - as all this is done in realtime mode context! Possible enhancements: --- -Pass incoming frames to rtnetproxy not only by checking the protocol ID but -by actual checking, if a certain frame has been processed by rtnet or not. -This leads to a couple of changes in the rtnet implementation... +Pass incoming frames to RTnetproxy not only by checking the protocol ID but +by actual checking, if a certain frame has been processed by RTnet or not. +This leads to a couple of changes in the RTnet implementation... -- - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's excitin
[RTnet-users] [PATCH/RFC 4/5] Disable RTnet IPv4 ICMP support
This patch allows to disable the RTnet IPv4 ICMP support, which might
be useful when using the RTnet-Proxy add-on. ICMP will then be handled
by the Linux network stack. ICMP support in RTnet is enabled by default
and it can be disabled with the configure option "--disable-icmp".
Note: this patch requires running "scripts/autogen.sh"
Signed-off-by: Wolfang Grandegger <[EMAIL PROTECTED]>
Index: rtnet/stack/ipv4/af_inet.c
===
--- rtnet.orig/stack/ipv4/af_inet.c
+++ rtnet/stack/ipv4/af_inet.c
@@ -79,6 +79,7 @@ static void cleanup_route_solicit(void *
+#ifdef CONFIG_RTNET_RTIPV4_ICMP
static int ping_handler(struct rt_proc_call *call)
{
struct ipv4_cmd *cmd;
@@ -114,6 +115,7 @@ static void ping_complete_handler(struct
usr_cmd->args.ping.ip_addr = cmd->args.ping.ip_addr;
usr_cmd->args.ping.rtt = cmd->args.ping.rtt;
}
+#endif /* CONFIG_RTNET_RTIPV4_ICMP */
@@ -187,6 +189,7 @@ static int ipv4_ioctl(struct rtnet_devic
break;
#endif /* CONFIG_RTNET_RTIPV4_NETROUTING */
+#ifdef CONFIG_RTNET_RTIPV4_ICMP
case IOC_RT_PING:
ret = rtpc_dispatch_call(ping_handler, cmd.args.ping.timeout, &cmd,
sizeof(cmd), ping_complete_handler, NULL);
@@ -197,6 +200,7 @@ static int ipv4_ioctl(struct rtnet_devic
if (ret < 0)
rt_icmp_cleanup_echo_requests();
break;
+#endif /* CONFIG_RTNET_RTIPV4_ICMP */
default:
ret = -ENOTTY;
@@ -338,7 +342,9 @@ int __init rt_ipv4_proto_init(void)
for (i=0; i@]),
+[case "$enableval" in
+y | yes) CONFIG_RTNET_RTIPV4_ICMP=y ;;
+*) CONFIG_RTNET_RTIPV4_ICMP=n ;;
+esac])
+AC_MSG_RESULT([${CONFIG_RTNET_RTIPV4_ICMP:-n}])
+AM_CONDITIONAL(CONFIG_RTNET_RTIPV4_ICMP,[test "$CONFIG_RTNET_RTIPV4_ICMP" =
"y"])
+if test "$CONFIG_RTNET_RTIPV4_ICMP" = "y"; then
+AC_DEFINE(CONFIG_RTNET_RTIPV4_ICMP,1,[Real-Time IPv4 ICMP support])
+fi
+
AC_MSG_CHECKING([whether to enable source IP routing])
AC_ARG_ENABLE(route-src,
AS_HELP_STRING([--enable-route-src], [enable source IP routing
@<:@default=no@:>@]),
Index: rtnet/defconfig
===
--- rtnet.orig/defconfig
+++ rtnet/defconfig
@@ -33,6 +33,7 @@ CONFIG_RTNET_RX_FIFO_SIZE=32
# Protocols
#
CONFIG_RTNET_RTIPV4=y
+CONFIG_RTNET_RTIPV4_ICMP=y
# CONFIG_RTNET_RTIPV4_ROUTE_SRC is not set
# CONFIG_RTNET_RTIPV4_NETROUTING is not set
# CONFIG_RTNET_RTIPV4_ROUTER is not set
Index: rtnet/stack/ipv4/GNUmakefile.am
===
--- rtnet.orig/stack/ipv4/GNUmakefile.am
+++ rtnet/stack/ipv4/GNUmakefile.am
@@ -16,10 +16,13 @@ libkernel_ipv4_a_SOURCES = \
ip_input.c \
ip_sock.c \
udp.c \
- icmp.c \
ip_output.c \
ip_fragment.c
+if CONFIG_RTNET_RTIPV4_ICMP
+libkernel_ipv4_a_SOURCES += icmp.c
+endif
+
OBJS = rtipv4$(modext)
rtipv4.o: libkernel_ipv4.a
--
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
[RTnet-users] [PATCH/RFC 2/5] RTnet-Proxy: ARP support
This patch enables ARP support for the RT-Proxy Linux device.
Incoming ARP replys are delivered to both, the RTnet and the
Linux network stack. The RT-Proxy then gets attached to the
corresponding RTnet device, rteth0 by default. You can enable
this feature with the configure option "--enable-proxy-arp".
Note: this patch requires running "scripts/autogen.sh"
Signed-off-by: Wolfang Grandegger <[EMAIL PROTECTED]>
Index: rtnet/stack/ipv4/arp.c
===
--- rtnet.orig/stack/ipv4/arp.c
+++ rtnet/stack/ipv4/arp.c
@@ -25,6 +25,9 @@
#include
#include
+#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
+#include
+#endif /* CONFIG_RTNET_ADDON_PROXY_ARP */
/***
* arp_send: Create and send an arp packet. If (dest_hw == NULL),
@@ -174,6 +177,12 @@ int rt_arp_rcv(struct rtskb *skb, struct
}
out:
+#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
+if (rt_ip_fallback_handler) {
+ rt_ip_fallback_handler(skb);
+ return 0;
+}
+#endif
kfree_rtskb(skb);
return 0;
}
Index: rtnet/addons/rtnetproxy.c
===
--- rtnet.orig/addons/rtnetproxy.c
+++ rtnet/addons/rtnetproxy.c
@@ -105,6 +105,14 @@ static rtdm_task_t rtnetproxy_thread;
static rtdm_sem_t rtnetproxy_sem;
+#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
+static char* rtdev_attach = "rteth0";
+module_param(rtdev_attach, charp, 0444);
+MODULE_PARM_DESC(rtdev_attach, "Attach to the specified RTnet device");
+
+struct rtnet_device *rtnetproxy_rtdev;
+#endif
+
/* ***
* Returns the next pointer from the ringbuffer or zero if nothing is
* available
@@ -181,7 +189,10 @@ static inline void send_data_out(struct
{
struct rtskb*rtskb;
+#ifndef CONFIG_RTNET_ADDON_PROXY_ARP
struct dest_route rt;
+int rc;
+#endif
struct skb_data_format
{
@@ -194,7 +205,6 @@ static inline void send_data_out(struct
* thus no spaces are allowed! */
struct skb_data_format *pData;
-int rc;
/* Copy the data from the standard sk_buff to the realtime sk_buff:
* Both have the same length. */
@@ -208,6 +218,18 @@ static inline void send_data_out(struct
pData = (struct skb_data_format*) rtskb->data;
+#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
+ rtskb->rtdev = rtnetproxy_rtdev;
+
+/* Call the actual transmit function */
+rtdev_xmit_proxy(rtskb);
+
+/* The rtskb is freed somewhere deep in the driver...
+ * No need to do it here. */
+
+rtdev_dereference(rtskb->rtdev);
+
+#else /* !CONFIG_RTNET_ADDON_PROXY_ARP */
/* Determine the device to use: Only ip routing is used here.
* Non-ip protocols are not supported... */
rc = rt_ip_route_output(&rt, pData->ip_dst, INADDR_ANY);
@@ -244,6 +266,7 @@ static inline void send_data_out(struct
kfree_rtskb(rtskb);
}
+#endif /* !CONFIG_RTNET_ADDON_PROXY_ARP */
}
/*
@@ -456,7 +479,11 @@ static int __init rtnetproxy_init(struct
/* Fill in device structure with ethernet-generic values. */
ether_setup(dev);
dev->tx_queue_len = 0;
+#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
+memcpy(dev->dev_addr, rtnetproxy_rtdev->dev_addr, sizeof(dev->dev_addr));
+#else
dev->flags |= IFF_NOARP;
+#endif
dev->flags &= ~IFF_MULTICAST;
return 0;
@@ -479,6 +506,14 @@ static int __init rtnetproxy_init_module
{
int err;
+#ifdef CONFIG_RTNET_ADDON_PROXY_ARP
+if ((rtnetproxy_rtdev = rtdev_get_by_name(rtdev_attach)) == NULL) {
+ printk("Couldn't attach to %s\n", rtdev_attach);
+ return -EINVAL;
+}
+printk("RTproxy attached to %s\n", rtdev_attach);
+#endif
+
/* Initialize the proxy's rtskb pool (JK) */
if (rtskb_pool_init(&rtskb_pool, proxy_rtskbs) < proxy_rtskbs) {
rtskb_pool_release(&rtskb_pool);
Index: rtnet/configure.ac
===
--- rtnet.orig/configure.ac
+++ rtnet/configure.ac
@@ -1202,6 +1202,19 @@ if test "$CONFIG_RTNET_ADDON_PROXY_UDP"
AC_DEFINE(CONFIG_RTNET_ADDON_PROXY_UDP,1,[rtnetproxy UDP support])
fi
+AC_MSG_CHECKING([whether to enable rtnetproxy ARP support])
+AC_ARG_ENABLE(proxy-arp,
+AS_HELP_STRING([--enable-proxy-arp], [enable ARP support for IP protocol
proxy driver @<:@default=no@:>@]),
+[case "$enableval" in
+y | yes) CONFIG_RTNET_ADDON_PROXY_ARP=y ;;
+*) CONFIG_RTNET_ADDON_PROXY_ARP=n ;;
+esac])
+AC_MSG_RESULT([${CONFIG_RTNET_ADDON_PROXY_ARP:-n}])
+AM_CONDITIONAL(CONFIG_RTNET_ADDON_PROXY_ARP,[test
"$CONFIG_RTNET_ADDON_PROXY_ARP" = "y"])
+if test "$CONFIG_RTNET_ADDON_PROXY_ARP" = "y"; then
+AC_DEFINE(CONFIG_RTNET_ADDON_PROXY_ARP,1,[rtnetproxy ARP support])
+fi
+
#dnl ==
#dnl
[RTnet-users] [PATCH/RFC 1/5] RTnet-Proxy: UDP support
With this patch non-real-time UDP packets a routed to the Linux
network stack. You can enable this feature with the configure
option "--enable-proxy-udp".
Note: this patch requires running "scripts/autogen.sh"
Signed-off-by: Wolfang Grandegger <[EMAIL PROTECTED]>
Index: rtnet/stack/ipv4/ip_input.c
===
--- rtnet.orig/stack/ipv4/ip_input.c
+++ rtnet/stack/ipv4/ip_input.c
@@ -70,6 +70,13 @@ static inline void rt_ip_local_deliver(s
} else {
/* Get the destination socket */
if ((sock = ipprot->dest_socket(skb)) == NULL) {
+#ifdef CONFIG_RTNET_ADDON_PROXY_UDP
+if (rt_ip_fallback_handler) {
+__rtskb_push(skb, iph->ihl*4);
+rt_ip_fallback_handler(skb);
+return;
+}
+#endif
kfree_rtskb(skb);
return;
}
Index: rtnet/stack/ipv4/ip_fragment.c
===
--- rtnet.orig/stack/ipv4/ip_fragment.c
+++ rtnet/stack/ipv4/ip_fragment.c
@@ -33,6 +33,11 @@
#include
+#ifdef CONFIG_RTNET_ADDON_PROXY_UDP
+#include
+#endif /* CONFIG_RTNET_ADDON_PROXY_UDP */
+
+#define FRAG_DBG
/*
* This defined sets the number of incoming fragmented IP messages that
@@ -185,6 +190,14 @@ static struct rtskb *add_to_collector(st
rtdm_lock_put_irqrestore(&p_coll->frags.lock, context);
}
+#ifdef CONFIG_RTNET_ADDON_PROXY_UDP
+if (rt_ip_fallback_handler) {
+ __rtskb_push(skb, iph->ihl*4);
+ rt_ip_fallback_handler(skb);
+ return NULL;
+}
+#endif
+
#ifdef FRAG_DBG
rtdm_printk("RTnet: Unordered IP fragment (saddr:%x, daddr:%x)"
" - dropped\n", iph->saddr, iph->daddr);
@@ -276,6 +289,13 @@ struct rtskb *rt_ip_defrag(struct rtskb
{
/* Get the destination socket */
if ((sock = ipprot->dest_socket(skb)) == NULL) {
+#ifdef CONFIG_RTNET_ADDON_PROXY_UDP
+if (rt_ip_fallback_handler) {
+__rtskb_push(skb, iph->ihl*4);
+rt_ip_fallback_handler(skb);
+return NULL;
+}
+#endif
/* Drop the rtskb */
kfree_rtskb(skb);
return NULL;
Index: rtnet/configure.ac
===
--- rtnet.orig/configure.ac
+++ rtnet/configure.ac
@@ -1189,6 +1189,19 @@ if test "$CONFIG_RTNET_ADDON_PROXY" = "y
AC_DEFINE(CONFIG_RTNET_ADDON_PROXY,1,[rtnetproxy support])
fi
+AC_MSG_CHECKING([whether to enable rtnetproxy UDP support])
+AC_ARG_ENABLE(proxy-udp,
+AS_HELP_STRING([--enable-proxy-udp], [enable UDP support for IP protocol
proxy driver @<:@default=no@:>@]),
+[case "$enableval" in
+y | yes) CONFIG_RTNET_ADDON_PROXY_UDP=y ;;
+*) CONFIG_RTNET_ADDON_PROXY_UDP=n ;;
+esac])
+AC_MSG_RESULT([${CONFIG_RTNET_ADDON_PROXY_UDP:-n}])
+AM_CONDITIONAL(CONFIG_RTNET_ADDON_PROXY_UDP,[test
"$CONFIG_RTNET_ADDON_PROXY_UDP" = "y"])
+if test "$CONFIG_RTNET_ADDON_PROXY_UDP" = "y"; then
+AC_DEFINE(CONFIG_RTNET_ADDON_PROXY_UDP,1,[rtnetproxy UDP support])
+fi
+
#dnl ==
#dnl RTDM select (disabled until RTDM actually supports this)
--
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
[RTnet-users] [PATCH/RFC 0/5] RTnet-Proxy extensions
Hello, it follows a series of patches extending the functionality and usability of the RTnet-Proxy [1]: 1. RTnet-Proxy: UDP support 2. RTnet-Proxy: ARP support 3. IOCTL request to check if a host address has been resolved 4. Disable RTnet IPv4 ICMP support 5. RTnet-Proxy: Update documentation of the extened RTnet-Proxy The RTnet-Proxy allows to share real-time and non-real-time network traffic on the same RTnet device. Incoming non-real-time packets are forwarded to the Linux network stack. Here is the list of configuration options for the extended RTnet-Proxy: --enable-proxy: this enables RTnetproxy support, which is by default restricted to IP-based protocols (TCP/IP!!!). Incoming frames from ICMP and UDP are interpreted directly by RTnet and are not forwarded to RTnetproxy => UDP works only with outgoing frames from Linux context. Of course UDP works with RTnet! --enabled-proxy-udp: this option enables routing of non-realtime UDP packets to the Linux network stack (via rtproxy device). It's the users responsibility to make sure that port numbers used by RTnet or the Linux network stack are assigned uniquely. --enable-proxy-arp: this option enables ARP support for the rtproxy Linux network device. Incoming ARP replys are delivered to both, the RTnet and the Linux network stack. The rtproxy then gets attached to the corresponding RTnet device, rteth0 by default. --disable-icmp: this option disables the RTnet IPv4 ICMP support. ICMP will then be handled by the Linux network stack via the rtproxy Linux network device. Comments are welcome. Wolfgang. [1] http://www.rts.uni-hannover.de/rtnet/lxr/source/Documentation/README.rtnetproxy - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] [PATCH] Fix Linux version incompatibility with pci_register_driver()
Jan Kiszka wrote: > Wolfgang Grandegger wrote: >> Jan Kiszka wrote: >>> Wolfgang Grandegger wrote: >>>> Jan Kiszka wrote: >>>>> Wolfgang Grandegger wrote: >>>>>> Fix Linux version incompatibility with pci_register_driver() >>>>>> >>>>>> The function pci_register_driver() returns different error codes on >>>>>> Linux 2.4 and 2.6. This patch adds compat_pci_register_driver() >>>>>> to deal with this incompatibility and updates all drivers using it. >>>>> Please repost this patch and the MPC one, both are line-wrapped. >>>> Grrr, it's always a challenge to send inline patches with thunderbird, >>>> sorry. >>> https://addons.mozilla.org/de/firefox/addon/2351 8) >> Ah, didn't know that one but will try now. So far I used the >> recommendations from >> >> http://kerneltrap.org/Linux/Email_Clients_and_Patches > > That plugin does not obsolete send_plaintext_flowed=false, but it allows > you to switch between automatic and manual wrapping with Ctrl-Shift-W, > thus very comfortably. OK, I have just re-sent the patch unsing this plugin. Hope it's fine now (as my internal tests showed). > > Additionally, I have set up Ctrl-Shift-U (->keyconfig, > http://mozilla.dorando.at/) to cmd_rewrap so that I can selectively wrap > text blocks and then switch to non-wrapped mode (in case you glue patch > and description with TB). Sounds useful. Thanks, Wolfgang. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
[RTnet-users] [PATCH] Fix Linux version incompatibility with pci_register_driver()
Fix Linux version incompatibility with pci_register_driver()
The function pci_register_driver() returns different error codes on
Linux 2.4 and 2.6. This patch adds compat_pci_register_driver()
to deal with this incompatibility and updates all drivers using it.
Signed-off-by: Wolfang Grandegger <[EMAIL PROTECTED]>
Index: rtnet/drivers/rt_eepro100.c
===
--- rtnet.orig/drivers/rt_eepro100.c
+++ rtnet/drivers/rt_eepro100.c
@@ -1999,13 +1999,7 @@ static int __init eepro100_init_module(v
debug = speedo_debug; /* touch debug variable */
#endif /* RTNET_DRV_EEPRO100_DBG */
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0)
- if (pci_register_driver(&eepro100_driver) <= 0)
- return -EINVAL;
- return 0;
-#else
- return pci_register_driver(&eepro100_driver);
-#endif
+ return compat_pci_register_driver(&eepro100_driver);
}
static void __exit eepro100_cleanup_module(void)
Index: rtnet/stack/include/rtnet_port.h
===
--- rtnet.orig/stack/include/rtnet_port.h
+++ rtnet/stack/include/rtnet_port.h
@@ -32,6 +32,16 @@
#include
+#ifndef compat_pci_register_driver
+# if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0)
+# define compat_pci_register_driver(drv) \
+ (pci_register_driver(drv) <= 0 ? -EINVAL : 0)
+# else
+# define compat_pci_register_driver(drv) \
+ pci_register_driver(drv)
+# endif
+#endif
+
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0)
# define pci_dma_sync_single_for_device pci_dma_sync_single
# define pci_dma_sync_single_for_cpupci_dma_sync_single
Index: rtnet/drivers/rt_8139too.c
===
--- rtnet.orig/drivers/rt_8139too.c
+++ rtnet/drivers/rt_8139too.c
@@ -1861,7 +1861,7 @@ static int __init rtl8139_init_module (v
printk (KERN_INFO RTL8139_DRIVER_NAME "\n");
#endif
-return pci_register_driver (&rtl8139_pci_driver);
+return compat_pci_register_driver (&rtl8139_pci_driver);
}
Index: rtnet/drivers/rt_natsemi.c
===
--- rtnet.orig/drivers/rt_natsemi.c
+++ rtnet/drivers/rt_natsemi.c
@@ -2865,7 +2865,7 @@ static int __init natsemi_init_mod (void
rtdm_printk(version);
#endif
- return pci_register_driver (&natsemi_driver);
+ return compat_pci_register_driver (&natsemi_driver);
}
static void __exit natsemi_exit_mod (void)
Index: rtnet/drivers/rt_pcnet32.c
===
--- rtnet.orig/drivers/rt_pcnet32.c
+++ rtnet/drivers/rt_pcnet32.c
@@ -1810,7 +1810,7 @@ static int __init pcnet32_init_module(vo
tx_start = tx_start_pt;
/* find the PCI devices */
-if (!pci_register_driver(&pcnet32_driver))
+if (!compat_pci_register_driver(&pcnet32_driver))
pcnet32_have_pci = 1;
/* should we find any remaining VLbus devices ? */
Index: rtnet/drivers/rt_via-rhine.c
===
--- rtnet.orig/drivers/rt_via-rhine.c
+++ rtnet/drivers/rt_via-rhine.c
@@ -2037,7 +2037,7 @@ static int __init via_rhine_init (void)
#ifdef MODULE
printk(version);
#endif
- return pci_register_driver (&via_rhine_driver);
+ return compat_pci_register_driver (&via_rhine_driver);
}
Index: rtnet/drivers/e1000/e1000_main.c
===
--- rtnet.orig/drivers/e1000/e1000_main.c
+++ rtnet/drivers/e1000/e1000_main.c
@@ -277,7 +277,7 @@ e1000_init_module(void)
printk(KERN_INFO "%s\n", e1000_copyright);
- ret = pci_register_driver(&e1000_driver);
+ ret = compat_pci_register_driver(&e1000_driver);
return ret;
}
Index: rtnet/drivers/experimental/rt2500/rt_rt2500pci.c
===
--- rtnet.orig/drivers/experimental/rt2500/rt_rt2500pci.c
+++ rtnet/drivers/experimental/rt2500/rt_rt2500pci.c
@@ -1239,7 +1239,7 @@ struct pci_driver rt2x00_pci_driver =
static int __init rt2x00_pci_init(void) {
rtdm_printk(KERN_INFO "Loading module: %s\n", version);
-return pci_register_driver(&rt2x00_pci_driver);
+return compat_pci_register_driver(&rt2x00_pci_driver);
}
static void __exit rt2x00_pci_exit(void) {
Index: rtnet/drivers/experimental/rt_3c59x.c
===
--- rtnet.orig/drivers/experimental/rt_3c59x.c
+++ rtnet/drivers/experimental/rt_3c59x.c
@@ -3358,7 +3358,7 @@ static int __init vortex_init (void)
{
int pci_rc;
- pci_rc = pci_register_driver(&vortex_driver);
+ pci_rc = compat_pci_register_driver(&vortex_driver);
if (pci_rc == 0)
vortex_have_pci = 1;
Index: rtnet/drivers/experimental/rt_r8169.c
===
Re: [RTnet-users] [PATCH] Fix Linux version incompatibility with pci_register_driver()
Jan Kiszka wrote: > Wolfgang Grandegger wrote: >> Jan Kiszka wrote: >>> Wolfgang Grandegger wrote: >>>> Fix Linux version incompatibility with pci_register_driver() >>>> >>>> The function pci_register_driver() returns different error codes on >>>> Linux 2.4 and 2.6. This patch adds compat_pci_register_driver() >>>> to deal with this incompatibility and updates all drivers using it. >>> Please repost this patch and the MPC one, both are line-wrapped. >> Grrr, it's always a challenge to send inline patches with thunderbird, >> sorry. > > https://addons.mozilla.org/de/firefox/addon/2351 8) Ah, didn't know that one but will try now. So far I used the recommendations from http://kerneltrap.org/Linux/Email_Clients_and_Patches Wolfgang. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] [PATCH] Fix Linux version incompatibility with pci_register_driver()
Jan Kiszka wrote: > Wolfgang Grandegger wrote: >> Fix Linux version incompatibility with pci_register_driver() >> >> The function pci_register_driver() returns different error codes on >> Linux 2.4 and 2.6. This patch adds compat_pci_register_driver() >> to deal with this incompatibility and updates all drivers using it. > > Please repost this patch and the MPC one, both are line-wrapped. Grrr, it's always a challenge to send inline patches with thunderbird, sorry. Wolfgang. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Expresscard ethernet ?
Wolfgang Köbler wrote: > Hello, > > Is there any Expresscard Ethernet Network Interface Card that is > supported by RTnet ? The E1000 RTnet driver seems to support some PCI express cards. Have a look to e1000_hw.c for further details. Wolfgang. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
[RTnet-users] [PATCH] Fix Linux version incompatibility with pci_register_driver()
Fix Linux version incompatibility with pci_register_driver()
The function pci_register_driver() returns different error codes on
Linux 2.4 and 2.6. This patch adds compat_pci_register_driver()
to deal with this incompatibility and updates all drivers using it.
Signed-off-by: Wolfang Grandegger <[EMAIL PROTECTED]>
Index: rtnet/drivers/rt_eepro100.c
===
--- rtnet.orig/drivers/rt_eepro100.c
+++ rtnet/drivers/rt_eepro100.c
@@ -1999,13 +1999,7 @@ static int __init eepro100_init_module(v
debug = speedo_debug; /* touch debug variable */
#endif /* RTNET_DRV_EEPRO100_DBG */
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0)
-if (pci_register_driver(&eepro100_driver) <= 0)
-return -EINVAL;
-return 0;
-#else
-return pci_register_driver(&eepro100_driver);
-#endif
+return compat_pci_register_driver(&eepro100_driver);
}
static void __exit eepro100_cleanup_module(void)
Index: rtnet/stack/include/rtnet_port.h
===
--- rtnet.orig/stack/include/rtnet_port.h
+++ rtnet/stack/include/rtnet_port.h
@@ -32,6 +32,16 @@
#include
+#ifndef compat_pci_register_driver
+# if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0)
+# define compat_pci_register_driver(drv) \
+(pci_register_driver(drv) <= 0 ? -EINVAL : 0)
+# else
+# define compat_pci_register_driver(drv) \
+pci_register_driver(drv)
+# endif
+#endif
+
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0)
# define pci_dma_sync_single_for_device pci_dma_sync_single
# define pci_dma_sync_single_for_cpupci_dma_sync_single
Index: rtnet/drivers/rt_8139too.c
===
--- rtnet.orig/drivers/rt_8139too.c
+++ rtnet/drivers/rt_8139too.c
@@ -1861,7 +1861,7 @@ static int __init rtl8139_init_module (v
printk (KERN_INFO RTL8139_DRIVER_NAME "\n");
#endif
-return pci_register_driver (&rtl8139_pci_driver);
+return compat_pci_register_driver (&rtl8139_pci_driver);
}
Index: rtnet/drivers/rt_natsemi.c
===
--- rtnet.orig/drivers/rt_natsemi.c
+++ rtnet/drivers/rt_natsemi.c
@@ -2865,7 +2865,7 @@ static int __init natsemi_init_mod (void
rtdm_printk(version);
#endif
-return pci_register_driver (&natsemi_driver);
+return compat_pci_register_driver (&natsemi_driver);
}
static void __exit natsemi_exit_mod (void)
Index: rtnet/drivers/rt_pcnet32.c
===
--- rtnet.orig/drivers/rt_pcnet32.c
+++ rtnet/drivers/rt_pcnet32.c
@@ -1810,7 +1810,7 @@ static int __init pcnet32_init_module(vo
tx_start = tx_start_pt;
/* find the PCI devices */
-if (!pci_register_driver(&pcnet32_driver))
+if (!compat_pci_register_driver(&pcnet32_driver))
pcnet32_have_pci = 1;
/* should we find any remaining VLbus devices ? */
Index: rtnet/drivers/rt_via-rhine.c
===
--- rtnet.orig/drivers/rt_via-rhine.c
+++ rtnet/drivers/rt_via-rhine.c
@@ -2037,7 +2037,7 @@ static int __init via_rhine_init (void)
#ifdef MODULE
printk(version);
#endif
-return pci_register_driver (&via_rhine_driver);
+return compat_pci_register_driver (&via_rhine_driver);
}
Index: rtnet/drivers/e1000/e1000_main.c
===
--- rtnet.orig/drivers/e1000/e1000_main.c
+++ rtnet/drivers/e1000/e1000_main.c
@@ -277,7 +277,7 @@ e1000_init_module(void)
printk(KERN_INFO "%s\n", e1000_copyright);
-ret = pci_register_driver(&e1000_driver);
+ret = compat_pci_register_driver(&e1000_driver);
return ret;
}
Index: rtnet/drivers/experimental/rt2500/rt_rt2500pci.c
===
--- rtnet.orig/drivers/experimental/rt2500/rt_rt2500pci.c
+++ rtnet/drivers/experimental/rt2500/rt_rt2500pci.c
@@ -1239,7 +1239,7 @@ struct pci_driver rt2x00_pci_driver =
static int __init rt2x00_pci_init(void) {
rtdm_printk(KERN_INFO "Loading module: %s\n", version);
-return pci_register_driver(&rt2x00_pci_driver);
+return compat_pci_register_driver(&rt2x00_pci_driver);
}
static void __exit rt2x00_pci_exit(void) {
Index: rtnet/drivers/experimental/rt_3c59x.c
===
--- rtnet.orig/drivers/experimental/rt_3c59x.c
+++ rtnet/drivers/experimental/rt_3c59x.c
@@ -3358,7 +3358,7 @@ static int __init vortex_init (void)
{
int pci_rc;
-pci_rc = pci_register_driver(&vortex_driver);
+pci_rc = compat_pci_register_driver(&vortex_driver);
if (pci_rc == 0)
vortex_have_pci = 1;
Index: rtnet/drivers/experimental/rt_r8169.c
===
--- rtnet.orig/drivers/experimental/rt_r8169.c
+++ rtnet/drivers/experimental/rt_r
Re: [RTnet-users] Trouble Starting RTnet with a Intel 82551
Jan Kiszka wrote: > Wolfgang Grandegger wrote: >> Thomas Häberle wrote: >>>> Does the attached patch help? >>> Yes, it does! RTnet is working now. >>> THANKS A LOT! >>> Did I miss the patch somewhere or is it from an non-public area? >> It is from my not yet published quilt stack of patches for RTnet under >> Linux 2.4.25 on the MPC5200. > > Patch applied, looking forward to the rest. Well, I did not expect that you accept such a hack ;-). A proper fix using "compat_pci_register" for all drivers using it will follow. Wolfgang. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Trouble Starting RTnet with a Intel 82551
Thomas Häberle wrote: >> Does the attached patch help? > Yes, it does! RTnet is working now. > THANKS A LOT! > Did I miss the patch somewhere or is it from an non-public area? It is from my not yet published quilt stack of patches for RTnet under Linux 2.4.25 on the MPC5200. Wolfgang. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Trouble Starting RTnet with a Intel 82551
Thomas Häberle wrote: > Hello! > > I am using a Xenomai 2.3.5 patched 2.4.25 Denx Kernel with the latest > RTnet trunk on an MPC5200S. > When I start RTnet on the PCI-Ethernet-Device I get: > > >>> > *** RTnet 0.9.10 - built on Apr 8 2008 10:43:09 *** > > RTnet: initialising real-time networking > PCI: Enabling device 00:18.0 (0006 -> 0007) > RTnet: registered rteth0 > /root/xenomai/modules/rt_eepro100.o: init_module: Device or resource busy > <<< > > An following "rtifconfig -a" shows: > >>> > rteth0Medium: Ethernet Hardware address: 00:1B:21:18:54:31 > BROADCAST MTU: 1500 > <<< > > When I configure the card manually: > >>> > rtifconfig rteth0 up 10.0.0.1 > <<< > I get a nice little Kernel oops. As far as I could traced it, I figured > that something with RTnet trying to initialize the device goes wrong. > > The PCI-Ethernet-Card uses an Intel 82551 which is not explicitly named > in "rt_eepro100.c". > Does this mean I can't use the card with RTnet (without adapting the > driver)? Does the attached patch help? Wolfgang. Index: rtnet/drivers/rt_eepro100.c === --- rtnet.orig/drivers/rt_eepro100.c +++ rtnet/drivers/rt_eepro100.c @@ -1999,7 +1999,13 @@ static int __init eepro100_init_module(v debug = speedo_debug; /* touch debug variable */ #endif /* RTNET_DRV_EEPRO100_DBG */ +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0) + if (pci_register_driver(&eepro100_driver) <= 0) + return -EINVAL; + return 0; +#else return pci_register_driver(&eepro100_driver); +#endif } static void __exit eepro100_cleanup_module(void) - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] [Xenomai-help] Current state of RTDM-native?
M. Koehrer wrote: > Hello Wolfgang, > >> I do not know of any activities, but it should not be a big effort to >> get RTnet ported over RTDM-native. As I see it, mainly the build system >> of RTnet needs adaption. >> > thanks for your response. That sounds very good. > I can remember, that a long while ago, the interrupt handling was not > realized yet with rtdm-native > which is necessary to get rtnet up and running. > Is this implemented now? I'm not sure what you mean. RTDM-native has been tested with RT-Socket-CAN, which uses interrupts, of course. While reading my old README http://svn.gna.org/viewcvs/xenomai/branches/rtdm-native/README.rtdm-native?rev=2386&view=auto I now remember some more quirks, especially with tasks termination, which might be problematic with RTnet. Maybe a RTDM port over Xenomai-Solo would be more straight forward, but that's another project. Wolfgang. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] [Xenomai-help] Current state of RTDM-native?
M. Koehrer wrote: > Hi everybody, > > by reading the homepage of http://www.osadl.org I was (again) led to the > RTDM-native project which > has as target to provide an RTDM port for standard Linux (using the RT > Preempt Patch). > Looking at the GNA page http://svn.gna.org/svn/xenomai/branches/rtdm-native > it seems to be fairly quiet... > My long time "wish" is to have a real time standard linux with a real time > capable UDP networking implementation. > For the tasks and the required latency, the RT preempt patch seems to be fine > for our application, > however there is currently no way to get a realtime network system running. > Thus, rtnet via RTDM via RT preempt patch seems to be perfect for our needs... > > Does anybody knows of some activities on rtdm-native? I do not know of any activities, but it should not be a big effort to get RTnet ported over RTDM-native. As I see it, mainly the build system of RTnet needs adaption. Wolfgang. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] porting fs_enet driver on MPC85xx
Hi Julien, please don't drop the CC to the RTnet-users mailing list. LEBRETON, Julien wrote: > > Hello wolfgang, > > >> Hi Julien, >> LEBRETON, Julien wrote: >>> Hello, >>> >>> I want to port a driver 10/100 Mb to RTnet. I'm working on a platform >>> MPC85xx and I use this configuration : >>> linux kernel 2.6.18 > >> Any chance to switch to a more recent version of Linux based on the >> arch/powerpc tree? This would allow for a more generic RTnet driver. As >> you might know, arch/ppc is almost dead and will be removed from the >> kernel later this year. > > > It's not plan actually. I'm a trainee and my person in charge wants to work > on kernel 2.6.18 and 2.6.14 (for another BSP). You are using MPC8560ADS boards? IIRC, these are already supported by the arch/powerpc tree which should make migration a piece of cake. >>> xenomai 2.3.4 >>> rtnet 0.9.8 >>> >>> I want to know which driver should I port. I began with the source >>> fs_enet-main.c in directory linux/drivers/net/fs_enet, is it good? >>> I see some others drivers in arch/ppc/8260_io or 8xx_io, should I port one >>> of these? >> You should port the driver Linux uses for your ethernet interface. The >> MPC 85xx has Gianfar and, if a CPM is present, also FCC ethernet >> interfaces, IIRC. >> > > perhaps you'll found my next question a little silly, but I'm not sure about > FCC ethernet interface. Which source files must I port? fs_enet-main.c, > mac-fcc.c mii-bitbang.c in the directory drivers/fs_enet ? > > I'm trying already to port fs_enet-main.c using README.drvporting.. but if > it's not the good source file I'm porting, it's silly to continu in this way. I don't know. Check which one get's compiled (check for the *.o) file or search for the corresponding boot log message. Do you want to use the FCC or der Gigabit-Ethernet-Interface of the MPC85xx? >>> I see also three drivers (rt_mpc82xx_fcc_enet.c, rt_mpc8xx_enet.c, >>> rt_mpc8xx_fec.c) in drivers' directory of RTnet tree. Can I use one on >>> these on my >board? >>> Is there lot of differences between driver for mpc82xx and mpc85xx? >> These driver are for Linux 2.4 and it does make little sense to use them. >> >>> Can you give me some information about my task? is it hard or easy to port >>> this driver? >> It's not that hard and there is also a README on driver porting: >> >> http://www.rts.uni-hannover.de/rtnet/lxr/source/Documentation/README.drvporting >> >> Wolfgang. > > Julien > > The information in this e-mail is confidential. The contents may not be > disclosed or used by anyone other then the addressee. Access to this e-mail > by anyone else is unauthorised. > If you are not the intended recipient, please notify Airbus immediately and > delete this e-mail. > Airbus cannot accept any responsibility for the accuracy or completeness of > this e-mail as it has been sent over public networks. If you have any > concerns over the content of this message or its Accuracy or Integrity, > please contact Airbus immediately. > All outgoing e-mails from Airbus are checked using regularly updated virus > scanning software but you should take whatever measures you deem to be > appropriate to ensure that this message and any attachments are virus free. And please don't send confidential e-mails to public mailing lists! Wolfgang - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] porting fs_enet driver on MPC85xx
Hi Julien, LEBRETON, Julien wrote: > Hello, > > I want to port a driver 10/100 Mb to RTnet. I'm working on a platform MPC85xx > and I use this configuration : > linux kernel 2.6.18 Any chance to switch to a more recent version of Linux based on the arch/powerpc tree? This would allow for a more generic RTnet driver. As you might know, arch/ppc is almost dead and will be removed from the kernel later this year. > xenomai 2.3.4 > rtnet 0.9.8 > > I want to know which driver should I port. I began with the source > fs_enet-main.c in directory linux/drivers/net/fs_enet, is it good? > I see some others drivers in arch/ppc/8260_io or 8xx_io, should I port one of > these? You should port the driver Linux uses for your ethernet interface. The MPC 85xx has Gianfar and, if a CPM is present, also FCC ethernet interfaces, IIRC. > I see also three drivers (rt_mpc82xx_fcc_enet.c, rt_mpc8xx_enet.c, > rt_mpc8xx_fec.c) in drivers' directory of RTnet tree. Can I use one on these > on my board? > Is there lot of differences between driver for mpc82xx and mpc85xx? These driver are for Linux 2.4 and it does make little sense to use them. > Can you give me some information about my task? is it hard or easy to port > this driver? It's not that hard and there is also a README on driver porting: http://www.rts.uni-hannover.de/rtnet/lxr/source/Documentation/README.drvporting Wolfgang. -- Dr. Wolfgang Grandegger, Phone: (+49)-8142-6698930, Email: [EMAIL PROTECTED] _ DENX Software Engineering GmbH,CEO: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] 2.6.24-rc8-rt1: Strange latencies on mpc5200 powerpc
Wolfgang Grandegger wrote: > Hi Luis, > > I re-added CC to the mailing list. Well, I put the wrong mailing list on CC. It was meant for the Linux--rt ML. Please forget this mail, please. Sorry for the noise. Wolfgang. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] 2.6.24-rc8-rt1: Strange latencies on mpc5200 powerpc
Hi Luis, I re-added CC to the mailing list. Luis Claudio R. Goncalves wrote: > On Thu, Jan 24, 2008 at 11:53:56AM +0100, Wolfgang Grandegger wrote: > | Wolfgang Grandegger wrote: > ... > I deleted lots of lines just to make it easy to see my question: > ... > | OK, here is the full report. > ... > | bash-3.00# ./cyclictest -n -p80 -t1 -i1000 > | 2.91 4.81 13.72 1/50 23887 > | > | T: 0 ( 976) P:80 I:1000 C:1634520 Min: 15 Act: 45 Avg: 68 Max: 138 > > ... > > | bash-3.00# ./cyclictest -n -p80 -i1000 > | 52.31 96.08 61.61 2/51 9129 > | > | T: 0 ( 976) P:80 I:1000 C: 795180 Min: 14 Act: 75 Avg: 69 Max: 134 > > Are the loadavg values right? If so, the results were obtained in very > different circunstances. In the first case, load was around 2.91... in the > second one, 52.31. This is also true for the other tests below. > > Please compare /proc/loadavg and /proc/loadavgrt (a simple cat do the > trick). If loadavgrt is reporting bogus values, let us know. It was fixed a > looong time ago, but I never tested that in a ppc. Here is the output: bash-3.00# cat /proc/loadavg; cat /proc/loadavgrt 3.12 3.13 4.57 3/46 5541 75.35 73.84 72.94 0/46 5543 There is no constant load as I run: "while ./hackbench 10; do ./calibrator 400 32M cali; sleep 30; done" in the second terminal window. What you see is the load when I interrupted the test manually. Wolfgang. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] rt_mpc52xx_fec in kernel 2.6
Jan Kiszka wrote: > Wolfgang Grandegger wrote: >> Hello, >> >> Siniša Denić wrote: >>> Hello Jan, we met each other on Real Time Conference in Linz, a few days >>> ago. >>> We talked about, rt_8139too driver and also I told you about my idea to >>> wrote some kind of rt_mpc52xx_fec for 2.6 kernel. >>> For now I have two questions: >>> 1. does the MPC5200 Bestcomm DMA engine must be handled as rtdm device >>> in order to serve data transfer between rt_mpc52xx_fec driver and >>> memory, or I can use Bestcomm API as is? >> I believe you can use it as-is. Spin_lock/spin_unlock functions are used >> for SDMA task creation, but they get called at initialization time in >> secondary mode. I need to check more carefully, though. > > CONFIG_IPIPE_DEBUG_CONTEXT can help to find remaining incompatible > spinlock usages during runtime. OK >>> 2. what I have to do to put built-in fec driver "out of the kernel" and >>> get it as module.I think that problem is because BestcommDMA is system >>> device and must be built-in, hence(I suppose) fec is also work only as >>> built-in. >> You need to port the FEC driver of a recent version of 2.6 to RTnet >> using arch/powerpc. >> >>> This is already done for 2.4 kernel with kernel-patch which alows >>> rt_mpc52xx_fec as module, but I think for 2.6 there is difference in >>> patch and I don't know how to get it? >> The RTnet driver for the FEC om MPC5200 currently available for 2.4 is >> not usable for 2.6 and it makes little sense to port it. >> >>> I hope you understand me.If these questions are rather for Wolfgang I'll >>> be pleased to meet him here. >> You want to use RTnet on the MPC5200 with Linux 2.6, right? >> Unfortunately, that FEC driver is still missing in Linux 2.6.23. There >> are patches around and hopefully they will get included already in >> 2.6.24. The corresponding RTnet driver should then be derived from that >> Linux driver. > > One further question we discussed in Linz was if a directly attached FEC > device might provide faster roundtrip times than a PCI-attached NIC with > that controller. Wolfgang, what would you say? I believe that a "good" PCI NIC is a bit faster. The bestcomm task may introduce some overhead and latencies because the FEC is not the only user. But I do not have real numbers to show. > In any case, the so far used rt_8139 is not an optimal choice even if > ignoring the PCI path for a while. The reason I just realised again: > This hardware requires incoming and outgoing packets to be _copied_ > between the stack data structures and special DMA regions of this card. > So, maybe switching to another PCI adapter would already provide better > numbers! Such a comparison would be interesting, indeed. I have the gut feeling that most of the latencies are due to the CPU power of the MPC5200 and the memory bandwidth of the board. Wolfgang- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] rt_mpc52xx_fec in kernel 2.6
Hello, Siniša Denić wrote: > Hello Jan, we met each other on Real Time Conference in Linz, a few days > ago. > We talked about, rt_8139too driver and also I told you about my idea to > wrote some kind of rt_mpc52xx_fec for 2.6 kernel. > For now I have two questions: > 1. does the MPC5200 Bestcomm DMA engine must be handled as rtdm device > in order to serve data transfer between rt_mpc52xx_fec driver and > memory, or I can use Bestcomm API as is? I believe you can use it as-is. Spin_lock/spin_unlock functions are used for SDMA task creation, but they get called at initialization time in secondary mode. I need to check more carefully, though. > 2. what I have to do to put built-in fec driver "out of the kernel" and > get it as module.I think that problem is because BestcommDMA is system > device and must be built-in, hence(I suppose) fec is also work only as > built-in. You need to port the FEC driver of a recent version of 2.6 to RTnet using arch/powerpc. > This is already done for 2.4 kernel with kernel-patch which alows > rt_mpc52xx_fec as module, but I think for 2.6 there is difference in > patch and I don't know how to get it? The RTnet driver for the FEC om MPC5200 currently available for 2.4 is not usable for 2.6 and it makes little sense to port it. > I hope you understand me.If these questions are rather for Wolfgang I'll > be pleased to meet him here. You want to use RTnet on the MPC5200 with Linux 2.6, right? Unfortunately, that FEC driver is still missing in Linux 2.6.23. There are patches around and hopefully they will get included already in 2.6.24. The corresponding RTnet driver should then be derived from that Linux driver. Wolfgang. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] (no subject)
Siniša Denić wrote: > Hallo,everyone > I have one question. > Is mpc5200_fec supported by rtnet in kernel 2.6 > It is stayed in menuconfig but I have not got it compiled. > First, there is no header file in latest rtnet.tar.bz > I've got one from net but problem continue. > Is this motorola driver still supported or not, or I have bad paths. There is an experimental RTNET driver for the FEC on the MPC5200 for Linux 2.4. Unfortunately, this driver in not suitable for Linux 2.6. The Linux FEC driver needs to be ported to RTnet. Wolfgang. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] [Xenomai-help] [Ethercatmaster-users] EML conflict with RTCAN? low_level_input framebuilding failed.
Roland Tollenaar wrote: > Hi, > > Some more interesting findings (no i-pipe trace yet though). > >> Hmm, this doesn't convince me yet. Such skews during startup may as well >> be triggered by unusual load during runtime (non-RT activity or new RT >> components). Did you put your system under adequate non-RT load as well >> while measuring the outputs? > Running latencytest with my application shows an average latency of > about 40 and a max of 200ns. This was rather shocking so I turned off > rtcan in my application. Now the max latecy is 60ns. Turn off EML and > turn on rtcan, max latecy is 230ns. How is that for strange? But since I > can see the scope output bobbing with 200ns during the latency test, I > can also see that if I run my application without the latency test the > huge max latency disappears entirely. Maybe it is time for the trace but > then again I am still using CAN over the parallel port so will see what > it does on a machine with a PCI CAN adaptor first. Because I think I > know what happens: Due to the external loading the CAN recv interrupt > triggers the Rx ISR briefly before the 1ms task period ends. Due to the > priority of the ISR (huge debate over this) and its atomicness (if I > remember correctly) the reading out of the slow hardware delays the > start of the new task period. > > Just thought it was interesting to mention. Btw when the latency appears > there are no overflow messages or anything like that which support the > theory I have about the cause. > > Btw2 the 200ns latency spikes do not cause the scope to loose lock on > the saw-tooth so whatever causes that problem is of a different nature > still. s/ns/us/ ? Wolfgang. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Porting mpc8260 fcc_enet.c
Jan Kiszka wrote: > Juha Niskanen wrote: >> 2007/6/3, Wolfgang Grandegger <[EMAIL PROTECTED]>: >>> Juha Niskanen wrote: >>>> Hi Jan, >>>> >>> [...] >>> >>>>>> I can allready start the rtnet and get a lot of error messages. >>>>>> >>>>>> rteth0: tx queue full!. >>>>>> rteth0: tx queue full!. >>>>>> >>>>> Transmission is not working, maybe its IRQ line setup is broken. Thus >>>> Any idea of good place to start debugging? >>> Do you get interrupts? Check /proc/xenomai/irq! I briefly browsed the >>> code: a RTDM interrupt handler should return RTDM_IRQ_HANDLED and _not_ >>> IRQ_HANDLED. >> I get interrupts only for a virtual irq line 259 every time I ping. >> >> ~ $ cat /proc/xenomai/irq >> IRQ CPU0 >> 256: 57723 [virtual] >> 259: 2 [virtual] >> >> ~ $ modprobe rt_mpc8260_fcc_enet >> RTnet: registered rteth0 >> rteth0: FCC ENET Version 0.3, 00:06:70:81:04:29 >> >> ~ $ cat /proc/xenomai/irq >> IRQ CPU0 >> 32: 1 rt_mpc8260_fcc_enet >> 256: 75629 [virtual] >> 259: 2 [virtual] >> >> ... >> ~ $ rtping 10.0.0.4 >> >> ~ $ cat /proc/xenomai/irq >> IRQ CPU0 >> 32: 1 rt_mpc8260_fcc_enet >> 256: 94630 [virtual] >> 259: 3 [virtual] >> >> ~ $ rtping 10.0.0.4 >> >> ~ $ cat /proc/xenomai/irq >> IRQ CPU0 >> 32: 1 rt_mpc8260_fcc_enet >> 256: 94630 [virtual] >> 259: 4 [virtual] >> >> . > > Looks like an IRQ re-enabling problem. I recall Philippe recently fixing > such a thing... Here it is [1]. Does your ISR now return RTDM_IRQ_HANDLED instead of IRQ_HANDLED? Wolfgang. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Porting mpc8260 fcc_enet.c
Juha Niskanen wrote: > 2007/6/4, Wolfgang Grandegger <[EMAIL PROTECTED]>: >> Juha Niskanen wrote: >>> 2007/6/3, Wolfgang Grandegger <[EMAIL PROTECTED]>: >>>> Wolfgang Grandegger wrote: >>>>> Jan Kiszka wrote: >>>>>> Juha Niskanen wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I am porting mpc8260 fcc_enet.c from 2.6.18 to rtnet, >>>>> I recommend using the a more recent version of Linux with the >>>>> arch/powerpc tree. The arch/ppc tree is not maintained any more. Any >>>>> chance to switch? >>>> I just had a look into 2.6.21. There is now a generic Freescale ethernet >>>> driver in drivers/net/fs_enet supporting SCC, FEC and FCC. It _really_ >>>> makes sense to port this driver to RTnet. >>> I allready try it, but can't get it working even without rt-patches. >>> I didn't spend mutch time for it. But it is in plan. >> What did you try? Backporting this driver to 2.6.18? This will not be a >> trivial task, of course. > > It is already in 2.6.18, but I tried also 2.6.21. Ah, you are right. In arch/ppc of 2.6.18 it's used by 85xx and in 2.6.21 by 8272 as well. Likely adaption to 8260 will take some effort, but that's the right way to go. Getting RTnet to work with the old FCC driver is a good exercise, at least. Wolfgang. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Porting mpc8260 fcc_enet.c
Juha Niskanen wrote: > 2007/6/3, Wolfgang Grandegger <[EMAIL PROTECTED]>: >> Wolfgang Grandegger wrote: >> > Jan Kiszka wrote: >> >> Juha Niskanen wrote: >> >>> Hi, >> >>> >> >>> I am porting mpc8260 fcc_enet.c from 2.6.18 to rtnet, >> > >> > I recommend using the a more recent version of Linux with the >> > arch/powerpc tree. The arch/ppc tree is not maintained any more. Any >> > chance to switch? >> >> I just had a look into 2.6.21. There is now a generic Freescale ethernet >> driver in drivers/net/fs_enet supporting SCC, FEC and FCC. It _really_ >> makes sense to port this driver to RTnet. > I allready try it, but can't get it working even without rt-patches. > I didn't spend mutch time for it. But it is in plan. What did you try? Backporting this driver to 2.6.18? This will not be a trivial task, of course. Wolfgang. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Porting mpc8260 fcc_enet.c
Juha Niskanen wrote: > Hi Jan, > [...] >> > I can allready start the rtnet and get a lot of error messages. >> > >> > rteth0: tx queue full!. >> > rteth0: tx queue full!. >> > >> >> Transmission is not working, maybe its IRQ line setup is broken. Thus > > Any idea of good place to start debugging? Do you get interrupts? Check /proc/xenomai/irq! I briefly browsed the code: a RTDM interrupt handler should return RTDM_IRQ_HANDLED and _not_ IRQ_HANDLED. Wolfgang. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Porting mpc8260 fcc_enet.c
Wolfgang Grandegger wrote: > Jan Kiszka wrote: >> Juha Niskanen wrote: >>> Hi, >>> >>> I am porting mpc8260 fcc_enet.c from 2.6.18 to rtnet, > > I recommend using the a more recent version of Linux with the > arch/powerpc tree. The arch/ppc tree is not maintained any more. Any > chance to switch? I just had a look into 2.6.21. There is now a generic Freescale ethernet driver in drivers/net/fs_enet supporting SCC, FEC and FCC. It _really_ makes sense to port this driver to RTnet. Wolfgang. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Porting mpc8260 fcc_enet.c
Jan Kiszka wrote:
> Juha Niskanen wrote:
>> Hi Jan,
>>
>> I forget mention my defines I add beginin of file:
>> /* My configs */
>> #define CONFIG_EA8248
>> #define CONFIG_FCC1_ENET 1
>> #define CONFIG_FCC_LXT971 1
>> /* #define CONFIG_RTAI_RTNET_USE_MDIO 1 */
>> /* #define PHY_INTERRUPT 1 */
>>
>> If I define CONFIG_RTAI_RTNET_USE_MDIO
>> I get:
>> ~ $ modprobe rtnet
>>
>> *** RTnet 0.9.9 - built on Jun 1 2007 12:45:42 ***
>>
>> RTnet: initialising real-time networking
>> ~ $ modprobe rtipv4
>> ~ $ modprobe rtpacket
>> ~ $ modprobe rt_loopback
>> initializing loopback...
>> RTnet: registered rtlo
>> ~ $ modprobe rt_mpc8260_fcc_enet
>> RTnet: registered rteth0
>> rteth0: FCC ENET Version 0.3, 00:06:70:81:04:29
>> mii_reg: 600e78e2
>> rteth0: Phy @ 0x0, type LXT971 (0x001378e2)
>> ~ $
>> ~ $ rtifconfig -a
>> rtlo Medium: Local Loopback
>> LOOPBACK MTU: 1500
>>
>> rteth0Medium: Ethernet Hardware address: 00:06:70:81:04:29
>> BROADCAST MTU: 1500
>>
>> ~ $
>> ~ $ rtifconfig rteth0 up
>> Oops: kernel access of bad area, sig: 11 [#1]
>> NIP: C504FB24 LR: C504F858 CTR:
>> REGS: c0517cd0 TRAP: 0300 Not tainted (2.6.18)
>> MSR: 9032 CR: 44004244 XER:
>> DAR: 0108, DSISR: 2000
>> TASK = c05296d0[763] 'rtifconfig' THREAD: c0516000
>> GPR00: 0001 C0517D80 C05296D0 501201E1 C0218008 C504FB04 C0517E74
>>
>> GPR08: F001 F001 C0006300 84004228 10019594 03FFE000
>>
>> GPR16: 0001 03FF8304 7FABEA30 C0218008
>> C504FB04
>> GPR24: C020 C020 F001 0084 501201E1
>> C5050AB0
>> Call Trace:
>> [C0517D80] [C046A000] (unreliable)
>> [C0517DC0] [C504F8B4]
>> [C0517DE0] [C50500B4]
>> [C0517E00] [C505BC9C]
>> [C0517E20] [C505C17C]
>> [C0517EA0] [C505BF74]
>> [C0517EE0] [C0095CD8]
>> [C0517EF0] [C00960AC]
>> [C0517F10] [C0096110]
>> [C0517F40] [C0004200]
>> Instruction dump:
>> 419e0008 6002 90090108 4e800020 5460c7fe 81240138 2c80 70600020
>> 5460d7fe 2f80 5460cffe 2f00 <80090108> 5400072e 41820008 6010
>> Segmentation fault
>>
>
> You should switch on symbol names in your kernel: CONFIG_KALLSYMS. Dunno
> if there is more for PPC, maybe check the Kernel Hacking section.
That should be enough, IIRC.
>
>>
>> 2007/6/1, Jan Kiszka <[EMAIL PROTECTED]>:
>>> Juha Niskanen wrote:
Hi,
I am porting mpc8260 fcc_enet.c from 2.6.18 to rtnet,
>>> Please help me first: Is this a rewrite of the existing driver or an
>>> update/extension/2.6-compatibility patch? In the latter case, sending
>>> your changes in form of a real patch would be preferred for reviews
>>> ("svn diff" may help if you work with RTnet svn).
>> Like rewriting using
>> http://www.rts.uni-hannover.de/rtnet/lxr/source/Documentation/README.drvporting
>>
>> and orginal driver.
>>
>> I attach latest svn diff.
>
> Ok. Lots of cosmetic changes due to the kernel version jump
> unfortunately. Makes it harder to compare. BTW, Wolfgang, what is the
> status of the current RTnet driver? Working under 2.4?
The FCC driver for the MPC82xx should work with 2.4. For 2.6, the right
thing is to port the new FCC CMP2 driver to RTnet. IIRC, the driver also
works other processors as well (with compatible CPM) :-).
Wolfgang.
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Porting mpc8260 fcc_enet.c
Jan Kiszka wrote:
> Juha Niskanen wrote:
>> Hi,
>>
>> I am porting mpc8260 fcc_enet.c from 2.6.18 to rtnet,
I recommend using the a more recent version of Linux with the
arch/powerpc tree. The arch/ppc tree is not maintained any more. Any
chance to switch?
> Please help me first: Is this a rewrite of the existing driver or an
> update/extension/2.6-compatibility patch? In the latter case, sending
> your changes in form of a real patch would be preferred for reviews
> ("svn diff" may help if you work with RTnet svn).
>
>> First I get error when loading module:
>> rt_mpc8260_fcc_enet: Unknown symbol cpmp
>> rt_mpc8260_fcc_enet: Unknown symbol __res
>>
>> I exported symbols:
>> arch/ppc/syslib/m8260_setup.c
>> EXPORT_SYMBOL(__res);
>>
>> arch/ppc/syslib/cpm2_common.c
>> EXPORT_SYMBOL(cpmp);
>>
>
> Wolfgang, is this due to the original Linux driver not being a module?
Yes.
>
>> I can allready start the rtnet and get a lot of error messages.
>>
>> rteth0: tx queue full!.
>> rteth0: tx queue full!.
>>
>
> Transmission is not working, maybe its IRQ line setup is broken. Thus
> you get a full queue after a while - a short while if RTmac/TDMA is running.
>
> What is your precise setup? I assume it's latest RTnet, but which I-pipe
> patch, which Xenomai version? Just to have a common ground for the
> discussion.
>
>> The driver is attached.
>> If some one find reason for that or can get it working
>>
>
> I would prefer to leave first detail comments up to Wolfgang... :->
OK, I will have a look a.s.a.p-
Wolfgang.
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] building rtnet
roland Tollenaar wrote: >> A collection of modules, tools/scripts, config files, and headers. >> Provide some installation directory during configure, run "make install" >> as well, and watch what gets filled into it. > Thanks found it. > > The compilation works now, or so it seems. There are some warnings but > I am not sure its something critical yet. I have to set the rtconf And why did it not work with your original configuration? Try to do the same setup with your fresh /usr/src/linux-2.6.16 kernel. Wolfgang. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] building rtnet
roland Tollenaar wrote: > Hi, > > Thanks for all the flak. > >> I would say now Roland is trying to build RTnet against some split-up >> kernel tree where sources and binaries sit in different directories. >> Roland, can you confirm this? That should not work with RTnet's build >> system (no one felt the need to support this yet), while Xenomai is fine >> as it is built together with the main tree. > > I wish this were the case but I cannot confirm it. I only have 4 > machines running linux and they all seem to have the same structure of > kernel source in /usr/src/linux-version and the binaries under > /lib/ The other distros I run are Suse 8.2, 9.2 and some embedded > variant. I have not tried to patch them with xenomai and rtnet so > cannot tell if they give the same behaviour.I am probably not > familiar enough with linux to understand exactly what is meant by the > split in src and binary and how that should differ from what I have on > my machines. Perhaps there are kernel binaries stored in other places > i do not know of or amongst the kernel src which is not taking place > on this slackware variant of mine. > > I have tried another 2.6.16 kernel src package on this slackware > distribution, exactly the same result. I have done > > make bzimage > make modules > make modules_install > > the latter to sync the modules and the src tree and then tried it. No > luck. I have no evidence that there is anything strange about my > kernel source directory other than that rtnet takes a nose dive on it. > > What binaries is it looking for that do not get generated and put in > the correct place by the above mentioned make process? Also does the > build process of rtnet need any binaries? Search in top kernel makefile for "O=". > Please, I repeat my request. Tell me the exact 2.6.16 kernel src > package to download (to be sure preferably exactly where to down-load > it). I will then use that package and see what it does. You can get offical kernel releases from http://kernel.org. e.g.: ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.16.tar.bz2 > > Correct me if I am wrong: > > If I take a vanilla kernel src and set this up under > /usr/src/linux-2.6.16 subsequently patch this kernel with xenomai and > build it with my current config file. If I then run the rtnet build > process on it, I should come right? > > In fact, after patching the kernel with xenomai do I need to build the > kernel at all? Should not the "correct" kernel src patched with > xenomai be enough to build the rtnet thingy? You need to configure and build the kernel, otherwise some configuration files are missing: - Run the prepare_kernel.sh script to apply the Adeos-iPipe-Patch and link the kernel with the Xenomai sources. - Copy your .config to the kernels root directory. - Run "make menuconfig" and select additional options. Make sure Xenomai is enabled. Or run "make oldconfig" if you are happy with the default configuration. - Build your kernel with "make vmlinux" or "make bzImage". - Then start configuring RTnet. Wolfgang. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] building rtnet
Jan Kiszka wrote: > Wolfgang Grandegger wrote: >> roland Tollenaar wrote: >>> Hi Wolfgang, >>> >>>>... >>>>--with-linux=LINUX real-time extended Linux kernel >>>> >>>> Please try >>>> >>>> $ ./configure --with-linux= >>> Same thing I am afraid. Identical :( >>> >>> checking whether the g++ linker (/usr/i486-slackware-linux/bin/ld) >>> supports shared libraries... yes >>> checking dynamic linker characteristics... GNU/Linux ld.so >>> checking how to hardcode library paths into programs... immediate >>> appending configuration tag "F77" to libtool >>> checking for main in -lncurses... yes >>> checking for RTnet Kconfig file... ./defconfig (default) >>> checking for RT-extension... /usr/src/linux-2.6.16 (kernel 2.6.16 + >>> Xenomai) >>> checking for Xenomai version... 2.3.1 >>> checking for RTDM skin... y >>> checking for RT-FireWire installation... none >>> checking for RT-extension target arch... i386 >>> checking for RTnet target arch... i386 >>> checking for CROSS_COMPILE... none >>> checking for kernel module extension... .ko >>> checking for rtdm/rtdm_driver.h... no >>> configure: error: *** header not found or working, please check >>> RT-extension installation >>> >>> If only there were some hint as to what might be wrong with my kernel >>> src. Even if I have to try another kernel src package -god forbid!- at >>> least I would like to know why. Otherwise I might end up on a classic >>> trial & error adventure and i cannot believe that rtnet is one of >>> those black-art projects. >>> >>> Would it be an idea to take the first point where configure goes off >>> kilter? >>> >>> I have attached my config.log file in the meager hope that someone >>> would care to look at the disaster within. I can see where the first >>> error occurs, something with conftest.c and a header which is missing >>> ac_nonexistent.h but I cannot make out where it is looking or where >>> this file is supposed to be, or even what it makes out part of. >>> >>> I get the feeling that my endeavors of getting rtnet operational with >>> xenomai have been passed a "doomed to fail" judgment by the list. :( > > Well, Roland, you once again picked the non-common approach for your > first setup, so you _have_to_ expect uncommon problems. You said that > building and installing your own clean vanilla+xenomai kernel from > scratch is so much more complicated - do you expect me to seriously > comment on this anymore? We had the same discussion not long ago when > you started to get your feet wet with Xenomai. > >>> If so, and I do want to get this running what is the advice? Start >>> trial and erroring with any and all kernels I can lay my hands on to >>> see if there is one out there that is actually compatible?:) Try a >>> couple of other distros? Anything?.damn. > > Please just do what everyone does _first_, do something that _we_ can > easily reproduce. If that fails we will be quickly at your site because > the effort/result ratio will be far better than now (or order individual > support). _Once_ you have a standard setup working, going the winding > road is still an option and would _far_ better reveal where RTnet or > your steps have a problem. If you go a non-standard path like now, we > depend on _you_ to find the common ground, the differences, and then the > reason for this issue. > >> Help yourself, try finding the problem. The configure actually fails >> when building conftest.c with the command: >> >>make -C /usr/src/linux-2.6.16 ARCH=i386 CROSS_COMPILE= V=1 \ >>M=/usr/src/rtnet-0.9.9 SUBDIRS=/usr/src/rtnet-0.9.9 modules > /dev/nul >> >> Edit the "configure" script and search for "rtdm_driver". Some lines >> below you will find the compile command "$bs_kcompile > /dev/null" two >> times. Remove the redirection "> /dev/null" to see the compile command, >> which might help. > > Agreed. Though I'm afraid the result will just once again tell us > something is missing, and as we cannot reproduce your kernel tree, we > will be not much wiser than before. You are probably right. I was not aware that his Linux/Xenomai installation is that special. Wolfgang. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] building rtnet
roland Tollenaar wrote: > Hi Wolfgang, > >>... >>--with-linux=LINUX real-time extended Linux kernel >> >> Please try >> >> $ ./configure --with-linux= > > Same thing I am afraid. Identical :( > > checking whether the g++ linker (/usr/i486-slackware-linux/bin/ld) > supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > appending configuration tag "F77" to libtool > checking for main in -lncurses... yes > checking for RTnet Kconfig file... ./defconfig (default) > checking for RT-extension... /usr/src/linux-2.6.16 (kernel 2.6.16 + > Xenomai) > checking for Xenomai version... 2.3.1 > checking for RTDM skin... y > checking for RT-FireWire installation... none > checking for RT-extension target arch... i386 > checking for RTnet target arch... i386 > checking for CROSS_COMPILE... none > checking for kernel module extension... .ko > checking for rtdm/rtdm_driver.h... no > configure: error: *** header not found or working, please check > RT-extension installation > > If only there were some hint as to what might be wrong with my kernel > src. Even if I have to try another kernel src package -god forbid!- at > least I would like to know why. Otherwise I might end up on a classic > trial & error adventure and i cannot believe that rtnet is one of > those black-art projects. > > Would it be an idea to take the first point where configure goes off > kilter? > > I have attached my config.log file in the meager hope that someone > would care to look at the disaster within. I can see where the first > error occurs, something with conftest.c and a header which is missing > ac_nonexistent.h but I cannot make out where it is looking or where > this file is supposed to be, or even what it makes out part of. > > I get the feeling that my endeavors of getting rtnet operational with > xenomai have been passed a "doomed to fail" judgment by the list. :( > If so, and I do want to get this running what is the advice? Start > trial and erroring with any and all kernels I can lay my hands on to > see if there is one out there that is actually compatible?:) Try a > couple of other distros? Anything?.damn. Help yourself, try finding the problem. The configure actually fails when building conftest.c with the command: make -C /usr/src/linux-2.6.16 ARCH=i386 CROSS_COMPILE= V=1 \ M=/usr/src/rtnet-0.9.9 SUBDIRS=/usr/src/rtnet-0.9.9 modules > /dev/nul Edit the "configure" script and search for "rtdm_driver". Some lines below you will find the compile command "$bs_kcompile > /dev/null" two times. Remove the redirection "> /dev/null" to see the compile command, which might help. Wolfgang. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] building rtnet
roland Tollenaar wrote: > Hi > >> Could you please show use the complete make output including command >> line. rtdm_driver.h is in Xenomai's installation directory under >> include/rtdm. > > This is the entire operation. I don't change any configure settings > from what I understand there is no need for this. > > [EMAIL PROTECTED]:/usr/src/rtnet-0.9.9# ./configure $ ./configure --help ... --with-linux=LINUX real-time extended Linux kernel Please try $ ./configure --with-linux= Wolfgang. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] building rtnet
roland Tollenaar wrote: > Hi All, >> Could you please show use the complete make output including command >> line. rtdm_driver.h is in Xenomai's installation directory under >> include/rtdm. It gets installed with "make install". > > Aha, this may be the lead. I was not aware that the kernel src > directory gets changed on compiling the kernel. > > To clarify, I have to compile the kernel, full-pull? I.e. > > from /usr/src/linux > > run > > Make menuconfig (or load existing config file) > make modules > make install? > > only then will the kernel src be ripe for rtnet? No, I was wrong, forget it, sorry for the confusion. rtdm_driver.h should be in the patched kernael tree under "include/xenomai/rtdm/". What does "ls -l /include/xenomai/rtdm/rtdm_driver.h" say? Please tell us step by step how you installed Xenomai and RTnet. Wolfgang. [snip] - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] building rtnet
roland Tollenaar wrote: > Hi, > >> Maybe you should give the error messages for further help? > > Absolutely. Here are the last few lines before configure bails out. > > appending configuration tag "F77" to libtool > checking for main in -lncurses... yes > checking for RTnet Kconfig file... ./defconfig (default) > checking for RT-extension... /lib/modules/2.6.16/build (kernel 2.6.16 + > Xenomai) > checking for Xenomai version... 2.3.1 > checking for RTDM skin... y > checking for RT-FireWire installation... none > checking for RT-extension target arch... i386 > checking for RTnet target arch... i386 > checking for CROSS_COMPILE... none > checking for kernel module extension... .ko > checking for rtdm/rtdm_driver.h... no > configure: error: *** header not found or working, please check > RT-extension installation. > > It tells me to check the rt extension installation which in my case is > xenomai, which compiles and runs perfectly. rtdm is in the kernel > source exactly where the xenomai patch puts it and rtnet -see above- > knows that, and what version, xenomai is being used. Could you please show use the complete make output including command line. rtdm_driver.h is in Xenomai's installation directory under include/rtdm. It gets installed with "make install". Wolfgang. > Kind regards, > > Roland > > >> >> Am Dienstag, 8. Mai 2007 19:40 schrieb Roland Tollenaar: >>> Hi, >>> >>> I am having problems building the rtnet package. For some reason my >>> kernel src package does not seem compatible (2.6.16 and relatively >>> standard AFAIK) to the configure script of rtnet. >>> >>> Trying to figure out what is going on in the configure script is no fun >>> whatsoever. I am also pretty sure that unless there are more precise >>> specification as to what the kernel src package must comply to in order >>> for the beast to behave its of little use attempting to use rtnet. >>> Because AFAIK and can see in the documentation there should be no problems. >>> >>> My current problem is that the configure script cannot find the >>> rtdm_driver.h header in the kernel sources (but it is there, the >>> configure script only seems to be looking in the wrong place). >>> >>> Am I supposed to feed the configure script some path as to where it must >>> look? Does anyone know where it is looking so that maybe I can copy the >>> rtdm_driver.h file to where it is looking? >>> >>> Or is there any manner to circumvent this configure script by simply >>> getting the pre-compiled rtnet module somewhere? >>> >>> This is very frustrating. >>> >>> kind regards, >>> >>> Roland Tollenaar. >> - >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> ___ >> RTnet-users mailing list >> RTnet-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/rtnet-users >> > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > RTnet-users mailing list > RTnet-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/rtnet-users > > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] MPC860T FEC: strange behavior
Hallo, some more comments to this Email... Javi Roman wrote: > On 1/10/07, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: >> Javi Roman wrote: >> > On 1/10/07, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: >> >> Jan Kiszka wrote: >> >> > Javi Roman wrote: >> >> >> ... >> >> >> I think the driver requires PHY management (MDIO) to get my >> ethernet >> >> >> working, and from the brand new rtnet-0.9.7 (rt_mpc8xx_fec.c): >> >> >> >> >> >> #ifdef CONFIG_RTAI_RTNET_USE_MDIO >> >> >> #error "MDIO for PHY configuration is not yet supported!" >> >> >> #endif >> >> > >> >> > OK, that's something Wolfgang has to comment on. >> >> >> >> As the message says, MDIO is not supported. >> >> >> >> > >> >> >> All MDIO stuff is under this macro. >> >> >> I don't know why is not supported, nevertheless I'm going to >> work with >> >> >> this issue. >> >> > >> >> > The original phy management here includes timed jobs that you don't >> >> want >> >> > in a deterministic environment, therefore they have been switched >> off. >> >> > Of course, this only makes sense when those jobs are not required to >> >> > keep the link running. If they are needed to bring it up, a smart >> >> way to >> >> > only do this during fec_enet_open has to be found. >> >> > >> >> > The golden rule is: Keep "comfort" functions out of the critical >> path. >> >> > If you have high rate deterministic traffic, some link watchdog at a >> >> few >> >> > HZ will choke far too late anyway. In this case, error detection can >> >> > best be performed at higher levels. >> >> >> >> Before we think more about PHY support some more questions: >> >> >> >> - did you disable the FEC driver in Linux via kernel config >> > >> > Yes I did. >> >> OK. >> >> >> - do you see link up messages or are the corresponding LEDs on or >> >>blinking. >> > >> > LEDs are on but they aren't blinking when I try something like >> > "rtroute solicit ". >> > The driver output queue only is freed when the network wire is >> > unplugged. Only raises the handler fec_enet_interrupt when the >> > network wire is unplugged. >> > >> >> - does FEC work under Linux without PHY support (try disabling PHY >> >>support via kenrel config). >> > >> > I'm trying this one right now. >> >> OK, I'm going to check for old bugs now. Nevertheless, the software >> versions of Linux, RTAI and RTnet are very old :-(. >> >> Wolfgang >> >> >> >> > > I'm sorry for ask this question again but any idea is good for me, I > know that these software versions are ancients. > > I think that my board works without MDIO, so the following is with the > original rtnet FEC driver (with MDIO unsupported). > > I have detected a problem with the flag FEC_ECNTRL_ETHER_EN, this flag > is cleared (I don't know where) when the function > fec_enet_start_xmit() tries to trigger the transmission start with > fecp->fec_x_des_active = 0x0100. The following are some traces of > my execution: > > 1. Driver load: > [EMAIL PROTECTED]:/realtime/rtnet/sbin# insmod mpc8xx_fec-rt.o > RTnet: registered rteth0 > rteth0: FEC ENET Version 0.3, irq 7, addr 00:a0:26:23:57:2c > rteth0: FEC with MDIO disable > > 2. Inteface open (with network wire connected): > [EMAIL PROTECTED]:/realtime/rtnet/sbin# ./rtifconfig rteth0 up 10.10.10.1 > fec_restart: restarting FEC, duplex = 1 Why is fec_restart called from fec_open()? If MDIO is disabled, fec_enet_restart() is called in fec_enet_init() with duplex = 0. The MDIO code is a reminder from the original code and is just left in place to simplify porting of MDIO later on. > fec_stop: stopping > fec_stop: FEC_ECNTRL_ETHER_EN -> 0 (already down) > Full duplex > fec_restart: setting FEC_ECNTRL_PINMUX | FEC_ECNTRL_ETHER_EN > fec_enet_open: FEC_ECNTRL_ETHER_EN -> 1 > fec_enet_open: FEC_ECNTRL_ETHER_EN -> 1 > > 3. Trying get the ARP response: > [EMAIL PROTECTED]:/realtime/rtnet/sbin# ./rtroute solicit 10.10.10.2 dev > rteth0 > fec_enet_start_xmit: data len is 42 > fec_enet_start_xmit: Link is up > f
Re: [RTnet-users] MPC860T FEC: strange behavior
Javi Roman wrote: On 1/12/07, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: Javi Roman wrote: On 1/10/07, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: Javi Roman wrote: On 1/10/07, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: Jan Kiszka wrote: Javi Roman wrote: ... I think the driver requires PHY management (MDIO) to get my ethernet working, and from the brand new rtnet-0.9.7 (rt_mpc8xx_fec.c): #ifdef CONFIG_RTAI_RTNET_USE_MDIO #error "MDIO for PHY configuration is not yet supported!" #endif OK, that's something Wolfgang has to comment on. As the message says, MDIO is not supported. All MDIO stuff is under this macro. I don't know why is not supported, nevertheless I'm going to work with this issue. The original phy management here includes timed jobs that you don't want in a deterministic environment, therefore they have been switched off. Of course, this only makes sense when those jobs are not required to keep the link running. If they are needed to bring it up, a smart way to only do this during fec_enet_open has to be found. The golden rule is: Keep "comfort" functions out of the critical path. If you have high rate deterministic traffic, some link watchdog at a few HZ will choke far too late anyway. In this case, error detection can best be performed at higher levels. Before we think more about PHY support some more questions: - did you disable the FEC driver in Linux via kernel config Yes I did. OK. - do you see link up messages or are the corresponding LEDs on or blinking. LEDs are on but they aren't blinking when I try something like "rtroute solicit ". The driver output queue only is freed when the network wire is unplugged. Only raises the handler fec_enet_interrupt when the network wire is unplugged. - does FEC work under Linux without PHY support (try disabling PHY support via kenrel config). I'm trying this one right now. OK, I'm going to check for old bugs now. Nevertheless, the software versions of Linux, RTAI and RTnet are very old :-(. Wolfgang I'm sorry for ask this question again but any idea is good for me, I know that these software versions are ancients. I think that my board works without MDIO, so the following is with the original rtnet FEC driver (with MDIO unsupported). I have detected a problem with the flag FEC_ECNTRL_ETHER_EN, this flag is cleared (I don't know where) when the function fec_enet_start_xmit() tries to trigger the transmission start with fecp->fec_x_des_active = 0x0100. The following are some traces of my execution: 1. Driver load: [EMAIL PROTECTED]:/realtime/rtnet/sbin# insmod mpc8xx_fec-rt.o RTnet: registered rteth0 rteth0: FEC ENET Version 0.3, irq 7, addr 00:a0:26:23:57:2c rteth0: FEC with MDIO disable 2. Inteface open (with network wire connected): [EMAIL PROTECTED]:/realtime/rtnet/sbin# ./rtifconfig rteth0 up 10.10.10.1 fec_restart: restarting FEC, duplex = 1 fec_stop: stopping fec_stop: FEC_ECNTRL_ETHER_EN -> 0 (already down) Full duplex fec_restart: setting FEC_ECNTRL_PINMUX | FEC_ECNTRL_ETHER_EN fec_enet_open: FEC_ECNTRL_ETHER_EN -> 1 fec_enet_open: FEC_ECNTRL_ETHER_EN -> 1 3. Trying get the ARP response: [EMAIL PROTECTED]:/realtime/rtnet/sbin# ./rtroute solicit 10.10.10.2 dev rteth0 fec_enet_start_xmit: data len is 42 fec_enet_start_xmit: Link is up fec_enet_start_xmit: setting X_DES_ACTIVE fec_enet_start_xmit: BD_ENET_TX_UN -> 0 fec_enet_start_xmit: FEC_ECNTRL_PINMUX -> 1 fec_enet_start_xmit: FEC_ECNTRL_ETHER_EN -> 0 fec_enet_start_xmit: transmission start triggered [From this point nothing more happends] 4. I close the NIC interface: [EMAIL PROTECTED]:/realtime/rtnet/sbin# ./rtifconfig rteth0 down fec_stop: stopping fec_stop: FEC_ECNTRL_ETHER_EN -> 0 (already down) 5. Disconnect the network wire and set up the interface again: [EMAIL PROTECTED]:/realtime/rtnet/sbin# ./rtifconfig rteth0 up 10.10.10.1 fec_restart: restarting FEC, duplex = 1 fec_stop: stopping fec_stop: FEC_ECNTRL_ETHER_EN -> 0 (already down) Full duplex fec_restart: setting FEC_ECNTRL_PINMUX | FEC_ECNTRL_ETHER_EN fec_enet_open: FEC_ECNTRL_ETHER_EN -> 1 fec_enet_open: FEC_ECNTRL_ETHER_EN -> 1 7. Now the FEC interruption is raised, because of the ETHER_EN flag is set correctly: [EMAIL PROTECTED]:/realtime/rtnet/sbin# ./rtroute solicit 10.10.10.2 dev rteth0 fec_enet_start_xmit: data len is 42 fec_enet_start_xmit: Link is up fec_enet_start_xmit: setting X_DES_ACTIVE fec_enet_start_xmit: BD_ENET_TX_UN -> 0 fec_enet_start_xmit: FEC_ECNTRL_PINMUX -> 1 fec_enet_start_xmit: FEC_ECNTRL_ETHER_EN -> 1 fec_enet_interrupt: in ISR fec_enet_tx: TX path TXI: c65ff100 c6937990 0 fec_enet_tx: dev_kfree_rtskb, sk buffer freed [One thing more, the fep->link value is not correctly handled] At least you got an TX done interrupt telling the the packet has been handle and sent out. Do you see the pack
Re: [RTnet-users] MPC860T FEC: strange behavior
Javi Roman wrote: > On 1/10/07, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: >> Javi Roman wrote: >>> On 1/10/07, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: >>>> Jan Kiszka wrote: >>>>> Javi Roman wrote: >>>>>> ... >>>>>> I think the driver requires PHY management (MDIO) to get my ethernet >>>>>> working, and from the brand new rtnet-0.9.7 (rt_mpc8xx_fec.c): >>>>>> >>>>>> #ifdef CONFIG_RTAI_RTNET_USE_MDIO >>>>>> #error "MDIO for PHY configuration is not yet supported!" >>>>>> #endif >>>>> OK, that's something Wolfgang has to comment on. >>>> As the message says, MDIO is not supported. >>>> >>>>>> All MDIO stuff is under this macro. >>>>>> I don't know why is not supported, nevertheless I'm going to work with >>>>>> this issue. >>>>> The original phy management here includes timed jobs that you don't >>>> want >>>>> in a deterministic environment, therefore they have been switched off. >>>>> Of course, this only makes sense when those jobs are not required to >>>>> keep the link running. If they are needed to bring it up, a smart >>>> way to >>>>> only do this during fec_enet_open has to be found. >>>>> >>>>> The golden rule is: Keep "comfort" functions out of the critical path. >>>>> If you have high rate deterministic traffic, some link watchdog at a >>>> few >>>>> HZ will choke far too late anyway. In this case, error detection can >>>>> best be performed at higher levels. >>>> Before we think more about PHY support some more questions: >>>> >>>> - did you disable the FEC driver in Linux via kernel config >>> Yes I did. >> OK. >> >>>> - do you see link up messages or are the corresponding LEDs on or >>>>blinking. >>> LEDs are on but they aren't blinking when I try something like >>> "rtroute solicit ". >>> The driver output queue only is freed when the network wire is >>> unplugged. Only raises the handler fec_enet_interrupt when the >>> network wire is unplugged. >>> >>>> - does FEC work under Linux without PHY support (try disabling PHY >>>>support via kenrel config). >>> I'm trying this one right now. >> OK, I'm going to check for old bugs now. Nevertheless, the software >> versions of Linux, RTAI and RTnet are very old :-(. >> >> Wolfgang >> >> >> >> > > I'm sorry for ask this question again but any idea is good for me, I > know that these software versions are ancients. > > I think that my board works without MDIO, so the following is with the > original rtnet FEC driver (with MDIO unsupported). > > I have detected a problem with the flag FEC_ECNTRL_ETHER_EN, this flag > is cleared (I don't know where) when the function > fec_enet_start_xmit() tries to trigger the transmission start with > fecp->fec_x_des_active = 0x0100. The following are some traces of > my execution: > > 1. Driver load: > [EMAIL PROTECTED]:/realtime/rtnet/sbin# insmod mpc8xx_fec-rt.o > RTnet: registered rteth0 > rteth0: FEC ENET Version 0.3, irq 7, addr 00:a0:26:23:57:2c > rteth0: FEC with MDIO disable > > 2. Inteface open (with network wire connected): > [EMAIL PROTECTED]:/realtime/rtnet/sbin# ./rtifconfig rteth0 up 10.10.10.1 > fec_restart: restarting FEC, duplex = 1 > fec_stop: stopping > fec_stop: FEC_ECNTRL_ETHER_EN -> 0 (already down) > Full duplex > fec_restart: setting FEC_ECNTRL_PINMUX | FEC_ECNTRL_ETHER_EN > fec_enet_open: FEC_ECNTRL_ETHER_EN -> 1 > fec_enet_open: FEC_ECNTRL_ETHER_EN -> 1 > > 3. Trying get the ARP response: > [EMAIL PROTECTED]:/realtime/rtnet/sbin# ./rtroute solicit 10.10.10.2 dev > rteth0 > fec_enet_start_xmit: data len is 42 > fec_enet_start_xmit: Link is up > fec_enet_start_xmit: setting X_DES_ACTIVE > fec_enet_start_xmit: BD_ENET_TX_UN -> 0 > fec_enet_start_xmit: FEC_ECNTRL_PINMUX -> 1 > fec_enet_start_xmit: FEC_ECNTRL_ETHER_EN -> 0 > fec_enet_start_xmit: transmission start triggered > > [From this point nothing more happends] > > 4. I close the NIC interface: > [EMAIL PROTECTED]:/realtime/rtnet/sbin# ./rtifconfig rteth0 down > fec_stop: stopping > fec_stop: FEC_ECNTRL_ETHER_EN -> 0 (already down) > > 5. Disconnect the network wire and set up the interface agai
Re: [RTnet-users] MPC860T FEC: strange behavior
Javi Roman wrote: > On 1/10/07, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: >> Jan Kiszka wrote: >> > Javi Roman wrote: >> >> ... >> >> I think the driver requires PHY management (MDIO) to get my ethernet >> >> working, and from the brand new rtnet-0.9.7 (rt_mpc8xx_fec.c): >> >> >> >> #ifdef CONFIG_RTAI_RTNET_USE_MDIO >> >> #error "MDIO for PHY configuration is not yet supported!" >> >> #endif >> > >> > OK, that's something Wolfgang has to comment on. >> >> As the message says, MDIO is not supported. >> >> > >> >> All MDIO stuff is under this macro. >> >> I don't know why is not supported, nevertheless I'm going to work with >> >> this issue. >> > >> > The original phy management here includes timed jobs that you don't >> want >> > in a deterministic environment, therefore they have been switched off. >> > Of course, this only makes sense when those jobs are not required to >> > keep the link running. If they are needed to bring it up, a smart >> way to >> > only do this during fec_enet_open has to be found. >> > >> > The golden rule is: Keep "comfort" functions out of the critical path. >> > If you have high rate deterministic traffic, some link watchdog at a >> few >> > HZ will choke far too late anyway. In this case, error detection can >> > best be performed at higher levels. >> >> Before we think more about PHY support some more questions: >> >> - did you disable the FEC driver in Linux via kernel config > > Yes I did. OK. >> - do you see link up messages or are the corresponding LEDs on or >>blinking. > > LEDs are on but they aren't blinking when I try something like > "rtroute solicit ". > The driver output queue only is freed when the network wire is > unplugged. Only raises the handler fec_enet_interrupt when the > network wire is unplugged. > >> - does FEC work under Linux without PHY support (try disabling PHY >>support via kenrel config). > > I'm trying this one right now. OK, I'm going to check for old bugs now. Nevertheless, the software versions of Linux, RTAI and RTnet are very old :-(. Wolfgang - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] MPC860T FEC: strange behavior
Jan Kiszka wrote: > Javi Roman wrote: >> ... >> I think the driver requires PHY management (MDIO) to get my ethernet >> working, and from the brand new rtnet-0.9.7 (rt_mpc8xx_fec.c): >> >> #ifdef CONFIG_RTAI_RTNET_USE_MDIO >> #error "MDIO for PHY configuration is not yet supported!" >> #endif > > OK, that's something Wolfgang has to comment on. As the message says, MDIO is not supported. > >> All MDIO stuff is under this macro. >> I don't know why is not supported, nevertheless I'm going to work with >> this issue. > > The original phy management here includes timed jobs that you don't want > in a deterministic environment, therefore they have been switched off. > Of course, this only makes sense when those jobs are not required to > keep the link running. If they are needed to bring it up, a smart way to > only do this during fec_enet_open has to be found. > > The golden rule is: Keep "comfort" functions out of the critical path. > If you have high rate deterministic traffic, some link watchdog at a few > HZ will choke far too late anyway. In this case, error detection can > best be performed at higher levels. Before we think more about PHY support some more questions: - did you disable the FEC driver in Linux via kernel config - do you see link up messages or are the corresponding LEDs on or blinking. - does FEC work under Linux without PHY support (try disabling PHY support via kenrel config). Wolfgang. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] RTnet on PowerPC 405 Platform
Leonardo Pappagallo wrote: > Hi Jan, > I have a PowerPC 405 Platform and I would like to use RTnet. I have > three questions: > > 1) Are there any RTnet drivers available for this Platform? If your platform has a PCI slot, you can use any supported card, preferably a eepro100. The on-chip Ethernet controller is not yet supported. > 2) If it is, which RtNet distribution supports these drivers? A recent distribution should be fine. > 3) If there aren't any drivers for this platform what are the > necessary steps to build a driver starting from a standard no-real time > driver? Have a look to the existing drivers. Wolfgang. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] rt_mpc52xx_fec status
Hello, sorry for late answer. I'm just back from vacation. [EMAIL PROTECTED] wrote: > > Hi, > > Does anyone know the status of the MPC52xx FEC driver for rtnet? The driver is available for (DENX) Linux 2.4 but is currently untested (because I didn't have a proper hardware at that time). Please let me know if you have problems to build and use the driver. Wolfgang. > Thanks in advance! > > Mats Larsson > > > > > ___ > RTnet-users mailing list > RTnet-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/rtnet-users ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
[RTnet-users] Kernel CFLAGS capturing trick, first version
Hi Jan,
attached you will find a first version of the kernel CFLAGS capturing
trick for Xenomai 2.1 and Linux 2.4. It works fine for PowerPC, but I
have not tested other archs. Please give it try and adapt it if
necessary. The patch fixes also a problem with eepro100-cmdtimeout.
Wolfgang.
+ diff -u rtnet/config/modules/Makefile.KMOD_CFLAGS rtnet/config/modules/Makefile
--- rtnet/config/modules/Makefile.KMOD_CFLAGS 2006-01-17 15:28:00.0 +0100
+++ rtnet/config/modules/Makefile 2006-01-17 14:49:36.0 +0100
@@ -0,0 +1,8 @@
+all:
+ @echo $(RTEXT_LINUX_DIR) $(ARCH)
+ $(MAKE) -s -C $(RTEXT_LINUX_DIR) CC=$(CC) $(RTEXT_LINUX_DIR)/include/linux/modversions.h
+ $(MAKE) -s -C $(RTEXT_LINUX_DIR) CC=$(CC) ARCH=$(ARCH) SUBDIRS=$(shell if [ "$$PWD" != "" ]; then echo $$PWD; else pwd; fi) modules
+
+modules:
+ @echo RTEXT_KMOD_CFLAGS="\"$(CFLAGS)\""
+
+ diff -u rtnet/configure.ac.KMOD_CFLAGS rtnet/configure.ac
--- rtnet/configure.ac.KMOD_CFLAGS 2006-01-04 11:29:15.0 +0100
+++ rtnet/configure.ac 2006-01-17 15:50:27.0 +0100
@@ -459,7 +459,13 @@
RTEXT_KMOD_CFLAGS="`${RTAI_CONFIG} --module-cflags`"
;;
xeno-21x)
-RTEXT_KMOD_CFLAGS="-D__KERNEL__ -DMODULE -DEXPORT_SYMTAB -I${RTEXT_LINUX_DIR}/include -Wall -Wstrict-prototypes -fomit-frame-pointer -fno-strict-aliasing -pipe -O2 -I${RTEXT_LINUX_DIR}/include/xenomai -I${RTEXT_LINUX_DIR}/include/xenomai/compat"
+ # Kernel cflags capturing trick from RTAI
+ kmod_cflags=`cd $srcdir/config/modules && make -s RTEXT_LINUX_DIR=$RTEXT_LINUX_DIR ARCH=$RTNET_TARGET_ARCH CC=$CC | grep '^RTEXT_KMOD_CFLAGS='`
+ eval $kmod_cflags
+ if test "$RTEXT_KMOD_CFLAGS" = ""; then
+ AC_MSG_ERROR([Unable to retrieve compilation flags for kernel modules out of $RTEXT_LINUX_DIR/Makefile])
+ fi
+ RTEXT_KMOD_CFLAGS="$RTEXT_KMOD_CFLAGS -DEXPORT_SYMTAB -I${RTEXT_LINUX_DIR}/include/xenomai -I${RTEXT_LINUX_DIR}/include/xenomai/compat"
;;
*)
AC_MSG_ERROR([*** internal error])
@@ -771,7 +777,7 @@
*) AC_MSG_ERROR([Bad argument to option: --enable-eepro100-cmdtimeout=]) ;;
esac])
if test x$CONFIG_RTNET_DRV_EEPRO100_CMDTIMEOUT = x ; then
-$CONFIG_RTNET_DRV_EEPRO100_CMDTIMEOUT = 20
+CONFIG_RTNET_DRV_EEPRO100_CMDTIMEOUT=20
fi
AC_MSG_RESULT($CONFIG_RTNET_DRV_EEPRO100_CMDTIMEOUT us)
AC_DEFINE_UNQUOTED(CONFIG_RTNET_DRV_EEPRO100_CMDTIMEOUT,
Re: [RTnet-users] Re: Compiler flags for making RTnet kernel modules
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hi Jan,
I have now finally a RTnet running on MPC860/FCC <-> MPC8260/EEPRO100.
Next I will test MPC860/SCC <-> MPC8260/FCC. A few fixes are
needed, one
with the compiler flags for module compilation. I think we should use
the same flags as the kernel uses to build it's modules. In old
Xenomai
or RTAI there was a way to get them automatically. What do you think?
Yes, it's probably best to port this into current RTnet. Or is there an
official interface now in recent 2.4 kernels to obtain them?
I don't know. Is there one in 2.6?
Not that I know. It's not needed because you build via
"make -C SUBDIRS= modules",
using the original make rules of the kernel. For me the question is how
other external modules for 2.4 handle this. They all have the same
problem like we do now.
Yes, and for this reason the "flags capturing trick" was invented, I
guess. But to avoid trouble...
Of course we can install the "flags capturing trick" in configure that
RTAI does for 2.4. But this is some code to copy and it seems to be
arch-dependent as well:
[configure.in of RTAI]
...
kmod_cflags=`cd $srcdir/base/config/modules && make -s
RTAI_LINUX_DIR=$RTAI_LINUX_DIR ARCH=$RTAI_TARGET_ARCH CC=$CC | grep
'^RTAI_KMOD_CFLAGS='`
eval $kmod_cflags
if test "$RTAI_KMOD_CFLAGS" = ""; then
AC_MSG_ERROR([Unable to retrieve compilation flags for kernel
modules out of $RTAI_LINUX_DIR/Makefile])
fi
...
case $RTAI_TARGET_ARCH in
...
ppc)
RTAI_TARGET_SUBARCH=
RTAI_KMOD_CFLAGS="$RTAI_KMOD_CFLAGS -I${RTAI_LINUX_DIR}/arch/ppc"
:-/
Hm, the include path is already included. When I do the following I get:
make RTAI_LINUX_DIR=/temp/rtai/devel/linuxppc_2_4_devel ARCH=ppc
make -s -C /temp/rtai/devel/linuxppc_2_4_devel CC=cc
/temp/rtai/devel/linuxppc_2_4_devel/include/linux/modversions.h
make -s -C /temp/rtai/devel/linuxppc_2_4_devel CC=cc ARCH=ppc
SUBDIRS=/opt/eldk/ppc_8xx/root/rtai/kilauea/rtai-core/config/modules
modules
RTAI_KMOD_CFLAGS="-D__KERNEL__
-I/temp/rtai/devel/linuxppc_2_4_devel/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer
-I/temp/rtai/devel/linuxppc_2_4_devel/arch/ppc -fsigned-char
-msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring -g
-ggdb -DMODULE -DEXPORT_SYMTAB -Wall"
That's good. Ok, then just take over the capturing stuff. Could you do this?
Yes.
Have a nice weekend.
Wolfgang.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Re: Compiler flags for making RTnet kernel modules
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hi Jan,
I have now finally a RTnet running on MPC860/FCC <-> MPC8260/EEPRO100.
Next I will test MPC860/SCC <-> MPC8260/FCC. A few fixes are needed, one
with the compiler flags for module compilation. I think we should use
the same flags as the kernel uses to build it's modules. In old Xenomai
or RTAI there was a way to get them automatically. What do you think?
Yes, it's probably best to port this into current RTnet. Or is there an
official interface now in recent 2.4 kernels to obtain them?
I don't know. Is there one in 2.6?
Not that I know. It's not needed because you build via
"make -C SUBDIRS= modules",
using the original make rules of the kernel. For me the question is how
other external modules for 2.4 handle this. They all have the same
problem like we do now.
Yes, and for this reason the "flags capturing trick" was invented, I
guess. But to avoid trouble...
Of course we can install the "flags capturing trick" in configure that
RTAI does for 2.4. But this is some code to copy and it seems to be
arch-dependent as well:
[configure.in of RTAI]
...
kmod_cflags=`cd $srcdir/base/config/modules && make -s
RTAI_LINUX_DIR=$RTAI_LINUX_DIR ARCH=$RTAI_TARGET_ARCH CC=$CC | grep
'^RTAI_KMOD_CFLAGS='`
eval $kmod_cflags
if test "$RTAI_KMOD_CFLAGS" = ""; then
AC_MSG_ERROR([Unable to retrieve compilation flags for kernel
modules out of $RTAI_LINUX_DIR/Makefile])
fi
...
case $RTAI_TARGET_ARCH in
...
ppc)
RTAI_TARGET_SUBARCH=
RTAI_KMOD_CFLAGS="$RTAI_KMOD_CFLAGS -I${RTAI_LINUX_DIR}/arch/ppc"
:-/
Hm, the include path is already included. When I do the following I get:
make RTAI_LINUX_DIR=/temp/rtai/devel/linuxppc_2_4_devel ARCH=ppc
make -s -C /temp/rtai/devel/linuxppc_2_4_devel CC=cc
/temp/rtai/devel/linuxppc_2_4_devel/include/linux/modversions.h
make -s -C /temp/rtai/devel/linuxppc_2_4_devel CC=cc ARCH=ppc
SUBDIRS=/opt/eldk/ppc_8xx/root/rtai/kilauea/rtai-core/config/modules modules
RTAI_KMOD_CFLAGS="-D__KERNEL__
-I/temp/rtai/devel/linuxppc_2_4_devel/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer
-I/temp/rtai/devel/linuxppc_2_4_devel/arch/ppc -fsigned-char
-msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring -g
-ggdb -DMODULE -DEXPORT_SYMTAB -Wall"
Wolfgang.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
[RTnet-users] Re: Compiler flags for making RTnet kernel modules
Jan Kiszka wrote: Wolfgang Grandegger wrote: Hi Jan, I have now finally a RTnet running on MPC860/FCC <-> MPC8260/EEPRO100. Next I will test MPC860/SCC <-> MPC8260/FCC. A few fixes are needed, one with the compiler flags for module compilation. I think we should use the same flags as the kernel uses to build it's modules. In old Xenomai or RTAI there was a way to get them automatically. What do you think? Yes, it's probably best to port this into current RTnet. Or is there an official interface now in recent 2.4 kernels to obtain them? I don't know. Is there one in 2.6? Wolfgang. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
[RTnet-users] Compiler flags for making RTnet kernel modules
Hi Jan, I have now finally a RTnet running on MPC860/FCC <-> MPC8260/EEPRO100. Next I will test MPC860/SCC <-> MPC8260/FCC. A few fixes are needed, one with the compiler flags for module compilation. I think we should use the same flags as the kernel uses to build it's modules. In old Xenomai or RTAI there was a way to get them automatically. What do you think? Wolfgang. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Re: Trouble building RTnet with Xenomai for PPC
Jan Kiszka wrote: Wolfgang Grandegger wrote: Hi Jan, when trying to build RTnet with Xenomai and Linux 2.4.25 for PowerPC I realized that the ELDK 3.1.1 does not have the user space definition ARPHRD_IEEE1394 used in tools/rtifconfig.c. Where should we add an appropriate definition to fix that problem? So far in rtifconfig.c itself with #ifndef ARPHRD_IEEE1394 #define ARPHRD_IEEE1394 24 #endif until someone may come up with a better solution. OK, I thought you might have a compatibility header file for such definitions. Furthermore I realized the following warning message when making rt_8139too.c: rt_8139too.c: In function `rtl8139_init_board': rt_8139too.c:699: warning: implicit declaration of function `pci_request_regions ' rt_8139too.c:775: warning: implicit declaration of function `pci_release_regions ' Where are they declared in that kernel version? They should normally stick in linux/pci.h, and that one is included by the driver. Ah, there is a "#ifdef CONFIG_PCI" in "linux/pci.h". Therefore it makes little sense to select PCI based drivers without selecting CONFIG_PCI. Thanks. Wolfgang. Jan --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
[RTnet-users] Trouble building RTnet with Xenomai for PPC
Hi Jan, when trying to build RTnet with Xenomai and Linux 2.4.25 for PowerPC I realized that the ELDK 3.1.1 does not have the user space definition ARPHRD_IEEE1394 used in tools/rtifconfig.c. Where should we add an appropriate definition to fix that problem? Furthermore I realized the following warning message when making rt_8139too.c: rt_8139too.c: In function `rtl8139_init_board': rt_8139too.c:699: warning: implicit declaration of function `pci_request_regions ' rt_8139too.c:775: warning: implicit declaration of function `pci_release_regions ' Thanks. Wolfgang. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
[RTnet-users] Problem with #define uint "i"
Hallo, when trying to build RTnet with Xenomai and Linux 2.4.25 for PowerPC, I stumbeld over the following problem: In "linuxppc_2_4_devel/include/asm-generic/xenomai/wrappers.h" there is defined: #define ulong "i" #define uint "i" This makes trouble when a driver uses the types uint or ulong, which is the case for the MPC RTnet drivers. Can we use different names for the above definitions? Thanks. Wolfgang. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Re: RTnet configure failed with Xenomai 2.1
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
...
As mentioned, I fiddled with and "--with-rtext" and "--with-linux"
without success. In the meantime I realized (from the README) the
interactive configuration but still it does not work. It does not find
"rtdm/rtdm.h". Should'nt it look for "xenomai/rtdm/rtdm.h"
This should be catched by an appropriate "-I" in the CFLAGS - to remain
portable (see also the related recent thread on xenomai-core).
Attached is the log file of "make CROSS_COMPILE=ppc_8xx- ARCH=ppc
config".
What does config.log says about the compilation failure? I think there
should also be a print-out of the invoked compiler commands. But I will
also re-check if this could be an arch- or 2.4-related bug.
...
/home/wolf/rt/linuxppc_2_4_devel-2006-01-04_1034-ipipe/include/asm/mpc8xx.h:96:30:
platforms/tqm8xx.h: No such file or directory
...
I see, it's a PowerPC related problem. Apart from
-I/home/wolf/rt/linuxppc_2_4_devel-2006-01-04_1034-ipipe/include
we need
-I/home/wolf/rt/linuxppc_2_4_devel-2006-01-04_1034-ipipe/arch/ppc
to find all kernel related header files.
Ah! Yes, with 2.4 on xeno.2.1 we have to take care of all compiler
arguments on our own.
You certainly know of some out-of-tree PPC-specific drivers. Could you
check if they use other special switches? Is this specific for the
mpc8xx? Do you see a clean, generic solution? Feel free to patch
configure.ac when you think you found one.
Adding -I${RTEXT_LINUX_DIR}/arch/ppc to RTEXT_KMOD_CFLAGS in
configure.ac fixed the configure problem. Apart from that the flags look
OK (but the kernel uses a lot more to compile modules). I will provide a
patch when I have RTnet succesfully built. There are a few other issues,
e.g. min_t does not exist in 2.4 kernels.
Wolfgang.
Jan
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Re: RTnet configure failed with Xenomai 2.1
Jan Kiszka wrote: Wolfgang Grandegger wrote: ... As mentioned, I fiddled with and "--with-rtext" and "--with-linux" without success. In the meantime I realized (from the README) the interactive configuration but still it does not work. It does not find "rtdm/rtdm.h". Should'nt it look for "xenomai/rtdm/rtdm.h" This should be catched by an appropriate "-I" in the CFLAGS - to remain portable (see also the related recent thread on xenomai-core). Attached is the log file of "make CROSS_COMPILE=ppc_8xx- ARCH=ppc config". What does config.log says about the compilation failure? I think there should also be a print-out of the invoked compiler commands. But I will also re-check if this could be an arch- or 2.4-related bug. ... /home/wolf/rt/linuxppc_2_4_devel-2006-01-04_1034-ipipe/include/asm/mpc8xx.h:96:30: platforms/tqm8xx.h: No such file or directory ... I see, it's a PowerPC related problem. Apart from -I/home/wolf/rt/linuxppc_2_4_devel-2006-01-04_1034-ipipe/include we need -I/home/wolf/rt/linuxppc_2_4_devel-2006-01-04_1034-ipipe/arch/ppc to find all kernel related header files. Thanks. Wolfgang. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Re: RTnet configure failed with Xenomai 2.1
Jan Kiszka wrote: Hi Wolfgang, Wolfgang Grandegger wrote: Hallo Jan, first I wish you all a Happy and successful New Year. Thanks a lot, best wishes to you as well! I now want to build and test RTnet on the MPC 8xx with: DENX linuxppc_2_4_devel (2.4.25) + adeos-ipipe-2.6.14-ppc-1.1-00.patch Xenomai 2.1 pre (2.0.90) checked out today RTnet checked out today I can build Xenomai and run the latency test on the MPC 8xx. But the ./configure of RTnet fails because "xeno-config" option "--config" does not exists. I already fiddled with --with-linux and --with-rtext without success. I have attached the output of ./configure ... Any idea where the problem is? Yes: don't use --with-rtext for Xeno-2.1. If you had used the interactive configuration, RTnet would have resolved this automatically... :) When doing it manually, you have to know that RTnet assumes a Xenomai 2.0 / RTAI 3.3 build in case you provide --with-rtext. As long as you do not build any example, the Xenomai userspace part need not be given anymore. If you enable the examples, provide the full xeno-config path via --with-rtext-config instead. As mentioned, I fiddled with and "--with-rtext" and "--with-linux" without success. In the meantime I realized (from the README) the interactive configuration but still it does not work. It does not find "rtdm/rtdm.h". Should'nt it look for "xenomai/rtdm/rtdm.h" Attached is the log file of "make CROSS_COMPILE=ppc_8xx- ARCH=ppc config". Thanks. Wolfgang. 8xx*~/rt/trunk/rtnet$ make CROSS_COMPILE=ppc_8xx- ARCH=ppc config make[1]: Entering directory `/home/wolf/rt/trunk/rtnet/scripts/kconfig' # # using defaults found in ../../.rtnet_config # * * RTnet Configuration * * * Real-Time Extension * Variant 1. RTAI 3.3 or better, Xenomain 2.0.x (RTNET_RTEXT_CLASSIC) > 2. Xenomai 2.1 or better (RTNET_RTEXT_INKERNEL) choice[1-2]: 2 Real-Time Extended Linux Kernel (RTNET_LINUX_DIR) [/home/wolf/rt/linuxppc_2_4_devel-2006-01-04_1034-ipipe] * * RTnet Parameters * Installation Path of RTnet (RTNET_INSTALLDIR) [/home/wolf/xeno-rtnet] Internal Bug Checks (RTNET_CHECKED) [N/y/?] * * Protocol Stack * Real-Time IPv4 (RTNET_RTIPV4) [Y/n/?] IP Network Routing (RTNET_RTIPV4_NETROUTING) [N/y/?] IP Router (RTNET_RTIPV4_ROUTER) [N/y/?] Real-Time Packet Socket Support (RTNET_RTPACKET) [Y/n/?] * * RTmac Layer * RTmac Layer (RTNET_RTMAC) [Y/n/?] TDMA discipline for RTmac (RTNET_TDMA) [Y/n/?] TDMA master support (RTNET_TDMA_MASTER) [Y/n/?] NoMAC discipline for RTmac (RTNET_NOMAC) [N/y/?] RTcfg Service (RTNET_RTCFG) [Y/n/?] RTcfg Debugging (RTNET_RTCFG_DEBUG) [N/y/?] * * Drivers * * * Common PCI Drivers * AMD PCnet32 (RTNET_DRV_PCNET32) [N/y] DEC Tulip (RTNET_DRV_TULIP) [N/y] Intel EtherExpress PRO/100 (RTNET_DRV_EEPRO100) [N/y] NatSemi (RTNET_DRV_NATSEMI) [N/y] Realtek 8139 (RTNET_DRV_8139) [Y/n] VIA Rhine (RTNET_DRV_VIA_RHINE) [N/y] * * Embedded MPC Drivers * MPC8260 FCC Ethernet (RTNET_DRV_FCC_ENET) [N/y] MPC8xx FEC Ethernet (RTNET_DRV_FEC_ENET) [Y/n] MPC8xx SCC Ethernet (RTNET_DRV_SCC_ENET) [Y/n] MPC52xx FEC Ethernet (RTNET_DRV_MPC52XX_FEC) [N/y] * * Misc Drivers * Loopback (RTNET_DRV_LOOPBACK) [Y/n] SMSC LAN91C111 (RTNET_DRV_SMC9) [N/y] Ethernet over 1394 (RTNET_DRV_ETH1394) [N/y] Experimental Drivers (RTNET_EXP_DRIVERS) [N/y] * * Add-Ons * Real-Time Capturing Support (RTNET_ADDON_RTCAP) [N/y/?] IP protocol proxy (legacy) (RTNET_ADDON_PROXY) [N/y/?] * * Examples * RTnet Application Examples (RTNET_EXAMPLES) [N/y/?] make[1]: Leaving directory `/home/wolf/rt/trunk/rtnet/scripts/kconfig' checking build system type... i686-pc-linux checking host system type... powerpc-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking for powerpc-unknown-linux-gnu-gcc... ppc_8xx-gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... yes checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether ppc_8xx-gcc accepts -g... yes checking for ppc_8xx-gcc option to accept ANSI C... none needed checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking for powerpc-unknown-linux-gnu-strip... ppc_8xx-strip checking dependency style of ppc_8xx-gcc... gcc3 checking whether to enable maintainer-specific portions of Makefiles... no checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by ppc_8xx-gcc... ppc_8xx-ld checking if the linker (ppc_8xx-ld) is GNU ld... yes checking for ppc_8xx-ld option to reload object files... -r checking for BSD-compatible nm... ppc_8xx-nm checking whether ln -s works... yes checking how to recognise dependen
[RTnet-users] RTnet configure failed with Xenomai 2.1
Hallo Jan, first I wish you all a Happy and successful New Year. I now want to build and test RTnet on the MPC 8xx with: DENX linuxppc_2_4_devel (2.4.25) + adeos-ipipe-2.6.14-ppc-1.1-00.patch Xenomai 2.1 pre (2.0.90) checked out today RTnet checked out today I can build Xenomai and run the latency test on the MPC 8xx. But the ./configure of RTnet fails because "xeno-config" option "--config" does not exists. I already fiddled with --with-linux and --with-rtext without success. I have attached the output of ./configure ... Any idea where the problem is? Thanks. 8xx*~/rt/trunk/rtnet$ ./configure --host=ppc-linux --build=i686-linux --with-rtext=/opt/eldk/ppc_8xx/home/wolf/xeno-rtnet --enable-fec-enet --enable-scc-enet --with-linux=/home/wolf/rt/linuxppc_2_4_devel-2006-01-04_1034-ipipe checking build system type... i686-pc-linux checking host system type... powerpc-unknown-linux checking for a BSD-compatible install... /usr/bin/install -c checking for ppc-linux-gcc... ppc-linux-gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... yes checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether ppc-linux-gcc accepts -g... yes checking for ppc-linux-gcc option to accept ANSI C... none needed checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking for ppc-linux-strip... ppc-linux-strip checking dependency style of ppc-linux-gcc... gcc3 checking whether to enable maintainer-specific portions of Makefiles... no checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by ppc-linux-gcc... /opt/eldk-3.1.1/usr/ppc-linux/bin/ld checking if the linker (/opt/eldk-3.1.1/usr/ppc-linux/bin/ld) is GNU ld... yes checking for /opt/eldk-3.1.1/usr/ppc-linux/bin/ld option to reload object files... -r checking for BSD-compatible nm... /opt/eldk/usr/bin/ppc-linux-nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... ppc-linux-gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ppc-linux-g++... ppc-linux-g++ checking whether we are using the GNU C++ compiler... yes checking whether ppc-linux-g++ accepts -g... yes checking dependency style of ppc-linux-g++... gcc3 checking how to run the C++ preprocessor... ppc-linux-g++ -E checking for ppc-linux-g77... no checking for ppc-linux-f77... no checking for ppc-linux-xlf... no checking for ppc-linux-frt... no checking for ppc-linux-pgf77... no checking for ppc-linux-fort77... no checking for ppc-linux-fl32... no checking for ppc-linux-af77... no checking for ppc-linux-f90... no checking for ppc-linux-xlf90... no checking for ppc-linux-pgf90... no checking for ppc-linux-epcf90... no checking for ppc-linux-f95... no checking for ppc-linux-fort... no checking for ppc-linux-xlf95... no checking for ppc-linux-ifc... no checking for ppc-linux-efc... no checking for ppc-linux-pgf95... no checking for ppc-linux-lf95... no checking for ppc-linux-gfortran... no checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /opt/eldk/usr/bin/ppc-linux-nm -B output from ppc-linux-gcc object... ok checking for objdir... .libs checking for ppc-linux-ar... ppc-linux-ar checking for ppc-linux-ranlib... ppc-linux-ranlib checking for ppc-linux-strip... (cached) ppc-linux-strip checking if ppc-linux-gcc static flag works... yes checking if ppc-linux-gcc supports -fno-rtti -fno-exceptions... no checking for ppc-linux-gcc option to produce PIC... -fPIC checking if ppc-linux-gcc PIC flag -fPIC works... yes checking if ppc-linux-gcc supports -c -o file.o... yes checking whether the ppc-linux-gcc linker (/opt/eldk-3.1.1/usr/ppc-linux/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool chec
Re: [RTnet-users] rtai for linux-2.4.22 or above for ppc
On 10/01/2005 09:26 PM [EMAIL PROTECTED] wrote: > > > Hi , > recently i was using linux-2.4.19 stock kernel for ppc and rtai-24.1.12 > i got it compiled and was able to insmod modules even the rtnet modules > also , > but i got stuck with rt_mpc8xx_enet.o module , > it was suggested on the mailing list to upgrade to higher version of > kerne and rtai and also rtnet > as i face lot many problems and bugs , > it was recommended to use linux-2.4.22 or above , > i have here the basic question > i tried using linux-2.4.22 stock kernel and using rtai-24.1.13 stromblis > verison and even the other version of rtai , > but every time i used topatch i used to always get in function* pend_mm > rthal undeclared in sched.c .* > i think rtai-24.1.13 only supports X86 version not for ppc version , > correct me if i am wrong , as lxrt is not supported in powerpc , > i am using the appropriate patch for linux-2.4.22 , patch-2.4.22-rthal5g ? > or i should be using somethng else ? > when i checked the code sched.c i saw #ifdef CONFIG_X86 in linux-2.4.19 > kernel patched one with #else mmdrop(...) > where as i dont see it on other higher version of kernel ? > is it not supported in higher version of kernel ? > i need to qucikly fix on this versioning its bit confusing for rtai > if someone has used rtai for linux-2.4.22 or higher verison of kernel > for ppc ,please guide me which kernel which rtai to be used , > in our company there is no cvs access so i am not able to download cvs > kernel downlaods ummm.. Note that you need an appropriate version of the Linux kernel tree, RTAI and RTnet. Furthermore, PowerPC support is not included in the normal RTAI patches, e.g. the one you mentioned above. I suggest to use: - A recent version of the DENX linuxppc_2_4_devel tree (check http://www.denx.de for further information), which is a 2.4.25 kernel known to work well on MPC 8xx. There are rather recent tarballs at ftp://ftp.denx.de/pub/ppc/linux/ e.g. linuxppc_2_4_devel-2005-09-15-2320.tar.bz2 in case you don't have CVS or GIT access. - A recent RTAI kernel patch from ftp://ftp.denx.de/pub/RTAI/patches, e.g. patch-denx-linuxppc_2_4_devel-2005_06_23_1722 should be OK: $ export CROSS_COMPILE=ppc_8xx- $ tar xjf linuxppc_2_4_devel-2005-09-15-2320.tar.bz2 $ cd linuxppc_2_4_devel-2005-09-15-2320 $ patch -p1 -b -z.ORIG < \ ../patch-denx-linuxppc_2_4_devel-2005_06_23_1722 $ make TQM862M_config $ make menuconfig ... [ ] CPM SCC Ethernet ... $ make dep $ make uImage Also read ftp://ftp.denx.de/pub/RTAI/README, please. - RTnet 0.8.3 and head of CVS of the RTAI from the "stromboli" branch. There is a daily snapshot of the CVS tree available at https://gna.org/cvs/?group=rtai $ tar xzf rtai-snapshot.tar.gz $ cd rtai/stromboli/ $ export CROSS_COMPILE=ppc_8xx- $ make ... Enter location of Linux source tree [...]: ... $ make $ cd ../.. $ tar xjf rtnet-0.8.3.tar.bz2 $ cd rtnet-0.8.3 $ export DESTDIR=/opt/eldk/ppc_8xx $ ./configure --host=ppc-linux --build=i686-linux \ --with-rtai=/temp/rtai/devel/rtai/stromboli --prefix=/usr/realtime \ --enable-scc-enet --enable-fec-enet $ make $ make install $ ls -l $DESTDIR/usr/realtime/modules -rw-r--r-- 1 wolf badboys 18070 Oct 3 13:37 rtai_rtdm.o -rw-r--r-- 1 wolf badboys 45453 Oct 3 13:37 rtcfg.o -rw-r--r-- 1 wolf badboys 3681 Oct 3 13:37 rt_loopback.o -rw-r--r-- 1 wolf badboys 17342 Oct 3 13:37 rtmac.o -rw-r--r-- 1 wolf badboys 9665 Oct 3 13:37 rt_mpc8xx_enet.o -rw-r--r-- 1 wolf badboys 9722 Oct 3 13:37 rt_mpc8xx_fec.o -rw-r--r-- 1 wolf badboys 75003 Oct 3 13:37 rtnet.o -rw-r--r-- 1 wolf badboys 23163 Oct 3 13:37 tdma.o I have tested RTnet on MPC 8xx with this combination recently. Wolfgang. > > > Thanks In Advance > Neelu > > * * --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
[RTnet-users] Re: rt_mpc8xx_enet.o device or resource busy
Hello Neelu, please keep this discussion public as it might be of interest for others as well. It looks like you already hit various problems with old versions of Linux, RTAI and RTnet. On 09/29/2005 01:59 PM [EMAIL PROTECTED] wrote: > > HI Wolfgang , > > yes it works when include four symbols in ppc_ksyms.c it works fine , > except one consistent_alloc symbol , as it was not delclared in any *.h > file , i declared it in commproc.h , it works fine now , now no more > unresolved symbols In 2.4.25 consistent_alloc is declared in include/asm-ppc/io.h. > when i insmod rt_mpc8xx_enet.o it says device or resource busy ? > rtdev->irq = CPM_IRQ_OFFSET + CPMVEC_ENET; > i get CPM_IRQ_OFFSET as undeclared where is this defined ? CPM_IRQ_OFFSET is declared in include/asm-ppc/irq.h but it might be introduced into the Linux 2.4 kernel later after 2.4.19. In old versions of Linux 2.4 the CPM interrupts are not treated like the SIU interrupts but by a secondary interrupt handler, which is not visible by RTAI. For this reason we provide the "CONFIG_CPM_MULTILEVEL_IRQ" in the RTAI patch for Linux 2.4.4 (check patch-denx-linux-2.4-LABEL_2003_10_13_1740 in ftp://ftp.denx.de/pub/RTAI/old/24.1.12/). > and onemore chnage i did to code is > earlier it was SET_MODULE_OWNER(rtdev); > made as RTNET_SET_MODULE_OWNER(rtdev); This is fixed in more recent version of RTnet. > i got it compiled . but when i insmod i get the device or resource busy > , its not even entering the module , > > the sequence of insmod are as follows > /sbin/insmod rtai.o > /sbin/insmod rt_mem_rt_mgr.o > /sbin/insmod rtai_fifos.o > /sbin/insmod rtai_shm.o > /sbin/insmod rtai_sched.o > > for rtnet part > /sbin/insmod rtai_rtdm.o > /sbin/insmod rtnet.o > /sbin/insmod rt_mpc8xx_enet.o > thorows device or reosurce busy > is it that i am missing some parameters for module , or irq number ? Please check the output of "cat /proc/interrupts" to see if the CPM interrupts are visible. If not you need to backport the corresponing CPM part from Linux 2.4.25. Wolfgang. > > tahnks in advance > Neelu > --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] rtnet ethernet driver
On 09/27/2005 10:09 PM [EMAIL PROTECTED] wrote: > > Hi Wolfgang , > > Thanks for the advice, > now i am in a bit of confusion , > as I am not compiling the driver as module normal linux enet driver , > and for rtnet to get it up , i need to compile it as a module , i mean > to say as i am not compiling this driver at all how will the symbols of > this will get exported ? > or is it in commproc.c , u say these symbols will be avilable to the rtnet > module , correct me please , You cannot compile the normal Linux enet driver as module because it's not supported. But for RTnet, a module must be loaded to provide the required functionality. Therefore you have to export the missing symbols in ppc_ksym.c: EXPORT_SYMBOL(cpmp); EXPORT_SYMBOL(m8xx_cpm_hostalloc); EXPORT_SYMBOL(m8xx_cpm_dpalloc); EXPORT_SYMBOL(m8xx_cpm_dpfree); ... EXPORT_SYMBOL(consistent_alloc); EXPORT_SYMBOL(consistent_free); And do not forget to disable the "enet" driver in the kernel. The README.rtnet at ftp://ftp.denx.de/pub/RTAI/old/24.1.12/ might be useful, even if it's not up to date. > yes i would like to go higher vesrion , as our project needs to meet > deadline , i need to make many chnages with higher version of kernel , yes > but will take it up after sometime . OK, good luck. Wolfgang. > > > > > (Embedded Wolfgang Grandegger <[EMAIL PROTECTED]>@lists.sourceforge.net > > image moved 09/28/2005 12:44 AM > > to file: > > pic14962.pcx) > > > > > > > > Sent by:[EMAIL PROTECTED] > > > To:[EMAIL PROTECTED] > cc:[EMAIL PROTECTED], [EMAIL PROTECTED], >rtnet-users@lists.sourceforge.net, [EMAIL PROTECTED] > Subject:Re: [RTnet-users] rtnet ethernet driver > > Security Level:? Internal > > On 09/27/2005 05:39 PM [EMAIL PROTECTED] wrote: >> >> hi , >> I am newbie to rtai and rtnet , >> onmy custom controller i am running linux-2.4.19 ,with rtai24.2.12 and >> rtnet-0.8.0 , on mpc862 >> first problem i faced when insmod rtai-rtdm.o is , it says resource not >> avialble temporarily , then i found in the code , its not able to make >> entry in proc it was failing create_proc_entry , i disabled > CONFIG_PROC_FS >> , i got rtai-rtdm working , later got rtnet.o working , is this the > correct >> soulution ? >> now when i try to insmod rt_mpc8xx_enet.o >> i get this >> >> Using rt_mpc8xx_enet.o >> insmod: unresolved symbol m8xx_cpm_dpalloc >> insmod: unresolved symbol consistent_alloc >> insmod: unresolved symbol m8xx_cpm_dpfree >> insmod: unresolved symbol cpmp >> >> is it that i needto EXPORT_SYMBOL in arch/ppc/kernel/ppc_ksysm.c file , >> correct me if am wrong , or what else i am missing . > > You are right. The missing symbols have to be exported in ppc_ksysm.c > like it is already done inthe DENX linuxppc_2_4_devel tree (have a look > to http://www.denx.de). It may also make sense to update to a more > recent version of Linux 2.4. Furthermore I recommand to use RTnet > version 0.8.3 and RTAI 24.1.13 from the RTAI "stromboli" CVS branch. > > Wolfgang. > >> >> Thanks In Advance >> neelu >> >> >> >> >> >> --- >> This SF.Net email is sponsored by: >> Power Architecture Resource Center: Free content, downloads, discussions, >> and more. http://solutions.newsforge.com/ibmarch.tmpl >> ___ >> RTnet-users mailing list >> RTnet-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/rtnet-users >> >> > > > > --- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > ___ > RTnet-users mailing list > RTnet-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/rtnet-users > > > --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] rtnet ethernet driver
On 09/27/2005 05:39 PM [EMAIL PROTECTED] wrote: > > hi , > I am newbie to rtai and rtnet , > onmy custom controller i am running linux-2.4.19 ,with rtai24.2.12 and > rtnet-0.8.0 , on mpc862 > first problem i faced when insmod rtai-rtdm.o is , it says resource not > avialble temporarily , then i found in the code , its not able to make > entry in proc it was failing create_proc_entry , i disabled CONFIG_PROC_FS > , i got rtai-rtdm working , later got rtnet.o working , is this the correct > soulution ? > now when i try to insmod rt_mpc8xx_enet.o > i get this > > Using rt_mpc8xx_enet.o > insmod: unresolved symbol m8xx_cpm_dpalloc > insmod: unresolved symbol consistent_alloc > insmod: unresolved symbol m8xx_cpm_dpfree > insmod: unresolved symbol cpmp > > is it that i needto EXPORT_SYMBOL in arch/ppc/kernel/ppc_ksysm.c file , > correct me if am wrong , or what else i am missing . You are right. The missing symbols have to be exported in ppc_ksysm.c like it is already done inthe DENX linuxppc_2_4_devel tree (have a look to http://www.denx.de). It may also make sense to update to a more recent version of Linux 2.4. Furthermore I recommand to use RTnet version 0.8.3 and RTAI 24.1.13 from the RTAI "stromboli" CVS branch. Wolfgang. > > Thanks In Advance > neelu > > > > > > --- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > ___ > RTnet-users mailing list > RTnet-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/rtnet-users > > --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Problems setting up RT network
On 07/06/2005 07:18 PM Jan Kiszka wrote:
> Wolfgang Grandegger wrote:
>> ...
>> I found the problem:
>>
>> /* Get and patch time stamp just before the transmission */
>> if (skb->xmit_stamp) {
>> rtos_get_time(&time);
>> rtos_print("xmit_stamp=%#Lx -> ", *skb->xmit_stamp);
>> *skb->xmit_stamp = cpu_to_be64
>> rtos_time_to_nanosecs(&time) +
>> *skb->xmit_stamp);
>> rtos_print("%#Lx\n", *skb->xmit_stamp);
>> }
>>
>> /* Push the data cache so the CPM does not get stale memory
>> * data.
>> */
>> flush_dcache_range((unsigned long)skb->data,
>> (unsigned long)skb->data + skb->len);
>>
>> The "flush_dcache_range" was before modifying skb->xmit_stamp. I was not
>> aware, that it's pointing to skb's data :-(.
>>
>
> ...and as the packets were sniffed on the sender side, the correct copy
> made it into the dump. Fine, another problem solved. :)
Yes, it was a nice cache problem. Thanks for help.
> Then please let me know when your tests with the new driver run fine so
> that we can roll out a 0.8.3. With the upcoming official RTDM, we need
> some reorganisation work (=>0.9), and I would like to have a cut first.
OK, I want to finish the MPC 52xx driver development end of this week
anyhow.
Wolfgang.
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Problems setting up RT network
On 07/05/2005 11:51 PM Jan Kiszka wrote:
> Jan Kiszka wrote:
>>> ...
>>> Also on my MPC860 module I see large calibrated master-to-slave packet
>>> delays. 440 seconds, this looks like an endianess problem or a wrong
>>> (64-bit?) calculation.
>>>
>>
>> Oops. Ok, let's wait for the binary dump - and what Ethereal dissects.
>>
>
> The dump revealed that there is some problem on the master side (you can
> follow this explanations by opening your dump in a recent Ethereal):
>
> The slave sends its calibration requests including a "Transmission Time
> Stamp". This value should be copied by the master on reception into the
> calibration reply frame ("Request Transmission Time"). For unknown
> reasons, this field is always 0 in your dump. All systems I tested so
> far did not show this effect (ok, all were x86). It immediately leads to
> such exorbitant round-trip delays.
>
> Could you try to debug this further? The involved code in the TDMA
> module can be found here:
>
> http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/rtmac/tdma/tdma_proto.c#L261
>
> The copy is performed in line 297. Please check if the value is
> correctly transfered and probably overwritten afterwards (in the 3com
> driver?) or if 0 is already contained in the reply frame.
I found the problem:
/* Get and patch time stamp just before the transmission */
if (skb->xmit_stamp) {
rtos_get_time(&time);
rtos_print("xmit_stamp=%#Lx -> ", *skb->xmit_stamp);
*skb->xmit_stamp = cpu_to_be64
rtos_time_to_nanosecs(&time) +
*skb->xmit_stamp);
rtos_print("%#Lx\n", *skb->xmit_stamp);
}
/* Push the data cache so the CPM does not get stale memory
* data.
*/
flush_dcache_range((unsigned long)skb->data,
(unsigned long)skb->data + skb->len);
The "flush_dcache_range" was before modifying skb->xmit_stamp. I was not
aware, that it's pointing to skb's data :-(.
Thanks.
Wolfgang.
> Thanks again for your help,
> Jan
>
>
> ---
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> ___
> RTnet-users mailing list
> RTnet-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rtnet-users
>
>
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Problems setting up RT network
On 07/05/2005 11:51 PM Jan Kiszka wrote:
> Jan Kiszka wrote:
>>> ...
>>> Also on my MPC860 module I see large calibrated master-to-slave packet
>>> delays. 440 seconds, this looks like an endianess problem or a wrong
>>> (64-bit?) calculation.
>>>
>>
>> Oops. Ok, let's wait for the binary dump - and what Ethereal dissects.
>>
>
> The dump revealed that there is some problem on the master side (you can
> follow this explanations by opening your dump in a recent Ethereal):
>
> The slave sends its calibration requests including a "Transmission Time
> Stamp". This value should be copied by the master on reception into the
> calibration reply frame ("Request Transmission Time"). For unknown
> reasons, this field is always 0 in your dump. All systems I tested so
> far did not show this effect (ok, all were x86). It immediately leads to
> such exorbitant round-trip delays.
>
> Could you try to debug this further? The involved code in the TDMA
> module can be found here:
>
> http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/rtmac/tdma/tdma_proto.c#L261
>
> The copy is performed in line 297. Please check if the value is
> correctly transfered and probably overwritten afterwards (in the 3com
> driver?) or if 0 is already contained in the reply frame.
The value of REQ_CAL_FRM(head)->xmit_stamp) is already 0. The first 10
long-words at "head" are:
head d470c954 head->xmit_stamp d470c958
0x1102 0x0 0x0 0x9501 0x0 0x20a10700 0x0 0x0 0x0 0x0
Strange... I also see the same data in the RX buffer of 3com RTnet
driver. More soon...
Thanks.
Wolfgang.
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Problems setting up RT network
Hi Jan, I have now a working version of tcpdump running on my PPC targets... On 07/02/2005 11:17 AM Jan Kiszka wrote: > Wolfgang Grandegger wrote: >> ... >> OK, now I have another strange behaviour when TDMA is loaded. With >> rtnet, rt_3c59x/rt_mpc52xx_fec and rtcfg loaded I get: >> >> [EMAIL PROTECTED] modules]# rtping 10.0.0.2 >> Real-time PING 10.0.0.2 56(84) bytes of data. >> 64 bytes from 10.0.0.2: icmp_seq=1 time=430.2 us >> 64 bytes from 10.0.0.2: icmp_seq=2 time=408.4 us >> 64 bytes from 10.0.0.2: icmp_seq=3 time=394.6 us >> >> and also the round-trip-test returns reasonable values: >> >> # showtime >> Roundtrip = 413us (min: 413us, max: 413us) >> Roundtrip = 339us (min: 339us, max: 413us) >> Roundtrip = 349us (min: 339us, max: 413us) >> >> But with TDMA running (via "rtnet start") I get on the RTnet slave: >> >> Stage 1: searching for master...+/usr/realtime/sbin/rtcfg rteth0 >> client -c >> +/bin/sh -c >>TDMACFG=/usr/realtime/sbin/tdmacfg;IPADDR=10.0.0.2;NETMASK_OPT=""; >>$TDMACFG rteth0 slot 0 500;ifconfig vnic0 up $IPADDR $NETMASK_OPT > > Mmh, this internal batch of commands should not be dumped to the screen. > What shell do you use on your target box? standard or busybox bash? At > least those two are tested and should work. Anyway, cosmetic effect. > >>TDMA: calibrated master-to-slave packet delay: 61557080 us (min/max: >>61309526/61 804640 us) >> > > Well, this is alarming. Something goes wrong during the calibration, at > least when printing the results. Could you capture the calibration phase > on the slave with RTcap+tcpdump and send me the result? > Attached is the output of "tcpdump -i rteth0" for the startup: bash-2.05b# rtnet -cf ../etc/rtnet-tqm860l.conf start *** RTnet 0.8.3 - built on Jul 5 2005 17:37:45 *** RTnet: initialising real-time networking RTnet: stack-mgr started RTDM: registered protocol device 2:2 RTDM: registered protocol device 17:2 RTnet: registered rteth0 RTnet: rteth0: FEC ENET Version 0.3, irq 9, addr 00:d0:93:80:03:54 initializing loopback... RTnet: registered rtlo RTcap: real-time capturing interface RTcfg: init real-time configuration distribution protocol RTmac: init realtime media access control RTmac/TDMA: init time division multiple access control mechanism RTDM: registered named device TDMA0 Stage 1: searching for master...TDMA: calibrated master-to-slave packet delay: 439754586 us (min/max: 439506992/440002182 us) Stage 2: waiting for other slaves... Stage 3: waiting for common setup completion... Also on my MPC860 module I see large calibrated master-to-slave packet delays. 440 seconds, this looks like an endianess problem or a wrong (64-bit?) calculation. >> >> and then ping returns rather long delay and big fluctuations: >> >> [EMAIL PROTECTED] modules]# rtping 10.0.0.2 >> Real-time PING 10.0.0.2 56(84) bytes of data. >> 64 bytes from 10.0.0.2: icmp_seq=1 time=5394.8 us >> 64 bytes from 10.0.0.2: icmp_seq=2 time=9436.8 us >> 64 bytes from 10.0.0.2: icmp_seq=3 time=8433.4 us >> >> I use TDMA_CYCLE=5000 and TDMA_OFFSET=500. Therefore a packet should be >> sent every 5ms. >> > > At least the three round-trips above are normal. Note that your ping is > out of sync with the TDMA cycle, thus the ping request first have to > wait up to a full cycle to get sent. And then the reply may also have to > be defered on the target side (depends on the slot order of ping sender > and receiver and on the time between the slots). > > Jan > > > --- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > ___ > RTnet-users mailing list > RTnet-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/rtnet-users > > tcpdump-slave-start.log.gz Description: GNU Zip compressed data
Re: [RTnet-users] Problems setting up RT network
On 07/05/2005 06:29 PM Jan Kiszka wrote: > Jan Kiszka wrote: >>> RTmac: init realtime media access control >>> RTmac/TDMA: init time division multiple access control mechanism >>> RTDM: registered named device TDMA0 >>> Stage 1: searching for master...TDMA: calibrated master-to-slave >>> packet delay: 439754586 us (min/max: 439506992/440002182 us) >>> > > I forgot to mention a nice feature of tdmacfg: you can generate a log > file of all round-trip times measured during calibration. Just add the > "-l logfile" parameter to "tdmacfg rteth0 slot..." on the slave side. You mean, on the master side, which sends a tdmacfg command to the slave(s). Below, I have attached the log file. I will have a closer look myself later on this week. Thanks, Wolfgang. bash-2.05b# rtnet -cf ../etc/rtnet-tqm860l.conf start *** RTnet 0.8.3 - built on Jul 5 2005 17:37:45 *** RTnet: initialising real-time networking RTnet: stack-mgr started RTDM: registered protocol device 2:2 RTDM: registered protocol device 17:2 RTnet: registered rteth0 RTnet: rteth0: FEC ENET Version 0.3, irq 9, addr 00:d0:93:80:03:54 initializing loopback... RTnet: registered rtlo RTcap: real-time capturing interface RTcfg: init real-time configuration distribution protocol RTmac: init realtime media access control RTmac/TDMA: init time division multiple access control mechanism RTDM: registered named device TDMA0 Stage 1: searching for master...log_filename=/tmp/tdma1.log result_size=100 TDMA: calibrated master-to-slave packet delay: -920425119 us (min/max: -920672716/-920177525 us) Stage 2: waiting for other slaves... Stage 3: waiting for common setup completion... 7669261875879 7669266883855 7669271886150 7669276889081 7669281888009 7669286891186 7669291891391 7669296894438 7669301893872 7669306898600 7669311897174 7669316900944 7669321900378 7669326903690 7669331904192 7669336907294 7669341911343 7669346912537 7669351912096 7669356914502 7669361915551 7669366918886 7669371920029 7669376922688 7669381923881 7669386924325 7669391927248 7669396927542 7669401931812 7669406932726 7669411938069 7669416938263 7669421939367 7669426940626 7669431942789 7669436943999 7669441947137 7669446947569 7669451950287 7669456951303 7669461954111 7669466954631 7669471958367 7669476958061 7669481961802 7669486965868 7669491968410 7669496966688 7669501969751 7669506970890 7669511973004 7669516974191 7669521977762 7669526977496 7669531981107 7669536981702 7669541984645 7669546985553 7669551988715 7669556993002 7669562016025 7669567002325 7669571999561 7669577020415 7669582010177 7669587000729 7669592002566 7669597004749 7669602008522 7669607010310 7669612012550 7669617012994 7669622012637 7669627020784 7669632021811 7669637021288 7669642022151 7669647024981 7669652025319 7669657028054 7669662028352 7669667031949 7669672032550 7669677035375 7669682037936 7669687038568 7669692040154 7669697049335 7669702048407 7669707045460 7669712048558 7669717050778 7669722053357 7669727055128 7669732056438 7669737059710 7669742061444 7669747062468 7669752065511 7669757066699
Re: [RTnet-users] Problems setting up RT network
On 07/02/2005 11:17 AM Jan Kiszka wrote: > Wolfgang Grandegger wrote: >> ... >> OK, now I have another strange behaviour when TDMA is loaded. With >> rtnet, rt_3c59x/rt_mpc52xx_fec and rtcfg loaded I get: >> >> [EMAIL PROTECTED] modules]# rtping 10.0.0.2 >> Real-time PING 10.0.0.2 56(84) bytes of data. >> 64 bytes from 10.0.0.2: icmp_seq=1 time=430.2 us >> 64 bytes from 10.0.0.2: icmp_seq=2 time=408.4 us >> 64 bytes from 10.0.0.2: icmp_seq=3 time=394.6 us >> >> and also the round-trip-test returns reasonable values: >> >> # showtime >> Roundtrip = 413us (min: 413us, max: 413us) >> Roundtrip = 339us (min: 339us, max: 413us) >> Roundtrip = 349us (min: 339us, max: 413us) >> >> But with TDMA running (via "rtnet start") I get on the RTnet slave: >> >> Stage 1: searching for master...+/usr/realtime/sbin/rtcfg rteth0 >> client -c >> +/bin/sh -c >>TDMACFG=/usr/realtime/sbin/tdmacfg;IPADDR=10.0.0.2;NETMASK_OPT=""; >>$TDMACFG rteth0 slot 0 500;ifconfig vnic0 up $IPADDR $NETMASK_OPT > > Mmh, this internal batch of commands should not be dumped to the screen. > What shell do you use on your target box? standard or busybox bash? At > least those two are tested and should work. Anyway, cosmetic effect. I use the busybox shell "msh" which cannot execute the RTnet scripts :-(: Therefore I had to modify "rtnet" to some extend and I enabled debug output. There seems not to be a "bash" in older verions (0.65 which comes with the ELDK) of busybox, but I have to check. >>TDMA: calibrated master-to-slave packet delay: 61557080 us (min/max: >>61309526/61 804640 us) >> > > Well, this is alarming. Something goes wrong during the calibration, at > least when printing the results. Could you capture the calibration phase > on the slave with RTcap+tcpdump and send me the result? Till now I have no idea on how to do that. Needs some more time. >> >> and then ping returns rather long delay and big fluctuations: >> >> [EMAIL PROTECTED] modules]# rtping 10.0.0.2 >> Real-time PING 10.0.0.2 56(84) bytes of data. >> 64 bytes from 10.0.0.2: icmp_seq=1 time=5394.8 us >> 64 bytes from 10.0.0.2: icmp_seq=2 time=9436.8 us >> 64 bytes from 10.0.0.2: icmp_seq=3 time=8433.4 us >> >> I use TDMA_CYCLE=5000 and TDMA_OFFSET=500. Therefore a packet should be >> sent every 5ms. >> > > At least the three round-trips above are normal. Note that your ping is > out of sync with the TDMA cycle, thus the ping request first have to > wait up to a full cycle to get sent. And then the reply may also have to > be defered on the target side (depends on the slot order of ping sender > and receiver and on the time between the slots). Ah, OK. I could sucessfully run telnet through vnic0. I will try a NFS mount later on. What else can I test? The MPC 52xx FEC driver seems to work basically but I have still some problem with link management at startup. Thanks and have a nice weekend. Wolfgang. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Problems setting up RT network
On 07/01/2005 06:21 PM Jan Kiszka wrote: > Wolfgang Grandegger wrote: >>> >>>Don't remember when this driver last transfered some packets >>>successfully. It was a contribution that we were never able to test and >>>maintain here. And then there are those documented RT issues due to >>>potential long delays in IRQ or xmit context. >> >> >> OK, I'm a beat tester for this card... When I have my MPC 52xx driver >> working I will have a closer look. >> > > Great! > >> ... >> No, I have two RT ethernet interfaces connected with a cross over cable. >> And the I just do rtping on the local (or remote) side: >> >> # insmod rtnet.o >> # insmod rt_mpc52xx_fec.o >> # rtifconfig rteth0 up 10.0.0.2 >> # rtroute solicit 10.0.0.1 dev rteth0 >> # rtping 10.0.0.1 >> Real-time PING 10.0.0.1 56(84) bytes of data. >> mpc5xxx_fec_hard_start_xmit: >> dev c34b4800, priv c34b4900, skb c340c040 >> Outgoing data @c340c0a0, length 0062: >> : 0001027a 37c90002 b3cb5bf8 08004500 >> 0010: 0054 4000ff01 67a60a00 00020a00 >> 0020: 00010800 f81cd59f 0001 >> 0030: 0001 02030405 06070809 0a0b0c0d >> 0040: 0e0f1011 12131415 16171819 1a1b1c1d >> 0050: 1e1f2021 22232425 26272829 2a2b2c2d >> 0060: 2e2f2e2f c340c162 c340c150 c340c140 >> mpc5xxx_sdma_transmit_interrupt: >> dev c34b4800, priv c34b4900 >> mpc5xxx_sdma_receive_interrupt: >> status 0866, skb c3413480, rbuf c34134e0 >> Incoming rbuf, length: 0066 >> : 0002b3cb 5bf80001 027a37c9 08004500 >> 0010: 0054007e 4000ff01 67280a00 00010a00 >> 0020: 0002 001dd59f 0001 >> 0030: 0001 02030405 06070809 0a0b0c0d >> 0040: 0e0f1011 12131415 16171819 1a1b1c1d >> 0050: 1e1f2021 22232425 26272829 2a2b2c2d >> 0060: 2e2f4965 b86eb86e >> RTnet: unknown layer-3 protocol >> 64 bytes from 10.0.0.1: icmp_seq=1 time=0.0 us >> ... >> >> >> Do you see an obvious problem with the received data (with your RTnet >> sensitive eyes)? >> > > No, I don't. The layer-3 protocol ID is 0x0800 - IPv4. And if this were > unknown to the stack, you would not see the ping reply. Strange. > > And you are definitely using latest SVN? Have a look at do_stacktask() > in stack/stack_mgr.c: in case pt_entry->handler() was called (i.e. the > ping reply was received), you should not get to the line where that > infamous message is generated. Updating to todays SVN revision fixed the problem. > >> I'm also puzzled why the time is 0.0. >> > > RTAI timer is not running. Insert rtcfg.ko e.g. to get it started (even > if you don't use RTcfg). OK, now I have another strange behaviour when TDMA is loaded. With rtnet, rt_3c59x/rt_mpc52xx_fec and rtcfg loaded I get: [EMAIL PROTECTED] modules]# rtping 10.0.0.2 Real-time PING 10.0.0.2 56(84) bytes of data. 64 bytes from 10.0.0.2: icmp_seq=1 time=430.2 us 64 bytes from 10.0.0.2: icmp_seq=2 time=408.4 us 64 bytes from 10.0.0.2: icmp_seq=3 time=394.6 us and also the round-trip-test returns reasonable values: # showtime Roundtrip = 413us (min: 413us, max: 413us) Roundtrip = 339us (min: 339us, max: 413us) Roundtrip = 349us (min: 339us, max: 413us) But with TDMA running (via "rtnet start") I get on the RTnet slave: Stage 1: searching for master...+/usr/realtime/sbin/rtcfg rteth0 client -c +/bin/sh -c TDMACFG=/usr/realtime/sbin/tdmacfg;IPADDR=10.0.0.2;NETMASK_OPT=""; $TDMACFG rteth0 slot 0 500;ifconfig vnic0 up $IPADDR $NETMASK_OPT TDMA: calibrated master-to-slave packet delay: 61557080 us (min/max: 61309526/61 804640 us) and then ping returns rather long delay and big fluctuations: [EMAIL PROTECTED] modules]# rtping 10.0.0.2 Real-time PING 10.0.0.2 56(84) bytes of data. 64 bytes from 10.0.0.2: icmp_seq=1 time=5394.8 us 64 bytes from 10.0.0.2: icmp_seq=2 time=9436.8 us 64 bytes from 10.0.0.2: icmp_seq=3 time=8433.4 us I use TDMA_CYCLE=5000 and TDMA_OFFSET=500. Therefore a packet should be sent every 5ms. Any hints are welcome. Thanks. Wolfgang. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Problems setting up RT network
On 07/01/2005 06:21 PM Jan Kiszka wrote: > Wolfgang Grandegger wrote: >>> >>>Don't remember when this driver last transfered some packets >>>successfully. It was a contribution that we were never able to test and >>>maintain here. And then there are those documented RT issues due to >>>potential long delays in IRQ or xmit context. >> >> >> OK, I'm a beat tester for this card... When I have my MPC 52xx driver >> working I will have a closer look. >> > > Great! > >> ... >> No, I have two RT ethernet interfaces connected with a cross over cable. >> And the I just do rtping on the local (or remote) side: >> >> # insmod rtnet.o >> # insmod rt_mpc52xx_fec.o >> # rtifconfig rteth0 up 10.0.0.2 >> # rtroute solicit 10.0.0.1 dev rteth0 >> # rtping 10.0.0.1 >> Real-time PING 10.0.0.1 56(84) bytes of data. >> mpc5xxx_fec_hard_start_xmit: >> dev c34b4800, priv c34b4900, skb c340c040 >> Outgoing data @c340c0a0, length 0062: >> : 0001027a 37c90002 b3cb5bf8 08004500 >> 0010: 0054 4000ff01 67a60a00 00020a00 >> 0020: 00010800 f81cd59f 0001 >> 0030: 0001 02030405 06070809 0a0b0c0d >> 0040: 0e0f1011 12131415 16171819 1a1b1c1d >> 0050: 1e1f2021 22232425 26272829 2a2b2c2d >> 0060: 2e2f2e2f c340c162 c340c150 c340c140 >> mpc5xxx_sdma_transmit_interrupt: >> dev c34b4800, priv c34b4900 >> mpc5xxx_sdma_receive_interrupt: >> status 0866, skb c3413480, rbuf c34134e0 >> Incoming rbuf, length: 0066 >> : 0002b3cb 5bf80001 027a37c9 08004500 >> 0010: 0054007e 4000ff01 67280a00 00010a00 >> 0020: 0002 001dd59f 0001 >> 0030: 0001 02030405 06070809 0a0b0c0d >> 0040: 0e0f1011 12131415 16171819 1a1b1c1d >> 0050: 1e1f2021 22232425 26272829 2a2b2c2d >> 0060: 2e2f4965 b86eb86e >> RTnet: unknown layer-3 protocol >> 64 bytes from 10.0.0.1: icmp_seq=1 time=0.0 us >> ... >> >> >> Do you see an obvious problem with the received data (with your RTnet >> sensitive eyes)? >> > > No, I don't. The layer-3 protocol ID is 0x0800 - IPv4. And if this were > unknown to the stack, you would not see the ping reply. Strange. > > And you are definitely using latest SVN? Have a look at do_stacktask() > in stack/stack_mgr.c: in case pt_entry->handler() was called (i.e. the > ping reply was received), you should not get to the line where that > infamous message is generated. Well, on my PowerPC target I use an older version of RTnet 0.8.3 from 18th of June. I'm going to update it tomorrow. > >> I'm also puzzled why the time is 0.0. >> > > RTAI timer is not running. Insert rtcfg.ko e.g. to get it started (even > if you don't use RTcfg). Ah, OK. Thanks for the hints. Wolfgang. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Problems setting up RT network
On 07/01/2005 10:54 AM Jan Kiszka wrote: > Wolfgang Grandegger wrote: >> On 06/30/2005 10:35 AM Jan Kiszka wrote: >> >>>Wolfgang Grandegger wrote: >>> >>>>OK, I realized as well, that I stumbeled over untested code. For some >>> >>>Why the heck is this driver located in drivers/experimental? ;) >>> >>> >>>>reason the kernel of FC 2 uses "zero-copy". I disabled DD_ZEROCOPY and >>> >>>Could you check this modification in? It seems to be another unwanted >>>dependency on the Linux kernel config. >> >> >> Well, in the driver rt_3c59.c there is: >> >> #ifdef MAX_SKB_FRAGS >> #define DO_ZEROCOPY 1 >> #else >> #define DO_ZEROCOPY 0 >> #endif >> >> And MAX_SKB_FRAGS is set somewhere in the Linux kernel, for all kernels >> I guess. Well, I'm really puzzled how the rt_3c59 driver already worked >> ... good luck accessing invalid memory space? >> > > Don't remember when this driver last transfered some packets > successfully. It was a contribution that we were never able to test and > maintain here. And then there are those documented RT issues due to > potential long delays in IRQ or xmit context. OK, I'm a beat tester for this card... When I have my MPC 52xx driver working I will have a closer look. >> >>>>now it works. Is the rtskb memory contiguous? How is it allocated? >>>>Actually what the DMA engine of the 3c59 needs is a chain of memory >>>>chunk address and size. I will look into this later on. >>>> >>> >>>rtskbs, including the contained payload buffer, are allocated via >>>kmalloc. Therefore, the buffer consists of contignous memory and should >>>cause no DMA problems. >> >> >> OK. Then there is no need for the frags stuff, as I see it today. >> >> BTW: on my PowerPC test target I get frequently the message: >> >>RTnet: unknown layer-3 protocol >> >> Is the reason for is known? Corrupted data? >> > > This indicates that packet arrive for which no handling protocol driver > is registered. Are you testing on a "public" (non-rt) network? Then this > is normal. No, I have two RT ethernet interfaces connected with a cross over cable. And the I just do rtping on the local (or remote) side: # insmod rtnet.o # insmod rt_mpc52xx_fec.o # rtifconfig rteth0 up 10.0.0.2 # rtroute solicit 10.0.0.1 dev rteth0 # rtping 10.0.0.1 Real-time PING 10.0.0.1 56(84) bytes of data. mpc5xxx_fec_hard_start_xmit: dev c34b4800, priv c34b4900, skb c340c040 Outgoing data @c340c0a0, length 0062: : 0001027a 37c90002 b3cb5bf8 08004500 0010: 0054 4000ff01 67a60a00 00020a00 0020: 00010800 f81cd59f 0001 0030: 0001 02030405 06070809 0a0b0c0d 0040: 0e0f1011 12131415 16171819 1a1b1c1d 0050: 1e1f2021 22232425 26272829 2a2b2c2d 0060: 2e2f2e2f c340c162 c340c150 c340c140 mpc5xxx_sdma_transmit_interrupt: dev c34b4800, priv c34b4900 mpc5xxx_sdma_receive_interrupt: status 0866, skb c3413480, rbuf c34134e0 Incoming rbuf, length: 0066 : 0002b3cb 5bf80001 027a37c9 08004500 0010: 0054007e 4000ff01 67280a00 00010a00 0020: 0002 001dd59f 0001 0030: 0001 02030405 06070809 0a0b0c0d 0040: 0e0f1011 12131415 16171819 1a1b1c1d 0050: 1e1f2021 22232425 26272829 2a2b2c2d 0060: 2e2f4965 b86eb86e RTnet: unknown layer-3 protocol 64 bytes from 10.0.0.1: icmp_seq=1 time=0.0 us ... Do you see an obvious problem with the received data (with your RTnet sensitive eyes)? I'm also puzzled why the time is 0.0. Wolfgang. > Jan > > > --- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > ___ > RTnet-users mailing list > RTnet-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/rtnet-users > > --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Problems setting up RT network
On 06/30/2005 10:35 AM Jan Kiszka wrote: > Wolfgang Grandegger wrote: >> >> OK, I realized as well, that I stumbeled over untested code. For some > > Why the heck is this driver located in drivers/experimental? ;) > >> reason the kernel of FC 2 uses "zero-copy". I disabled DD_ZEROCOPY and > > Could you check this modification in? It seems to be another unwanted > dependency on the Linux kernel config. Well, in the driver rt_3c59.c there is: #ifdef MAX_SKB_FRAGS #define DO_ZEROCOPY 1 #else #define DO_ZEROCOPY 0 #endif And MAX_SKB_FRAGS is set somewhere in the Linux kernel, for all kernels I guess. Well, I'm really puzzled how the rt_3c59 driver already worked ... good luck accessing invalid memory space? >> now it works. Is the rtskb memory contiguous? How is it allocated? >> Actually what the DMA engine of the 3c59 needs is a chain of memory >> chunk address and size. I will look into this later on. >> > > rtskbs, including the contained payload buffer, are allocated via > kmalloc. Therefore, the buffer consists of contignous memory and should > cause no DMA problems. OK. Then there is no need for the frags stuff, as I see it today. BTW: on my PowerPC test target I get frequently the message: RTnet: unknown layer-3 protocol Is the reason for is known? Corrupted data? Thanks. Wolfgang. > > Jan > > --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Problems setting up RT network
On 06/29/2005 11:45 PM Jan Kiszka wrote:
> Wolfgang Grandegger wrote:
>> ...
>> I was rigt, The problem is with "frags" in rt_3c59.c":
>
> Oh, yes, our old friend again. :)
>
>>
>>for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
>> skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
>>
>> vp->tx_ring[entry].frag[i+1].addr =
>> // *** RTnet: page mapping correct? Or is this code never used?
>> cpu_to_le32(pci_map_single(vp->pdev,
>>
>> (void*)page_address(frag->page) +
>> frag->page_offset,
>> frag->size, PCI_DMA_TODEVICE));
>>
>> What memory is actually used for the RTnet skb's?
>>
>
> The usage of skb_shinfo is illegal with real-time skbs (rtskbs). It
> assumes that there is some skb_shared_info struct at the end of the
> payload buffer. But rtskbs are not shared as normal skbs between several
> users. Thus, the assumption for RTnet should be that always only a
> single fragment exists and that the rtskb at hand already describes it.
> But I don't know yet how to apply this to the 3c59x code.
OK, I realized as well, that I stumbeled over untested code. For some
reason the kernel of FC 2 uses "zero-copy". I disabled DD_ZEROCOPY and
now it works. Is the rtskb memory contiguous? How is it allocated?
Actually what the DMA engine of the 3c59 needs is a chain of memory
chunk address and size. I will look into this later on.
Thank.
Wolfgang.
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Problems setting up RT network
On 06/29/2005 06:19 PM Wolfgang Grandegger wrote:
> On 06/29/2005 06:03 PM Jan Kiszka wrote:
>> Wolfgang Grandegger wrote:
>>>>
>>>>When did you last update your SVN checkout, i.e. which revision do you
>>>>use? Yesterday I fixed an ugly bug in the reception path that was
>>>>introduced after 0.8.2 release.
>>>
>>> Today at 16:14:
>>>
>>> /temp/rtai$ ls -ld trunk/
>>> drwxr-xr-x 4 wolf badboys 4096 Jun 29 16:14 trunk/
>>>
>>> ~$ dmesg|tail
>>> ...
>>> *** RTnet 0.8.3 - built on Jun 29 2005 17:00:29 ***
>>>
>>
>> Damn, would have been too easy. :)
>>
>>> I'm going to update to a more recent version of RTAI/fusion. What
>>> version do you recommend?
>>>
>>
>> I'm typically testing against CVS, but at least anything with a 0.8 in
>> front should not cause troubles by itself. 0.7.3 is really a bit
>> "out-of-date".
>>
>> But let's have a look at your kernel console again:
>>
>>> RTmac/TDMA: init time division multiple access control mechanism
>>> RTDM: registered named device TDMA0
>>> divert: not allocating divert_blk for non-ethernet device vnic0
>>> RTAI: RTAI: suspending kernel thread ce725380 ('ce725380') at 0xc013b117
>>> after exception #14
>>
>> Please identify which thread is being supended, i.e. which module owned
>> it. RTcfg? Maybe there is problem in the transmission path, maybe even
>> in your driver? ;) And try to find out which module/function is behind
>> the crash address.
>>
>>> vnic0: no IPv6 routers present
>>> RTnet: host 10.0.0.2 unreachable
>>> RTnet: host 10.0.0.2 unreachable
>>> divert: no divert_blk to free, vnic0 not ethernet
>>> RTAI: RTAI: suspending kernel thread e0ac5c40 ('e0ac5c40') at 0xc013b117
>>> after exception #13
>>
>> Same address here, looks like the same bug.
>
> I'm already investigating. Also the following command does not return:
>
> $ rtroute solicit 10.0.0.2 dev rteth0
>
> and it thoughs the above exception:
>
> /temp/rtai/fusion-0.7.3/include/nucleus/asm-i386$ cat /proc/rtai/sched
> CPU PIDNAME PRI TIMEOUT STATUS
> 0 0 ROOT 0 0 0x00140080 - fpu
> 0 0 e0a07880 980 0x0081 - ssp
> 0 0 e0a08240 1 0 0x0082 - pnd
>
> Obviously the marked thread is making the trouble, which is started when
> rtnet.ko is loaded.
>
> Unfortunately, none of this is "my" software. I'm afraid, that the
> experimental driver 3c59x is the source of trouble.
>
> Wolfgang.
I was rigt, The problem is with "frags" in rt_3c59.c":
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
vp->tx_ring[entry].frag[i+1].addr =
// *** RTnet: page mapping correct? Or is this code never used?
cpu_to_le32(pci_map_single(vp->pdev,
(void*)page_address(frag->page) +
frag->page_offset,
frag->size, PCI_DMA_TODEVICE));
What memory is actually used for the RTnet skb's?
Wolfgang.
>>
>> Jan
>>
>>
>
>
>
> ---
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> ___
> RTnet-users mailing list
> RTnet-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rtnet-users
>
>
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Problems setting up RT network
On 06/29/2005 06:03 PM Jan Kiszka wrote:
> Wolfgang Grandegger wrote:
>>>
>>>When did you last update your SVN checkout, i.e. which revision do you
>>>use? Yesterday I fixed an ugly bug in the reception path that was
>>>introduced after 0.8.2 release.
>>
>> Today at 16:14:
>>
>> /temp/rtai$ ls -ld trunk/
>> drwxr-xr-x 4 wolf badboys 4096 Jun 29 16:14 trunk/
>>
>> ~$ dmesg|tail
>> ...
>> *** RTnet 0.8.3 - built on Jun 29 2005 17:00:29 ***
>>
>
> Damn, would have been too easy. :)
>
>> I'm going to update to a more recent version of RTAI/fusion. What
>> version do you recommend?
>>
>
> I'm typically testing against CVS, but at least anything with a 0.8 in
> front should not cause troubles by itself. 0.7.3 is really a bit
> "out-of-date".
>
> But let's have a look at your kernel console again:
>
>> RTmac/TDMA: init time division multiple access control mechanism
>> RTDM: registered named device TDMA0
>> divert: not allocating divert_blk for non-ethernet device vnic0
>> RTAI: RTAI: suspending kernel thread ce725380 ('ce725380') at 0xc013b117
>> after exception #14
>
> Please identify which thread is being supended, i.e. which module owned
> it. RTcfg? Maybe there is problem in the transmission path, maybe even
> in your driver? ;) And try to find out which module/function is behind
> the crash address.
>
>> vnic0: no IPv6 routers present
>> RTnet: host 10.0.0.2 unreachable
>> RTnet: host 10.0.0.2 unreachable
>> divert: no divert_blk to free, vnic0 not ethernet
>> RTAI: RTAI: suspending kernel thread e0ac5c40 ('e0ac5c40') at 0xc013b117
>> after exception #13
>
> Same address here, looks like the same bug.
I'm already investigating. Also the following command does not return:
$ rtroute solicit 10.0.0.2 dev rteth0
and it thoughs the above exception:
/temp/rtai/fusion-0.7.3/include/nucleus/asm-i386$ cat /proc/rtai/sched
CPU PIDNAME PRI TIMEOUT STATUS
0 0 ROOT 0 0 0x00140080 - fpu
0 0 e0a07880 980 0x0081 - ssp
0 0 e0a08240 1 0 0x0082 - pnd
Obviously the marked thread is making the trouble, which is started when
rtnet.ko is loaded.
Unfortunately, none of this is "my" software. I'm afraid, that the
experimental driver 3c59x is the source of trouble.
Wolfgang.
>
> Jan
>
>
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
Re: [RTnet-users] Problems setting up RT network
On 06/29/2005 05:45 PM Jan Kiszka wrote: > Wolfgang Grandegger wrote: >> Hello Jan, >> >> I'm now trying to setup a RT network using: >> >> 1. PIII/600MHz Laptop with rt_3c59x >> 2. MPC860L Module with rt_fec_enet >> 3. MPC5200 Module with rt_mpc52xx_fec >> >> rtping is basicall working but "rtnet start" does not complete on the >> target. >> >> First, I wonder about a few error messages on 1. (see attachment). Do >> they harm? At least I can not unload rtcfg with "rtnet stop". >> > > When did you last update your SVN checkout, i.e. which revision do you > use? Yesterday I fixed an ugly bug in the reception path that was > introduced after 0.8.2 release. Today at 16:14: /temp/rtai$ ls -ld trunk/ drwxr-xr-x 4 wolf badboys 4096 Jun 29 16:14 trunk/ ~$ dmesg|tail ... *** RTnet 0.8.3 - built on Jun 29 2005 17:00:29 *** I'm going to update to a more recent version of RTAI/fusion. What version do you recommend? Thanks. Wolfgang. > Jan > > --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
