• State TI Thinks Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 2 answers
  • Subscribers 100 subscribers
  • Views 497 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.

Original question:

AM6422: change ethernet to switch mode

AM6422: The recovery time of the CPSW network port in switch mode

Zitong Liu
Prodigy 70 points
Part Number: AM6422
Other Parts Discussed in Thread: TMDS64EVM

Tool/software:

The commands I run are below: 

1、enable switch mode

ip link set dev eth0 down

ip link set dev eth1 down

sleep 1

ip link set dev eth0 up

ip link set dev eth1 up

sleep 2

devlink dev param set platform/8000000.ethernet name switch_mode value true cmode runtime

sleep 1

ip link add name br0 type bridge

sleep 1

ip link set dev eth0 master br0

ip link set dev eth1 master br0

ip link set dev br0 type bridge stp_state 1

ip link set dev br0 up

bridge vlan add dev br0 vid 1 self

bridge vlan add dev br0 vid 1 pvid untagged self

ip addr add 192.168.1.101/24 dev br0

 

the kernel logs are below:

 

2、I try link br0 down and up, found that the time it recover need 30+ seconds

As you can see, the log displays that br0 becomes ready need 30s, however, I use my PC to ping 192.168.1.101(br0 ip) may need more time, the time seems random, sometimes, it will need more than 60s.

 

3、I try link eth0 down and up（by unplugging and plugging the cable）, found that the time it recover need 60+ seconds

Also, the kernel logs displays 30s, but actually it need 60s.

Both eth0 and eth1 have the same situation.

Are these recovery time we expected?

Thanks for your all reply.

  • 0
    TI__Mastermind 27050 points

    What SW version are you running and what HW are you using (TI SK or EVM or your own)? 

      Pekka

  • 0 in reply to Pekka Varis
    Prodigy 70 points

    The SW is Linux debian11, hw is  built on senux platform not offical TI SDK.

  • 0 in reply to Zitong Liu
    TI__Genius 16685 points

    Hello Zitong, 

    Zitong Liu said:
    hw is  built on senux platform not offical TI SDK.

    Just to clarify, is this tested on a TI AM64x EVM or on a custom designed board featuring AM6422? 

    Zitong Liu said:
    The SW is Linux debian11

    This software is not from the TI provided Debian (Trixie) image? https://dr-download.ti.com/software-development/software-development-kit-sdk/MD-InmvA50mCw/10.01.10.04/tisdk-debian-trixie-rt-am64xx-evm-10.01.10.04.wic.xz 

    Can you share what Linux Kernel version you are using? (uname -a)

    Zitong Liu said:
    As you can see, the log displays that br0 becomes ready need 30s, however, I use my PC to ping 192.168.1.101(br0 ip) may need more time, the time seems random, sometimes, it will need more than 60s.

    Can you explain how you are determining the time for recovery is 60s since you are stating that the log timing is not correct? Also, which timestamps are you specifically comparing in the log to determine the 30s?

    -Daolin

  • 0 in reply to Daolin Qiu
    Prodigy 70 points

    HI Daolin,

    This is a custom designed board featuring AM6422.

    The Linux kernel version is

    $ uname -a
    Linux aug 6.1.33-g40c32565ca #1 SMP PREEMPT Thu Jul 6 14:17:24 UTC 2023 aarch64 GNU/Linux

    60s is the time the ping succeeds again.

    30s is the time from when I link br0 up again or plug the table again to the log displays 'br0 link becomes ready'

  • 0 in reply to Zitong Liu
    TI__Genius 16685 points

    Hi Zitong, 

    Last week, I tried to see if I could replicate the same issue on an AM64x EVM (TMDS64EVM), using RT-Linux SDK 10.1, but for the link up br0 part I didn't see a 30s or longer recovery time. I will try again this week and share my logs as well.

    Zitong Liu said:
    60s is the time the ping succeeds again.

    Did you run the ping test manually from your host PC after br0 was back up or was it always kept running in the background?

    Zitong Liu said:
    The SW is Linux debian11
    Zitong Liu said:
    Linux aug 6.1.33-g40c32565ca #1 SMP PREEMPT Thu Jul 6 14:17:24 UTC 2023 aarch64 GNU/Linux

    Any particular for using Debian as opposed to a yocto build of Linux or RT-Linux?

    -Daolin

  • 0 in reply to Daolin Qiu
    Prodigy 70 points

    Hi Daolin，

        Yesterday, We have a online discussion with TI team（Semon is our supporter）, and I tried some more tests. The result is below

    1. If disable rstp, the recovery time of eth port is 1-2s.
    2. If enable rstp, use 2 Windows PC(192.168.1.10 and 192.168.1.20) connect 2 eth port of CPSW. We discover that if we ping continuously, use the command `ping xxxx -t`, the recovery time will very long.

    Through the packet capture tool, we can see that there are many ARP requests from random IP(for example the picture below is 192.168.1.192), until another PC makes a ping request, or restart the current ping request,  the ARP request IP is restored to normal(192.168.1.20), and the other PC can also be pinged successfully.

        ...

  • 0 in reply to Zitong Liu
    TI__Genius 16685 points

    Hi Zitong, 

    Zitong Liu said:
    If disable rstp, the recovery time of eth port is 1-2s.
    Daolin Qiu said:
    Last week, I tried to see if I could replicate the same issue on an AM64x EVM (TMDS64EVM), using RT-Linux SDK 10.1, but for the link up br0 part I didn't see a 30s or longer recovery time.

    Thanks for pointing this out. In fact, during my testing I did not enable rstp so it could be reason why I could not reproduce the issue.

    Zitong Liu said:
    ip link set dev br0 type bridge stp_state 1

    I looked at the script you used, and it seems that this is the only line that is relevant for enabling STP. Are you positive this is supposed to enable RSTP as opposed to STP? If it's STP, from my understanding, the recovery time is likely to take up to 30-60 seconds when the topology changes.

    -Daolin

  • 0 in reply to Daolin Qiu
    Prodigy 70 points

    Hi Daolin,

        This script really enable STP only, not RSTP. 

        When I run the script below, it enable RSTP, and discover that if I `link br0 down` and `link br0 up`, the recovery time of ping is less than 3s

        But another question is when I swap the two cables of cpsw-eth0 and cpsw-eth1, the recovery time is still very long, the PC can ping successfully again until another PC make a ping request. Can you find out the reason?

    ip link set dev br0 type bridge stp_state 1
sudo mstpd
sudo mstpctl setforcevers br0 rstp
sudo mstpctl addbridge br0

  • 0 in reply to Zitong Liu
    TI__Genius 16685 points

    Hello Zitong, 

    In the commands you used to setup RSTP, do you still need the first command "ip link set dev br0 type bridge stp_state 1"? What happens when you remove this command, set up RSTP with the other commands, and test the recovery time?

    -Daolin 

  • 0 in reply to Daolin Qiu
    TI__Expert 8771 points

    Hello Zitong 

      STP is old spanning tree protocol, the link time is about 60s, need to enable RSTP instead, this can make link up rapid,

       you have already verified it in your system

       this thread can be closed

    Regards

       Semon

  • 0 in reply to Daolin Qiu
    Prodigy 70 points

    Hi Daolin,

        Remove that command exactly solve my problem, Thanks.