rtnet-developers — development-related list

Re: [RTnet-developers] Only slave mode works on new port to ns9xxx

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

James Kilts wrote:
> Well, after populating the xmit_stamp field before calling dma_map_single() from hard_start_xmit(), it seems that at least that part is transmitted.  The rest of the payload, however, is still non-existent.

What rest to you refer to? There is no further payload beyond that five
TDMA fields.

>  It looks like the packet should be 60 bytes long, but the skb->len is only 42 in hard_start_xmit().  I've verified that 42 is indeed the actual length, because anything beyond that is garbage data.

Who is responsible for padding with the ns9xxx, the driver or the
hardware (though there should be no difference between Linux operation
and RTnet)? What does the receiver see of the sync frames?

> 
> The source code in its current state is attached, as well as the packet capture as it was failing before (without timestamps), and the most recent capture with timestamps but still without the remaining payload.  The parts of interest for the driver are hard_start_xmit around line 1100 and the transmit interrupt around line 720.
> 
> Thanks,
> - James
> 

Jan

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

Re: [RTnet-developers] Only slave mode works on new port to ns9xxx

[James K. <jam...@gm...>]

__________________________________________________________________

WITH VALID TRANSMISSION TIME, FAILING WITH REMAINING DATA



No.     Time        Source                Destination           Protocol Info
  18615 32.524751   FsForth-_ff:ff:fa     Broadcast             TDMA     Synchronisation

Frame 18615 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: FsForth-_ff:ff:fa (00:04:f3:ff:ff:fa), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
        Address: Broadcast (ff:ff:ff:ff:ff:ff)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
    Source: FsForth-_ff:ff:fa (00:04:f3:ff:ff:fa)
        Address: FsForth-_ff:ff:fa (00:04:f3:ff:ff:fa)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: Real-Time Media Access Control (0x9021)
Real-Time Media Access Control, Version 2
    Type: TDMA (0x0001)
    Version: 2
    Flags: 0x00
        0000 000. = Reserved Flags: 0x00
        .... ...0 = Tunnelling Flag: Not Set
TDMA RTmac Discipline, Synchronisation
    Version: 0x0201
    Message ID: Synchronisation (0x0000)
    Cycle Number: 1936
    Transmission Time Stamp: 23252741687 (+120304)
    Scheduled Transmission Time: 23252621383

0000  ff ff ff ff ff ff 00 04 f3 ff ff fa 90 21 00 01   .............!..
0010  02 00 02 01 00 00 00 00 07 90 00 00 00 05 69 f8   ..............i.
0020  ae 37 00 00 00 05 69 f6 d8 47 00 00 00 00 00 00   .7....i..G......
0030  00 00 00 00 00 00 00 00 00 00 00 00               ............





_______________________________________________________________

FAILING WITH TRANSMISSION TIME





No.     Time        Source                Destination           Protocol Info
  17857 20.935036   FsForth-_ff:ff:fa     Broadcast             TDMA     Synchronisation

Frame 17857 (60 bytes on wire, 60 bytes captured)
    Arrival Time: Dec 11, 2009 05:34:58.936120000
    [Time delta from previous captured frame: 0.000347000 seconds]
    [Time delta from previous displayed frame: 0.005003000 seconds]
    [Time since reference or first frame: 20.935036000 seconds]
    Frame Number: 17857
    Frame Length: 60 bytes
    Capture Length: 60 bytes
    [Frame is marked: False]
    [Protocols in frame: eth:rtmac]
    [Coloring Rule Name: Broadcast]
    [Coloring Rule String: eth[0] & 1]
Ethernet II, Src: FsForth-_ff:ff:fa (00:04:f3:ff:ff:fa), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
        Address: Broadcast (ff:ff:ff:ff:ff:ff)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
    Source: FsForth-_ff:ff:fa (00:04:f3:ff:ff:fa)
        Address: FsForth-_ff:ff:fa (00:04:f3:ff:ff:fa)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: Real-Time Media Access Control (0x9021)
Real-Time Media Access Control, Version 2
    Type: TDMA (0x0001)
    Version: 2
    Flags: 0x00
        0000 000. = Reserved Flags: 0x00
        .... ...0 = Tunnelling Flag: Not Set
TDMA RTmac Discipline, Synchronisation
    Version: 0x0201
    Message ID: Synchronisation (0x0000)
    Cycle Number: 10376
    Transmission Time Stamp: 0 (-80052902983)
    Scheduled Transmission Time: 80052902983

0000  ff ff ff ff ff ff 00 04 f3 ff ff fa 90 21 00 01   .............!..
0010  02 00 02 01 00 00 00 00 28 88 00 00 00 00 00 00   ........(.......
0020  00 00 00 00 00 12 a3 86 5c 47 00 00 00 00 00 00   ........\G......
0030  00 00 00 00 00 00 00 00 00 00 00 00               ............

Re: [RTnet-developers] Only slave mode works on new port to ns9xxx

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

CCs... :)

James Kilts wrote:
>> (Better include the parsed frames as wireshark displays them - easier to
>> read unless one knows all protocol bits by heart.)
> 
> Attached are the full Wireshark captures showing the device failing to populate all of the fields of the TDMA synch broadcast when running in master mode.

It shows that the driver obviously fails to populate the xmit-stamp field:

> TDMA RTmac Discipline, Synchronisation
>     Version: 0x0201
>     Message ID: Synchronisation (0x0000)
>     Cycle Number: 10376
>     Transmission Time Stamp: 0 (-80052902983)
>     Scheduled Transmission Time: 80052902983

and

> TDMA RTmac Discipline, Synchronisation
>     Version: 0x0201
>     Message ID: Synchronisation (0x0000)
>     Cycle Number: 89575
>     Transmission Time Stamp: 0 (-466667678324)
>     Scheduled Transmission Time: 466667678324

It's zero in both cases, but it should be close to the scheduled time.

> 
> 
>> Is your driver trying to time-stamp outgoing frame already? If yes,
>> maybe the is a problem with the required late update of the frame.
> 
> I'm not entirely sure I understand.  The driver time-stamps the outgoing frame in hard_start_xmit(), the same as many of the other drivers.  I've tried doing the time-stamp earlier and later in the process, but the result is basically the same.  In what part of the code does/should the "late update of the frame" occur?

It should happen atomically together with giving the transmission signal
to the hardware. If special measures are required to prepare the payload
transfer (like some cache flush e.g.), the frame patching must happen
before that or the measures need to be repeated for the modified payload
range.

Maybe you want to share your current work already, that would make the
discussion a bit more concrete.

Jan

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

Re: [RTnet-developers] Only slave mode works on new port to ns9xxx

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

James Kilts wrote:
> I'm running into another problem porting the ns9xxx-eth.c network
> driver to RTnet.  Slave mode works well when connecting to a known
> working PC with RTnet, and rtping works fine after the connection is
> established.  But device cannot establish a connection in master mode,
> neither while broadcasting for the PC nor while using another
> identical device (which obviously is known to work in slave mode).
> 
> I've verified that the RTcfg Stage 1 Config packets are identical
> (except for IP addresses) between the working setup (in slave mode)
> and the non-working condition (in master mode).  The problem seems to
> be with the TDMA Sync packets.  There are a number of fields which are
> simply not populated.  The "Cycle Number" is incrementing and
> "Scheduled Transmission Time" appears to be a somewhat reasonable
> value.  Why would the other values not be populated?  (see data
> capture below)

(Better include the parsed frames as wireshark displays them - easier to
read unless one knows all protocol bits by heart.)

Is your driver trying to time-stamp outgoing frame already? If yes,
maybe the is a problem with the required late update of the frame.

Jan

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

Re: [RTnet-developers] "Suspending kernel thread 'rtcfg-rx' after exception" on ns9xxx

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

James Kilts wrote:
> Here are a few patches that correct the memory alignment issues.  The first
> file also contains a change from "break" to "return" because the variable
> "stage_1_cfg" is used after the loop and is really just "rtskb->data" which
> is freed using kfree_rtskb() before the break.  The change to rtmac_proto.c
> was useful to me while tracking down an alignment issue, but if this last
> change was "accidentally" lost it wouldn't matter.  :-)
> 
> Syntactically I prefer dereferencing since it's easier to see what the code
> does at a glance (perhaps someone has a preference toward get_unaligned()
> and put_unaligned() instead).  But consistency with the rest of the code
> seems to demand memcpy().

All good catches, thanks! I just have a few style remarks below, and I
would like to ask you to properly slit up the patches:
 - unaligned access fixes
 - break->return fix
 - instrumentation enhancement

Moreover, when reposting, make sure that those patches are not
line-wrapped like this one.

> 
> - James
> 
> 
> 
> _____________________________
> 
> 
> 
> 
> Signed-off-by: James Kilts <jameskilts <at> google's mail service>

Your mail shows up in clear text when you go to public mailing lists, no
need to obfuscate, and I also prefer readable addresses in the git log.

> ---
> 
> 
> diff -ru rtnet-0.9.11_original/stack/rtcfg/rtcfg_client_event.c
> rtnet-0.9.11/stack/rtcfg/rtcfg_client_event.c
> --- rtnet-0.9.11_original/stack/rtcfg/rtcfg_client_event.c    2009-11-12
> 11:36:56.000000000 +0100
> +++ rtnet-0.9.11/stack/rtcfg/rtcfg_client_event.c    2009-12-10
> 16:07:16.000000000 +0100
> @@ -598,24 +622,24 @@
>              if (rtskb->len < sizeof(struct rtcfg_frm_stage_1_cfg) +
>                      2*RTCFG_ADDRSIZE_IP) {
>                  rtdm_mutex_unlock(&rtcfg_dev->dev_mutex);
>                  RTCFG_DEBUG(1, "RTcfg: received invalid stage_1_cfg "
>                              "frame\n");
>                  kfree_rtskb(rtskb);
> -                break;
> +                return;
>              }
> 
>              rtdev = rtskb->rtdev;
> 
> -            daddr = *(u32*)stage_1_cfg->client_addr;
> +            memcpy(&daddr, stage_1_cfg->client_addr, 4);
>              stage_1_cfg = (struct rtcfg_frm_stage_1_cfg *)
>                  (((u8 *)stage_1_cfg) + RTCFG_ADDRSIZE_IP);
> 
> -            saddr = *(u32*)stage_1_cfg->server_addr;
> +            memcpy(&saddr, stage_1_cfg->server_addr, 4);
>              stage_1_cfg = (struct rtcfg_frm_stage_1_cfg *)
>                  (((u8 *)stage_1_cfg) + RTCFG_ADDRSIZE_IP);
> 
>              __rtskb_pull(rtskb, 2*RTCFG_ADDRSIZE_IP);
> 
>              /* Broadcast: IP is used to address client */
>              if (rtskb->pkt_type == PACKET_BROADCAST) {
>                  /* directed to us? */
> @@ -748,6 +773,7 @@
>      struct rtcfg_frm_announce *announce_frm;
>      struct rtcfg_device       *rtcfg_dev = &device[ifindex];
>      u32                       i;
> +    u32                       announce_from_addr;
>      int                       result;
> 
> 
> @@ -771,8 +797,10 @@
>                  return -EINVAL;
>              }
> 
> +            memcpy(&announce_from_addr, announce_frm->addr, 4);
> +
>              /* update routing table */
> -            rt_ip_route_add_host(*(u32 *)announce_frm->addr,
> +            rt_ip_route_add_host(announce_from_addr,
>                                   rtskb->mac.ethernet->h_source,
> rtskb->rtdev);
> 
>              announce_frm = (struct rtcfg_frm_announce *)
> @@ -1045,7 +1073,7 @@
>                  return;
>              }
> 
> -            ip = *(u32 *)dead_station_frm->logical_addr;
> +            memcpy(&ip, dead_station_frm->logical_addr, 4);
> 
>              /* only delete remote IPs from routing table */
>              if (rtskb->rtdev->local_ip != ip)
> @@ -1132,11 +1160,11 @@
> 
>              rtdev = rtskb->rtdev;
> 
> -            daddr = *(u32*)stage_1_cfg->client_addr;
> +            memcpy(&daddr, stage_1_cfg->client_addr, 4);
>              stage_1_cfg = (struct rtcfg_frm_stage_1_cfg *)
>                  (((u8 *)stage_1_cfg) + RTCFG_ADDRSIZE_IP);
> 
> -            saddr = *(u32*)stage_1_cfg->server_addr;
> +            memcpy(&saddr, stage_1_cfg->server_addr, 4);
>              stage_1_cfg = (struct rtcfg_frm_stage_1_cfg *)
>                  (((u8 *)stage_1_cfg) + RTCFG_ADDRSIZE_IP);
> 
> diff -ru rtnet-0.9.11_original/stack/rtcfg/rtcfg_event.c
> rtnet-0.9.11/stack/rtcfg/rtcfg_event.c
> --- rtnet-0.9.11_original/stack/rtcfg/rtcfg_event.c    2009-11-12
> 11:36:56.000000000 +0100
> +++ rtnet-0.9.11/stack/rtcfg/rtcfg_event.c    2009-12-10 16:22:28.000000000
> +0100
> @@ -523,7 +532,7 @@
>  #ifdef CONFIG_RTNET_RTIPV4
>              case RTCFG_ADDR_IP:
>                  if (((conn->addr_type & RTCFG_ADDR_MASK) == RTCFG_ADDR_IP)
> &&
> -                    (*(u32 *)announce->addr == conn->addr.ip_addr)) {
> +                    (memcmp(announce->addr, &(conn->addr.ip_addr), 4) ==
> 0)) {

Better go via a local variable here that should carry announce->addr for
the comparison.

>                      /* save MAC address - Ethernet-specific! */
>                      memcpy(conn->mac_addr, rtskb->mac.ethernet->h_source,
>                             ETH_ALEN);
> 
> diff -ru rtnet-0.9.11_original/stack/rtcfg/rtcfg_frame.c
> rtnet-0.9.11/stack/rtcfg/rtcfg_frame.c
> --- rtnet-0.9.11_original/stack/rtcfg/rtcfg_frame.c    2009-11-12
> 11:36:56.000000000 +0100
> +++ rtnet-0.9.11/stack/rtcfg/rtcfg_frame.c    2009-12-10 16:13:04.000000000
> +0100
> @@ -170,12 +170,12 @@
>      if (stage_1_frm->addr_type == RTCFG_ADDR_IP) {
>          rtskb_put(rtskb, 2*RTCFG_ADDRSIZE_IP);
> 
> -        *(u32*)stage_1_frm->client_addr = conn->addr.ip_addr;
> +        memcpy(stage_1_frm->client_addr, &(conn->addr.ip_addr), 4);
> 
>          stage_1_frm = (struct rtcfg_frm_stage_1_cfg *)
>              (((u8 *)stage_1_frm) + RTCFG_ADDRSIZE_IP);
> 
> -        *(u32*)stage_1_frm->server_addr = rtdev->local_ip;
> +        memcpy(stage_1_frm->server_addr, &(rtdev->local_ip), 4);
> 
>          stage_1_frm = (struct rtcfg_frm_stage_1_cfg *)
>              (((u8 *)stage_1_frm) + RTCFG_ADDRSIZE_IP);
> @@ -332,7 +332,7 @@
>      if (announce_new->addr_type == RTCFG_ADDR_IP) {
>          rtskb_put(rtskb, RTCFG_ADDRSIZE_IP);
> 
> -        *(u32*)announce_new->addr = rtdev->local_ip;
> +        memcpy(announce_new->addr, &(rtdev->local_ip), 4);
> 
>          announce_new = (struct rtcfg_frm_announce *)
>              (((u8 *)announce_new) + RTCFG_ADDRSIZE_IP);
> @@ -388,7 +388,7 @@
>      if (announce_rpl->addr_type == RTCFG_ADDR_IP) {
>          rtskb_put(rtskb, RTCFG_ADDRSIZE_IP);
> 
> -        *(u32*)announce_rpl->addr = rtdev->local_ip;
> +        memcpy(announce_rpl->addr, &(rtdev->local_ip), 4);
> 
>          announce_rpl = (struct rtcfg_frm_announce *)
>              (((u8 *)announce_rpl) + RTCFG_ADDRSIZE_IP);
> @@ -512,7 +512,7 @@
>      if (dead_station_frm->addr_type == RTCFG_ADDR_IP) {
>          rtskb_put(rtskb, RTCFG_ADDRSIZE_IP);
> 
> -        *(u32*)dead_station_frm->logical_addr = conn->addr.ip_addr;
> +        memcpy(dead_station_frm->logical_addr, &(conn->addr.ip_addr), 4);
> 
>          dead_station_frm = (struct rtcfg_frm_dead_station *)
>              (((u8 *)dead_station_frm) + RTCFG_ADDRSIZE_IP);
> 
> diff -ru rtnet-0.9.11_original/stack/rtmac/rtmac_proto.c
> rtnet-0.9.11/stack/rtmac/rtmac_proto.c
> --- rtnet-0.9.11_original/stack/rtmac/rtmac_proto.c    2009-11-12
> 11:36:56.000000000 +0100
> +++ rtnet-0.9.11/stack/rtmac/rtmac_proto.c    2009-12-10 12:31:44.000000000
> +0100
> @@ -50,7 +50,8 @@
> 
>      if (hdr->ver != RTMAC_VERSION) {
>          rtdm_printk("RTmac: received unsupported RTmac protocol version on
> "
> -                    "device %s\n", skb->rtdev->name);
> +                    "device %s.  Got 0x%02x but expected 0x%02x.\n",
> +                    skb->rtdev->name, hdr->ver, RTMAC_VERSION);
>          goto error;
>      }
> 
> 
> 

Thanks again,
Jan

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

[RTnet-developers] Only slave mode works on new port to ns9xxx

[James K. <jam...@gm...>]

I'm running into another problem porting the ns9xxx-eth.c network
driver to RTnet.  Slave mode works well when connecting to a known
working PC with RTnet, and rtping works fine after the connection is
established.  But device cannot establish a connection in master mode,
neither while broadcasting for the PC nor while using another
identical device (which obviously is known to work in slave mode).

I've verified that the RTcfg Stage 1 Config packets are identical
(except for IP addresses) between the working setup (in slave mode)
and the non-working condition (in master mode).  The problem seems to
be with the TDMA Sync packets.  There are a number of fields which are
simply not populated.  The "Cycle Number" is incrementing and
"Scheduled Transmission Time" appears to be a somewhat reasonable
value.  Why would the other values not be populated?  (see data
capture below)

Thanks,
- James



___________________

Device as Slave - packet captures:

0000  ff ff ff ff ff ff 00 30  ab 02 87 df 90 21 00 01   .......0 .....!..
0010  02 00 02 01 00 00 00 04  9a 1a 11 7e 0b 2d 7a d5   ........ ...~.-z.
0020  b4 24 11 7e 0b 2d 7a d5  b0 ec 20 73 6c 6f 74 20   .$.~.-z. .. slot
0030  30 20 32 30 30 3b 69 66  63 6f 6e 66               0 200;if conf

0000  ff ff ff ff ff ff 00 30  ab 02 87 df 90 22 00 01   .......0 ....."..
0010  0a 65 01 7e 0a 65 01 7f  04 00 42 24 54 44 4d 41   .e.~.e.. ..B$TDMA
0020  43 46 47 20 72 74 65 74  68 30 20 73 6c 6f 74 20   CFG rtet h0 slot
0030  30 20 32 30 30 3b 69 66  63 6f 6e 66 69 67 20 76   0 200;if config v
0040  6e 69 63 30 20 75 70 20  24 49 50 41 44 44 52 20   nic0 up  $IPADDR
0050  24 4e 45 54 4d 41 53 4b  5f 4f 50 54 0a            $NETMASK _OPT.



___________________

Device as Master - packet captures:

0000  ff ff ff ff ff ff 00 04  f3 ff ff fa 90 21 00 01   ........ .....!..
0010  02 00 02 01 00 00 00 00  71 37 00 00 00 00 00 00   ........ q7........
0020  00 00 00 00 00 25 22 b7  d2 ea 00 00 00 00 00 00   .....%". ........
0030  00 00 00 00 00 00 00 00  00 00 00 00               ........ .....

0000  ff ff ff ff ff ff 00 30  ab 02 87 df 90 22 00 01   .......0 ....."..
0010  0a 65 01 7f 0a 65 01 7e  04 00 42 24 54 44 4d 41   .e...e.~ ..B$TDMA
0020  43 46 47 20 72 74 65 74  68 30 20 73 6c 6f 74 20   CFG rtet h0 slot
0030  30 20 32 30 30 3b 69 66  63 6f 6e 66 69 67 20 76   0 200;if config v
0040  6e 69 63 30 20 75 70 20  24 49 50 41 44 44 52 20   nic0 up  $IPADDR
0050  24 4e 45 54 4d 41 53 4b  5f 4f 50 54 0a            $NETMASK _OPT.

Re: [RTnet-developers] "Suspending kernel thread 'rtcfg-rx' after exception" on ns9xxx

[James K. <jam...@gm...>]

Here are a few patches that correct the memory alignment issues.  The first
file also contains a change from "break" to "return" because the variable
"stage_1_cfg" is used after the loop and is really just "rtskb->data" which
is freed using kfree_rtskb() before the break.  The change to rtmac_proto.c
was useful to me while tracking down an alignment issue, but if this last
change was "accidentally" lost it wouldn't matter.  :-)

Syntactically I prefer dereferencing since it's easier to see what the code
does at a glance (perhaps someone has a preference toward get_unaligned()
and put_unaligned() instead).  But consistency with the rest of the code
seems to demand memcpy().

- James



_____________________________




Signed-off-by: James Kilts <jameskilts <at> google's mail service>
---


diff -ru rtnet-0.9.11_original/stack/rtcfg/rtcfg_client_event.c
rtnet-0.9.11/stack/rtcfg/rtcfg_client_event.c
--- rtnet-0.9.11_original/stack/rtcfg/rtcfg_client_event.c    2009-11-12
11:36:56.000000000 +0100
+++ rtnet-0.9.11/stack/rtcfg/rtcfg_client_event.c    2009-12-10
16:07:16.000000000 +0100
@@ -598,24 +622,24 @@
             if (rtskb->len < sizeof(struct rtcfg_frm_stage_1_cfg) +
                     2*RTCFG_ADDRSIZE_IP) {
                 rtdm_mutex_unlock(&rtcfg_dev->dev_mutex);
                 RTCFG_DEBUG(1, "RTcfg: received invalid stage_1_cfg "
                             "frame\n");
                 kfree_rtskb(rtskb);
-                break;
+                return;
             }

             rtdev = rtskb->rtdev;

-            daddr = *(u32*)stage_1_cfg->client_addr;
+            memcpy(&daddr, stage_1_cfg->client_addr, 4);
             stage_1_cfg = (struct rtcfg_frm_stage_1_cfg *)
                 (((u8 *)stage_1_cfg) + RTCFG_ADDRSIZE_IP);

-            saddr = *(u32*)stage_1_cfg->server_addr;
+            memcpy(&saddr, stage_1_cfg->server_addr, 4);
             stage_1_cfg = (struct rtcfg_frm_stage_1_cfg *)
                 (((u8 *)stage_1_cfg) + RTCFG_ADDRSIZE_IP);

             __rtskb_pull(rtskb, 2*RTCFG_ADDRSIZE_IP);

             /* Broadcast: IP is used to address client */
             if (rtskb->pkt_type == PACKET_BROADCAST) {
                 /* directed to us? */
@@ -748,6 +773,7 @@
     struct rtcfg_frm_announce *announce_frm;
     struct rtcfg_device       *rtcfg_dev = &device[ifindex];
     u32                       i;
+    u32                       announce_from_addr;
     int                       result;


@@ -771,8 +797,10 @@
                 return -EINVAL;
             }

+            memcpy(&announce_from_addr, announce_frm->addr, 4);
+
             /* update routing table */
-            rt_ip_route_add_host(*(u32 *)announce_frm->addr,
+            rt_ip_route_add_host(announce_from_addr,
                                  rtskb->mac.ethernet->h_source,
rtskb->rtdev);

             announce_frm = (struct rtcfg_frm_announce *)
@@ -1045,7 +1073,7 @@
                 return;
             }

-            ip = *(u32 *)dead_station_frm->logical_addr;
+            memcpy(&ip, dead_station_frm->logical_addr, 4);

             /* only delete remote IPs from routing table */
             if (rtskb->rtdev->local_ip != ip)
@@ -1132,11 +1160,11 @@

             rtdev = rtskb->rtdev;

-            daddr = *(u32*)stage_1_cfg->client_addr;
+            memcpy(&daddr, stage_1_cfg->client_addr, 4);
             stage_1_cfg = (struct rtcfg_frm_stage_1_cfg *)
                 (((u8 *)stage_1_cfg) + RTCFG_ADDRSIZE_IP);

-            saddr = *(u32*)stage_1_cfg->server_addr;
+            memcpy(&saddr, stage_1_cfg->server_addr, 4);
             stage_1_cfg = (struct rtcfg_frm_stage_1_cfg *)
                 (((u8 *)stage_1_cfg) + RTCFG_ADDRSIZE_IP);

diff -ru rtnet-0.9.11_original/stack/rtcfg/rtcfg_event.c
rtnet-0.9.11/stack/rtcfg/rtcfg_event.c
--- rtnet-0.9.11_original/stack/rtcfg/rtcfg_event.c    2009-11-12
11:36:56.000000000 +0100
+++ rtnet-0.9.11/stack/rtcfg/rtcfg_event.c    2009-12-10 16:22:28.000000000
+0100
@@ -523,7 +532,7 @@
 #ifdef CONFIG_RTNET_RTIPV4
             case RTCFG_ADDR_IP:
                 if (((conn->addr_type & RTCFG_ADDR_MASK) == RTCFG_ADDR_IP)
&&
-                    (*(u32 *)announce->addr == conn->addr.ip_addr)) {
+                    (memcmp(announce->addr, &(conn->addr.ip_addr), 4) ==
0)) {
                     /* save MAC address - Ethernet-specific! */
                     memcpy(conn->mac_addr, rtskb->mac.ethernet->h_source,
                            ETH_ALEN);

diff -ru rtnet-0.9.11_original/stack/rtcfg/rtcfg_frame.c
rtnet-0.9.11/stack/rtcfg/rtcfg_frame.c
--- rtnet-0.9.11_original/stack/rtcfg/rtcfg_frame.c    2009-11-12
11:36:56.000000000 +0100
+++ rtnet-0.9.11/stack/rtcfg/rtcfg_frame.c    2009-12-10 16:13:04.000000000
+0100
@@ -170,12 +170,12 @@
     if (stage_1_frm->addr_type == RTCFG_ADDR_IP) {
         rtskb_put(rtskb, 2*RTCFG_ADDRSIZE_IP);

-        *(u32*)stage_1_frm->client_addr = conn->addr.ip_addr;
+        memcpy(stage_1_frm->client_addr, &(conn->addr.ip_addr), 4);

         stage_1_frm = (struct rtcfg_frm_stage_1_cfg *)
             (((u8 *)stage_1_frm) + RTCFG_ADDRSIZE_IP);

-        *(u32*)stage_1_frm->server_addr = rtdev->local_ip;
+        memcpy(stage_1_frm->server_addr, &(rtdev->local_ip), 4);

         stage_1_frm = (struct rtcfg_frm_stage_1_cfg *)
             (((u8 *)stage_1_frm) + RTCFG_ADDRSIZE_IP);
@@ -332,7 +332,7 @@
     if (announce_new->addr_type == RTCFG_ADDR_IP) {
         rtskb_put(rtskb, RTCFG_ADDRSIZE_IP);

-        *(u32*)announce_new->addr = rtdev->local_ip;
+        memcpy(announce_new->addr, &(rtdev->local_ip), 4);

         announce_new = (struct rtcfg_frm_announce *)
             (((u8 *)announce_new) + RTCFG_ADDRSIZE_IP);
@@ -388,7 +388,7 @@
     if (announce_rpl->addr_type == RTCFG_ADDR_IP) {
         rtskb_put(rtskb, RTCFG_ADDRSIZE_IP);

-        *(u32*)announce_rpl->addr = rtdev->local_ip;
+        memcpy(announce_rpl->addr, &(rtdev->local_ip), 4);

         announce_rpl = (struct rtcfg_frm_announce *)
             (((u8 *)announce_rpl) + RTCFG_ADDRSIZE_IP);
@@ -512,7 +512,7 @@
     if (dead_station_frm->addr_type == RTCFG_ADDR_IP) {
         rtskb_put(rtskb, RTCFG_ADDRSIZE_IP);

-        *(u32*)dead_station_frm->logical_addr = conn->addr.ip_addr;
+        memcpy(dead_station_frm->logical_addr, &(conn->addr.ip_addr), 4);

         dead_station_frm = (struct rtcfg_frm_dead_station *)
             (((u8 *)dead_station_frm) + RTCFG_ADDRSIZE_IP);

diff -ru rtnet-0.9.11_original/stack/rtmac/rtmac_proto.c
rtnet-0.9.11/stack/rtmac/rtmac_proto.c
--- rtnet-0.9.11_original/stack/rtmac/rtmac_proto.c    2009-11-12
11:36:56.000000000 +0100
+++ rtnet-0.9.11/stack/rtmac/rtmac_proto.c    2009-12-10 12:31:44.000000000
+0100
@@ -50,7 +50,8 @@

     if (hdr->ver != RTMAC_VERSION) {
         rtdm_printk("RTmac: received unsupported RTmac protocol version on
"
-                    "device %s\n", skb->rtdev->name);
+                    "device %s.  Got 0x%02x but expected 0x%02x.\n",
+                    skb->rtdev->name, hdr->ver, RTMAC_VERSION);
         goto error;
     }

Re: [RTnet-developers] "Suspending kernel thread 'rtcfg-rx' after exception" on ns9xxx

[James K. <jam...@gm...>]

It appears that boundary alignment was one of the causes for the
exceptions.  In rtcfg_client_event.c in the function
rtcfg_client_recv_stage_1() at line ~640, there are two lines that
dereference 32-bit values not aligned to a 4-byte boundary:

            daddr = *(u32*)stage_1_cfg->client_addr;
            saddr = *(u32*)stage_1_cfg->server_addr;

which should be changed to something like:

            memcpy(&daddr, stage_1_cfg->client_addr, 4);
            memcpy(&saddr, stage_1_cfg->server_addr, 4);

On ARM processors the data pointed to must be boundary aligned to the size
of the type being dereferenced, otherwise it can cause an exception.
Xenomai caught this exception and gave the ominous: "suspending kernel
thread ... after exception #0".  I'll look for some more of these unaligned
accesses, and send a patch later today.

I'm a bit surprised that no one else has had this issue on any of the other
ARM architectures...


> (take care of CCs)

Oops, too many late nights.  :-)


Thanks for your help.

- James


On Thu, Dec 10, 2009 at 1:47 AM, Jan Kiszka <jan...@we...> wrote:

> (take care of CCs)
>
> James Kilts wrote:
> >> rtcfg_main_state_off should not be called, even if the frame is totally
> >> corrupted (yeah, we are lacking basic range checks here):
> >> RTCFG_FRM_STAGE_1_CFG is added to the header ID, so you
> >> normally end up in the frame event handlers.
> >
> > While it's true that RTCFG_FRM_STAGE_1_CFG is added to the header ID for
> the
> > event_id, this has no effect on device[1].state in rtcfg_do_main_event().
> > The value of device[1].state defaults to 0, which means that the function
> is
> > invoked as "(*state[0])(...)" which in the state function array is
> > "rtcfg_main_state_off()".  Verified by rtdm_printk(),
> rtcfg_main_state_off()
> > is getting called.  In the end, rtcfg_main_state_off() puts it into the
> > correct state (RTCFG_MAIN_CLIENT_0), but not before potentially
> corrupting
> > memory.
>
> Now I got your path.
>
> >
> > Anyway, even when rtcfg_main_state_off() only calls
> rtcfg_next_main_state()
> > and rtdm_mutex_unlock() in the RTCFG_CMD_CLIENT case, this does not seem
> to
> > be the source of my problems.
> >
>
> Right. An unconfigured RTcfg node receiving RTcfg frames will spit out
> warnings if debugging is on or will simply ignore those frames. But it
> won't deference the event_data under an incorrect type.
>
> >
> >> What is the header ID when things go wrong?
> >
> > frm_head->id == 0.  It seems that the exception happens the first time
> > calling rtcfg_do_main_event() in rtcfg_rx_task().
> >
>
> Where precisely is important.
>
> >
> >> start with the frame as the stack finds it in memory after
> >> the driver handed it over. If that one is correct, we have a bug in the
> >> higher layers. But I strongly suspect the frame is corrupted.
> >
> > I think the frame is correct... here are some of the values from the
> rtskb
> > in rtcfg_main_state_client_0()  (where event_id ==
> RTCFG_FRM_STAGE_1_CFG):
> >
> > rtskb->nh.iph->saddr == 0x44542442
> > rtskb->nh.iph->daddr == 0x4643414d
> > rtskb->protocol == 8848
> > rtskb->pkt_type == 1
> > rtskb->priority == 0
> > rtskb->len == 83
> > rtskb->data[0] == 0x00
> > rtskb->data[1] == 0x01
> > rtskb->data[2] == 0x0a
> > rtskb->data[3] == 0x65
> > rtskb->data[4] == 0x01
> > rtskb->data[5] == 0x7e
> > rtskb->data[6] == 0x0a
> > rtskb->data[7] == 0x65
> >
> >
> > My debugging environment is limited at the moment.  When the exception
> > occurs, the stack is lost due to the exception handler, so the hardware
> > debugger is of little or no value.
>
> You know the call path quite well already, and this path is taken the
> first time here, so setting proper breakpoints should be no deal - given
> you actually have a suited hardware debugger, do you?
>
> >  And when I use too many rtdm_printk()
> > calls, the entire system hangs before the exception.  Because of the last
> > issue, I can't use the built-in debugging features of RTnet.  Any
> > suggestions for debugging this?
>
> Xenomai reports the failing instruction address in the suspension
> message. Collect the module address (/proc/modules), compile the module
> with debug symbols (=>CONFIG_DEBUG_INFO), and process the binary with
> objdump or gdb. That should give you the instruction and its environment
> (ie. source code line).
>
> Jan
>
>

Re: [RTnet-developers] "Suspending kernel thread 'rtcfg-rx' after exception" on ns9xxx

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

(take care of CCs)

James Kilts wrote:
>> rtcfg_main_state_off should not be called, even if the frame is totally
>> corrupted (yeah, we are lacking basic range checks here):
>> RTCFG_FRM_STAGE_1_CFG is added to the header ID, so you
>> normally end up in the frame event handlers.
> 
> While it's true that RTCFG_FRM_STAGE_1_CFG is added to the header ID for the
> event_id, this has no effect on device[1].state in rtcfg_do_main_event().
> The value of device[1].state defaults to 0, which means that the function is
> invoked as "(*state[0])(...)" which in the state function array is
> "rtcfg_main_state_off()".  Verified by rtdm_printk(), rtcfg_main_state_off()
> is getting called.  In the end, rtcfg_main_state_off() puts it into the
> correct state (RTCFG_MAIN_CLIENT_0), but not before potentially corrupting
> memory.

Now I got your path.

> 
> Anyway, even when rtcfg_main_state_off() only calls rtcfg_next_main_state()
> and rtdm_mutex_unlock() in the RTCFG_CMD_CLIENT case, this does not seem to
> be the source of my problems.
> 

Right. An unconfigured RTcfg node receiving RTcfg frames will spit out
warnings if debugging is on or will simply ignore those frames. But it
won't deference the event_data under an incorrect type.

> 
>> What is the header ID when things go wrong?
> 
> frm_head->id == 0.  It seems that the exception happens the first time
> calling rtcfg_do_main_event() in rtcfg_rx_task().
> 

Where precisely is important.

> 
>> start with the frame as the stack finds it in memory after
>> the driver handed it over. If that one is correct, we have a bug in the
>> higher layers. But I strongly suspect the frame is corrupted.
> 
> I think the frame is correct... here are some of the values from the rtskb
> in rtcfg_main_state_client_0()  (where event_id == RTCFG_FRM_STAGE_1_CFG):
> 
> rtskb->nh.iph->saddr == 0x44542442
> rtskb->nh.iph->daddr == 0x4643414d
> rtskb->protocol == 8848
> rtskb->pkt_type == 1
> rtskb->priority == 0
> rtskb->len == 83
> rtskb->data[0] == 0x00
> rtskb->data[1] == 0x01
> rtskb->data[2] == 0x0a
> rtskb->data[3] == 0x65
> rtskb->data[4] == 0x01
> rtskb->data[5] == 0x7e
> rtskb->data[6] == 0x0a
> rtskb->data[7] == 0x65
> 
> 
> My debugging environment is limited at the moment.  When the exception
> occurs, the stack is lost due to the exception handler, so the hardware
> debugger is of little or no value.

You know the call path quite well already, and this path is taken the
first time here, so setting proper breakpoints should be no deal - given
you actually have a suited hardware debugger, do you?

>  And when I use too many rtdm_printk()
> calls, the entire system hangs before the exception.  Because of the last
> issue, I can't use the built-in debugging features of RTnet.  Any
> suggestions for debugging this?

Xenomai reports the failing instruction address in the suspension
message. Collect the module address (/proc/modules), compile the module
with debug symbols (=>CONFIG_DEBUG_INFO), and process the binary with
objdump or gdb. That should give you the instruction and its environment
(ie. source code line).

Jan

Re: [RTnet-developers] Fwd: "Suspending kernel thread 'rtcfg-rx' after exception" on ns9xxx

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

James Kilts wrote:
>> I suspect the driver has some bug in its RX path, and the RTmac layer is
>> the first consumer suffering from it, generating an exception.
> 
> I've traced back through the RX path, but I don't see anything out of the
> ordinary compared to the other RTnet drivers.  Really, I'm a little bit
> confused as to how rtcfg_rx_task can work.  In rtcfg_rx_task() the last
> parameter to rtcfg_do_main_event() is rtskb*, which it gets from
> rtskb_dequeue().  This parameter is implicitly cast to void*.
> rtcfg_do_main_event() in turn calls the function pointer from array state[],
> which in the initial part of slave mode will call rtcfg_main_state_off().
> Here the rtskb* is cast from void* to rt_proc_call*.  All of this wouldn't
> be so bad if rt_proc_call and rtskb were compatible structures, but the two
> are quite different from the very beginning.

rtcfg_main_state_off should not be called, even if the frame is totally
corrupted (yeah, we are lacking basic range checks here):
RTCFG_FRM_STAGE_1_CFG is added to the header ID, so you normally end up
in the frame event handlers. What is the header ID when things go wrong?

> 
> Does rtskb_dequeue() actually return a rt_proc_call*, just improperly cast
> as a rtskb*?
> 
> 
> 
>> Resolve the address given along with the suspension error, check the
>> disassembly or instrument the RTmac code to find out what it tries to
>> access (I bet some rtskb field that is corrupted).
> 
> Even after the exception in RTcfg, the driver itself continues to produce
> (as far as I can tell) valid rtskb instances with incoming traffic.
> Although the exception is in RTcfg, is there a part of the code in RTmac
> that I should investigate for corruption?

Not RTmac, start with the frame as the stack finds it in memory after
the driver handed it over. If that one is correct, we have a bug in the
higher layers. But I strongly suspect the frame is corrupted.

Jan

[RTnet-developers] Fwd: "Suspending kernel thread 'rtcfg-rx' after exception" on ns9xxx

[James K. <jam...@gm...>]

> I suspect the driver has some bug in its RX path, and the RTmac layer is
> the first consumer suffering from it, generating an exception.

I've traced back through the RX path, but I don't see anything out of the
ordinary compared to the other RTnet drivers.  Really, I'm a little bit
confused as to how rtcfg_rx_task can work.  In rtcfg_rx_task() the last
parameter to rtcfg_do_main_event() is rtskb*, which it gets from
rtskb_dequeue().  This parameter is implicitly cast to void*.
rtcfg_do_main_event() in turn calls the function pointer from array state[],
which in the initial part of slave mode will call rtcfg_main_state_off().
Here the rtskb* is cast from void* to rt_proc_call*.  All of this wouldn't
be so bad if rt_proc_call and rtskb were compatible structures, but the two
are quite different from the very beginning.

Does rtskb_dequeue() actually return a rt_proc_call*, just improperly cast
as a rtskb*?



> Resolve the address given along with the suspension error, check the
> disassembly or instrument the RTmac code to find out what it tries to
> access (I bet some rtskb field that is corrupted).

Even after the exception in RTcfg, the driver itself continues to produce
(as far as I can tell) valid rtskb instances with incoming traffic.
Although the exception is in RTcfg, is there a part of the code in RTmac
that I should investigate for corruption?


Thanks,

- James

Re: [RTnet-developers] "Suspending kernel thread 'rtcfg-rx' after exception" on ns9xxx

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

James Kilts wrote:
> I'm porting the ns9xxx-eth.c network driver to RTnet, but I'm getting a
> "Xenomai: suspending kernel thread" exception in RTcfg in slave mode.  In
> Master mode, the driver appears to load fine and it floods the network with
> healthy dose of TDMA messages (about 200 packets per second).  I have yet to
> verify that another machine can connect to it, but that may be due to issues
> with the test PC.
> 
> However, while running in Slave mode the driver appears to fail while
> connecting to the master (or possibly while looking for it).  The output is
> listed below.  I searched the mailing lists but I haven't found this type of
> exception happening within one of the RTnet modules.

I suspect the driver has some bug in its RX path, and the RTmac layer is
the first consumer suffering from it, generating an exception.

> 
> This seems like a configuration issue since the wireshark output shows what
> appear to be bash script variables not being populated:  $IPADDR, $TDMACFG,
> etc.  The strange thing is that I'm also seeing the same output from my test
> PC running rt_8139too.  I've posted wireshark captures from an impartial
> third-party PC.
> 
> Any help would be greatly appreciated.

Resolve the address given along with the suspension error, check the
disassembly or instrument the RTmac code to find out what it tries to
access (I bet some rtskb field that is corrupted).

Jan

[RTnet-developers] "Suspending kernel thread 'rtcfg-rx' after exception" on ns9xxx

[James K. <jam...@gm...>]

I'm porting the ns9xxx-eth.c network driver to RTnet, but I'm getting a
"Xenomai: suspending kernel thread" exception in RTcfg in slave mode.  In
Master mode, the driver appears to load fine and it floods the network with
healthy dose of TDMA messages (about 200 packets per second).  I have yet to
verify that another machine can connect to it, but that may be due to issues
with the test PC.

However, while running in Slave mode the driver appears to fail while
connecting to the master (or possibly while looking for it).  The output is
listed below.  I searched the mailing lists but I haven't found this type of
exception happening within one of the RTnet modules.

This seems like a configuration issue since the wireshark output shows what
appear to be bash script variables not being populated:  $IPADDR, $TDMACFG,
etc.  The strange thing is that I'm also seeing the same output from my test
PC running rt_8139too.  I've posted wireshark captures from an impartial
third-party PC.

Any help would be greatly appreciated.

Thanks,
- James


-------------


RTnet: 0.9.11
Xenomai: 2.4.10
I-Pipe: 1.12-05
Linux: 2.6.28.10 (a patched variant thereof)
Platform: ns9xxx (yes, that arm9)


-------------


# ./rtnet start

*** RTnet 0.9.11 - built on Dec  2 2009 11:59:51 ***

RTnet: initialising real-time networking
ns9xxx-eth-mii: probed
RTnet: registered rteth0
ns9xxx-eth ns9xxx-eth: rteth0 at MMIO c28a0000
Digi NS9XXX RTnet Ethernet driver
initializing loopback...
RTnet: registered rtlo
RTcfg: init real-time configuration distribution protocol
RTmac: init realtime media access control
RTmac/TDMA: init time division multiple access control mechanism
Stage 1: searching for master...link up (100/full)
Xenomai: suspending kernel thread bf035be8 ('rtcfg-rx') at 0xc00269f8 after
exception #0
RTnet: no one cared for packet with layer 3 protocol type 0x0004
RTnet: no one cared for packet with layer 3 protocol type 0x0004
RTnet: no one cared for packet with layer 3 protocol type 0x0004
RTnet: no one cared for packet with layer 3 protocol type 0x0004
RTnet: no one cared for packet with layer 3 protocol type 0x0004
...


[ctrl+c still exits to the console, but the device stops trying to connect]



---------------



rt_ns9xxx-eth - TDMA Sync packet (captured with Wireshark):

0000  ff ff ff ff ff ff 00 04  f3 ff ff fa 90 21 00 01   ........ .....!..
0010  02 00 02 01 00 00 00 00  0a 95 00 00 00 00 00 00   ........ ........
0020  00 00 00 00 00 06 ac 1d  2d 6b 00 00 00 00 00 00   ........ -k......
0030  00 00 00 00 00 00 00 00  00 00 00 00               ........ ....


rt_ns9xxx-eth - RTcfg Stage 1 Config packet (captured with Wireshark):

0000  ff ff ff ff ff ff 00 04  f3 ff ff fa 90 22 00 01   ........ ....."..
0010  0a 65 01 ea 0a 65 01 7e  04 00 42 24 54 44 4d 41   .e...e.~ ..B$TDMA
0020  43 46 47 20 72 74 65 74  68 30 20 73 6c 6f 74 20   CFG rtet h0 slot
0030  30 20 32 30 30 3b 69 66  63 6f 6e 66 69 67 20 76   0 200;if config v
0040  6e 69 63 30 20 75 70 20  24 49 50 41 44 44 52 20   nic0 up  $IPADDR
0050  24 4e 45 54 4d 41 53 4b  5f 4f 50 54 0a            $NETMASK _OPT.



---------------



PC with rt_8139too - TDMA Sync packet (captured with Wireshark):

0000  ff ff ff ff ff ff 00 30  ab 02 87 df 90 21 00 01   .......0 .....!..
0010  02 00 02 01 00 00 00 01  bb bd 11 7b 84 7d 52 76   ........ ...{.}Rv
0020  e6 db 11 7b 84 7d 52 76  e3 b1 20 73 6c 6f 74 20   ...{.}Rv .. slot
0030  30 20 32 30 30 3b 69 66  63 6f 6e 66               0 200;if conf



PC with rt_8139too - RTcfg Stage 1 Config packet (captured with Wireshark):

0000  ff ff ff ff ff ff 00 30  ab 02 87 df 90 22 00 01   .......0 ....."..
0010  0a 65 01 7e 0a 65 01 7f  04 00 42 24 54 44 4d 41   .e.~.e.. ..B$TDMA
0020  43 46 47 20 72 74 65 74  68 30 20 73 6c 6f 74 20   CFG rtet h0 slot
0030  30 20 32 30 30 3b 69 66  63 6f 6e 66 69 67 20 76   0 200;if config v
0040  6e 69 63 30 20 75 70 20  24 49 50 41 44 44 52 20   nic0 up  $IPADDR
0050  24 4e 45 54 4d 41 53 4b  5f 4f 50 54 0a            $NETMASK _OPT.

Re: [RTnet-developers] rt_eepro100 suspected bug

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

stephane ancelot wrote:
> Hi,
> We have got some problems running eepro100 driver at VERY fast rate, we  
> send frame very fast, and read recv reply of there is one
> 
> at very very fast rate, sometime, frame are lost using our integrated nic .
> 
> We ran the same program using a pci rtl8139 nic board  and we are not  
> affected by the problem.

How are we supposed to help you, given this description?

Jan

Re: [RTnet-developers] Suspect packet

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

Frank Tkalcevic wrote:
>> Frank Tkalcevic wrote:
>>>>> I'm not sure why the sync packets were coming out as well
>>>> as the rtcfg
>>>>> traffic.  Is that correct behaviour?  I would have 
>> thought the sync 
>>>>> process would only happen after rtcfg set up was complete.
>>>> It is correct, RTmac/TDMA is in charge of managing the 
>> media access 
>>>> right from the start (that's why RTcfg stage 1 frames have 
>> to include 
>>>> all information a slave needs to send its own frames, 
>> namely the TDMA 
>>>> cycle offset and phase).
>>>>
>>>> BTW, Wireshark is capable of decoding RTnet frames, maybe 
>> helpful for 
>>>> understanding the procedures.
>>>
>>> That's confusing me a bit.  It looks like rtcfg just 
>> outputs packets 
>>> as it pleases and doesn't obey real time rules.  Does it 
>> sit on top of Rtmac?
>>> Does it need to stop after all the clients are ready and 
>> obeying the 
>>> TDMA protocol, or can it coexist?
>> RTcfg is plain payload from RTmac/TDMA POV. Check if RTcfg 
>> frames sent by the master have a fixed offset (minus jitter) 
>> from the Sync frame. If not, something is badly configured 
>> (but that is unlikely if you used the standard setup script).
> 
> Things are working fine.  The questions are for my understanding of rtnet.
> Sorry for being a pest.
> 
> How is the offset defined?  In my stage 1 configuration I have...
> 
> TDMACFG rteth0 slot 0 200;ifconfig vnic0
> 
> which defines one slot at an offset of 200.  Is this used for rtcfg?  How
> does the slave know at what offset to send rtcfg messages?  

RTcfg stage 1 is transferring this executable configuration bit to the
slave, the slave runs it and, thus, configures its TDMA to emit frames
in slot 0 with an offset of 200 us to the Sync frame.

This pattern works fine for Unix RTnet nodes, but it already showed it
limitations when adding RTmac/TDMA to old Etherboot (I had to parse that
script line, relying on its informal layout). We would actually need to
define proper config sub-formats (per RTmac discipline) for RTcfg, at
least for stage 1.

Jan

Re: [RTnet-developers] rt_eepro100 suspected bug

[stephane a. <san...@fr...>]

Le Tue, 24 Nov 2009 13:47:01 +0100, stephane ancelot <san...@fr...> a  
écrit:

> Le Tue, 24 Nov 2009 13:25:40 +0100, Jan Kiszka <jan...@we...> a  
> écrit:
>
>> stephane ancelot wrote:
>>> Hi,
>>> We have got some problems running eepro100 driver at VERY fast rate, we
>>> send frame very fast, and read recv reply of there is one
>>>
>>> at very very fast rate, sometime, frame are lost using our integrated
>>> nic .
>>>
>>> We ran the same program using a pci rtl8139 nic board  and we are not
>>> affected by the problem.
>>
>> How are we supposed to help you, given this description?
>
> That was to send out an SOS, at the moment, this problem is involved in
> talking to ethercat slaves, that quickly read frames and send it  
> back.This
> happens mainly when we setup our master's distributed clock.
>
I forgot it : it fails if computer is directly linked to slaves.

However, using a switch between the eepro100 and the slaves, the problem  
disappear....

> however, we might first  setup a basic program sending frames to another
> slave machine that only forward these frames , both sides using RTNet.But
> you may have already done this ?
>
>
>
>>
>> Jan
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> RTnet-developers mailing list
> RTn...@li...
> https://lists.sourceforge.net/lists/listinfo/rtnet-developers

Re: [RTnet-developers] rt_eepro100 suspected bug

[stephane a. <san...@fr...>]

Le Tue, 24 Nov 2009 13:25:40 +0100, Jan Kiszka <jan...@we...> a écrit:

> stephane ancelot wrote:
>> Hi,
>> We have got some problems running eepro100 driver at VERY fast rate, we
>> send frame very fast, and read recv reply of there is one
>>
>> at very very fast rate, sometime, frame are lost using our integrated  
>> nic .
>>
>> We ran the same program using a pci rtl8139 nic board  and we are not
>> affected by the problem.
>
> How are we supposed to help you, given this description?

That was to send out an SOS, at the moment, this problem is involved in  
talking to ethercat slaves, that quickly read frames and send it back.This  
happens mainly when we setup our master's distributed clock.

however, we might first  setup a basic program sending frames to another  
slave machine that only forward these frames , both sides using RTNet.But  
you may have already done this ?



>
> Jan
>

[RTnet-developers] rt_eepro100 suspected bug

[stephane a. <san...@fr...>]

Hi,
We have got some problems running eepro100 driver at VERY fast rate, we  
send frame very fast, and read recv reply of there is one

at very very fast rate, sometime, frame are lost using our integrated nic .

We ran the same program using a pci rtl8139 nic board  and we are not  
affected by the problem.

Best Regards
S.Ancelot

Re: [RTnet-developers] Suspect packet

[Frank T. <fr...@fr...>]

> 
> Frank Tkalcevic wrote:
> >>> I'm not sure why the sync packets were coming out as well
> >> as the rtcfg
> >>> traffic.  Is that correct behaviour?  I would have 
> thought the sync 
> >>> process would only happen after rtcfg set up was complete.
> >> It is correct, RTmac/TDMA is in charge of managing the 
> media access 
> >> right from the start (that's why RTcfg stage 1 frames have 
> to include 
> >> all information a slave needs to send its own frames, 
> namely the TDMA 
> >> cycle offset and phase).
> >>
> >> BTW, Wireshark is capable of decoding RTnet frames, maybe 
> helpful for 
> >> understanding the procedures.
> > 
> > 
> > That's confusing me a bit.  It looks like rtcfg just 
> outputs packets 
> > as it pleases and doesn't obey real time rules.  Does it 
> sit on top of Rtmac?
> > Does it need to stop after all the clients are ready and 
> obeying the 
> > TDMA protocol, or can it coexist?
> 
> RTcfg is plain payload from RTmac/TDMA POV. Check if RTcfg 
> frames sent by the master have a fixed offset (minus jitter) 
> from the Sync frame. If not, something is badly configured 
> (but that is unlikely if you used the standard setup script).

Things are working fine.  The questions are for my understanding of rtnet.
Sorry for being a pest.

How is the offset defined?  In my stage 1 configuration I have...

TDMACFG rteth0 slot 0 200;ifconfig vnic0

which defines one slot at an offset of 200.  Is this used for rtcfg?  How
does the slave know at what offset to send rtcfg messages?  


Thanks,
Frank

Re: [RTnet-developers] Suspect packet

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

Frank Tkalcevic wrote:
>>> I'm not sure why the sync packets were coming out as well 
>> as the rtcfg 
>>> traffic.  Is that correct behaviour?  I would have thought the sync 
>>> process would only happen after rtcfg set up was complete.
>> It is correct, RTmac/TDMA is in charge of managing the media 
>> access right from the start (that's why RTcfg stage 1 frames 
>> have to include all information a slave needs to send its own 
>> frames, namely the TDMA cycle offset and phase).
>>
>> BTW, Wireshark is capable of decoding RTnet frames, maybe 
>> helpful for understanding the procedures.
> 
> 
> That's confusing me a bit.  It looks like rtcfg just outputs packets as it
> pleases and doesn't obey real time rules.  Does it sit on top of Rtmac?
> Does it need to stop after all the clients are ready and obeying the TDMA
> protocol, or can it coexist?

RTcfg is plain payload from RTmac/TDMA POV. Check if RTcfg frames sent
by the master have a fixed offset (minus jitter) from the Sync frame. If
not, something is badly configured (but that is unlikely if you used the
standard setup script).

Jan

Re: [RTnet-developers] Suspect packet

[Frank T. <fr...@fr...>]

> > I'm not sure why the sync packets were coming out as well 
> as the rtcfg 
> > traffic.  Is that correct behaviour?  I would have thought the sync 
> > process would only happen after rtcfg set up was complete.
> 
> It is correct, RTmac/TDMA is in charge of managing the media 
> access right from the start (that's why RTcfg stage 1 frames 
> have to include all information a slave needs to send its own 
> frames, namely the TDMA cycle offset and phase).
> 
> BTW, Wireshark is capable of decoding RTnet frames, maybe 
> helpful for understanding the procedures.


That's confusing me a bit.  It looks like rtcfg just outputs packets as it
pleases and doesn't obey real time rules.  Does it sit on top of Rtmac?
Does it need to stop after all the clients are ready and obeying the TDMA
protocol, or can it coexist?

Thanks,
Frank

Re: [RTnet-developers] Suspect packet

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

Frank Tkalcevic wrote:
>>>
>>> It looks like a corrupt buffer, half sync packet, and half 
>> a config packet.
>> Not necessarily corrupted, but too long. Where and how did 
>> you capture this frame? 
> 
> The capture is from my embedded client.  The data transfers and packet
> length count is handled completely by the microcontroller, so I'm confident
> it is working correctly.  
> 
>> Does it fit into the TDMA cycle?
> 
> I don't fully understand rtnet to really answer that.  I started rtnet on my
> linux box, and it was waiting for slaves to connect.  Sync packets were
> coming out at the default 5000us interval as well as the rtcfg traffic
> (client config every 1000ms).  
> 
> I'm not sure why the sync packets were coming out as well as the rtcfg
> traffic.  Is that correct behaviour?  I would have thought the sync process
> would only happen after rtcfg set up was complete.

It is correct, RTmac/TDMA is in charge of managing the media access
right from the start (that's why RTcfg stage 1 frames have to include
all information a slave needs to send its own frames, namely the TDMA
cycle offset and phase).

BTW, Wireshark is capable of decoding RTnet frames, maybe helpful for
understanding the procedures.

> 
>>> This is coming from my master, a VIA Pico, with a via rhine 
>> ethernet 
>>> controller, using kernel 2.6.24-16-rtai (stock EMC2 deploy).  I 
>>> noticed that a comment in the rtnet rhine driver source say 
>> Rhine II, 
>>> but the board has a rhine III.  Could it be due to this?  
>> Or is this an undocumented packet?
>>
>> I guess the Rhine III is operated by the same driver as the 
>> II in standard Linux. Then is may make some sense to check 
>> the original code for diffs with our version, specifically 
>> for changes that target III support.
> 
> 
> Thanks, I'll check that.
> 

Additionally, you could instrument the driver to check what frame sizes
it receives from the upper layers and tries to send out. It's unlikely
that there is a bug at those levels, but who knows...

Jan

Re: [RTnet-developers] Suspect packet

[Frank T. <fr...@fr...>]

> > 
> > 
> > It looks like a corrupt buffer, half sync packet, and half 
> a config packet.
> > 
> 
> Not necessarily corrupted, but too long. Where and how did 
> you capture this frame? 

The capture is from my embedded client.  The data transfers and packet
length count is handled completely by the microcontroller, so I'm confident
it is working correctly.  

> Does it fit into the TDMA cycle?

I don't fully understand rtnet to really answer that.  I started rtnet on my
linux box, and it was waiting for slaves to connect.  Sync packets were
coming out at the default 5000us interval as well as the rtcfg traffic
(client config every 1000ms).  

I'm not sure why the sync packets were coming out as well as the rtcfg
traffic.  Is that correct behaviour?  I would have thought the sync process
would only happen after rtcfg set up was complete.

> 
> > This is coming from my master, a VIA Pico, with a via rhine 
> ethernet 
> > controller, using kernel 2.6.24-16-rtai (stock EMC2 deploy).  I 
> > noticed that a comment in the rtnet rhine driver source say 
> Rhine II, 
> > but the board has a rhine III.  Could it be due to this?  
> Or is this an undocumented packet?
> 
> I guess the Rhine III is operated by the same driver as the 
> II in standard Linux. Then is may make some sense to check 
> the original code for diffs with our version, specifically 
> for changes that target III support.


Thanks, I'll check that.

Frank

Re: [RTnet-developers] Suspect packet

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

Frank Tkalcevic wrote:
> I've just started playing around with RTNet.  The plan is to use a master on
> my EMC2 machine, and talk to slaves to do real time control of machines (my
> toy robot arm first).  The slave will be a small embedded device.  I'm
> currently developing on an NGW100 which has an Atmel AP7000 on it.
> Unfortunately there isn't a realtime kernel patch for this CPU, so I'm going

There were some guys on xenomai-help talking about porting ipipe to the
NGW100, but it's too early to asses this effort.

> to make the clients standalone - either by porting the rtnet software, or
> implementing it myself based on the packet specification.  The plan is to
> move it to a smaller self contain microcontroller (AVR32UC3 range) when it
> is up and running.
> 
> Anyhow, I've just got the basic networking going and noticed a strange
> packet appearing every now and then....
> 
> 
> Received 93 bytes
> 0000  FF FF FF FF FF FF 00 40 63 F6 3D 51 90 21 00 01  .......@c.=Q.!..
> 0010  02 00 02 01 00 00 00 01 20 38 00 00 00 82 DB 43  ........ 8.....C
> 0020  15 4B 00 00 00 82 DB 43 15 3D 00 00 00 00 00 00  .K.....C.=......
> 0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> 0040  6E 69 63 30 20 75 70 20 24 49 50 41 44 44 52 20  nic0 up $IPADDR 
> 0050  24 4E 45 54 4D 41 53 4B 5F 4F 50 54 0A           $NETMASK_OPT....
> 
> 
> It looks like a corrupt buffer, half sync packet, and half a config packet.
> 

Not necessarily corrupted, but too long. Where and how did you capture
this frame? Does it fit into the TDMA cycle?

> 
> This is the normal traffic I see...
> 
> Received 60 bytes
> 0000  FF FF FF FF FF FF 00 40 63 F6 3D 51 90 21 00 01  .......@c.=Q.!..
> 0010  02 00 02 01 00 00 00 00 06 A1 00 00 0A 78 1B 65  .............x.e
> 0020  A1 64 00 00 0A 78 1B 65 99 C8 00 00 00 00 00 00  .d...x.e........
> 0030  00 00 00 00 00 00 00 00 00 00 00 00              ................
> 
> 
> Received 85 bytes
> 0000  00 04 25 00 01 02 00 40 63 F6 3D 51 90 22 00 00  ..%....@c.=Q."..
> 0010  04 00 42 24 54 44 4D 41 43 46 47 20 72 74 65 74  ..B$TDMACFG rtet
> 0020  68 30 20 73 6C 6F 74 20 30 20 32 30 30 3B 69 66  h0 slot 0 200;if
> 0030  63 6F 6E 66 69 67 20 76 6E 69 63 30 20 75 70 20  config vnic0 up
> 0040  24 49 50 41 44 44 52 20 24 4E 45 54 4D 41 53 4B  $IPADDR $NETMASK
> 0050  5F 4F 50 54 0A                                   _OPT............
> 
> This is coming from my master, a VIA Pico, with a via rhine ethernet
> controller, using kernel 2.6.24-16-rtai (stock EMC2 deploy).  I noticed that
> a comment in the rtnet rhine driver source say Rhine II, but the board has a
> rhine III.  Could it be due to this?  Or is this an undocumented packet?

I guess the Rhine III is operated by the same driver as the II in
standard Linux. Then is may make some sense to check the original code
for diffs with our version, specifically for changes that target III
support.

Jan

[RTnet-developers] Suspect packet

[Frank T. <fr...@fr...>]

I've just started playing around with RTNet.  The plan is to use a master on
my EMC2 machine, and talk to slaves to do real time control of machines (my
toy robot arm first).  The slave will be a small embedded device.  I'm
currently developing on an NGW100 which has an Atmel AP7000 on it.
Unfortunately there isn't a realtime kernel patch for this CPU, so I'm going
to make the clients standalone - either by porting the rtnet software, or
implementing it myself based on the packet specification.  The plan is to
move it to a smaller self contain microcontroller (AVR32UC3 range) when it
is up and running.

Anyhow, I've just got the basic networking going and noticed a strange
packet appearing every now and then....


Received 93 bytes
0000  FF FF FF FF FF FF 00 40 63 F6 3D 51 90 21 00 01  .......@c.=Q.!..
0010  02 00 02 01 00 00 00 01 20 38 00 00 00 82 DB 43  ........ 8.....C
0020  15 4B 00 00 00 82 DB 43 15 3D 00 00 00 00 00 00  .K.....C.=......
0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0040  6E 69 63 30 20 75 70 20 24 49 50 41 44 44 52 20  nic0 up $IPADDR 
0050  24 4E 45 54 4D 41 53 4B 5F 4F 50 54 0A           $NETMASK_OPT....


It looks like a corrupt buffer, half sync packet, and half a config packet.


This is the normal traffic I see...

Received 60 bytes
0000  FF FF FF FF FF FF 00 40 63 F6 3D 51 90 21 00 01  .......@c.=Q.!..
0010  02 00 02 01 00 00 00 00 06 A1 00 00 0A 78 1B 65  .............x.e
0020  A1 64 00 00 0A 78 1B 65 99 C8 00 00 00 00 00 00  .d...x.e........
0030  00 00 00 00 00 00 00 00 00 00 00 00              ................


Received 85 bytes
0000  00 04 25 00 01 02 00 40 63 F6 3D 51 90 22 00 00  ..%....@c.=Q."..
0010  04 00 42 24 54 44 4D 41 43 46 47 20 72 74 65 74  ..B$TDMACFG rtet
0020  68 30 20 73 6C 6F 74 20 30 20 32 30 30 3B 69 66  h0 slot 0 200;if
0030  63 6F 6E 66 69 67 20 76 6E 69 63 30 20 75 70 20  config vnic0 up
0040  24 49 50 41 44 44 52 20 24 4E 45 54 4D 41 53 4B  $IPADDR $NETMASK
0050  5F 4F 50 54 0A                                   _OPT............

This is coming from my master, a VIA Pico, with a via rhine ethernet
controller, using kernel 2.6.24-16-rtai (stock EMC2 deploy).  I noticed that
a comment in the rtnet rhine driver source say Rhine II, but the board has a
rhine III.  Could it be due to this?  Or is this an undocumented packet?

Thanks
Frank