TDA4VM: CPSW2G report wrong ale fld id 1/2 after config vlan

Hi,

Is the VLAN configuration done from a script which is run on start-up or are you running the commands manually?

If its a script, can you consider using ".network" files of systemd-networkd to add VLAN. I am not sure if using vconfig this early in system boot is causing any issue.

Gaston yan said:

we found that the network rx was abnormal

Can you describe how it was abnormal? Was was the testing period?

Regards,
Tanmay

hello Tanmay Patil:    

        Yes, we use the network in systemd to configure vlan by default. Whether it is systemd or vconfig, we will get the error message am65-cpsw-nuss 46000000.ethernet: get: wrong ale fld id 2.

systemd configuration is as follows

cat vlan100.network
[Match]
Name=vlan100
Type=vlan

[Network]
Description=The interface for vlan100
Address=192.168.100.3/24

[Route]
Gateway=192.168.100.2

cat vlan100.netdev
[NetDev]
Name=vlan100
Kind=vlan

[VLAN]
Id=100

Can you describe how it was abnormal? Was was the testing period?

        My statement above was wrong. It was not after a long time, but after a certain restart.，rx has no data, only tx has data

Hi Gaston,

Sorry for the delay in response.

I have following suggestions for you to try out:

1. Can you rename the following files:
   1. "vlan100.netdev"  --> "15-vlan100.netdev"
   2. "vlan100.network" --> "16-vlan100.network"
2. Can you confirm that you have placed "VLAN=vlan100"  in the "[Network]" section of "*.network" file for eth0? If not can you please do so.

Regards,
Tanmay

Can you rename the following files:

1. "vlan100.netdev"  --> "15-vlan100.netdev"
2. "vlan100.network" --> "16-vlan100.network"

What does this do? I don’t quite understand.

Can you confirm that you have placed "VLAN=vlan100"  in the "[Network]" section of "*.network" file for eth0

yes

We have two problems. One is when configuring vlan, an error is reported. The second is that after multiple restarts, after one of the startups, ifconfig found that rx was 0.

hello Tanmay Patil:    

Can you rename the following files:

1. "vlan100.netdev"  --> "15-vlan100.netdev"
2. "vlan100.network" --> "16-vlan100.network"

I don’t quite understand the intention of this, and testing can’t solve the problem. It still reports errors.

Hi Gaston,

Gaston yan said:

I don’t quite understand the intention of this, and testing can’t solve the problem. It still reports errors.

The intention of this to make the files run in the intended order. In systemd-networkd, the files are parsed and run in the lexicological order. Renaming this will make sure that these files will run in proper order.

I will try this on my end with SDK 7.3.

Can you please provide me with following information:-

1. Can you also confirm that the ".network" for eth0 is the default file starting with "10-*"?
2. Have you made any changes in the device-tree files?
3. When you see no traffic on rx,
   1. Please shhare the kernel logfs
   2. please share the output of "ethtool -S $IF_NAME" where $IF_NAME is the name of the "eth*" interface you are using. It will be most probably be eth0 in your case.

Regards,
Tanmay

hello Tanmay Patil ：

                       I captured the comparison log of successful startup and failed startup, which contains ethtool -S interface and cpsw2g reg value data.1651.ok.log1651.fail.log     

hello Tanmay Patil ：

                            See here for dmesg info. For dmesg, there is no difference between success and failure.

                            6278.dmesg.log 

Hi Gaston,

The logs show that there are errors due to vid ingress.

I am also getting the same error log for " wrong ale fld id 2" and I am looking into it, but an ALE entry for corresponding vid is always added in my case. I would like to check the entries in your case.

Can you please dump the ALE table according to instruction here: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1204394/faq-tda4vm-how-to-print-the-ale-table-for-cpsw-in-tda4-dra8-devices

Regards,
Tanmay

hello Tanmay Patil ：

                              We have added an optimization to the upper layer, and the probability of recurrence has been reduced, but the problem has not been completely solved. We have now added multiple boards for testing. After the recurrence, the information will be updated as soon as possible.

hello Tanmay Patil ：

                               With support from Tony, feedback can be given that this bit can be changed to disable to solve the problem of rx being 0. I would like to ask if the gptp function is unavailable after changing this bit. Why does this bit under the gptp function affect normal network functions?

Hi Gaston,

Gaston yan said:

I would like to ask if the gptp function is unavailable after changing this bit

Hardware offloading for timestamping will not work after this.

I am checking with hardware team to get to the bottom of this issue. I will respond back here in case of any further updates

Regards,
Tanmay

hello Tanmay Patil:

                             When the problem reappeared, the log about switch-config --ndev $if was printed.

 The following is the failure situation and log.
1. 192.168.1.100, the test device retains all vlan settings, but deletes the upper workaround script, reproduces the different pings and executes the command:
root@iDC-mid:~# switch-config --ndev eth0 -d
K3 cpsw dump version (1) len(6328)
ALE table dump ents(64):
0: type: vlan, vid = 0, untag_force = 0x3, reg_mcast = 0x0, unreg_mcast = 0x0, member_list = 0x3
1 : type: ucast, addr = 02:51:52:00:00:0d, ucast_type = persistant, port_num = 0x0, Secure
2: type: mcast, vid = 0, addr = ff:ff:ff:ff:ff:ff, mcast_state = f, no super, port_mask = 0x3
3: type: vlan, vid = 100, untag_force = 0x0, reg_mcast = 0x0, unreg_mcast = 0x0, member_list = 0x3
4: type: vlan, vid = 104, untag_force = 0x0, reg_mcast = 0x0, unreg_mcast = 0x0, member_list = 0x3
5: type: vlan, vid = 105, untag_force = 0x0, reg_mcast = 0x0, unreg_mcast = 0x0, member_list = 0x3
6: type: vlan, vid = 101, untag_force = 0x0, reg_mcast = 0x0, unreg_mcast = 0x0, member_list = 0x3
7: type: mcast, addr = 33:33:00:00:00:01, mcast_state = f, no super, port_mask = 0x1
8: type: mcast, addr = 01:80:c2:00:00:21, mcast_state = f, no super, port_mask = 0x1
9: type: mcast, addr = 01:00:5e:00:00:01, mcast_state = f, no super, port_mask = 0x1
10: type: mcast, addr = 33:33:ff:00:00:0d, mcast_state = f, no super, port_mask = 0x1
11: type: mcast, addr = 01:80:c2:00:00:00, mcast_state = f, no super, port_mask = 0x1
12: type: mcast, addr = 01:80:c2:00:00:03, mcast_state = f, no super, port_mask = 0x1
13: type: mcast, addr = 01:80:c2:00:00:0e, mcast_state = f, no super, port_mask = 0x1
14: type: mcast, addr = 33:33:00:00:00:fb, mcast_state = f, no super, port_mask = 0x1
15: type: mcast, addr = 01:00:5e:00:00:fb, mcast_state = f, no super, port_mask = 0x1
16: type: mcast, addr = 01:00:5e:00:00:fc, mcast_state = f, no super, port_mask = 0x1
17: type: mcast, addr = 01:00:5e:40:00:02, mcast_state = f, no super, port_mask = 0x1
18: type: mcast, addr = 33:33:00:01:00:03, mcast_state = f, no super, port_mask = 0x1
The output after executing ifconfig eth0 down up:
root@iDC-mid:~# switch-config --ndev eth0 -d
K3 cpsw dump version (1) len(6328)
ALE table dump ents(64):
0: type: vlan, vid = 0, untag_force = 0x3, reg_mcast = 0x0, unreg_mcast = 0x0, member_list = 0x3
1 : type: ucast, addr = 02:51:52:00:00:0d, ucast_type = persistant, port_num = 0x0, Secure
2: type: mcast, vid = 0, addr = ff:ff:ff:ff:ff:ff, mcast_state = f, no super, port_mask = 0x3
3: type: vlan, vid = 100, untag_force = 0x0, reg_mcast = 0x0, unreg_mcast = 0x0, member_list = 0x3
4: type: vlan, vid = 104, untag_force = 0x0, reg_mcast = 0x0, unreg_mcast = 0x0, member_list = 0x3
5: type: vlan, vid = 105, untag_force = 0x0, reg_mcast = 0x0, unreg_mcast = 0x0, member_list = 0x3
6: type: vlan, vid = 101, untag_force = 0x0, reg_mcast = 0x0, unreg_mcast = 0x0, member_list = 0x3
7: type: mcast, addr = 01:80:c2:00:00:21, mcast_state = f, no super, port_mask = 0x1
8: type: mcast, addr = 01:00:5e:00:00:01, mcast_state = f, no super, port_mask = 0x1
9: type: mcast, addr = 01:00:5e:40:00:02, mcast_state = f, no super, port_mask = 0x1
10: type: mcast, addr = 33:33:00:00:00:01, mcast_state = f, no super, port_mask = 0x1
11: type: mcast, addr = 33:33:ff:00:00:0d, mcast_state = f, no super, port_mask = 0x1
12: type: mcast, addr = 01:80:c2:00:00:00, mcast_state = f, no super, port_mask = 0x1
13: type: mcast, addr = 01:80:c2:00:00:03, mcast_state = f, no super, port_mask = 0x1
14: type: mcast, addr = 01:80:c2:00:00:0e, mcast_state = f, no super, port_mask = 0x1
15: type: mcast, addr = 01:00:5e:00:00:fb, mcast_state = f, no super, port_mask = 0x1
16: type: mcast, addr = 01:00:5e:00:00:fc, mcast_state = f, no super, port_mask = 0x1
17: type: mcast, addr = 33:33:00:00:00:fb, mcast_state = f, no super, port_mask = 0x1
18: type: mcast, addr = 33:33:00:01:00:03, mcast_state = f, no super, port_mask = 0x1

hello Tanmay Patil:

We removed all vlan configurations and reproduced this problem. We also reproduced this problem by using gptp diable. Please help us analyze it further.

Hi,

Apologies for the delay.

Is this issue still observed?

Regards,
Tanmay

This can be closed