• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 2202 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/66AK2G02: Linux RMII RX packet loss

Ville Baillie97
Prodigy 110 points
Part Number: 66AK2G02


Tool/software: Linux

Hi all,

I managed to implement RMII into the Linux kernel for TI 66AK2G02 however, I am seeing a great deal of RX packet loss when sending from a windows machine, TX is fine.

Thanks

Ville

  • 0
    Prodigy 110 points
    Forgot to post link to previous e2e thread where implementation was posted

    e2e.ti.com/.../2479959
  • 0 in reply to Ville Baillie97
    TI__Guru**** 161600 points
    Let me check this.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Prodigy 110 points

    Here is some more debug info about the dropped packets

    root@mic-array:~# ./dropwatch -l kas
    Initalizing kallsyms db
    dropwatch> start
    Enabling monitoring...
    Kernel monitoring activated.
    Issue Ctrl-C to stop monitoring
    5 drops at ip6_mc_input+dc (0xc08b3494)
    3 drops at __netif_receive_skb_core+a5c (0xc0806014)
    10 drops at ip_rcv_finish+148 (0xc08460f8)
    1 drops at __udp4_lib_rcv+800 (0xc0878544)
    2 drops at ip_error+64 (0xc08418dc)
    12 drops at ip_rcv_finish+148 (0xc08460f8)
    1 drops at __netif_receive_skb_core+a5c (0xc0806014)
    80 drops at __udp4_lib_rcv+84 (0xc0877dc8)
    2 drops at __netif_receive_skb_core+a5c (0xc0806014)
    10 drops at ip_rcv_finish+148 (0xc08460f8)
    3 drops at ip6_mc_input+dc (0xc08b3494)
    2 drops at ip_error+64 (0xc08418dc)
    13 drops at ip_rcv_finish+148 (0xc08460f8)
    1 drops at __netif_receive_skb_core+a5c (0xc0806014)
    2 drops at __netif_receive_skb_core+a5c (0xc0806014)
    10 drops at ip_rcv_finish+148 (0xc08460f8)
    3 drops at __udp4_lib_rcv+800 (0xc0878544)
    1 drops at __udp6_lib_rcv+6d0 (0xc08ce454)
    1 drops at __netif_receive_skb_core+a5c (0xc0806014)
    11 drops at ip_rcv_finish+148 (0xc08460f8)
    2 drops at ip6_mc_input+dc (0xc08b3494)
    12 drops at ip_rcv_finish+148 (0xc08460f8)
    2 drops at __netif_receive_skb_core+a5c (0xc0806014)
    5 drops at __udp4_lib_rcv+800 (0xc0878544)
    11 drops at ip_rcv_finish+148 (0xc08460f8)
    2 drops at __netif_receive_skb_core+a5c (0xc0806014)
    2 drops at __udp4_lib_rcv+800 (0xc0878544)
    1 drops at ip6_mc_input+dc (0xc08b3494)
    5 drops at __udp4_lib_rcv+800 (0xc0878544)
    10 drops at ip_rcv_finish+148 (0xc08460f8)
    2 drops at __netif_receive_skb_core+a5c (0xc0806014)
    1 drops at ip6_mc_input+dc (0xc08b3494)
    17 drops at ip_rcv_finish+148 (0xc08460f8)
    2 drops at __udp4_lib_rcv+800 (0xc0878544)
    1 drops at __netif_receive_skb_core+a5c (0xc0806014)
    11 drops at ip6_mc_input+dc (0xc08b3494)
    2 drops at __netif_receive_skb_core+a5c (0xc0806014)
    12 drops at ip_rcv_finish+148 (0xc08460f8)
    10 drops at ip6_mc_input+dc (0xc08b3494)
    15 drops at ip_rcv_finish+148 (0xc08460f8)
    2 drops at __netif_receive_skb_core+a5c (0xc0806014)
    3 drops at ip6_mc_input+dc (0xc08b3494)
    ^CGot a stop message
    dropwatch> exit
    Shutting down ...
    root@mic-array:~# ifconfig | grep dropped
              RX packets:12164 errors:0 dropped:139 overruns:0 frame:0
              TX packets:10074 errors:0 dropped:0 overruns:0 carrier:0
              RX packets:494 errors:0 dropped:0 overruns:0 frame:0
              TX packets:494 errors:0 dropped:0 overruns:0 carrier:0
    root@mic-array:~# netstat -s
    Ip:
        12492 total packets received
        8 with invalid addresses
        0 forwarded
        0 incoming packets discarded
        11207 incoming packets delivered
        10687 requests sent out
        160 outgoing packets dropped
    Icmp:
        325 ICMP messages received
        1 input ICMP message failed.
        ICMP input histogram:
            destination unreachable: 324
            echo requests: 1
        324 ICMP messages sent
        0 ICMP messages failed
        ICMP output histogram:
            destination unreachable: 324
    IcmpMsg:
            InType3: 324
            InType8: 1
            OutType3: 324
    Tcp:
        0 active connections openings
        1 passive connection openings
        0 failed connection attempts
        0 connection resets received
        0 connections established
        10253 segments received
        10003 segments send out
        0 segments retransmited
        0 bad segments received.
        0 resets sent
    Udp:
        177 packets received
        324 packets to unknown port received.
        0 packet receive errors
        356 packets sent
        IgnoredMulti: 127
    UdpLite:
    TcpExt:
        4 delayed acks sent
        1 delayed acks further delayed because of locked socket
        3194 packet headers predicted
        10 acknowledgments not containing data payload received
        99 predicted acknowledgments
        IPReversePathFilter: 3
        TCPRcvCoalesce: 7298
        TCPOFOQueue: 4473
        TCPOrigDataSent: 201
    IpExt:
        InMcastPkts: 177
        OutMcastPkts: 33
        InBcastPkts: 127
        InOctets: 15535221
        OutOctets: 659850
        InMcastOctets: 37559
        OutMcastOctets: 5212
        InBcastOctets: 24359
        InNoECTPkts: 12493
    root@mic-array:~#

  • 0 in reply to Ville Baillie97
    TI__Guru**** 161600 points
    Hi,

    Thanks. Sorry for the delay, I am looking into this.. I am trying to setup the K2G EVM I have, but am running into a problem:
    you said: "I am seeing a great deal of RX packet loss when sending from a windows machine, TX is fine".
    Is the behavior the same with linux host machine, because I use ubuntu on my PC?

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Prodigy 110 points

    Hi there, the same issue occurs when sending data from a windows or a linux machine. I've tried both. The throughput on windows is much more severely affected by this, however, as it seems to keep much longer retransmission timeouts (300ms) for each packet it fails to transmit.

    Also I believe all the packet drops reported by the kernel are benign (dropping multicasts not meant for the device for example) and I can see the same behaviour on the K2G-EVM (which works fine). The packet loss is probably happening before the kernel IP stack (pktdma engine maybe?)

    Are you modding the K2G-EVM to talk to an RMII phy?

    Thanks

    Ville

  • 0 in reply to Ville Baillie97
    TI__Guru**** 161600 points
    Hi,

    Are you modding the K2G-EVM to talk to an RMII phy?


    Yes, that is the other blocking point. I don't have the equipment to change the Microchip KSZ9031RNXCA phy. I was starting to modify the kernel sources today (was busy with other tasks) and upon inspecting the schematic I realized i can't reproduce your exact use case on my side...

    The packet loss is probably happening before the kernel IP stack (pktdma engine maybe?)


    This is a good guess. Try checking the Netcp knav driver:
    knav packet DMA driver (drivers/soc/ti/knav_dma.c
    knav qmss queue driver (drivers/soc/ti/knav_qmss_queue.c
    knav qmss accumulator driver (driver/soc/ti/knav_qmss_queue.c

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Prodigy 110 points
    Ok, is there any change someone from TI could review my RMII code change to see if it is reasonable. Maybe someone could suggest if any more changes need to be added in to get RMII to work, as everything is currently geared up for RGMII.
  • 0 in reply to Ville Baillie97
    Prodigy 110 points
    Ok I think I've fixed it, the problem is that for GBE full duplex is forced on, so the FULLDUPLEX bit of the CPSW_P1_MAC_CONTROL is not controlled by the Linux driver (which is not geared up for RMII/MII). I've fixed it for my use case by forcing that bit on (as we always expect a full duplex mac link)