• TI Thinks Resolved

TMS32TCI6614BSXCMS: The tci6614 arm core sometimes can’t receive the ARP request and reply packet but can receive all the other packets at the same time.

Prodigy 40 points

Replies: 8

Views: 158

Part Number: TMS32TCI6614BSXCMS

 

The tci6614(TMS320TCI6614CCMSA) arm core sometimes can’t receive the ARP request and reply packet but can receive all the other packets at the same time.

 

We init the 3 port Ethernet switch in vlan aware mode. Set the switch port0 and switch port2 in vlan 1,the switch port0 and switch port1 in vlan 7. The switch port2 connect to FPGA, the switch port1 connect to a PHY to connect to PC for example. The tci6614 arm core sometimes can’t receive the ARP request and reply packet when running for a while maybe several days or 20 minutes. At this time, we get switch port0  statistics from the register 02090b34(TXGOODFRAMES) and 02090b38(TXBROADCASTFRAMES) and shows us that the 3 port Ethernet switch port0 can transmit the ARP request and reply packet to Packet Streaming Switch. But we can’t get any ARP request and reply packet in the interrupt handler(khwq_int_handler in the file keystone_hwqueue.c in the Linux kernel drivers/hwqueue directory). So we don’t know how the ARP request and reply packet dropped? Is it possible dropped in the PA module? How to debug to show it dropped in PA module? I try to configure to bypass the PA module, but failed. Can you tell us how to configure bypass the PA module? Or is there any other ways to know how the ARP packets dropped? 

 

PS:

1.      When the TCI6614 can receive ARP request and reply packet,we print out the packet information by calling the function netcp_dump_packet, and it shows us that the ARP request and reply packet has correct checksum, and there is no errors in the 3 port Ethernet switch statistics.

2.      When the TCI6614 arm core can’t receive ARP request and reply packet, we can see it can receive all the other packets from the switch port1 by calling the function netcp_dump_packet to show the packet information.

 

  • Hi,

    Just wanted to point your attention to the following FAQ:
     

    We will take a look at this and provide some guidance if possible, but note that TCI66x devices are getting obsolete.


    Best Regards,
    Yordan

     


     Please make sure you read the forum guidelines first.

  • In reply to Yordan Kovachev:

    Hi Yordan,

    The FAQ you gave is related to SYSCLOCKOUT. But the problem we met seems not related to this.Can you give more clues about the problem?

    Thanks a lot!

    Best Regards,

    Yanli

  • In reply to user6129697:

    Hi,


    Sorry, I messed up the links, it was supposed to be a support guidance FAQ about TCI devices.
    I've edited my post. 

    Best Regards,
    Yordan

     


     Please make sure you read the forum guidelines first.

  • In reply to Yordan Kovachev:

    Hi Yordan,

    We have no idea about the problem for the moment. Could you give some advice about the problem?

    Thanks a lot!

    Best Regards,

    Yanli

  • In reply to user6129697:

    Hi Yanli

    As Yordan explained we are not able to provide in depth support on some of these device families - the FAQ provides some guidance on where you can find additional support.

    I have referred this post to a colleague to see if they can provide some generic debug guidance. 

    Regards

    Mukul 

  • Guru 64870 points

    In reply to Mukul Bhatnagar:

    Hi,

    In your setup PC is connected to port 1, and you found that host port (port 0) still be able to transmit ARP packets from port 1 to PA, but the RX ISR is not fired, the packets are suspect to lost between host and CPSW. 

    In the TI RTOS code for PA sub-module, we have some API calls to get the PA statistics. TCI6614 use the same PA as C6678. The later is still supported by Processor SDK RTOS: http://software-dl.ti.com/processor-sdk-rtos/esd/C667x/latest/index_FDS.html. Inside the PA driver pdk_c667x_2_0_xx\packages\ti\drv\pa, there is a call getPaStats() you can refer to. To get PA stat, you need to need a command to PA. The code you referred to is Linux code, I am not sure how the Linux driver is written or it has similar code implemented. 

    The output printed like this:

    System_printf ("--- PA STATS --- \n");
    System_printf ("C1 number of packets: %d\n", stats->classify1.nPackets);
    System_printf ("C1 number IPv4 packets: %d\n", stats->classify1.nIpv4Packets);
    System_printf ("C1 number IPv6 packets: %d\n", stats->classify1.nIpv6Packets);
    System_printf ("C1 number custom packets: %d\n", stats->classify1.nCustomPackets);
    System_printf ("C1 number SRIO packets: %d\n", stats->classify1.nSrioPackets);
    System_printf ("C1 number llc/snap fail: %d\n", stats->classify1.nLlcSnapFail);
    System_printf ("C1 number table matched: %d\n", stats->classify1.nTableMatch);
    System_printf ("C1 number failed table matched: %d\n", stats->classify1.nNoTableMatch);
    System_printf ("C1 number Ingress IP frags: %d\n", stats->classify1.nIpFrag);
    System_printf ("C1 number IP depth overflow: %d\n", stats->classify1.nIpDepthOverflow);
    System_printf ("C1 number vlan depth overflow: %d\n", stats->classify1.nVlanDepthOverflow);
    System_printf ("C1 number gre depth overflow: %d\n", stats->classify1.nGreDepthOverflow);
    System_printf ("C1 number mpls packets: %d\n", stats->classify1.nMplsPackets);
    System_printf ("C1 number of parse fail: %d\n", stats->classify1.nParseFail);
    System_printf ("C1 number invalid IPv6 opts: %d\n", stats->classify1.nInvalidIPv6Opt);
    System_printf ("C1 number of Egress IP frags: %d\n", stats->classify1.nTxIpFrag);
    System_printf ("C1 number of silent discard: %d\n", stats->classify1.nSilentDiscard);
    System_printf ("C1 number of invalid control: %d\n", stats->classify1.nInvalidControl);
    System_printf ("C1 number of invalid states: %d\n", stats->classify1.nInvalidState);
    System_printf ("C1 number of system fails: %d\n\n", stats->classify1.nSystemFail);
    System_printf ("C2 number of packets: %d\n", stats->classify2.nPackets);
    System_printf ("C2 number of UDP packets: %d\n", stats->classify2.nUdp);
    System_printf ("C2 number of TCP packets: %d\n", stats->classify2.nTcp);
    System_printf ("C2 number of custom packets: %d\n", stats->classify2.nCustom);
    System_printf ("C2 number of silent discard: %d\n", stats->classify2.nSilentDiscard);
    System_printf ("C2 number of invalid control: %d\n\n", stats->classify2.nInvalidControl);

    So C1 is IP level and C2 is UDP/TCP level, this can give you a clue if PA dropped packets, but those statistics are not well documented.

    Regards, Eric

  • In reply to lding:

    Hi Eric,

    Thanks for your reply.We will do more tests according to your suggestions.We have made some progress these days.

    The problem seems to be resolved and Now we can receive ARP request and reply packet by modifying the following three parts:

    1. pa_add_mcast() in keystone_pa.c:

     

    struct pa_device *pa_dev = pa_from_module(data);

    int ret;

     

    pa_dev->addr_count += 1;

    if (pa_dev->addr_count == 64) ------> changed to if (pa_dev->addr_count >= 64)

               return 0;

     

    ret = keystone_pa_add_mac(pa_dev, new_mc_addr,

                                 PACKET_HST,  0x0800,

                                 (64 - pa_dev->addr_count));

     

    pa_dev->addr_count += 1;

    if (pa_dev->addr_count == 64)-------> changed to if (pa_dev->addr_count >= 64)

     

               return 0;

     

    ret = keystone_pa_add_mac(pa_dev, new_mc_addr,

                                 PACKET_HST,  0x86dd,

                                 (64 - pa_dev->addr_count));

     

     

    1. pa_add_ucast () in keystone_pa.c

    struct pa_device *pa_dev = pa_from_module(data);

    int ret;

     

    pa_dev->addr_count += 1;

    if (pa_dev->addr_count == 64) ------->changed to if (pa_dev->addr_count >= 64)

     

               return 0;

     

    ret = keystone_pa_add_mac(pa_dev, new_uc_addr,

                                 PACKET_PARSE,  0x0800,

                                 (64 - pa_dev->addr_count));

     

    pa_dev->addr_count += 1;

    if (pa_dev->addr_count == 64) ------> changed to if (pa_dev->addr_count >= 64)

     

               return 0;

     

    ret = keystone_pa_add_mac(pa_dev, new_uc_addr,

                                 PACKET_PARSE,  0x86dd,

                                 (64 - pa_dev->addr_count));

    1. pa_open()in keystone_pa.c

    ret = keystone_pa_add_mac(pa_dev, NULL,       PACKET_HST,  0,      63);

     

    ret = keystone_pa_add_mac(pa_dev, bcast_addr, PACKET_HST,  0,      62);

     

    ret = keystone_pa_add_mac(pa_dev, mac_addr,   PACKET_HST,  0,      61);

     

    ret = keystone_pa_add_mac(pa_dev, mac_addr,   PACKET_PARSE, 0x0800, 60); ------> changed to ret = keystone_pa_add_mac(pa_dev, mac_addr,   PACKET_PARSE, 0x0806, 60);

     

    ret = keystone_pa_add_mac(pa_dev, mac_addr,   PACKET_PARSE, 0x86dd, 59); ------>changed to ret = keystone_pa_add_mac(pa_dev, mac_addr,   PACKET_PARSE, 0x8100, 59);

     

    pa_dev->addr_count = 5;

     

     

    We don’t know why packet routed to PACKET_PARSE (Packet remains in PA sub-system for more parsing and LUT1 classification) will not be dropped, but will be dropped sometimes when routed to PACKET_HST(Packet is routed to host)?  Is there any possibility that we can’t receive IPV4(0x0800) and IPV6(0x86dd) packets sometimes since we now change to route these kinds of packets  to PACKET_HST(Packet is routed to host)?

    Best Regards!

    Yanli

  • Guru 64870 points

    In reply to user6129697:

    Hi,

    ARP is broadcast packet, in the original code ret = keystone_pa_add_mac(pa_dev, bcast_addr, PACKET_HST,  0,      62);, I thought this will be direct to host, and 0x0800 (IPV4) and 0x86dd (IPV6?) will be move to PA LUT2 for further packet classification. This worked but not sure why broadcast packet got dropped after a while.

    In your new code, you put ARP (0x0806) and 0x8100 (?) to PACKET_PARSE. Then you must have at least IP address level parsing to direct them to host. But how do you send the IPV4 and IPV6 packets to host? Will you add two more MAC entries for IPV4 and IPV6?

    Regards, Eric