rtnet-developers — development-related list

Re: [RTnet-developers] Ethernet IP

[Jan K. <jan...@si...>]

On 2011-02-09 17:31, Glen Wernersbach wrote:
> Jan, I did a kernel message while my send command was blocking 
> 
> It said 
> RTNET host 10.82.88.249 unreachable.
> 
> 10.82.88.249 is the NIC I received the packette on.

That, first of all, means you are lacking a host route from your RTnet
node to that target. Check with rtroute, see README.routing for more info.

But I was referring to that oops you mentioned under RTAI. It may point
to an issue in the stack.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [RTnet-developers] [PATCH] Build fixes for 2.6.36

[Wolfgang G. <wg...@gr...>]

On 02/09/2011 04:47 PM, Jan Kiszka wrote:
> On 2011-02-09 16:35, Wolfgang Grandegger wrote:
>> On 02/09/2011 01:25 PM, Jan Kiszka wrote:
>>> On 2011-02-09 13:08, Wolfgang Grandegger wrote:
>>>> On 02/09/2011 12:49 PM, Jan Kiszka wrote:
>>>>> On 2011-02-09 12:08, Wolfgang Grandegger wrote:
>>>>>> Signed-off-by: Wolfgang Grandegger <wg...@de...>
>>>>>> ---
>>>>>>  stack/include/rtnet_port.h |    9 +++++++++
>>>>>>  stack/ipv4/route.c         |    1 +
>>>>>>  stack/rtcfg/rtcfg_proc.c   |    1 +
>>>>>>  stack/rtnet_chrdev.c       |    9 +++++++++
>>>>>>  4 files changed, 20 insertions(+), 0 deletions(-)
>>>>>>

...

> Thanks, applied (and even pushed this time...).

Successfully pulled and tested.

Thanks,

Wolfgang.

Re: [RTnet-developers] [PATCH] Build fixes for 2.6.36

[Jan K. <jan...@si...>]

On 2011-02-09 16:35, Wolfgang Grandegger wrote:
> On 02/09/2011 01:25 PM, Jan Kiszka wrote:
>> On 2011-02-09 13:08, Wolfgang Grandegger wrote:
>>> On 02/09/2011 12:49 PM, Jan Kiszka wrote:
>>>> On 2011-02-09 12:08, Wolfgang Grandegger wrote:
>>>>> Signed-off-by: Wolfgang Grandegger <wg...@de...>
>>>>> ---
>>>>>  stack/include/rtnet_port.h |    9 +++++++++
>>>>>  stack/ipv4/route.c         |    1 +
>>>>>  stack/rtcfg/rtcfg_proc.c   |    1 +
>>>>>  stack/rtnet_chrdev.c       |    9 +++++++++
>>>>>  4 files changed, 20 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/stack/include/rtnet_port.h b/stack/include/rtnet_port.h
>>>>> index b47c0db..09101cc 100644
>>>>> --- a/stack/include/rtnet_port.h
>>>>> +++ b/stack/include/rtnet_port.h
>>>>> @@ -213,6 +213,15 @@ static inline void *netdev_priv(struct net_device *dev)
>>>>>  #define DMA_BIT_MASK(n)	(((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
>>>>>  #endif
>>>>>  
>>>>> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,35)
>>>>> +#define NIPQUAD(addr) \
>>>>> +        ((unsigned char *)&addr)[0],	\
>>>>> +	((unsigned char *)&addr)[1],	\
>>>>> +	((unsigned char *)&addr)[2],	\
>>>>> +	((unsigned char *)&addr)[3]
>>>>> +#define NIPQUAD_FMT "%u.%u.%u.%u"
>>>>> +#endif
>>>>> +
>>>>>  #endif /* __KERNEL__ */
>>>>>  
>>>>>  #endif /* __RTNET_PORT_H_ */
>>>>> diff --git a/stack/ipv4/route.c b/stack/ipv4/route.c
>>>>> index 2151686..505b32e 100644
>>>>> --- a/stack/ipv4/route.c
>>>>> +++ b/stack/ipv4/route.c
>>>>> @@ -26,6 +26,7 @@
>>>>>  #include <net/ip.h>
>>>>>  
>>>>>  #include <rtnet_internal.h>
>>>>> +#include <rtnet_port.h>
>>>>>  #include <rtnet_chrdev.h>
>>>>>  #include <ipv4/af_inet.h>
>>>>>  #include <ipv4/route.h>
>>>>> diff --git a/stack/rtcfg/rtcfg_proc.c b/stack/rtcfg/rtcfg_proc.c
>>>>> index 3d55d50..93aafd8 100644
>>>>> --- a/stack/rtcfg/rtcfg_proc.c
>>>>> +++ b/stack/rtcfg/rtcfg_proc.c
>>>>> @@ -24,6 +24,7 @@
>>>>>  
>>>>>  #include <rtdev.h>
>>>>>  #include <rtnet_internal.h>
>>>>> +#include <rtnet_port.h>
>>>>>  #include <rtcfg/rtcfg_conn_event.h>
>>>>>  #include <rtcfg/rtcfg_event.h>
>>>>>  #include <rtcfg/rtcfg_frame.h>
>>>>
>>>> OK for this.
>>>>
>>>>> diff --git a/stack/rtnet_chrdev.c b/stack/rtnet_chrdev.c
>>>>> index b0f2863..0d3fae3 100644
>>>>> --- a/stack/rtnet_chrdev.c
>>>>> +++ b/stack/rtnet_chrdev.c
>>>>> @@ -47,8 +47,13 @@ LIST_HEAD(ioctl_handlers);
>>>>>   * @request:
>>>>>   * @arg:
>>>>>   */
>>>>> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,35)
>>>>> +static long rtnet_ioctl(struct file *file,
>>>>> +			unsigned int request, unsigned long arg)
>>>>> +#else
>>>>>  static int rtnet_ioctl(struct inode *inode, struct file *file,
>>>>>                         unsigned int request, unsigned long arg)
>>>>> +#endif
>>>
>>> Any clever idea on how to handle this unconditionally?
>>
>> Actually... no. :)
>>
>>>
>>>>>  {
>>>>>      struct rtnet_ioctl_head head;
>>>>>      struct rtnet_device     *rtdev = NULL;
>>>>> @@ -286,7 +291,11 @@ void rtnet_unregister_ioctls(struct rtnet_ioctls *ioctls)
>>>>>  
>>>>>  
>>>>>  static struct file_operations rtnet_fops = {
>>>>> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,35)
>>>>> +    .unlocked_ioctl = rtnet_ioctl,
>>>>> +#else
>>>>>      .ioctl= rtnet_ioctl,
>>>>> +#endif
>>>>>  };
>>>>>  
>>>>>  static struct miscdevice rtnet_chr_misc_dev = {
>>>>
>>>> But here we should be able to rely on Xenomai redefining unlocked_ioctl
>>>> to ioctl on 2.4 kernels. Means: convert unconditionally. Can you check this?
>>>
>>> Well, as I just realized, in Xenomai we just use:
>>>
>>> #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,11)
>>> ##define unlocked_ioctl ioctl
>>> #endif
>>>
>>> with the modified new argument list. But this will not work for < 2.6.11
>>> :-(.
>>
>> Ah. At least we found a bug this way. Then let's keep it conditional in
>> RTnet (depending on < 2.6.11) - and fix Xenomai.
> 
> OK, see patch below. Patch for Xenomai will follow.
> 
>> The alternative is to finally bury 2.4 (and old 2.6) support with the
>> next release. I bet no one would dare to update RTnet while sticking
>> with such prehistoric kernels. Anyway, this fixup could then still be
>> consolidated.
> 
> We still have support for 2.4, I think, therefore...
>  
> Wolfgang.
> 
> 
> 
> From: Wolfgang Grandegger <wg...@de...>
> Subject: [PATCH] Build fixes for 2.6.36
> 
> Signed-off-by: Wolfgang Grandegger <wg...@de...>
> ---
>  stack/include/rtnet_port.h |    9 +++++++++
>  stack/ipv4/route.c         |    1 +
>  stack/rtcfg/rtcfg_proc.c   |    1 +
>  stack/rtnet_chrdev.c       |    9 +++++++++
>  4 files changed, 20 insertions(+)
> 
> Index: rtnet/stack/include/rtnet_port.h
> ===================================================================
> --- rtnet.orig/stack/include/rtnet_port.h	2011-02-09 16:22:47.000000000 +0100
> +++ rtnet/stack/include/rtnet_port.h	2011-02-09 16:22:51.279350420 +0100
> @@ -213,6 +213,15 @@
>  #define DMA_BIT_MASK(n)	(((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
>  #endif
>  
> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,35)
> +#define NIPQUAD(addr) \
> +        ((unsigned char *)&addr)[0],	\
> +	((unsigned char *)&addr)[1],	\
> +	((unsigned char *)&addr)[2],	\
> +	((unsigned char *)&addr)[3]
> +#define NIPQUAD_FMT "%u.%u.%u.%u"
> +#endif
> +
>  #endif /* __KERNEL__ */
>  
>  #endif /* __RTNET_PORT_H_ */
> Index: rtnet/stack/ipv4/route.c
> ===================================================================
> --- rtnet.orig/stack/ipv4/route.c	2011-02-09 16:22:47.000000000 +0100
> +++ rtnet/stack/ipv4/route.c	2011-02-09 16:22:51.366362852 +0100
> @@ -26,6 +26,7 @@
>  #include <net/ip.h>
>  
>  #include <rtnet_internal.h>
> +#include <rtnet_port.h>
>  #include <rtnet_chrdev.h>
>  #include <ipv4/af_inet.h>
>  #include <ipv4/route.h>
> Index: rtnet/stack/rtcfg/rtcfg_proc.c
> ===================================================================
> --- rtnet.orig/stack/rtcfg/rtcfg_proc.c	2011-02-09 16:22:47.000000000 +0100
> +++ rtnet/stack/rtcfg/rtcfg_proc.c	2011-02-09 16:22:51.400367679 +0100
> @@ -24,6 +24,7 @@
>  
>  #include <rtdev.h>
>  #include <rtnet_internal.h>
> +#include <rtnet_port.h>
>  #include <rtcfg/rtcfg_conn_event.h>
>  #include <rtcfg/rtcfg_event.h>
>  #include <rtcfg/rtcfg_frame.h>
> Index: rtnet/stack/rtnet_chrdev.c
> ===================================================================
> --- rtnet.orig/stack/rtnet_chrdev.c	2011-02-09 16:22:47.000000000 +0100
> +++ rtnet/stack/rtnet_chrdev.c	2011-02-09 16:28:51.891258634 +0100
> @@ -47,8 +47,13 @@
>   * @request:
>   * @arg:
>   */
> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,11)
> +static long rtnet_ioctl(struct file *file,
> +			unsigned int request, unsigned long arg)
> +#else
>  static int rtnet_ioctl(struct inode *inode, struct file *file,
>                         unsigned int request, unsigned long arg)
> +#endif
>  {
>      struct rtnet_ioctl_head head;
>      struct rtnet_device     *rtdev = NULL;
> @@ -286,7 +291,11 @@
>  
>  
>  static struct file_operations rtnet_fops = {
> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,11)
> +    .unlocked_ioctl= rtnet_ioctl,
> +#else
>      .ioctl= rtnet_ioctl,
> +#endif
>  };
>  
>  static struct miscdevice rtnet_chr_misc_dev = {
> 

Thanks, applied (and even pushed this time...).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [RTnet-developers] [PATCH] Build fixes for 2.6.36

[Wolfgang G. <wg...@gr...>]

On 02/09/2011 01:25 PM, Jan Kiszka wrote:
> On 2011-02-09 13:08, Wolfgang Grandegger wrote:
>> On 02/09/2011 12:49 PM, Jan Kiszka wrote:
>>> On 2011-02-09 12:08, Wolfgang Grandegger wrote:
>>>> Signed-off-by: Wolfgang Grandegger <wg...@de...>
>>>> ---
>>>>  stack/include/rtnet_port.h |    9 +++++++++
>>>>  stack/ipv4/route.c         |    1 +
>>>>  stack/rtcfg/rtcfg_proc.c   |    1 +
>>>>  stack/rtnet_chrdev.c       |    9 +++++++++
>>>>  4 files changed, 20 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/stack/include/rtnet_port.h b/stack/include/rtnet_port.h
>>>> index b47c0db..09101cc 100644
>>>> --- a/stack/include/rtnet_port.h
>>>> +++ b/stack/include/rtnet_port.h
>>>> @@ -213,6 +213,15 @@ static inline void *netdev_priv(struct net_device *dev)
>>>>  #define DMA_BIT_MASK(n)	(((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
>>>>  #endif
>>>>  
>>>> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,35)
>>>> +#define NIPQUAD(addr) \
>>>> +        ((unsigned char *)&addr)[0],	\
>>>> +	((unsigned char *)&addr)[1],	\
>>>> +	((unsigned char *)&addr)[2],	\
>>>> +	((unsigned char *)&addr)[3]
>>>> +#define NIPQUAD_FMT "%u.%u.%u.%u"
>>>> +#endif
>>>> +
>>>>  #endif /* __KERNEL__ */
>>>>  
>>>>  #endif /* __RTNET_PORT_H_ */
>>>> diff --git a/stack/ipv4/route.c b/stack/ipv4/route.c
>>>> index 2151686..505b32e 100644
>>>> --- a/stack/ipv4/route.c
>>>> +++ b/stack/ipv4/route.c
>>>> @@ -26,6 +26,7 @@
>>>>  #include <net/ip.h>
>>>>  
>>>>  #include <rtnet_internal.h>
>>>> +#include <rtnet_port.h>
>>>>  #include <rtnet_chrdev.h>
>>>>  #include <ipv4/af_inet.h>
>>>>  #include <ipv4/route.h>
>>>> diff --git a/stack/rtcfg/rtcfg_proc.c b/stack/rtcfg/rtcfg_proc.c
>>>> index 3d55d50..93aafd8 100644
>>>> --- a/stack/rtcfg/rtcfg_proc.c
>>>> +++ b/stack/rtcfg/rtcfg_proc.c
>>>> @@ -24,6 +24,7 @@
>>>>  
>>>>  #include <rtdev.h>
>>>>  #include <rtnet_internal.h>
>>>> +#include <rtnet_port.h>
>>>>  #include <rtcfg/rtcfg_conn_event.h>
>>>>  #include <rtcfg/rtcfg_event.h>
>>>>  #include <rtcfg/rtcfg_frame.h>
>>>
>>> OK for this.
>>>
>>>> diff --git a/stack/rtnet_chrdev.c b/stack/rtnet_chrdev.c
>>>> index b0f2863..0d3fae3 100644
>>>> --- a/stack/rtnet_chrdev.c
>>>> +++ b/stack/rtnet_chrdev.c
>>>> @@ -47,8 +47,13 @@ LIST_HEAD(ioctl_handlers);
>>>>   * @request:
>>>>   * @arg:
>>>>   */
>>>> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,35)
>>>> +static long rtnet_ioctl(struct file *file,
>>>> +			unsigned int request, unsigned long arg)
>>>> +#else
>>>>  static int rtnet_ioctl(struct inode *inode, struct file *file,
>>>>                         unsigned int request, unsigned long arg)
>>>> +#endif
>>
>> Any clever idea on how to handle this unconditionally?
> 
> Actually... no. :)
> 
>>
>>>>  {
>>>>      struct rtnet_ioctl_head head;
>>>>      struct rtnet_device     *rtdev = NULL;
>>>> @@ -286,7 +291,11 @@ void rtnet_unregister_ioctls(struct rtnet_ioctls *ioctls)
>>>>  
>>>>  
>>>>  static struct file_operations rtnet_fops = {
>>>> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,35)
>>>> +    .unlocked_ioctl = rtnet_ioctl,
>>>> +#else
>>>>      .ioctl= rtnet_ioctl,
>>>> +#endif
>>>>  };
>>>>  
>>>>  static struct miscdevice rtnet_chr_misc_dev = {
>>>
>>> But here we should be able to rely on Xenomai redefining unlocked_ioctl
>>> to ioctl on 2.4 kernels. Means: convert unconditionally. Can you check this?
>>
>> Well, as I just realized, in Xenomai we just use:
>>
>> #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,11)
>> ##define unlocked_ioctl ioctl
>> #endif
>>
>> with the modified new argument list. But this will not work for < 2.6.11
>> :-(.
> 
> Ah. At least we found a bug this way. Then let's keep it conditional in
> RTnet (depending on < 2.6.11) - and fix Xenomai.

OK, see patch below. Patch for Xenomai will follow.

> The alternative is to finally bury 2.4 (and old 2.6) support with the
> next release. I bet no one would dare to update RTnet while sticking
> with such prehistoric kernels. Anyway, this fixup could then still be
> consolidated.

We still have support for 2.4, I think, therefore...
 
Wolfgang.



From: Wolfgang Grandegger <wg...@de...>
Subject: [PATCH] Build fixes for 2.6.36

Signed-off-by: Wolfgang Grandegger <wg...@de...>
---
 stack/include/rtnet_port.h |    9 +++++++++
 stack/ipv4/route.c         |    1 +
 stack/rtcfg/rtcfg_proc.c   |    1 +
 stack/rtnet_chrdev.c       |    9 +++++++++
 4 files changed, 20 insertions(+)

Index: rtnet/stack/include/rtnet_port.h
===================================================================
--- rtnet.orig/stack/include/rtnet_port.h	2011-02-09 16:22:47.000000000 +0100
+++ rtnet/stack/include/rtnet_port.h	2011-02-09 16:22:51.279350420 +0100
@@ -213,6 +213,15 @@
 #define DMA_BIT_MASK(n)	(((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
 #endif
 
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,35)
+#define NIPQUAD(addr) \
+        ((unsigned char *)&addr)[0],	\
+	((unsigned char *)&addr)[1],	\
+	((unsigned char *)&addr)[2],	\
+	((unsigned char *)&addr)[3]
+#define NIPQUAD_FMT "%u.%u.%u.%u"
+#endif
+
 #endif /* __KERNEL__ */
 
 #endif /* __RTNET_PORT_H_ */
Index: rtnet/stack/ipv4/route.c
===================================================================
--- rtnet.orig/stack/ipv4/route.c	2011-02-09 16:22:47.000000000 +0100
+++ rtnet/stack/ipv4/route.c	2011-02-09 16:22:51.366362852 +0100
@@ -26,6 +26,7 @@
 #include <net/ip.h>
 
 #include <rtnet_internal.h>
+#include <rtnet_port.h>
 #include <rtnet_chrdev.h>
 #include <ipv4/af_inet.h>
 #include <ipv4/route.h>
Index: rtnet/stack/rtcfg/rtcfg_proc.c
===================================================================
--- rtnet.orig/stack/rtcfg/rtcfg_proc.c	2011-02-09 16:22:47.000000000 +0100
+++ rtnet/stack/rtcfg/rtcfg_proc.c	2011-02-09 16:22:51.400367679 +0100
@@ -24,6 +24,7 @@
 
 #include <rtdev.h>
 #include <rtnet_internal.h>
+#include <rtnet_port.h>
 #include <rtcfg/rtcfg_conn_event.h>
 #include <rtcfg/rtcfg_event.h>
 #include <rtcfg/rtcfg_frame.h>
Index: rtnet/stack/rtnet_chrdev.c
===================================================================
--- rtnet.orig/stack/rtnet_chrdev.c	2011-02-09 16:22:47.000000000 +0100
+++ rtnet/stack/rtnet_chrdev.c	2011-02-09 16:28:51.891258634 +0100
@@ -47,8 +47,13 @@
  * @request:
  * @arg:
  */
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,11)
+static long rtnet_ioctl(struct file *file,
+			unsigned int request, unsigned long arg)
+#else
 static int rtnet_ioctl(struct inode *inode, struct file *file,
                        unsigned int request, unsigned long arg)
+#endif
 {
     struct rtnet_ioctl_head head;
     struct rtnet_device     *rtdev = NULL;
@@ -286,7 +291,11 @@
 
 
 static struct file_operations rtnet_fops = {
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,11)
+    .unlocked_ioctl= rtnet_ioctl,
+#else
     .ioctl= rtnet_ioctl,
+#endif
 };
 
 static struct miscdevice rtnet_chr_misc_dev = {

Re: [RTnet-developers] Ethernet IP

[Jan K. <jan...@si...>]

On 2011-02-09 15:58, Glen Wernersbach wrote:
> My current theory is that with RTNET you need a Connect() to do a Send().

That would be clearly a bug. I still can't see how this may happen, though.

> 
> Connect() only works if a socket is not in listen().

You either accept connections or you establish them. I'm not sure if
switching between both stats is even a valid transition.

> 
> Not sure what happens yet if I change the send() to a sentto() if the first
> example

send, sendto, sendmsg, write - they all end up in the same handler
internally. Target address is ignored.

> 
> On Xenomai , Sent() does not error. it just blocks. On RTAI, it produces an
> "oops".

[/me still waiting for a kernel log]

The fact that Xenomai blocks likely means, the socket is in
TCP_ESTABLISHED state. "Just" the communication fails or something else
prevents the RTnet side to consider its TX window open.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [RTnet-developers] Ethernet IP

[Glen W. <gl...@je...>]

My current theory is that with RTNET you need a Connect() to do a Send().

Connect() only works if a socket is not in listen().

Not sure what happens yet if I change the send() to a sentto() if the first
example

On Xenomai , Sent() does not error. it just blocks. On RTAI, it produces an
"oops".

I have extended the pools via RTNET_RTIOC_EXTPOOL to both 30 and 1024 with
no effect on above.


On 2/9/11 9:24 AM, "Jan Kiszka" <jan...@si...> wrote:

> On 2011-02-09 15:18, Glen Wernersbach wrote:
>> Jan,
>> 
>> I think I figured out the send error.
>> 
>> With RTNET I cannot receive and send on the same socket.
>> 
>> So I cannot with RTNET do the follow that works with Linux:
>> 1. Socket
>> 2. SetSocketOpts
>> 3. Bind
>> 4. Listen
>> 5. Accept
>> 6. Recv
>> 7. Send
>> 8. close
>> ------
>> 
>> I can however with RTNET do the following:
>> 1. Socket
>> 2. SetSocketOpts
>> 3. Bind
>> 4. Listen
>> 5. Accept
>> 6. Recv
>> 7. Close
>> ------
>> 8. Socket
>> 9. SetSocketOpts
>> 10. Bind
>> 11. Connect
>> 12. Send
>> 13. Close
>> 
>> The second seemed to work.
>> 
>> Does this makes sense to you?
> 
> Not yet. You once said accept() fails, but your setup starts to diverge
> after recv() (by doing a send()). What errors do which services return?
> Did you check that you have sufficient buffers configured for your
> network load (RTNET_RTIOC_EXTPOOL)?
> 
> Again, it's _much_ easier if you stick this simple setup in a generic
> test case.
> 
> Thanks,
> Jan

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
----
"Support Dyslexia Research"

Re: [RTnet-developers] Ethernet IP

[Jan K. <jan...@si...>]

On 2011-02-09 15:18, Glen Wernersbach wrote:
> Jan,
> 
> I think I figured out the send error.
> 
> With RTNET I cannot receive and send on the same socket.
> 
> So I cannot with RTNET do the follow that works with Linux:
> 1. Socket
> 2. SetSocketOpts
> 3. Bind
> 4. Listen
> 5. Accept
> 6. Recv
> 7. Send
> 8. close
> ------
> 
> I can however with RTNET do the following:
> 1. Socket
> 2. SetSocketOpts
> 3. Bind
> 4. Listen
> 5. Accept
> 6. Recv
> 7. Close
> ------
> 8. Socket
> 9. SetSocketOpts
> 10. Bind
> 11. Connect
> 12. Send
> 13. Close
> 
> The second seemed to work.
> 
> Does this makes sense to you?

Not yet. You once said accept() fails, but your setup starts to diverge
after recv() (by doing a send()). What errors do which services return?
Did you check that you have sufficient buffers configured for your
network load (RTNET_RTIOC_EXTPOOL)?

Again, it's _much_ easier if you stick this simple setup in a generic
test case.

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [RTnet-developers] Ethernet IP

[Glen W. <gl...@je...>]

Jan,

I think I figured out the send error.

With RTNET I cannot receive and send on the same socket.

So I cannot with RTNET do the follow that works with Linux:
1. Socket
2. SetSocketOpts
3. Bind
4. Listen
5. Accept
6. Recv
7. Send
8. close
------

I can however with RTNET do the following:
1. Socket
2. SetSocketOpts
3. Bind
4. Listen
5. Accept
6. Recv
7. Close
------
8. Socket
9. SetSocketOpts
10. Bind
11. Connect
12. Send
13. Close

The second seemed to work.

Does this makes sense to you?

Glen



On 2/8/11 9:49 AM, "Jan Kiszka" <jan...@we...> wrote:

> On 2011-02-08 15:27, Glen Wernersbach wrote:
>> Jan,
>> 
>> The project I am trying to make real time is:
>> http://sourceforge.net/projects/opener/
>> 
>> It is hard to give a test case because my other side of this is an Allen
> 
> I'm primarily interested in the connection setup pattern which should be
> extractable into a set of two simple test applications.
> 
>> Bradley controller. This project does work in standard Linux but then I have
>> to deal with OS latencies from the card to my real time program.
>> 
>> Here is my current thought. The code as written in your example works. If I
>> run accept() before select, accept() always returns the same file descriptor
>> as was put it. Is this a a limitation of RTNET?
> 
> Yes, see Documentation/README.tcp.
> 
>> 
>> Also, it appear that select() without accept() and you can read()
>> successfully.
> 
> Are you implementing a server or a client? A server without accept would
> be weird, and a client with it just as well.
> 
>> 
>> I can probably work around the above.
> 
> Wrong approach, likely doomed to blow up at a different end later on.
> 
>> 
>> Now I need to focus on why Send or Write  are "oops"ing.
> 
> If you don't post it, you will have to parse it on your own...
> 
>> 
>> The only difference between my code and your example is that I am not
>> setting the same socket options SO_KEEPALIVE and SO_SNDTIMEO. I will try
>> these this mourning.
>> 
>> The only other reason this could be "oops"ing is that I am reading and
>> writing on the same socket and your example does not.
> 
> We do in a less trivial application in the field. No complains from my
> colleagues so far.
> 
>> 
>> I will let you know.
>> 
>> Glen
>> 
>> P.S. At least now I know I can go back to RTAI if I want. The rest of our
>> project works in RTAI.
> 
> OTOH, analysis is easier elsewhere.
> 
> Jan
> 

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
----
"Support Dyslexia Research"

Re: [RTnet-developers] [PATCH] Build fixes for 2.6.36

[Jan K. <jan...@si...>]

On 2011-02-09 13:08, Wolfgang Grandegger wrote:
> On 02/09/2011 12:49 PM, Jan Kiszka wrote:
>> On 2011-02-09 12:08, Wolfgang Grandegger wrote:
>>> Signed-off-by: Wolfgang Grandegger <wg...@de...>
>>> ---
>>>  stack/include/rtnet_port.h |    9 +++++++++
>>>  stack/ipv4/route.c         |    1 +
>>>  stack/rtcfg/rtcfg_proc.c   |    1 +
>>>  stack/rtnet_chrdev.c       |    9 +++++++++
>>>  4 files changed, 20 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/stack/include/rtnet_port.h b/stack/include/rtnet_port.h
>>> index b47c0db..09101cc 100644
>>> --- a/stack/include/rtnet_port.h
>>> +++ b/stack/include/rtnet_port.h
>>> @@ -213,6 +213,15 @@ static inline void *netdev_priv(struct net_device *dev)
>>>  #define DMA_BIT_MASK(n)	(((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
>>>  #endif
>>>  
>>> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,35)
>>> +#define NIPQUAD(addr) \
>>> +        ((unsigned char *)&addr)[0],	\
>>> +	((unsigned char *)&addr)[1],	\
>>> +	((unsigned char *)&addr)[2],	\
>>> +	((unsigned char *)&addr)[3]
>>> +#define NIPQUAD_FMT "%u.%u.%u.%u"
>>> +#endif
>>> +
>>>  #endif /* __KERNEL__ */
>>>  
>>>  #endif /* __RTNET_PORT_H_ */
>>> diff --git a/stack/ipv4/route.c b/stack/ipv4/route.c
>>> index 2151686..505b32e 100644
>>> --- a/stack/ipv4/route.c
>>> +++ b/stack/ipv4/route.c
>>> @@ -26,6 +26,7 @@
>>>  #include <net/ip.h>
>>>  
>>>  #include <rtnet_internal.h>
>>> +#include <rtnet_port.h>
>>>  #include <rtnet_chrdev.h>
>>>  #include <ipv4/af_inet.h>
>>>  #include <ipv4/route.h>
>>> diff --git a/stack/rtcfg/rtcfg_proc.c b/stack/rtcfg/rtcfg_proc.c
>>> index 3d55d50..93aafd8 100644
>>> --- a/stack/rtcfg/rtcfg_proc.c
>>> +++ b/stack/rtcfg/rtcfg_proc.c
>>> @@ -24,6 +24,7 @@
>>>  
>>>  #include <rtdev.h>
>>>  #include <rtnet_internal.h>
>>> +#include <rtnet_port.h>
>>>  #include <rtcfg/rtcfg_conn_event.h>
>>>  #include <rtcfg/rtcfg_event.h>
>>>  #include <rtcfg/rtcfg_frame.h>
>>
>> OK for this.
>>
>>> diff --git a/stack/rtnet_chrdev.c b/stack/rtnet_chrdev.c
>>> index b0f2863..0d3fae3 100644
>>> --- a/stack/rtnet_chrdev.c
>>> +++ b/stack/rtnet_chrdev.c
>>> @@ -47,8 +47,13 @@ LIST_HEAD(ioctl_handlers);
>>>   * @request:
>>>   * @arg:
>>>   */
>>> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,35)
>>> +static long rtnet_ioctl(struct file *file,
>>> +			unsigned int request, unsigned long arg)
>>> +#else
>>>  static int rtnet_ioctl(struct inode *inode, struct file *file,
>>>                         unsigned int request, unsigned long arg)
>>> +#endif
> 
> Any clever idea on how to handle this unconditionally?

Actually... no. :)

> 
>>>  {
>>>      struct rtnet_ioctl_head head;
>>>      struct rtnet_device     *rtdev = NULL;
>>> @@ -286,7 +291,11 @@ void rtnet_unregister_ioctls(struct rtnet_ioctls *ioctls)
>>>  
>>>  
>>>  static struct file_operations rtnet_fops = {
>>> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,35)
>>> +    .unlocked_ioctl = rtnet_ioctl,
>>> +#else
>>>      .ioctl= rtnet_ioctl,
>>> +#endif
>>>  };
>>>  
>>>  static struct miscdevice rtnet_chr_misc_dev = {
>>
>> But here we should be able to rely on Xenomai redefining unlocked_ioctl
>> to ioctl on 2.4 kernels. Means: convert unconditionally. Can you check this?
> 
> Well, as I just realized, in Xenomai we just use:
> 
> #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,11)
> ##define unlocked_ioctl ioctl
> #endif
> 
> with the modified new argument list. But this will not work for < 2.6.11
> :-(.

Ah. At least we found a bug this way. Then let's keep it conditional in
RTnet (depending on < 2.6.11) - and fix Xenomai.

The alternative is to finally bury 2.4 (and old 2.6) support with the
next release. I bet no one would dare to update RTnet while sticking
with such prehistoric kernels. Anyway, this fixup could then still be
consolidated.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [RTnet-developers] [PATCH] Build fixes for 2.6.36

[Wolfgang G. <wg...@gr...>]

On 02/09/2011 12:49 PM, Jan Kiszka wrote:
> On 2011-02-09 12:08, Wolfgang Grandegger wrote:
>> Signed-off-by: Wolfgang Grandegger <wg...@de...>
>> ---
>>  stack/include/rtnet_port.h |    9 +++++++++
>>  stack/ipv4/route.c         |    1 +
>>  stack/rtcfg/rtcfg_proc.c   |    1 +
>>  stack/rtnet_chrdev.c       |    9 +++++++++
>>  4 files changed, 20 insertions(+), 0 deletions(-)
>>
>> diff --git a/stack/include/rtnet_port.h b/stack/include/rtnet_port.h
>> index b47c0db..09101cc 100644
>> --- a/stack/include/rtnet_port.h
>> +++ b/stack/include/rtnet_port.h
>> @@ -213,6 +213,15 @@ static inline void *netdev_priv(struct net_device *dev)
>>  #define DMA_BIT_MASK(n)	(((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
>>  #endif
>>  
>> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,35)
>> +#define NIPQUAD(addr) \
>> +        ((unsigned char *)&addr)[0],	\
>> +	((unsigned char *)&addr)[1],	\
>> +	((unsigned char *)&addr)[2],	\
>> +	((unsigned char *)&addr)[3]
>> +#define NIPQUAD_FMT "%u.%u.%u.%u"
>> +#endif
>> +
>>  #endif /* __KERNEL__ */
>>  
>>  #endif /* __RTNET_PORT_H_ */
>> diff --git a/stack/ipv4/route.c b/stack/ipv4/route.c
>> index 2151686..505b32e 100644
>> --- a/stack/ipv4/route.c
>> +++ b/stack/ipv4/route.c
>> @@ -26,6 +26,7 @@
>>  #include <net/ip.h>
>>  
>>  #include <rtnet_internal.h>
>> +#include <rtnet_port.h>
>>  #include <rtnet_chrdev.h>
>>  #include <ipv4/af_inet.h>
>>  #include <ipv4/route.h>
>> diff --git a/stack/rtcfg/rtcfg_proc.c b/stack/rtcfg/rtcfg_proc.c
>> index 3d55d50..93aafd8 100644
>> --- a/stack/rtcfg/rtcfg_proc.c
>> +++ b/stack/rtcfg/rtcfg_proc.c
>> @@ -24,6 +24,7 @@
>>  
>>  #include <rtdev.h>
>>  #include <rtnet_internal.h>
>> +#include <rtnet_port.h>
>>  #include <rtcfg/rtcfg_conn_event.h>
>>  #include <rtcfg/rtcfg_event.h>
>>  #include <rtcfg/rtcfg_frame.h>
> 
> OK for this.
> 
>> diff --git a/stack/rtnet_chrdev.c b/stack/rtnet_chrdev.c
>> index b0f2863..0d3fae3 100644
>> --- a/stack/rtnet_chrdev.c
>> +++ b/stack/rtnet_chrdev.c
>> @@ -47,8 +47,13 @@ LIST_HEAD(ioctl_handlers);
>>   * @request:
>>   * @arg:
>>   */
>> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,35)
>> +static long rtnet_ioctl(struct file *file,
>> +			unsigned int request, unsigned long arg)
>> +#else
>>  static int rtnet_ioctl(struct inode *inode, struct file *file,
>>                         unsigned int request, unsigned long arg)
>> +#endif

Any clever idea on how to handle this unconditionally?

>>  {
>>      struct rtnet_ioctl_head head;
>>      struct rtnet_device     *rtdev = NULL;
>> @@ -286,7 +291,11 @@ void rtnet_unregister_ioctls(struct rtnet_ioctls *ioctls)
>>  
>>  
>>  static struct file_operations rtnet_fops = {
>> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,35)
>> +    .unlocked_ioctl = rtnet_ioctl,
>> +#else
>>      .ioctl= rtnet_ioctl,
>> +#endif
>>  };
>>  
>>  static struct miscdevice rtnet_chr_misc_dev = {
> 
> But here we should be able to rely on Xenomai redefining unlocked_ioctl
> to ioctl on 2.4 kernels. Means: convert unconditionally. Can you check this?

Well, as I just realized, in Xenomai we just use:

#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,11)
##define unlocked_ioctl ioctl
#endif

with the modified new argument list. But this will not work for < 2.6.11
:-(.

Wolfgang.

Re: [RTnet-developers] [PATCH] Build fixes for 2.6.36

[Jan K. <jan...@si...>]

On 2011-02-09 12:08, Wolfgang Grandegger wrote:
> Signed-off-by: Wolfgang Grandegger <wg...@de...>
> ---
>  stack/include/rtnet_port.h |    9 +++++++++
>  stack/ipv4/route.c         |    1 +
>  stack/rtcfg/rtcfg_proc.c   |    1 +
>  stack/rtnet_chrdev.c       |    9 +++++++++
>  4 files changed, 20 insertions(+), 0 deletions(-)
> 
> diff --git a/stack/include/rtnet_port.h b/stack/include/rtnet_port.h
> index b47c0db..09101cc 100644
> --- a/stack/include/rtnet_port.h
> +++ b/stack/include/rtnet_port.h
> @@ -213,6 +213,15 @@ static inline void *netdev_priv(struct net_device *dev)
>  #define DMA_BIT_MASK(n)	(((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
>  #endif
>  
> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,35)
> +#define NIPQUAD(addr) \
> +        ((unsigned char *)&addr)[0],	\
> +	((unsigned char *)&addr)[1],	\
> +	((unsigned char *)&addr)[2],	\
> +	((unsigned char *)&addr)[3]
> +#define NIPQUAD_FMT "%u.%u.%u.%u"
> +#endif
> +
>  #endif /* __KERNEL__ */
>  
>  #endif /* __RTNET_PORT_H_ */
> diff --git a/stack/ipv4/route.c b/stack/ipv4/route.c
> index 2151686..505b32e 100644
> --- a/stack/ipv4/route.c
> +++ b/stack/ipv4/route.c
> @@ -26,6 +26,7 @@
>  #include <net/ip.h>
>  
>  #include <rtnet_internal.h>
> +#include <rtnet_port.h>
>  #include <rtnet_chrdev.h>
>  #include <ipv4/af_inet.h>
>  #include <ipv4/route.h>
> diff --git a/stack/rtcfg/rtcfg_proc.c b/stack/rtcfg/rtcfg_proc.c
> index 3d55d50..93aafd8 100644
> --- a/stack/rtcfg/rtcfg_proc.c
> +++ b/stack/rtcfg/rtcfg_proc.c
> @@ -24,6 +24,7 @@
>  
>  #include <rtdev.h>
>  #include <rtnet_internal.h>
> +#include <rtnet_port.h>
>  #include <rtcfg/rtcfg_conn_event.h>
>  #include <rtcfg/rtcfg_event.h>
>  #include <rtcfg/rtcfg_frame.h>

OK for this.

> diff --git a/stack/rtnet_chrdev.c b/stack/rtnet_chrdev.c
> index b0f2863..0d3fae3 100644
> --- a/stack/rtnet_chrdev.c
> +++ b/stack/rtnet_chrdev.c
> @@ -47,8 +47,13 @@ LIST_HEAD(ioctl_handlers);
>   * @request:
>   * @arg:
>   */
> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,35)
> +static long rtnet_ioctl(struct file *file,
> +			unsigned int request, unsigned long arg)
> +#else
>  static int rtnet_ioctl(struct inode *inode, struct file *file,
>                         unsigned int request, unsigned long arg)
> +#endif
>  {
>      struct rtnet_ioctl_head head;
>      struct rtnet_device     *rtdev = NULL;
> @@ -286,7 +291,11 @@ void rtnet_unregister_ioctls(struct rtnet_ioctls *ioctls)
>  
>  
>  static struct file_operations rtnet_fops = {
> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,35)
> +    .unlocked_ioctl = rtnet_ioctl,
> +#else
>      .ioctl= rtnet_ioctl,
> +#endif
>  };
>  
>  static struct miscdevice rtnet_chr_misc_dev = {

But here we should be able to rely on Xenomai redefining unlocked_ioctl
to ioctl on 2.4 kernels. Means: convert unconditionally. Can you check this?

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[RTnet-developers] [PATCH] Build fixes for 2.6.36

[Wolfgang G. <wg...@gr...>]

Signed-off-by: Wolfgang Grandegger <wg...@de...>
---
 stack/include/rtnet_port.h |    9 +++++++++
 stack/ipv4/route.c         |    1 +
 stack/rtcfg/rtcfg_proc.c   |    1 +
 stack/rtnet_chrdev.c       |    9 +++++++++
 4 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/stack/include/rtnet_port.h b/stack/include/rtnet_port.h
index b47c0db..09101cc 100644
--- a/stack/include/rtnet_port.h
+++ b/stack/include/rtnet_port.h
@@ -213,6 +213,15 @@ static inline void *netdev_priv(struct net_device *dev)
 #define DMA_BIT_MASK(n)	(((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
 #endif
 
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,35)
+#define NIPQUAD(addr) \
+        ((unsigned char *)&addr)[0],	\
+	((unsigned char *)&addr)[1],	\
+	((unsigned char *)&addr)[2],	\
+	((unsigned char *)&addr)[3]
+#define NIPQUAD_FMT "%u.%u.%u.%u"
+#endif
+
 #endif /* __KERNEL__ */
 
 #endif /* __RTNET_PORT_H_ */
diff --git a/stack/ipv4/route.c b/stack/ipv4/route.c
index 2151686..505b32e 100644
--- a/stack/ipv4/route.c
+++ b/stack/ipv4/route.c
@@ -26,6 +26,7 @@
 #include <net/ip.h>
 
 #include <rtnet_internal.h>
+#include <rtnet_port.h>
 #include <rtnet_chrdev.h>
 #include <ipv4/af_inet.h>
 #include <ipv4/route.h>
diff --git a/stack/rtcfg/rtcfg_proc.c b/stack/rtcfg/rtcfg_proc.c
index 3d55d50..93aafd8 100644
--- a/stack/rtcfg/rtcfg_proc.c
+++ b/stack/rtcfg/rtcfg_proc.c
@@ -24,6 +24,7 @@
 
 #include <rtdev.h>
 #include <rtnet_internal.h>
+#include <rtnet_port.h>
 #include <rtcfg/rtcfg_conn_event.h>
 #include <rtcfg/rtcfg_event.h>
 #include <rtcfg/rtcfg_frame.h>
diff --git a/stack/rtnet_chrdev.c b/stack/rtnet_chrdev.c
index b0f2863..0d3fae3 100644
--- a/stack/rtnet_chrdev.c
+++ b/stack/rtnet_chrdev.c
@@ -47,8 +47,13 @@ LIST_HEAD(ioctl_handlers);
  * @request:
  * @arg:
  */
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,35)
+static long rtnet_ioctl(struct file *file,
+			unsigned int request, unsigned long arg)
+#else
 static int rtnet_ioctl(struct inode *inode, struct file *file,
                        unsigned int request, unsigned long arg)
+#endif
 {
     struct rtnet_ioctl_head head;
     struct rtnet_device     *rtdev = NULL;
@@ -286,7 +291,11 @@ void rtnet_unregister_ioctls(struct rtnet_ioctls *ioctls)
 
 
 static struct file_operations rtnet_fops = {
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,35)
+    .unlocked_ioctl = rtnet_ioctl,
+#else
     .ioctl= rtnet_ioctl,
+#endif
 };
 
 static struct miscdevice rtnet_chr_misc_dev = {
-- 
1.7.2.3

Re: [RTnet-developers] Ethernet IP

[Jan K. <jan...@we...>]

On 2011-02-08 16:52, Anders Blomdell wrote:
> On 02/08/2011 04:03 PM, Jan Kiszka wrote:
>> On 2011-02-08 16:00, Anders Blomdell wrote:
>>>>> The only other reason this could be "oops"ing is that I am reading and
>>>>> writing on the same socket and your example does not.
>>>>
>>>> We do in a less trivial application in the field. No complains from my
>>>> colleagues so far.
>>> With raw sockets I have problems reading and writing from/to the same
>>> socket
>>> when done from different threads (on my todo list to track this down
>>> some time
>>> in the future), might this be the same problem?
>>
>> You mean one thread reads and another writes? Or both mixed? What kind of
>> problems?
> At least with one thread reading and one writing.
> Some errno which I cant exctly recall (9x, something, might have been
> EADDRINUSE, but I'm not sure).

98 == EADDRINUSE. But that's only thrown by UDP and TCP, not AF_PACKET.

> My workaround was to read from the socket
> with a timeout, that way I was able to do everything in one thread (yes,
> I know it's not a long term solution).

Maybe there is same race and some missing locking. I would be interested
to hear more details / see a test case when you find some time.

Thanks,
Jan

Re: [RTnet-developers] Ethernet IP

[Anders B. <and...@co...>]

On 02/08/2011 04:03 PM, Jan Kiszka wrote:
> On 2011-02-08 16:00, Anders Blomdell wrote:
>>>> The only other reason this could be "oops"ing is that I am reading and
>>>> writing on the same socket and your example does not.
>>>
>>> We do in a less trivial application in the field. No complains from my
>>> colleagues so far.
>> With raw sockets I have problems reading and writing from/to the same socket
>> when done from different threads (on my todo list to track this down some time
>> in the future), might this be the same problem?
>
> You mean one thread reads and another writes? Or both mixed? What kind of
> problems?
At least with one thread reading and one writing.
Some errno which I cant exctly recall (9x, something, might have been 
EADDRINUSE, but I'm not sure). My workaround was to read from the socket 
with a timeout, that way I was able to do everything in one thread (yes, 
I know it's not a long term solution).

/Anders


-- 
Anders Blomdell                  Email: and...@co...
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

Re: [RTnet-developers] Ethernet IP

[Anders B. <and...@co...>]

On 2011-02-08 15.49, Jan Kiszka wrote:
> On 2011-02-08 15:27, Glen Wernersbach wrote:
>> Jan,
>>
>> The project I am trying to make real time is:
>> http://sourceforge.net/projects/opener/
>>
>> It is hard to give a test case because my other side of this is an Allen
> 
> I'm primarily interested in the connection setup pattern which should be
> extractable into a set of two simple test applications.
> 
>> Bradley controller. This project does work in standard Linux but then I have
>> to deal with OS latencies from the card to my real time program.
>>
>> Here is my current thought. The code as written in your example works. If I
>> run accept() before select, accept() always returns the same file descriptor
>> as was put it. Is this a a limitation of RTNET?
> 
> Yes, see Documentation/README.tcp.
> 
>>
>> Also, it appear that select() without accept() and you can read()
>> successfully.
> 
> Are you implementing a server or a client? A server without accept would
> be weird, and a client with it just as well.
> 
>>
>> I can probably work around the above.
> 
> Wrong approach, likely doomed to blow up at a different end later on.
> 
>>
>> Now I need to focus on why Send or Write  are "oops"ing.
> 
> If you don't post it, you will have to parse it on your own...
> 
>>
>> The only difference between my code and your example is that I am not
>> setting the same socket options SO_KEEPALIVE and SO_SNDTIMEO. I will try
>> these this mourning.
>>
>> The only other reason this could be "oops"ing is that I am reading and
>> writing on the same socket and your example does not.
> 
> We do in a less trivial application in the field. No complains from my
> colleagues so far.
With raw sockets I have problems reading and writing from/to the same socket
when done from different threads (on my todo list to track this down some time
in the future), might this be the same problem?


> 
>>
>> I will let you know.
>>
>> Glen
>>
>> P.S. At least now I know I can go back to RTAI if I want. The rest of our
>> project works in RTAI.
> 
> OTOH, analysis is easier elsewhere.

/Anders

-- 
Anders Blomdell                  Email: and...@co...
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

Re: [RTnet-developers] Ethernet IP

[Jan K. <jan...@we...>]

On 2011-02-08 15:27, Glen Wernersbach wrote:
> Jan,
> 
> The project I am trying to make real time is:
> http://sourceforge.net/projects/opener/
> 
> It is hard to give a test case because my other side of this is an Allen

I'm primarily interested in the connection setup pattern which should be
extractable into a set of two simple test applications.

> Bradley controller. This project does work in standard Linux but then I have
> to deal with OS latencies from the card to my real time program.
> 
> Here is my current thought. The code as written in your example works. If I
> run accept() before select, accept() always returns the same file descriptor
> as was put it. Is this a a limitation of RTNET?

Yes, see Documentation/README.tcp.

> 
> Also, it appear that select() without accept() and you can read()
> successfully.

Are you implementing a server or a client? A server without accept would
be weird, and a client with it just as well.

> 
> I can probably work around the above.

Wrong approach, likely doomed to blow up at a different end later on.

> 
> Now I need to focus on why Send or Write  are "oops"ing.

If you don't post it, you will have to parse it on your own...

> 
> The only difference between my code and your example is that I am not
> setting the same socket options SO_KEEPALIVE and SO_SNDTIMEO. I will try
> these this mourning.
> 
> The only other reason this could be "oops"ing is that I am reading and
> writing on the same socket and your example does not.

We do in a less trivial application in the field. No complains from my
colleagues so far.

> 
> I will let you know.
> 
> Glen
> 
> P.S. At least now I know I can go back to RTAI if I want. The rest of our
> project works in RTAI.

OTOH, analysis is easier elsewhere.

Jan

Re: [RTnet-developers] Ethernet IP

[Glen W. <gl...@je...>]

Jan,

The project I am trying to make real time is:
http://sourceforge.net/projects/opener/

It is hard to give a test case because my other side of this is an Allen
Bradley controller. This project does work in standard Linux but then I have
to deal with OS latencies from the card to my real time program.

Here is my current thought. The code as written in your example works. If I
run accept() before select, accept() always returns the same file descriptor
as was put it. Is this a a limitation of RTNET?

Also, it appear that select() without accept() and you can read()
successfully.

I can probably work around the above.

Now I need to focus on why Send or Write  are "oops"ing.

The only difference between my code and your example is that I am not
setting the same socket options SO_KEEPALIVE and SO_SNDTIMEO. I will try
these this mourning.

The only other reason this could be "oops"ing is that I am reading and
writing on the same socket and your example does not.

I will let you know.

Glen

P.S. At least now I know I can go back to RTAI if I want. The rest of our
project works in RTAI.




On 2/8/11 7:24 AM, "Jan Kiszka" <jan...@we...> wrote:

> On 2011-02-08 13:18, Glen Wernersbach wrote:
>> I used select with a timeout. Select seems to work. It returns a positive
>> number and a fdset.
>> 
>> It is accept which does not seem to work in taking off the top packets and
>> send or write oopses the machine.
>> 
>> Accept does seem to work if I run it before select.
> 
> Given that this is not the pattern we tested so far (actually, the whole
> server side TCP implementation was only "for fun", real use cases were
> only clients so far) nor is it supposed to work based on the existing
> logic, you may have triggered a BUG path.
> 
>> 
>> We can try the example but then I have to set up another machine.
> 
> Or provide your test for local reproduction.
> 
>> 
>> Could any of thus be e1000 driver?
> 
> Test via rtlo instead.
> 
> Jan
> 

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
----
"Support Dyslexia Research"

Re: [RTnet-developers] Ethernet IP

[Jan K. <jan...@we...>]

On 2011-02-08 13:18, Glen Wernersbach wrote:
> I used select with a timeout. Select seems to work. It returns a positive number and a fdset.
> 
> It is accept which does not seem to work in taking off the top packets and send or write oopses the machine.
> 
> Accept does seem to work if I run it before select.

Given that this is not the pattern we tested so far (actually, the whole
server side TCP implementation was only "for fun", real use cases were
only clients so far) nor is it supposed to work based on the existing
logic, you may have triggered a BUG path.

> 
> We can try the example but then I have to set up another machine.

Or provide your test for local reproduction.

> 
> Could any of thus be e1000 driver?

Test via rtlo instead.

Jan

Re: [RTnet-developers] Ethernet IP

[Glen W. <gl...@je...>]

I used select with a timeout. Select seems to work. It returns a positive number and a fdset.

It is accept which does not seem to work in taking off the top packets and send or write oopses the machine.

Accept does seem to work if I run it before select.

We can try the example but then I have to set up another machine.

Could any of thus be e1000 driver?

--
Glen Wernersbach
President & CTO
Jetsoft Development Co
629 Old St. Rt. 74 - Suite 210
Cincinnati Ohio 45244
Custom Programming Web Site: www.JetsoftDev.com
Retail Product Web Site: www.ScanHelp.com
Phone: 513-528-6660
Fax: 513-528-3470

On Feb 8, 2011, at 6:47 AM, Jan Kiszka <jan...@we...> wrote:

> On 2011-02-08 05:24, Glen Wernersbach wrote:
>> Well, I installed Xenomai and RTNET on a different distribution and
>> basically got the same issues as in the email below.
>> 
>> If I run accept() after select(), I get a -1 Invalid Argument error.
> 
> Do you use select() to wait on a connection request? This is obviously
> not yet supported by RTnet.
> 
>> 
>> The rest is exactly alike.
>> 
>> I get these errors, even when I get the code as close as I can to the
>> RTTCP_SERVER example.
> 
> Does the original example work for you?
> 
> However, I think we better discuss your issues based on a self-contained
> test that exposed them for you.
> 
> Jan
> 
> 
>> 
>> So there is either some problem with my insmods, some obscure program
>> setting or I have just found problems with TCP on RTNET.
>> 
>> At least the errors are in the same place both on RTAI and XENO_POSIX
>> 
>> Glen
>> 
>> 
>> On 1/28/11 4:32 PM, "Glen Wernersbach" <gl...@je...> wrote:
>> 
>>> Thanks.
>>> 
>>> I will check.
>>> 
>>> Verdict is still out if I can used RTAI , RTNET and TCP
>>> Here are my current troubles:
>>> 
>>> 1. rt_dev_Accept() seems to return ether -9,-22,-38 with the errorn specifying
>>> funciton not implemented.
>>> 2. If I skip accept and just use the original FD, I get data but when I try to
>>> rt_dev_send() back to this FD, I get a crash and a "Ooops" output
>>> 3. If I issue a rt_dev_shutdown() on a UDP socket, I get an "Ooops' output.
>>> Works on the TCP socket.
>>> 
>>> The program works with standard linux commands.
>>> 
>>> Glen
>>> 
>>> 
>>> On 1/28/11 4:13 PM, "Jan Kiszka" <jan...@we...> wrote:
>>> 
>>>> On 2011-01-28 21:40, Glen Wernersbach wrote:
>>>>> Jan,
>>>>> 
>>>>> On you last comment below about pre allocating buffers, I am trying to find
>>>>> where in the RTAI examples it show that?
>>>> 
>>>> It's lacking in those few RTAI examples. Check xenomai/posix and watch
>>>> out for RTNET_RTIOC_EXTPOOL. I think that should be trivially transferable.
>>>> 
>>>> Jan
>>>> 
>> 
> 
> 

Re: [RTnet-developers] Ethernet IP

[Jan K. <jan...@we...>]

On 2011-02-08 05:24, Glen Wernersbach wrote:
> Well, I installed Xenomai and RTNET on a different distribution and
> basically got the same issues as in the email below.
> 
> If I run accept() after select(), I get a -1 Invalid Argument error.

Do you use select() to wait on a connection request? This is obviously
not yet supported by RTnet.

> 
> The rest is exactly alike.
> 
> I get these errors, even when I get the code as close as I can to the
> RTTCP_SERVER example.

Does the original example work for you?

However, I think we better discuss your issues based on a self-contained
test that exposed them for you.

Jan


> 
> So there is either some problem with my insmods, some obscure program
> setting or I have just found problems with TCP on RTNET.
> 
> At least the errors are in the same place both on RTAI and XENO_POSIX
> 
> Glen
> 
> 
> On 1/28/11 4:32 PM, "Glen Wernersbach" <gl...@je...> wrote:
> 
>> Thanks.
>>
>> I will check.
>>
>> Verdict is still out if I can used RTAI , RTNET and TCP
>> Here are my current troubles:
>>
>> 1. rt_dev_Accept() seems to return ether -9,-22,-38 with the errorn specifying
>> funciton not implemented.
>> 2. If I skip accept and just use the original FD, I get data but when I try to
>> rt_dev_send() back to this FD, I get a crash and a "Ooops" output
>> 3. If I issue a rt_dev_shutdown() on a UDP socket, I get an "Ooops' output.
>> Works on the TCP socket.
>>
>> The program works with standard linux commands.
>>
>> Glen
>>
>>
>> On 1/28/11 4:13 PM, "Jan Kiszka" <jan...@we...> wrote:
>>
>>> On 2011-01-28 21:40, Glen Wernersbach wrote:
>>>> Jan,
>>>>
>>>> On you last comment below about pre allocating buffers, I am trying to find
>>>> where in the RTAI examples it show that?
>>>
>>> It's lacking in those few RTAI examples. Check xenomai/posix and watch
>>> out for RTNET_RTIOC_EXTPOOL. I think that should be trivially transferable.
>>>
>>> Jan
>>>
> 

Re: [RTnet-developers] Ethernet IP

[Glen W. <gl...@je...>]

Well, I installed Xenomai and RTNET on a different distribution and
basically got the same issues as in the email below.

If I run accept() after select(), I get a -1 Invalid Argument error.

The rest is exactly alike.

I get these errors, even when I get the code as close as I can to the
RTTCP_SERVER example.

So there is either some problem with my insmods, some obscure program
setting or I have just found problems with TCP on RTNET.

At least the errors are in the same place both on RTAI and XENO_POSIX

Glen


On 1/28/11 4:32 PM, "Glen Wernersbach" <gl...@je...> wrote:

> Thanks.
> 
> I will check.
> 
> Verdict is still out if I can used RTAI , RTNET and TCP
> Here are my current troubles:
> 
> 1. rt_dev_Accept() seems to return ether -9,-22,-38 with the errorn specifying
> funciton not implemented.
> 2. If I skip accept and just use the original FD, I get data but when I try to
> rt_dev_send() back to this FD, I get a crash and a "Ooops" output
> 3. If I issue a rt_dev_shutdown() on a UDP socket, I get an "Ooops' output.
> Works on the TCP socket.
> 
> The program works with standard linux commands.
> 
> Glen
> 
> 
> On 1/28/11 4:13 PM, "Jan Kiszka" <jan...@we...> wrote:
> 
>> On 2011-01-28 21:40, Glen Wernersbach wrote:
>>> Jan,
>>> 
>>> On you last comment below about pre allocating buffers, I am trying to find
>>> where in the RTAI examples it show that?
>> 
>> It's lacking in those few RTAI examples. Check xenomai/posix and watch
>> out for RTNET_RTIOC_EXTPOOL. I think that should be trivially transferable.
>> 
>> Jan
>> 

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
----
"Support Dyslexia Research"

Re: [RTnet-developers] Ethernet IP

[Jan K. <jan...@we...>]

On 2011-01-28 22:32, Glen Wernersbach wrote:
> Thanks.
> 
> I will check.
> 
> Verdict is still out if I can used RTAI , RTNET and TCP
> Here are my current troubles:
> 
> 1. rt_dev_Accept() seems to return ether -9,-22,-38 with the errorn
> specifying funciton not implemented.

Maybe rt_dev_accept is not properly wired up in RTAI user land though it
should simply translate to an IOCTL on the rtnet fd. Check the call
path, specifically if RTnet receives the IOCTL in rt_tcp_ioctl.

> 2. If I skip accept and just use the original FD, I get data but when I try
> to rt_dev_send() back to this FD, I get a crash and a "Ooops" output

Please provide backtraces.

> 3. If I issue a rt_dev_shutdown() on a UDP socket, I get an "Ooops' output.

Our UDP does not implement shutdown, but you shouldn't get an oops.
Again, we need backtraces (frame pointers enabled, please).

Jan

Re: [RTnet-developers] Ethernet IP

[Glen W. <gl...@je...>]

Thanks.

I will check.

Verdict is still out if I can used RTAI , RTNET and TCP
Here are my current troubles:

1. rt_dev_Accept() seems to return ether -9,-22,-38 with the errorn
specifying funciton not implemented.
2. If I skip accept and just use the original FD, I get data but when I try
to rt_dev_send() back to this FD, I get a crash and a "Ooops" output
3. If I issue a rt_dev_shutdown() on a UDP socket, I get an "Ooops' output.
Works on the TCP socket.

The program works with standard linux commands.

Glen


On 1/28/11 4:13 PM, "Jan Kiszka" <jan...@we...> wrote:

> On 2011-01-28 21:40, Glen Wernersbach wrote:
>> Jan,
>> 
>> On you last comment below about pre allocating buffers, I am trying to find
>> where in the RTAI examples it show that?
> 
> It's lacking in those few RTAI examples. Check xenomai/posix and watch
> out for RTNET_RTIOC_EXTPOOL. I think that should be trivially transferable.
> 
> Jan
> 

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
----
"Support Dyslexia Research"

Re: [RTnet-developers] Ethernet IP

[Jan K. <jan...@we...>]

On 2011-01-28 21:40, Glen Wernersbach wrote:
> Jan,
> 
> On you last comment below about pre allocating buffers, I am trying to find
> where in the RTAI examples it show that?

It's lacking in those few RTAI examples. Check xenomai/posix and watch
out for RTNET_RTIOC_EXTPOOL. I think that should be trivially transferable.

Jan

Re: [RTnet-developers] Ethernet IP

[Glen W. <gl...@je...>]

Jan,

On you last comment below about pre allocating buffers, I am trying to find
where in the RTAI examples it show that?

Glen


On 9/28/10 5:35 PM, "Jan Kiszka" <jan...@we...> wrote:

> Am 28.09.2010 23:17, Glen Wernersbach wrote:
>> Jan,
>> 
>> My basic concern was to keep the data flowing from the NIC to my program as
>> close to hard real time as possible. I know doing Linux calls can break hard
>> real time especially when I want to receive a UDP packet every 1ms.
> 
> Is that UDP packet part of your control loop? Why do you need the whole
> opener stack then? Or is there more?
> 
>> 
>> The only thing Ethernet IP really gives you real time is optional support
>> for the Ethernet 1588 timing standard so you know what the jitter was in
>> receiving the packet over the Ethernet line. The 1588 support is not yet
>> implemented in opener. The rest is just a protocol for handling critical
>> data over TCP and UDP. Unfortunately, I have a device that needs to work on
>> Allen Bradley controllers which only support this real time protocol.
>> 
>> All I want to do is replace the Linux calls in networkhandler.c
>> (socket,bind,listen...) with RTAI real time calls.
> 
> Additionally, you will have to configure the socket resources, namely
> how many buffers each socket should pre-allocate for its real-time
> operation (that's the major difference to normal networking stack that
> do on-demand allocations). See the examples.
> 
> Jan
> 

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
----
"Support Dyslexia Research"