* Marvell switch port shows LOWERLAYERDOWN, ping fails
@ 2021-07-22 22:55 Dario Alcocer
2021-07-23 13:41 ` Andrew Lunn
0 siblings, 1 reply; 27+ messages in thread
From: Dario Alcocer @ 2021-07-22 22:55 UTC (permalink / raw)
To: netdev
After configuring a DSA tree for two Marvell 88E6176 chips, attempts to
ping a host connected to the first user port fail. Running "ip link" shows
the user port state as LOWERLAYERDOWN, and no packets make it out the port.
It's not clear why the state is LOWERLAYERDOWN. The port has a connected
network device, and the port LED is on.
I'd welcome any ideas on how to figure out why the port is not working.
The Marvell chips are configured for multi-chip mode, and are connected
to a single MDIO bus:
* chip at PHY address 0x1E is connected to eth0 of the host processor,
an Altera Cyclone V
* chip at PHY address 0x1A is connected over SERDES to the other chip,
using port 4
Here's a console capture showing the port set-up and the failed ping:
root@dali:~# uname -a
Linux dali 5.4.114-altera #1 SMP Thu Jul 22 20:07:57 UTC 2021 armv7l armv7l armv7l GNU/Linux
root@dali:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
link/can
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
4: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
5: lan1@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
6: lan2@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
7: lan3@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
8: lan4@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
9: dmz@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
root@dali:~# ip addr add 192.0.2.1/24 dev lan1
root@dali:~# ip link set lan1 up
[ 902.623835] mv88e6085 stmmac-0:1a lan1: configuring for phy/gmii link mode
[ 902.633092] 8021q: adding VLAN 0 to HW filter on device lan1
root@dali:~# ping -c 4 192.0.2.2
PING 192.0.2.2 (192.0.2.2): 56 data bytes
--- 192.0.2.2 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
root@dali:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
link/can
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
4: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
5: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
6: lan2@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
7: lan3@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
8: lan4@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
9: dmz@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
root@dali:~# ip route
default via 192.168.0.1 dev eth0
192.0.2.0/24 dev lan1 proto kernel scope link src 192.0.2.1 linkdown
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.3
224.0.0.0/4 dev eth0 scope link src 192.168.0.3
root@dali:~#
The DSA switch tree is configured using this device tree fragment:
gmac0 {
status = "okay";
phy-mode = "gmii";
txc-skew-ps = <0xbb8>;
rxc-skew-ps = <0xbb8>;
txen-skew-ps = <0>;
rxdv-skew-ps = <0>;
rxd0-skew-ps = <0>;
rxd1-skew-ps = <0>;
rxd2-skew-ps = <0>;
rxd3-skew-ps = <0>;
txd0-skew-ps = <0>;
txd1-skew-ps = <0>;
txd2-skew-ps = <0>;
txd3-skew-ps = <0>;
max-frame-size = <3800>;
fixed-link {
speed = <0x3e8>;
full-duplex;
pause;
};
mdio {
compatible = "snps,dwmac-mdio";
#address-cells = <0x1>;
#size-cells = <0x0>;
switch0: switch0@1a {
compatible = "marvell,mv88e6085";
reg = <0x1a>;
dsa,member = <0 0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan1";
};
port@1 {
reg = <1>;
label = "lan2";
};
port@2 {
reg = <2>;
label = "lan3";
};
switch0port4: port@4 {
reg = <4>;
phy-mode = "rgmii-id";
link = <&switch1port4>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
port@6 {
reg = <6>;
ethernet = <&gmac0>;
label = "cpu";
};
};
};
switch1: switch1@1e {
compatible = "marvell,mv88e6085";
reg = <0x1e>;
dsa,member = <0 1>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan4";
};
port@1 {
reg = <1>;
label = "dmz";
};
switch1port4: port@4 {
reg = <4>;
link = <&switch0port4>;
phy-mode = "rgmii-id";
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
};
};
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-07-22 22:55 Marvell switch port shows LOWERLAYERDOWN, ping fails Dario Alcocer
@ 2021-07-23 13:41 ` Andrew Lunn
2021-07-23 18:21 ` Dario Alcocer
0 siblings, 1 reply; 27+ messages in thread
From: Andrew Lunn @ 2021-07-23 13:41 UTC (permalink / raw)
To: Dario Alcocer; +Cc: netdev
On Thu, Jul 22, 2021 at 03:55:04PM -0700, Dario Alcocer wrote:
> After configuring a DSA tree for two Marvell 88E6176 chips, attempts to
> ping a host connected to the first user port fail. Running "ip link" shows
> the user port state as LOWERLAYERDOWN, and no packets make it out the port.
>
> It's not clear why the state is LOWERLAYERDOWN. The port has a connected
> network device, and the port LED is on.
>
> I'd welcome any ideas on how to figure out why the port is not working.
>
> The Marvell chips are configured for multi-chip mode, and are connected
> to a single MDIO bus:
>
> * chip at PHY address 0x1E is connected to eth0 of the host processor,
> an Altera Cyclone V
> * chip at PHY address 0x1A is connected over SERDES to the other chip,
> using port 4
>
> Here's a console capture showing the port set-up and the failed ping:
>
> root@dali:~# uname -a
> Linux dali 5.4.114-altera #1 SMP Thu Jul 22 20:07:57 UTC 2021 armv7l armv7l armv7l GNU/Linux
> root@dali:~# ip link
>
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
> link/can
> 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP mode DEFAULT group default qlen 1000
> link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
> 4: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> link/sit 0.0.0.0 brd 0.0.0.0
> 5: lan1@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
> 6: lan2@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
> 7: lan3@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
> 8: lan4@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
> 9: dmz@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
> root@dali:~# ip addr add 192.0.2.1/24 dev lan1
> root@dali:~# ip link set lan1 up
> [ 902.623835] mv88e6085 stmmac-0:1a lan1: configuring for phy/gmii link mode
> [ 902.633092] 8021q: adding VLAN 0 to HW filter on device lan1
> root@dali:~# ping -c 4 192.0.2.2
> PING 192.0.2.2 (192.0.2.2): 56 data bytes
>
> --- 192.0.2.2 ping statistics ---
> 4 packets transmitted, 0 packets received, 100% packet loss
> root@dali:~# ip link
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
> link/can
> 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP mode DEFAULT group default qlen 1000
> link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
> 4: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> link/sit 0.0.0.0 brd 0.0.0.0
> 5: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
> link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
NO-CARRIER suggests a PHY problem. You should see it report link up if
it really is up.
When then switch probes the PHYs should also probe. What PHY driver is
being used? You want the Marvell PHY driver, not genphy.
> 6: lan2@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
> 7: lan3@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
> 8: lan4@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
> 9: dmz@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
> root@dali:~# ip route
> default via 192.168.0.1 dev eth0
That is not correct. eth0 just acts as a pipe towards the switch. It
does not have an IP address, and there should not be any routes using
it. It needs to be configured up, but that is all.
> 192.0.2.0/24 dev lan1 proto kernel scope link src 192.0.2.1 linkdown
> 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.3
> 224.0.0.0/4 dev eth0 scope link src 192.168.0.3
> root@dali:~#
>
> The DSA switch tree is configured using this device tree fragment:
>
> gmac0 {
> status = "okay";
> phy-mode = "gmii";
gmii? That is a bit unusual. You normally see rgmii.
> txc-skew-ps = <0xbb8>;
> rxc-skew-ps = <0xbb8>;
> txen-skew-ps = <0>;
> rxdv-skew-ps = <0>;
> rxd0-skew-ps = <0>;
> rxd1-skew-ps = <0>;
> rxd2-skew-ps = <0>;
> rxd3-skew-ps = <0>;
> txd0-skew-ps = <0>;
> txd1-skew-ps = <0>;
> txd2-skew-ps = <0>;
> txd3-skew-ps = <0>;
> max-frame-size = <3800>;
>
> fixed-link {
> speed = <0x3e8>;
decimal would be much more readable. Or is this not the source .dts
file, but you have decompiled the DTB back to DTS?
> full-duplex;
> pause;
> };
>
> mdio {
> compatible = "snps,dwmac-mdio";
> #address-cells = <0x1>;
> #size-cells = <0x0>;
>
> switch0: switch0@1a {
> compatible = "marvell,mv88e6085";
> reg = <0x1a>;
> dsa,member = <0 0>;
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> port@0 {
> reg = <0>;
> label = "lan1";
> };
> port@1 {
> reg = <1>;
> label = "lan2";
> };
> port@2 {
> reg = <2>;
> label = "lan3";
> };
> switch0port4: port@4 {
> reg = <4>;
> phy-mode = "rgmii-id";
> link = <&switch1port4>;
> fixed-link {
> speed = <1000>;
> full-duplex;
> };
> };
> port@6 {
> reg = <6>;
> ethernet = <&gmac0>;
> label = "cpu";
> };
> };
> };
> switch1: switch1@1e {
> compatible = "marvell,mv88e6085";
> reg = <0x1e>;
> dsa,member = <0 1>;
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> port@0 {
> reg = <0>;
> label = "lan4";
> };
> port@1 {
> reg = <1>;
> label = "dmz";
> };
> switch1port4: port@4 {
> reg = <4>;
> link = <&switch0port4>;
> phy-mode = "rgmii-id";
You probably don't want both ends of the link in rgmii-id mode. That
will give you twice the delay.
Andrew
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-07-23 13:41 ` Andrew Lunn
@ 2021-07-23 18:21 ` Dario Alcocer
2021-07-23 18:25 ` Andrew Lunn
0 siblings, 1 reply; 27+ messages in thread
From: Dario Alcocer @ 2021-07-23 18:21 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
On 7/23/21 6:41 AM, Andrew Lunn wrote:
> On Thu, Jul 22, 2021 at 03:55:04PM -0700, Dario Alcocer wrote:
>> root@dali:~# ip link
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> 2: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
>> link/can
>> 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP mode DEFAULT group default qlen 1000
>> link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
>> 4: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
>> link/sit 0.0.0.0 brd 0.0.0.0
>> 5: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
>> link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
>
> NO-CARRIER suggests a PHY problem. You should see it report link up if
> it really is up.
>
> When then switch probes the PHYs should also probe. What PHY driver is
> being used? You want the Marvell PHY driver, not genphy.
Looks like the Marvell PHY driver is being used:
root@dali:~# grep -i phy /var/log/messages
Jan 1 00:00:10 (none) user.info kernel: [ 4.126862] libphy:
mv88e6xxx SMI: probed
Jan 1 00:00:10 (none) user.info kernel: [ 5.620909] mv88e6085
stmmac-0:1a lan1 (uninitialized): PHY [mv88e6xxx-0:00] driver [Marvell
88E1540]
Jan 1 00:00:10 (none) user.info kernel: [ 5.669606] mv88e6085
stmmac-0:1a lan2 (uninitialized): PHY [mv88e6xxx-0:01] driver [Marvell
88E1540]
Jan 1 00:00:10 (none) user.info kernel: [ 5.719458] mv88e6085
stmmac-0:1a lan3 (uninitialized): PHY [mv88e6xxx-0:02] driver [Marvell
88E1540]
Jan 1 00:00:10 (none) user.info kernel: [ 7.103178] mv88e6085
stmmac-0:1e lan4 (uninitialized): PHY [mv88e6xxx-2:00] driver [Marvell
88E1540]
Jan 1 00:00:10 (none) user.info kernel: [ 7.151820] mv88e6085
stmmac-0:1e dmz (uninitialized): PHY [mv88e6xxx-2:01] driver [Marvell
88E1540]
Nov 1 12:01:37 (none) user.info kernel: [ 107.993670] mv88e6085
stmmac-0:1a lan1: configuring for phy/gmii link mode
>> 6: lan2@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
>> link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
>> 7: lan3@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
>> link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
>> 8: lan4@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
>> link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
>> 9: dmz@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
>> link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
>> root@dali:~# ip route
>> default via 192.168.0.1 dev eth0
>
> That is not correct. eth0 just acts as a pipe towards the switch. It
> does not have an IP address, and there should not be any routes using
> it. It needs to be configured up, but that is all.
>
I've been fighting with Busybox init to just bring up eth0 with no IPv4
configuration, without success. I'll go back and review the Busybox docs
to see how to bring up eth0 without any IPv4 configuration.
>> The DSA switch tree is configured using this device tree fragment:
>>
>> gmac0 {
>> status = "okay";
>> phy-mode = "gmii";
>
> gmii? That is a bit unusual. You normally see rgmii.
>
I reviewed the schematic again and confirmed that gmii is being used.
The schematic shows RXD[7:0] and TXD[7:0] connected to port 6. However,
I just noticed no skew values are specified for RXD[7:4] and TXD[7:4]. I
should fix that.
>> txc-skew-ps = <0xbb8>;
>> rxc-skew-ps = <0xbb8>;
>> txen-skew-ps = <0>;
>> rxdv-skew-ps = <0>;
>> rxd0-skew-ps = <0>;
>> rxd1-skew-ps = <0>;
>> rxd2-skew-ps = <0>;
>> rxd3-skew-ps = <0>;
>> txd0-skew-ps = <0>;
>> txd1-skew-ps = <0>;
>> txd2-skew-ps = <0>;
>> txd3-skew-ps = <0>;
>> max-frame-size = <3800>;
>>
>> fixed-link {
>> speed = <0x3e8>;
>
> decimal would be much more readable. Or is this not the source .dts
> file, but you have decompiled the DTB back to DTS?
>
The original .dts was auto-generated using Altera tools, which emit
hexadecimal. I've been converting to decimal as I make changes to the
.dts. The speed value 0x3e8 is 1000 decimal.
>> full-duplex;
>> pause;
>> };
>>
>> mdio {
>> compatible = "snps,dwmac-mdio";
>> #address-cells = <0x1>;
>> #size-cells = <0x0>;
>>
>> switch0: switch0@1a {
>> compatible = "marvell,mv88e6085";
>> reg = <0x1a>;
>> dsa,member = <0 0>;
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> port@0 {
>> reg = <0>;
>> label = "lan1";
>> };
>> port@1 {
>> reg = <1>;
>> label = "lan2";
>> };
>> port@2 {
>> reg = <2>;
>> label = "lan3";
>> };
>> switch0port4: port@4 {
>> reg = <4>;
>> phy-mode = "rgmii-id";
>> link = <&switch1port4>;
>> fixed-link {
>> speed = <1000>;
>> full-duplex;
>> };
>> };
>> port@6 {
>> reg = <6>;
>> ethernet = <&gmac0>;
>> label = "cpu";
>> };
>> };
>> };
>> switch1: switch1@1e {
>> compatible = "marvell,mv88e6085";
>> reg = <0x1e>;
>> dsa,member = <0 1>;
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> port@0 {
>> reg = <0>;
>> label = "lan4";
>> };
>> port@1 {
>> reg = <1>;
>> label = "dmz";
>> };
>> switch1port4: port@4 {
>> reg = <4>;
>> link = <&switch0port4>;
>> phy-mode = "rgmii-id";
>
> You probably don't want both ends of the link in rgmii-id mode. That
> will give you twice the delay.
Ok, I'll change phy-mode to "rgmii" for both ends. It's a little
confusing that there's a reference to phy-mode at all, though, given the
actual connection is SERDES. My understanding is SERDES is a digital,
PHY-less connection.
I'll update the .dts to include the missing skew settings and the
phy-mode setting for the dsa ports, then post my results. (I've already
fixed the .dts to specify the correct switch for the cpu port, an error
I caught after posting.)
Thanks for the input!
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-07-23 18:21 ` Dario Alcocer
@ 2021-07-23 18:25 ` Andrew Lunn
2021-07-23 18:36 ` Dario Alcocer
0 siblings, 1 reply; 27+ messages in thread
From: Andrew Lunn @ 2021-07-23 18:25 UTC (permalink / raw)
To: Dario Alcocer; +Cc: netdev
> > You probably don't want both ends of the link in rgmii-id mode. That
> > will give you twice the delay.
>
> Ok, I'll change phy-mode to "rgmii" for both ends. It's a little confusing
> that there's a reference to phy-mode at all, though, given the actual
> connection is SERDES. My understanding is SERDES is a digital, PHY-less
> connection.
Is it even RGMII? You say SERDES, so 1000BaseX seems more likely.
Andrew
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-07-23 18:25 ` Andrew Lunn
@ 2021-07-23 18:36 ` Dario Alcocer
2021-07-23 21:58 ` Dario Alcocer
0 siblings, 1 reply; 27+ messages in thread
From: Dario Alcocer @ 2021-07-23 18:36 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
On 7/23/21 11:25 AM, Andrew Lunn wrote:
>>> You probably don't want both ends of the link in rgmii-id mode. That
>>> will give you twice the delay.
>>
>> Ok, I'll change phy-mode to "rgmii" for both ends. It's a little confusing
>> that there's a reference to phy-mode at all, though, given the actual
>> connection is SERDES. My understanding is SERDES is a digital, PHY-less
>> connection.
>
> Is it even RGMII? You say SERDES, so 1000BaseX seems more likely.
>
> Andrew
>
Ah, I see, good point. I'll use "1000base-x" instead.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-07-23 18:36 ` Dario Alcocer
@ 2021-07-23 21:58 ` Dario Alcocer
2021-07-24 17:34 ` Andrew Lunn
0 siblings, 1 reply; 27+ messages in thread
From: Dario Alcocer @ 2021-07-23 21:58 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
On 7/23/21 11:36 AM, Dario Alcocer wrote:
> On 7/23/21 11:25 AM, Andrew Lunn wrote:
>>>> You probably don't want both ends of the link in rgmii-id mode. That
>>>> will give you twice the delay.
>>>
>>> Ok, I'll change phy-mode to "rgmii" for both ends. It's a little
>>> confusing
>>> that there's a reference to phy-mode at all, though, given the actual
>>> connection is SERDES. My understanding is SERDES is a digital, PHY-less
>>> connection.
>>
>> Is it even RGMII? You say SERDES, so 1000BaseX seems more likely.
>>
>> Andrew
>>
>
> Ah, I see, good point. I'll use "1000base-x" instead.
Using the updated device tree fragment produced no change. The port
still reports no link:
root@dali:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group
default qlen 10
link/can
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP
mode DEFAULT group default qlen 1000
link/ether b6:07:dc:be:30:f9 brd ff:ff:ff:ff:ff:ff
4: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group
default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
5: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
link/ether b6:07:dc:be:30:f9 brd ff:ff:ff:ff:ff:ff
6: lan2@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether b6:07:dc:be:30:f9 brd ff:ff:ff:ff:ff:ff
7: lan3@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether b6:07:dc:be:30:f9 brd ff:ff:ff:ff:ff:ff
8: lan4@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether b6:07:dc:be:30:f9 brd ff:ff:ff:ff:ff:ff
9: dmz@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether b6:07:dc:be:30:f9 brd ff:ff:ff:ff:ff:ff
The DSA kernel options used with the 5.4.114-altera kernel are below.
I've applied the DSA DEBUG_FS patch from Vivien Didelot (rebased for
5.4.114), just in case it might help.
root@dali:~# zcat /proc/config.gz | grep DSA
CONFIG_HAVE_NET_DSA=y
CONFIG_NET_DSA=y
CONFIG_NET_DSA_DEBUGFS=y
# CONFIG_NET_DSA_TAG_8021Q is not set
# CONFIG_NET_DSA_TAG_BRCM is not set
# CONFIG_NET_DSA_TAG_BRCM_PREPEND is not set
# CONFIG_NET_DSA_TAG_GSWIP is not set
CONFIG_NET_DSA_TAG_DSA=y
CONFIG_NET_DSA_TAG_EDSA=y
# CONFIG_NET_DSA_TAG_MTK is not set
# CONFIG_NET_DSA_TAG_KSZ is not set
# CONFIG_NET_DSA_TAG_QCA is not set
# CONFIG_NET_DSA_TAG_LAN9303 is not set
# CONFIG_NET_DSA_TAG_SJA1105 is not set
# CONFIG_NET_DSA_TAG_TRAILER is not set
# CONFIG_NET_DSA_BCM_SF2 is not set
# CONFIG_NET_DSA_LOOP is not set
# CONFIG_NET_DSA_LANTIQ_GSWIP is not set
# CONFIG_NET_DSA_MT7530 is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MICROCHIP_KSZ9477 is not set
# CONFIG_NET_DSA_MICROCHIP_KSZ8795 is not set
CONFIG_NET_DSA_MV88E6XXX=y
CONFIG_NET_DSA_MV88E6XXX_GLOBAL2=y
# CONFIG_NET_DSA_MV88E6XXX_PTP is not set
# CONFIG_NET_DSA_SJA1105 is not set
# CONFIG_NET_DSA_QCA8K is not set
# CONFIG_NET_DSA_REALTEK_SMI is not set
# CONFIG_NET_DSA_SMSC_LAN9303_I2C is not set
# CONFIG_NET_DSA_SMSC_LAN9303_MDIO is not set
# CONFIG_NET_DSA_VITESSE_VSC73XX_SPI is not set
# CONFIG_NET_DSA_VITESSE_VSC73XX_PLATFORM is not set
# CONFIG_HNS_DSAF is not set
# CONFIG_CRYPTO_ECRDSA is not set
Here are the PHY lines from the log:
[ 2.781894] libphy: Fixed MDIO Bus: probed
[ 2.885923] libphy: stmmac: probed
[ 3.094333] libphy: mv88e6xxx SMI: probed
[ 3.464755] libphy: mv88e6xxx SMI: probed
[ 3.875276] can: netlink gateway (rev 20190810) max_hops=1
[ 4.117463] libphy: mv88e6xxx SMI: probed
[ 5.609731] mv88e6085 stmmac-0:1a lan1 (uninitialized): PHY
[mv88e6xxx-0:00] driver [Marvell 88E1540]
[ 5.663118] mv88e6085 stmmac-0:1a lan2 (uninitialized): PHY
[mv88e6xxx-0:01] driver [Marvell 88E1540]
[ 5.711747] mv88e6085 stmmac-0:1a lan3 (uninitialized): PHY
[mv88e6xxx-0:02] driver [Marvell 88E1540]
[ 5.786248] mv88e6085 stmmac-0:1a: configuring for fixed/1000base-x
link mode
[ 5.853905] mv88e6085 stmmac-0:1a: Link is Up - 1Gbps/Full - flow
control off
[ 7.083450] mv88e6085 stmmac-0:1e lan4 (uninitialized): PHY
[mv88e6xxx-2:00] driver [Marvell 88E1540]
[ 7.132094] mv88e6085 stmmac-0:1e dmz (uninitialized): PHY
[mv88e6xxx-2:01] driver [Marvell 88E1540]
[ 7.224337] mv88e6085 stmmac-0:1e: configuring for fixed/1000base-x
link mode
[ 7.314012] mv88e6085 stmmac-0:1e: Link is Up - 1Gbps/Full - flow
control off
[ 11.026419] socfpga-dwmac ff700000.ethernet eth0: configuring for
fixed/gmii link mode
[ 11.035304] socfpga-dwmac ff700000.ethernet eth0: Link is Up -
1Gbps/Full - flow control rx/tx
[ 11.043993] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
The DSA debugfs shows the following:
root@dali:~# ls /sys/kernel/debug/dsa/
switch0
root@dali:~# ls /sys/kernel/debug/dsa/switch0
port0 port1 port2 port3 port4 port5 port6 tag_protocol tree
root@dali:~# cat /sys/kernel/debug/dsa/switch0/tree
0
root@dali:~# ls /sys/kernel/debug/dsa/switch0/port0
fdb mdb regs stats vlan
root@dali:~# cat /sys/kernel/debug/dsa/switch0/port0/vlan
root@dali:~# cat /sys/kernel/debug/dsa/switch0/port0/vlan | hexdump -C
root@dali:~# cat /sys/kernel/debug/dsa/switch0/port0/stats
in_good_octets : 0
in_bad_octets : 0
in_unicast : 0
in_broadcasts : 0
in_multicasts : 0
in_pause : 0
in_undersize : 0
in_fragments : 0
in_oversize : 0
in_jabber : 0
in_rx_error : 0
in_fcs_error : 0
out_octets : 0
out_unicast : 0
out_broadcasts : 0
out_multicasts : 0
out_pause : 0
excessive : 0
collisions : 0
deferred : 0
single : 0
multiple : 0
out_fcs_error : 0
late : 0
hist_64bytes : 0
hist_65_127bytes : 0
hist_128_255bytes : 0
hist_256_511bytes : 0
hist_512_1023bytes : 0
hist_1024_max_bytes : 0
sw_in_discards : 0
sw_in_filtered : 0
sw_out_filtered : 0
atu_member_violation: 0
atu_miss_violation : 0
atu_full_violation : 0
vtu_member_violation: 0
vtu_miss_violation : 0
root@dali:~# cat /sys/kernel/debug/dsa/switch0/port0/regs
0: 100f
1: 0003
2: 0000
3: 1761
4: 0433
5: 0000
6: 0010
7: 0000
8: 2080
9: 0001
10: 0000
11: 0001
12: 0000
13: 0000
14: 0000
15: 9100
16: 0000
17: 0000
18: 0000
19: 0000
20: 0000
21: 0000
22: 0033
23: 0000
24: 3210
25: 7654
26: 0000
27: 8000
28: 0000
29: 0000
30: 0000
31: 0000
root@dali:~#
Finally, here's the device tree fragment used to configure DSA. I added
phy-handle resources for each of the switch port, taken from the example
in Documentation/devicetree/bindings/net/dsa/dsa.txt. I did this to see
if it would fix the port link issue:
&gmac0 {
status = "okay";
phy-mode = "gmii";
txc-skew-ps = <3000>;
rxc-skew-ps = <3000>;
txen-skew-ps = <0>;
rxdv-skew-ps = <0>;
rxd0-skew-ps = <0>;
rxd1-skew-ps = <0>;
rxd2-skew-ps = <0>;
rxd3-skew-ps = <0>;
rxd4-skew-ps = <0>;
rxd5-skew-ps = <0>;
rxd6-skew-ps = <0>;
rxd7-skew-ps = <0>;
txd0-skew-ps = <0>;
txd1-skew-ps = <0>;
txd2-skew-ps = <0>;
txd3-skew-ps = <0>;
txd4-skew-ps = <0>;
txd5-skew-ps = <0>;
txd6-skew-ps = <0>;
txd7-skew-ps = <0>;
max-frame-size = <3800>;
fixed-link {
speed = <1000>;
full-duplex;
pause;
};
mdio {
compatible = "snps,dwmac-mdio";
#address-cells = <0x1>;
#size-cells = <0x0>;
switch0: switch0@1a {
compatible = "marvell,mv88e6085";
reg = <0x1a>;
dsa,member = <0 0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan1";
phy-handle = <&switch0phy0>;
};
port@1 {
reg = <1>;
label = "lan2";
phy-handle = <&switch0phy1>;
};
port@2 {
reg = <2>;
label = "lan3";
phy-handle = <&switch0phy2>;
};
switch0port4: port@4 {
reg = <4>;
phy-mode = "1000base-x";
link = <&switch1port4>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
mdio-bus {
#address-cells = <1>;
#size-cells = <0>;
switch0phy0: switch0phy@0 {
reg = <0>;
};
switch0phy1: switch0phy@1 {
reg = <1>;
};
switch0phy2: switch0phy@2 {
reg = <2>;
};
};
};
switch1: switch1@1e {
compatible = "marvell,mv88e6085";
reg = <0x1e>;
dsa,member = <0 1>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan4";
};
port@1 {
reg = <1>;
label = "dmz";
};
switch1port4: port@4 {
reg = <4>;
link = <&switch0port4>;
phy-mode = "1000base-x";
fixed-link {
speed = <1000>;
full-duplex;
};
};
port@6 {
reg = <6>;
ethernet = <&gmac0>;
label = "cpu";
};
};
mdio-bus {
#address-cells = <1>;
#size-cells = <0>;
switch1phy0: switch1phy@0 {
reg = <0>;
};
switch1phy1: switch1phy@1 {
reg = <1>;
};
};
};
};
};
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-07-23 21:58 ` Dario Alcocer
@ 2021-07-24 17:34 ` Andrew Lunn
2021-07-25 2:26 ` Dario Alcocer
0 siblings, 1 reply; 27+ messages in thread
From: Andrew Lunn @ 2021-07-24 17:34 UTC (permalink / raw)
To: Dario Alcocer; +Cc: netdev
> root@dali:~# ip link
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode
> DEFAULT group default qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group
> default qlen 10
> link/can
> 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP mode
> DEFAULT group default qlen 1000
> link/ether b6:07:dc:be:30:f9 brd ff:ff:ff:ff:ff:ff
> 4: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group
> default qlen 1000
> link/sit 0.0.0.0 brd 0.0.0.0
> 5: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
> state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
> link/ether b6:07:dc:be:30:f9 brd ff:ff:ff:ff:ff:ff
> 6: lan2@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
> DEFAULT group default qlen 1000
> link/ether b6:07:dc:be:30:f9 brd ff:ff:ff:ff:ff:ff
> 7: lan3@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
> DEFAULT group default qlen 1000
> link/ether b6:07:dc:be:30:f9 brd ff:ff:ff:ff:ff:ff
> 8: lan4@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
> DEFAULT group default qlen 1000
> link/ether b6:07:dc:be:30:f9 brd ff:ff:ff:ff:ff:ff
> 9: dmz@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
> DEFAULT group default qlen 1000
> link/ether b6:07:dc:be:30:f9 brd ff:ff:ff:ff:ff:ff
I would suggest you configure all the interfaces up. I've made the
stupid mistake of thinking the right most RJ-45 socket is lan1 when it
is in fact dmz, etc. If you configure them all up, you should see
kernel messages if any go up, and you can see LOWER_UP, etc.
What does the link peer think? Does it think there is link? I think
for this generation of switch, the PHYs by default are enabled and
will perform autoneg, even if the interface is down. But if the
interface is down, phylib will not be monitoring it, and so you don't
see any kernel messages.
You might want to enable dbg prints in driver/nets/phy/phy.c, so you
can see the state machine changes.
Andrew
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-07-24 17:34 ` Andrew Lunn
@ 2021-07-25 2:26 ` Dario Alcocer
2021-07-25 2:36 ` Dario Alcocer
0 siblings, 1 reply; 27+ messages in thread
From: Dario Alcocer @ 2021-07-25 2:26 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
On 7/24/21 10:34 AM, Andrew Lunn wrote:
>> root@dali:~# ip link
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode
>> DEFAULT group default qlen 1000
>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> 2: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group
>> default qlen 10
>> link/can
>> 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP mode
>> DEFAULT group default qlen 1000
>> link/ether b6:07:dc:be:30:f9 brd ff:ff:ff:ff:ff:ff
>> 4: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group
>> default qlen 1000
>> link/sit 0.0.0.0 brd 0.0.0.0
>> 5: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
>> state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
>> link/ether b6:07:dc:be:30:f9 brd ff:ff:ff:ff:ff:ff
>> 6: lan2@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
>> DEFAULT group default qlen 1000
>> link/ether b6:07:dc:be:30:f9 brd ff:ff:ff:ff:ff:ff
>> 7: lan3@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
>> DEFAULT group default qlen 1000
>> link/ether b6:07:dc:be:30:f9 brd ff:ff:ff:ff:ff:ff
>> 8: lan4@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
>> DEFAULT group default qlen 1000
>> link/ether b6:07:dc:be:30:f9 brd ff:ff:ff:ff:ff:ff
>> 9: dmz@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
>> DEFAULT group default qlen 1000
>> link/ether b6:07:dc:be:30:f9 brd ff:ff:ff:ff:ff:ff
> I would suggest you configure all the interfaces up. I've made the
> stupid mistake of thinking the right most RJ-45 socket is lan1 when it
> is in fact dmz, etc. If you configure them all up, you should see
> kernel messages if any go up, and you can see LOWER_UP, etc.
As suggested, I brought up all the interfaces after rebooting and
logging in. All interfaces report NO-CARRIER:
root@dali:~# ip addr add 192.0.2.1/24 dev lan1
root@dali:~# ip addr add 192.0.3.1/24 dev lan2
root@dali:~# ip addr add 192.0.4.1/24 dev lan3
root@dali:~# ip addr add 192.0.5.1/24 dev lan4
root@dali:~# ip addr add 192.0.6.1/24 dev dmz
root@dali:~# ip link set lan1 up
[ 100.725374] mv88e6085 stmmac-0:1a lan1: configuring for phy/gmii link
mode
[ 100.734414] 8021q: adding VLAN 0 to HW filter on device lan1
root@dali:~# ip link set lan2 up
[ 104.765609] mv88e6085 stmmac-0:1a lan2: configuring for phy/gmii link
mode
[ 104.774623] 8021q: adding VLAN 0 to HW filter on device lan2
root@dali:~# ip link set lan3 up
[ 109.175228] mv88e6085 stmmac-0:1a lan3: configuring for phy/gmii link
mode
[ 109.184329] 8021q: adding VLAN 0 to HW filter on device lan3
root@dali:~# ip link set lan4 up
[ 113.805224] mv88e6085 stmmac-0:1e lan4: configuring for phy/gmii link
mode
[ 113.816757] 8021q: adding VLAN 0 to HW filter on device lan4
root@dali:~# ip link set dmz up
[ 118.695089] mv88e6085 stmmac-0:1e dmz: configuring for phy/gmii link mode
[ 118.704109] 8021q: adding VLAN 0 to HW filter on device dmz
root@dali:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group
default qlen 10
link/can
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP
mode DEFAULT group default qlen 1000
link/ether 42:19:da:37:69:37 brd ff:ff:ff:ff:ff:ff
4: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group
default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
5: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
link/ether 42:19:da:37:69:37 brd ff:ff:ff:ff:ff:ff
6: lan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
link/ether 42:19:da:37:69:37 brd ff:ff:ff:ff:ff:ff
7: lan3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
link/ether 42:19:da:37:69:37 brd ff:ff:ff:ff:ff:ff
8: lan4@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
link/ether 42:19:da:37:69:37 brd ff:ff:ff:ff:ff:ff
9: dmz@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
link/ether 42:19:da:37:69:37 brd ff:ff:ff:ff:ff:ff
> What does the link peer think? Does it think there is link? I think
> for this generation of switch, the PHYs by default are enabled and
> will perform autoneg, even if the interface is down. But if the
> interface is down, phylib will not be monitoring it, and so you don't
> see any kernel messages.
Only lan1, lan2, and lan3 have link peers. All of these peers report
NO-CARRIER as well on their end.
I'll see if I can find a couple more devices to connect lan4 and dmz.
> You might want to enable dbg prints in driver/nets/phy/phy.c, so you
> can see the state machine changes.
Great suggestion. I added the following to the boot options:
dyndbg="file net/dsa/* +p; file drivers/net/phy/phy.c +p"
The relevant messages collected from the system log are below.
Interestingly, all of the ports go from UP to NOLINK. In addition,
"breaking chain for DSA event 7" is reported, once for each port.
I'll dig into the DSA sources to see the significance of event 7.
Jan 1 00:00:10 (none) user.info kernel: [ 3.916429] mv88e6085
stmmac-0:1e: switch 0x1760 detected: Marvell 88E6176, revision 1
Jan 1 00:00:10 (none) user.info kernel: [ 4.112181] libphy:
mv88e6xxx SMI: probed
Jan 1 00:00:10 (none) user.info kernel: [ 5.604619] mv88e6085
stmmac-0:1a lan1 (uninitialized): PHY [mv88e6xxx-0:00] driver [Marvell
88E1540]
Jan 1 00:00:10 (none) user.info kernel: [ 5.653303] mv88e6085
stmmac-0:1a lan2 (uninitialized): PHY [mv88e6xxx-0:01] driver [Marvell
88E1540]
Jan 1 00:00:10 (none) user.info kernel: [ 5.701971] mv88e6085
stmmac-0:1a lan3 (uninitialized): PHY [mv88e6xxx-0:02] driver [Marvell
88E1540]
Jan 1 00:00:10 (none) user.info kernel: [ 5.777739] mv88e6085
stmmac-0:1a: configuring for fixed/1000base-x link mode
Jan 1 00:00:10 (none) user.info kernel: [ 5.845517] mv88e6085
stmmac-0:1a: Link is Up - 1Gbps/Full - flow control off
Jan 1 00:00:10 (none) user.info kernel: [ 7.075948] mv88e6085
stmmac-0:1e lan4 (uninitialized): PHY [mv88e6xxx-2:00] driver [Marvell
88E1540]
Jan 1 00:00:10 (none) user.info kernel: [ 7.124591] mv88e6085
stmmac-0:1e dmz (uninitialized): PHY [mv88e6xxx-2:01] driver [Marvell
88E1540]
Jan 1 00:00:10 (none) user.info kernel: [ 7.216056] mv88e6085
stmmac-0:1e: configuring for fixed/1000base-x link mode
Jan 1 00:00:10 (none) user.info kernel: [ 7.305154] mv88e6085
stmmac-0:1e: Link is Up - 1Gbps/Full - flow control off
Jan 1 00:00:10 (none) user.err kernel: [ 7.348496] debugfs:
Directory 'switch0' with parent 'dsa' already present!
Jan 1 00:00:10 (none) user.warn kernel: [ 7.355442] DSA: failed to
create debugfs interface for switch 0 (-14)
Jan 1 00:00:10 (none) user.info kernel: [ 7.362201] DSA: tree 0 setup
Nov 1 12:00:00 (none) user.info kernel: [ 10.924223] socfpga-dwmac
ff700000.ethernet eth0: No Safety Features support found
Nov 1 12:00:00 (none) user.info kernel: [ 10.932024] socfpga-dwmac
ff700000.ethernet eth0: registered PTP clock
Nov 1 12:00:00 (none) user.info kernel: [ 10.938606] socfpga-dwmac
ff700000.ethernet eth0: configuring for fixed/gmii link mode
Nov 1 12:00:00 (none) user.info kernel: [ 10.947521] socfpga-dwmac
ff700000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
Nov 1 12:00:00 (none) user.info kernel: [ 10.956420] IPv6:
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Nov 1 12:01:30 (none) user.info kernel: [ 100.725374] mv88e6085
stmmac-0:1a lan1: configuring for phy/gmii link mode
Nov 1 12:01:30 (none) user.info kernel: [ 100.734414] 8021q: adding
VLAN 0 to HW filter on device lan1
Nov 1 12:01:30 (none) user.debug kernel: [ 100.740065] mv88e6085
stmmac-0:1a: breaking chain for DSA event 7 (-95)
Nov 1 12:01:30 (none) user.debug kernel: [ 100.792228] Marvell 88E1540
mv88e6xxx-0:00: PHY state change UP -> NOLINK
Nov 1 12:01:34 (none) user.info kernel: [ 104.765609] mv88e6085
stmmac-0:1a lan2: configuring for phy/gmii link mode
Nov 1 12:01:34 (none) user.debug kernel: [ 104.780274] mv88e6085
stmmac-0:1a: breaking chain for DSA event 7 (-95)
Nov 1 12:01:34 (none) user.debug kernel: [ 104.832491] Marvell 88E1540
mv88e6xxx-0:01: PHY state change UP -> NOLINK
Nov 1 12:01:38 (none) user.info kernel: [ 109.175228] mv88e6085
stmmac-0:1a lan3: configuring for phy/gmii link mode
Nov 1 12:01:38 (none) user.info kernel: [ 109.184329] 8021q: adding
VLAN 0 to HW filter on device lan3
Nov 1 12:01:38 (none) user.debug kernel: [ 109.189986] mv88e6085
stmmac-0:1a: breaking chain for DSA event 7 (-95)
Nov 1 12:01:38 (none) user.debug kernel: [ 109.240647] Marvell 88E1540
mv88e6xxx-0:02: PHY state change UP -> NOLINK
Nov 1 12:01:43 (none) user.info kernel: [ 113.805224] mv88e6085
stmmac-0:1e lan4: configuring for phy/gmii link mode
Nov 1 12:01:43 (none) user.info kernel: [ 113.816757] 8021q: adding
VLAN 0 to HW filter on device lan4
Nov 1 12:01:43 (none) user.debug kernel: [ 113.822414] mv88e6085
stmmac-0:1e: breaking chain for DSA event 7 (-95)
Nov 1 12:01:43 (none) user.debug kernel: [ 113.874108] Marvell 88E1540
mv88e6xxx-2:00: PHY state change UP -> NOLINK
Nov 1 12:01:48 (none) user.info kernel: [ 118.695089] mv88e6085
stmmac-0:1e dmz: configuring for phy/gmii link mode
Nov 1 12:01:48 (none) user.info kernel: [ 118.704109] 8021q: adding
VLAN 0 to HW filter on device dmz
Nov 1 12:01:48 (none) user.debug kernel: [ 118.709679] mv88e6085
stmmac-0:1e: breaking chain for DSA event 7 (-95)
Nov 1 12:01:48 (none) user.debug kernel: [ 118.763988] Marvell 88E1540
mv88e6xxx-2:01: PHY state change UP -> NOLINK
I've been reading up on kernel tracing. Perhaps some well-crafted trace
queries would help narrow down what's happening with the port PHYs.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-07-25 2:26 ` Dario Alcocer
@ 2021-07-25 2:36 ` Dario Alcocer
2021-07-27 1:39 ` Dario Alcocer
0 siblings, 1 reply; 27+ messages in thread
From: Dario Alcocer @ 2021-07-25 2:36 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
On 7/24/21 7:26 PM, Dario Alcocer wrote:
> On 7/24/21 10:34 AM, Andrew Lunn wrote:
>> You might want to enable dbg prints in driver/nets/phy/phy.c, so you
>> can see the state machine changes.
>
> Great suggestion. I added the following to the boot options:
>
> dyndbg="file net/dsa/* +p; file drivers/net/phy/phy.c +p"
>
> The relevant messages collected from the system log are below.
> Interestingly, all of the ports go from UP to NOLINK. In addition,
> "breaking chain for DSA event 7" is reported, once for each port.
>
> I'll dig into the DSA sources to see the significance of event 7.
Event 7 is DSA_NOTIFIER_VLAN_ADD, found in net/dsa/dsa_priv.h
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-07-25 2:36 ` Dario Alcocer
@ 2021-07-27 1:39 ` Dario Alcocer
2021-07-28 18:07 ` Dario Alcocer
0 siblings, 1 reply; 27+ messages in thread
From: Dario Alcocer @ 2021-07-27 1:39 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
On 7/24/21 7:36 PM, Dario Alcocer wrote:
> On 7/24/21 7:26 PM, Dario Alcocer wrote:
>> On 7/24/21 10:34 AM, Andrew Lunn wrote:
>>> You might want to enable dbg prints in driver/nets/phy/phy.c, so you
>>> can see the state machine changes.
>>
>> Great suggestion. I added the following to the boot options:
>>
>> dyndbg="file net/dsa/* +p; file drivers/net/phy/phy.c +p"
>>
>> The relevant messages collected from the system log are below.
>> Interestingly, all of the ports go from UP to NOLINK. In addition,
>> "breaking chain for DSA event 7" is reported, once for each port.
Andrew,
As I mentioned before, the system log shows that each switch port link
state goes from UP to NOLINK when "ip link set DEVNAME up" runs.
Since you suggested it's probably a PHY problem, I used kernel tracing
to track PHY-related calls in the following files:
* drivers/net/phy/phylink.c
* drivers/net/phy/marvell.c
* net/dsa/port.c
I set up the kernel tracing before trying to bring up the lan1 interface:
root@dali:~# mount -t tracefs tracefs /sys/kernel/tracing
root@dali:~# echo 0 > /sys/kernel/tracing/tracing_on
root@dali:~# echo function_graph > /sys/kernel/tracing/current_tracer
root@dali:~# echo phylink_\* > /sys/kernel/tracing/set_ftrace_filter
root@dali:~# echo dsa_port_phylink_\* >>
/sys/kernel/tracing/set_ftrace_filter
root@dali:~# echo m88e1510_probe >> /sys/kernel/tracing/set_ftrace_filter
root@dali:~# echo marvell_config_init >>
/sys/kernel/tracing/set_ftrace_filter
root@dali:~# echo m88e1510_config_aneg >>
/sys/kernel/tracing/set_ftrace_filter
root@dali:~# echo marvell_read_status >>
/sys/kernel/tracing/set_ftrace_filter
root@dali:~# echo marvell_ack_interrupt >>
/sys/kernel/tracing/set_ftrace_filter
root@dali:~# echo marvell_config_intr >>
/sys/kernel/tracing/set_ftrace_filter
root@dali:~# echo m88e1121_did_interrupt >>
/sys/kernel/tracing/set_ftrace_filter
root@dali:~# echo genphy_resume >> /sys/kernel/tracing/set_ftrace_filter
root@dali:~# echo genphy_suspend >> /sys/kernel/tracing/set_ftrace_filter
root@dali:~# echo marvell_read_page >> /sys/kernel/tracing/set_ftrace_filter
root@dali:~# echo marvell_write_page >>
/sys/kernel/tracing/set_ftrace_filter
root@dali:~# echo marvell_get_sset_count >>
/sys/kernel/tracing/set_ftrace_filter
root@dali:~# echo marvell_get_strings >>
/sys/kernel/tracing/set_ftrace_filter
root@dali:~# echo m88e1540_get_tunable >>
/sys/kernel/tracing/set_ftrace_filter
root@dali:~# echo m88e1540_set_tunable >>
/sys/kernel/tracing/set_ftrace_filter
root@dali:~# echo 1 > /sys/kernel/tracing/tracing_on
I then tried bringing up lan1 again to see which functions would be
called, then stopped kernel tracing:
root@dali:~# ip addr add 192.0.2.1/24 dev lan1
root@dali:~# ip link set lan1 up
[ 511.763909] mv88e6085 stmmac-0:1a lan1: configuring for phy/gmii link
mode
[ 511.773082] 8021q: adding VLAN 0 to HW filter on device lan1
root@dali:~# echo 0 > /sys/kernel/tracing/tracing_on
I then dumped the trace buffer:
root@dali:~# cat /sys/kernel/tracing/trace
# tracer: function_graph
#
# CPU DURATION FUNCTION CALLS
# | | | | | | |
1) + 10.900 us | phylink_ethtool_ksettings_get();
1) 5.220 us | phylink_ethtool_ksettings_get();
1) | phylink_ethtool_ksettings_get() {
1) 2.060 us | phylink_get_fixed_state();
1) 1.890 us | phylink_get_ksettings();
1) + 11.740 us | }
1) 6.760 us | phylink_ethtool_ksettings_get();
1) 4.890 us | phylink_ethtool_ksettings_get();
1) 4.670 us | phylink_ethtool_ksettings_get();
1) + 11.560 us | phylink_ethtool_ksettings_get();
1) 5.060 us | phylink_ethtool_ksettings_get();
1) | phylink_ethtool_ksettings_get() {
1) 2.010 us | phylink_get_fixed_state();
1) 1.810 us | phylink_get_ksettings();
1) + 12.140 us | }
1) 5.890 us | phylink_ethtool_ksettings_get();
1) 5.300 us | phylink_ethtool_ksettings_get();
1) 4.630 us | phylink_ethtool_ksettings_get();
1) + 10.070 us | phylink_ethtool_ksettings_get();
1) 5.100 us | phylink_ethtool_ksettings_get();
1) | phylink_ethtool_ksettings_get() {
1) 1.910 us | phylink_get_fixed_state();
1) 1.840 us | phylink_get_ksettings();
1) + 12.120 us | }
1) 5.910 us | phylink_ethtool_ksettings_get();
1) 5.410 us | phylink_ethtool_ksettings_get();
1) 4.630 us | phylink_ethtool_ksettings_get();
1) + 10.560 us | phylink_ethtool_ksettings_get();
1) 4.620 us | phylink_ethtool_ksettings_get();
1) | phylink_ethtool_ksettings_get() {
1) 1.920 us | phylink_get_fixed_state();
1) 1.930 us | phylink_get_ksettings();
1) + 12.370 us | }
1) 5.290 us | phylink_ethtool_ksettings_get();
1) 4.570 us | phylink_ethtool_ksettings_get();
1) 4.500 us | phylink_ethtool_ksettings_get();
0) | phylink_start() {
0) 2.510 us | phylink_resolve_flow();
0) | phylink_mac_config() {
0) 2.260 us | dsa_port_phylink_mac_config();
0) 5.830 us | }
0) + 14.740 us | phylink_run_resolve.part.0();
0) | genphy_resume() {
------------------------------------------
0) ip-626 => kworker-20
------------------------------------------
0) | phylink_resolve() {
0) 1.860 us | phylink_resolve_flow();
0) 6.800 us | }
------------------------------------------
0) kworker-20 => ip-626
------------------------------------------
0) # 1818.330 us | } /* genphy_resume */
0) # 8730.320 us | } /* phylink_start */
------------------------------------------
0) ip-626 => kworker-20
------------------------------------------
0) | m88e1510_config_aneg() {
0) # 1871.880 us | marvell_read_page();
0) # 1807.480 us | marvell_write_page();
0) # 1804.300 us | marvell_write_page();
0) * 42803.07 us | }
0) * 13283.95 us | marvell_read_status();
0) | phylink_phy_change() {
0) 3.990 us | phylink_run_resolve.part.0();
0) 8.930 us | }
0) | phylink_resolve() {
0) 2.110 us | phylink_resolve_flow();
0) 6.320 us | }
1) + 11.280 us | phylink_ethtool_ksettings_get();
1) 4.560 us | phylink_ethtool_ksettings_get();
1) | phylink_ethtool_ksettings_get() {
1) 2.180 us | phylink_get_fixed_state();
1) 1.960 us | phylink_get_ksettings();
1) + 12.620 us | }
1) 5.290 us | phylink_ethtool_ksettings_get();
1) 4.980 us | phylink_ethtool_ksettings_get();
1) 5.000 us | phylink_ethtool_ksettings_get();
1) + 10.430 us | phylink_ethtool_ksettings_get();
1) 4.860 us | phylink_ethtool_ksettings_get();
1) | phylink_ethtool_ksettings_get() {
1) 2.070 us | phylink_get_fixed_state();
1) 1.950 us | phylink_get_ksettings();
1) + 12.090 us | }
1) 5.310 us | phylink_ethtool_ksettings_get();
1) 5.110 us | phylink_ethtool_ksettings_get();
1) 4.730 us | phylink_ethtool_ksettings_get();
I filtered the output to see which specific calls are made when checking
the port link status:
root@dali:~# cat /sys/kernel/tracing/trace | fgrep '|' | cut -d '|' -f 2
| sort | uniq
dsa_port_phylink_mac_config();
genphy_resume() {
marvell_read_page();
marvell_write_page();
phylink_get_fixed_state();
phylink_get_ksettings();
phylink_mac_config() {
phylink_resolve_flow();
phylink_run_resolve.part.0();
}
} /* genphy_resume */
m88e1510_config_aneg() {
marvell_read_status();
phylink_ethtool_ksettings_get() {
phylink_ethtool_ksettings_get();
phylink_phy_change() {
phylink_resolve() {
phylink_start() {
}
} /* phylink_start */
root@dali:~#
I will focus on adding more tracing to these specific functions, in
hopes of narrowing down the link issue further.
Let me know if you have any other suggestions, in case I missed something.
Thanks!
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-07-27 1:39 ` Dario Alcocer
@ 2021-07-28 18:07 ` Dario Alcocer
2021-07-28 18:23 ` Andrew Lunn
0 siblings, 1 reply; 27+ messages in thread
From: Dario Alcocer @ 2021-07-28 18:07 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
It appears the port link-state issue is caused by the mv88e6xxx switch
driver. The function mv88e6xxx_mac_config identifies the PHY as internal
and skips the call to mv88e6xxx_port_setup_mac.
It does not make sense to me why internal PHY configuration should be
skipped.
During boot, the 5.4.114 kernel successfully probes both switch chips,
and the SERDES link appears to be brought up successfully:
[ 2.782024] libphy: Fixed MDIO Bus: probed
[ 2.800458] socfpga-dwmac ff700000.ethernet: IRQ eth_wake_irq not found
[ 2.807070] socfpga-dwmac ff700000.ethernet: IRQ eth_lpi not found
[ 2.813367] socfpga-dwmac ff700000.ethernet: PTP uses main clock
[ 2.819537] socfpga-dwmac ff700000.ethernet: Version ID not available
[ 2.825978] socfpga-dwmac ff700000.ethernet: DWMAC1000
[ 2.831186] socfpga-dwmac ff700000.ethernet: DMA HW capability
register supported
[ 2.838647] socfpga-dwmac ff700000.ethernet: RX Checksum Offload
Engine supported
[ 2.846108] socfpga-dwmac ff700000.ethernet: COE Type 2
[ 2.851312] socfpga-dwmac ff700000.ethernet: TX Checksum insertion
supported
[ 2.858338] socfpga-dwmac ff700000.ethernet: Enhanced/Alternate
descriptors
[ 2.865279] socfpga-dwmac ff700000.ethernet: Extended descriptors not
supported
[ 2.872557] socfpga-dwmac ff700000.ethernet: Ring mode enabled
[ 2.878382] socfpga-dwmac ff700000.ethernet: device MAC address
fa:8b:6f:1f:4b:83
[ 2.886010] libphy: stmmac: probed
[ 2.890027] mv88e6085 stmmac-0:1a: switch 0x1760 detected: Marvell
88E6176, revision 1
[ 3.085696] libphy: mv88e6xxx SMI: probed
[ 3.090416] mv88e6085 stmmac-0:1e: switch 0x1760 detected: Marvell
88E6176, revision 1
[ 3.281274] libphy: mv88e6xxx SMI: probed
[ 3.626689] mv88e6085 stmmac-0:1e: switch 0x1760 detected: Marvell
88E6176, revision 1
[ 3.824809] libphy: mv88e6xxx SMI: probed
[ 4.983937] mv88e6085 stmmac-0:1a lan1 (uninitialized): PHY
[mv88e6xxx-0:00] driver [Marvell 88E1540]
[ 4.999891] mv88e6085 stmmac-0:1a lan2 (uninitialized): PHY
[mv88e6xxx-0:01] driver [Marvell 88E1540]
[ 5.016620] mv88e6085 stmmac-0:1a lan3 (uninitialized): PHY
[mv88e6xxx-0:02] driver [Marvell 88E1540]
[ 5.032460] mv88e6085 stmmac-0:1a: configuring for fixed/1000base-x
link mode
[ 5.039594] mv88e6xxx_mac_config: switch=0, port=4, mode=0x1
[ 5.045245] mv88e6xxx_mac_config: mode==MLO_AN_FIXED, force link up,
speed=1000, duplex=1
[ 5.053875] mv88e6xxx_mac_config: switch=0, port=4, mode=0x1
[ 5.059522] mv88e6xxx_mac_config: mode==MLO_AN_FIXED, force link up,
speed=1000, duplex=1
[ 5.084915] mv88e6085 stmmac-0:1a: Link is Up - 1Gbps/Full - flow
control off
[ 6.253481] mv88e6085 stmmac-0:1e lan4 (uninitialized): PHY
[mv88e6xxx-2:00] driver [Marvell 88E1540]
[ 6.273714] mv88e6085 stmmac-0:1e dmz (uninitialized): PHY
[mv88e6xxx-2:01] driver [Marvell 88E1540]
[ 6.290369] mv88e6085 stmmac-0:1e: configuring for fixed/1000base-x
link mode
[ 6.297503] mv88e6xxx_mac_config: switch=1, port=4, mode=0x1
[ 6.303152] mv88e6xxx_mac_config: mode==MLO_AN_FIXED, force link up,
speed=1000, duplex=1
[ 6.311774] mv88e6xxx_mac_config: switch=1, port=4, mode=0x1
[ 6.317435] mv88e6xxx_mac_config: mode==MLO_AN_FIXED, force link up,
speed=1000, duplex=1
[ 6.340344] mv88e6085 stmmac-0:1e: Link is Up - 1Gbps/Full - flow
control off
[ 6.348972] debugfs: Directory 'switch0' with parent 'dsa' already
present!
[ 6.355938] DSA: failed to create debugfs interface for switch 0 (-14)
[ 6.362692] DSA: tree 0 setup
After booting, I logged in and set up dynamic tracing for the relevant
kernel routines:
dali login: root
Password:
root@dali:~# echo 'file drivers/net/phy/marvell.c +p' >
/sys/kernel/debug/dynamic_debug/control
root@dali:~# echo 'file drivers/net/phy/phy_device.c +p' >
/sys/kernel/debug/dynamic_debug/control
root@dali:~# echo 'file drivers/net/phy/phylink.c +p' >
/sys/kernel/debug/dynamic_debug/control
root@dali:~# echo 'file drivers/net/phy/phy.c +p' >
/sys/kernel/debug/dynamic_debug/control
root@dali:~# echo 'file net/dsa/port.c +p' >
/sys/kernel/debug/dynamic_debug/control
root@dali:~# echo 'file net/dsa/slave.c +p' >
/sys/kernel/debug/dynamic_debug/control
root@dali:~# echo 'file drivers/net/dsa/mv88e6xxx/chip.c +p' >
/sys/kernel/debug/dynamic_debug/control
root@dali:~# echo 'func mv88e6xxx_read -p' >
/sys/kernel/debug/dynamic_debug/control
root@dali:~# echo 'func mv88e6xxx_write -p' >
/sys/kernel/debug/dynamic_debug/control
I then attempted to bring up the lan1 port and duplicated the
LOWERLAYERDOWN issue. I inserted begin/end markers in the system log to
locate the PHY traces:
root@dali:~# logger -t adhoc begin: bring up lan1 port
root@dali:~# ip addr add 192.0.2.1/24 dev lan1
root@dali:~# ip link set lan1 up
[ 64.087971] mv88e6085 stmmac-0:1a lan1: configuring for phy/gmii link
mode
[ 64.094929] mv88e6xxx_mac_config: switch=0, port=0, mode=0x0
[ 64.100563] mv88e6xxx_mac_config: skip MAC config for internal PHY
[ 64.109285] 8021q: adding VLAN 0 to HW filter on device lan1
root@dali:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group
default qlen 10
link/can
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP
mode DEFAULT group default qlen 1000
link/ether fa:8b:6f:1f:4b:83 brd ff:ff:ff:ff:ff:ff
4: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group
default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
5: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
link/ether fa:8b:6f:1f:4b:83 brd ff:ff:ff:ff:ff:ff
6: lan2@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether fa:8b:6f:1f:4b:83 brd ff:ff:ff:ff:ff:ff
7: lan3@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether fa:8b:6f:1f:4b:83 brd ff:ff:ff:ff:ff:ff
8: lan4@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether fa:8b:6f:1f:4b:83 brd ff:ff:ff:ff:ff:ff
9: dmz@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether fa:8b:6f:1f:4b:83 brd ff:ff:ff:ff:ff:ff
root@dali:~# logger -t adhoc end: bring up lan1 port
The extracted PHY traces from the system log are below:
root@dali:~# sed -ne '/adhoc: begin:/,/adhoc: end:/p' /var/log/messages
Nov 1 12:00:54 (none) user.notice adhoc: begin: bring up lan1 port
Nov 1 12:00:54 (none) user.info kernel: [ 64.087971] mv88e6085
stmmac-0:1a lan1: configuring for phy/gmii link mode
Nov 1 12:00:54 (none) user.debug kernel: [ 64.094872] mv88e6085
stmmac-0:1a lan1: phylink_resolve_flow: link config MLO_PAUSE_AN: set
Nov 1 12:00:54 (none) user.debug kernel: [ 64.094882] mv88e6085
stmmac-0:1a lan1: phylink_resolve_flow: setting pause=10
Nov 1 12:00:54 (none) user.debug kernel: [ 64.094898] mv88e6085
stmmac-0:1a lan1: phylink_mac_config: mode=phy/gmii/Unknown/Unknown
adv=00,00000000,000022ef pause=10 link=0 an=1
Nov 1 12:00:54 (none) user.debug kernel: [ 64.094912]
dsa_port_phylink_mac_config: config type=0, mode=0, interface="gmii",
speed=-1, duplex=255, pause=16, link=0 an_enabled=1 an_complete=0
Nov 1 12:00:54 (none) user.debug kernel: [ 64.094918]
dsa_port_phylink_mac_config: switch=0, port=0 "lan1"
Nov 1 12:00:54 (none) user.debug kernel: [ 64.094923]
dsa_port_phylink_mac_config: calling switch op phylink_mac_config
Nov 1 12:00:54 (none) user.info kernel: [ 64.094929]
mv88e6xxx_mac_config: switch=0, port=0, mode=0x0
Nov 1 12:00:54 (none) user.info kernel: [ 64.100563]
mv88e6xxx_mac_config: skip MAC config for internal PHY
Nov 1 12:00:54 (none) user.debug kernel: [ 64.106754]
phylink_run_resolve: phylink_disable_state==false, dispatch
system_power_efficient_wq
Nov 1 12:00:54 (none) user.debug kernel: [ 64.106803] mv88e6085
stmmac-0:1a lan1: phylink_resolve: link_an_mode=phy
Nov 1 12:00:54 (none) user.debug kernel: [ 64.106814] mv88e6085
stmmac-0:1a lan1: phylink_resolve_flow: link config MLO_PAUSE_AN: set
Nov 1 12:00:54 (none) user.debug kernel: [ 64.106823] mv88e6085
stmmac-0:1a lan1: phylink_resolve_flow: setting pause=00
Nov 1 12:00:54 (none) user.debug kernel: [ 64.106832] mv88e6085
stmmac-0:1a lan1: phylink_resolve: have netdev, link_changed=0
Nov 1 12:00:54 (none) daemon.info avahi-daemon[529]: Joining mDNS
multicast group on interface lan1.IPv4 with address 192.0.2.1.
Nov 1 12:00:54 (none) user.debug kernel: [ 64.108923] libphy:
genphy_resume: phy_clear_bits returns 0x0
Nov 1 12:00:54 (none) user.info kernel: [ 64.109285] 8021q: adding
VLAN 0 to HW filter on device lan1
Nov 1 12:00:54 (none) daemon.info avahi-daemon[529]: New relevant
interface lan1.IPv4 for mDNS.
Nov 1 12:00:54 (none) daemon.info avahi-daemon[529]: Registering new
address record for 192.0.2.1 on lan1.IPv4.
Nov 1 12:00:54 (none) user.debug kernel: [ 64.119685]
marvell_read_page: id=0x1410eb1(21040817), state=UP, flags=0x0, link=0,
suspended=0, suspended_by_mdio_bus=0, autoneg=1, autoneg_complete=0
Nov 1 12:00:54 (none) user.debug kernel: [ 64.121499]
marvell_read_page: __phy_read(phydev, 22) returns 0x0
Nov 1 12:00:54 (none) user.debug kernel: [ 64.121511]
marvell_write_page: id=0x1410eb1(21040817), state=UP, flags=0x0, link=0,
suspended=0, suspended_by_mdio_bus=0, autoneg=1, autoneg_complete=0
Nov 1 12:00:54 (none) user.debug kernel: [ 64.126302]
marvell_write_page: __phy_write(phydev, 22, 2) returns 0x0
Nov 1 12:00:54 (none) user.debug kernel: [ 64.129909]
marvell_write_page: id=0x1410eb1(21040817), state=UP, flags=0x0, link=0,
suspended=0, suspended_by_mdio_bus=0, autoneg=1, autoneg_complete=0
Nov 1 12:00:54 (none) user.debug kernel: [ 64.131711]
marvell_write_page: __phy_write(phydev, 22, 0) returns 0x0
Nov 1 12:00:54 (none) user.debug kernel: [ 64.158548]
m88e1510_config_aneg: set copper page
Nov 1 12:00:54 (none) user.debug kernel: [ 64.160371]
marvell_read_status: read status from copper page
Nov 1 12:00:54 (none) user.debug kernel: [ 64.171227]
phylink_run_resolve: phylink_disable_state==false, dispatch
system_power_efficient_wq
Nov 1 12:00:54 (none) user.debug kernel: [ 64.171247] mv88e6085
stmmac-0:1a lan1: phy link down gmii/1Gbps/Half
Nov 1 12:00:54 (none) user.debug kernel: [ 64.171258] Marvell 88E1540
mv88e6xxx-0:00: PHY state change UP -> NOLINK
Nov 1 12:00:54 (none) user.debug kernel: [ 64.171271] mv88e6085
stmmac-0:1a lan1: phylink_resolve: link_an_mode=phy
Nov 1 12:00:54 (none) user.debug kernel: [ 64.171281] mv88e6085
stmmac-0:1a lan1: phylink_resolve_flow: link config MLO_PAUSE_AN: set
Nov 1 12:00:54 (none) user.debug kernel: [ 64.171290] mv88e6085
stmmac-0:1a lan1: phylink_resolve_flow: setting pause=00
Nov 1 12:00:54 (none) user.debug kernel: [ 64.171298] mv88e6085
stmmac-0:1a lan1: phylink_resolve: have netdev, link_changed=0
Nov 1 12:00:55 (none) user.notice adhoc: end: bring up lan1 port
root@dali:~#
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-07-28 18:07 ` Dario Alcocer
@ 2021-07-28 18:23 ` Andrew Lunn
2021-07-28 18:33 ` Dario Alcocer
0 siblings, 1 reply; 27+ messages in thread
From: Andrew Lunn @ 2021-07-28 18:23 UTC (permalink / raw)
To: Dario Alcocer; +Cc: netdev
On Wed, Jul 28, 2021 at 11:07:37AM -0700, Dario Alcocer wrote:
> It appears the port link-state issue is caused by the mv88e6xxx switch
> driver. The function mv88e6xxx_mac_config identifies the PHY as internal and
> skips the call to mv88e6xxx_port_setup_mac.
>
> It does not make sense to me why internal PHY configuration should be
> skipped.
The switch should do the configuration itself for internal PHYs. At
least that works for other switches. What value does CMODE have for
the port? 0xf?
Andrew
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-07-28 18:23 ` Andrew Lunn
@ 2021-07-28 18:33 ` Dario Alcocer
2021-07-28 19:24 ` Andrew Lunn
0 siblings, 1 reply; 27+ messages in thread
From: Dario Alcocer @ 2021-07-28 18:33 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
On 7/28/21 11:23 AM, Andrew Lunn wrote:
> On Wed, Jul 28, 2021 at 11:07:37AM -0700, Dario Alcocer wrote:
>> It appears the port link-state issue is caused by the mv88e6xxx switch
>> driver. The function mv88e6xxx_mac_config identifies the PHY as internal and
>> skips the call to mv88e6xxx_port_setup_mac.
>>
>> It does not make sense to me why internal PHY configuration should be
>> skipped.
>
> The switch should do the configuration itself for internal PHYs. At
> least that works for other switches. What value does CMODE have for
> the port? 0xf?
>
> Andrew
>
Is CMODE available via the DSA debugfs? Here are the registers for
port0, which should be lan1:
root@dali:~# ls /sys/kernel/debug/dsa/switch0/
port0/ port1/ port2/ port3/ port4/
port5/ port6/ tag_protocol tree
root@dali:~# ls /sys/kernel/debug/dsa/switch0/port0/
fdb mdb regs stats vlan
root@dali:~# cat /sys/kernel/debug/dsa/switch0/port0/regs
0: 100f
1: 0003
2: 0000
3: 1761
4: 0433
5: 0000
6: 0010
7: 0000
8: 2080
9: 0001
10: 0000
11: 0001
12: 0000
13: 0000
14: 0000
15: 9100
16: 0000
17: 0000
18: 0000
19: 0000
20: 0000
21: 0000
22: 0033
23: 0000
24: 3210
25: 7654
26: 0000
27: 8000
28: 0000
29: 0000
30: 0000
31: 0000
root@dali:~#
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-07-28 18:33 ` Dario Alcocer
@ 2021-07-28 19:24 ` Andrew Lunn
2021-07-28 19:37 ` Dario Alcocer
0 siblings, 1 reply; 27+ messages in thread
From: Andrew Lunn @ 2021-07-28 19:24 UTC (permalink / raw)
To: Dario Alcocer; +Cc: netdev
On Wed, Jul 28, 2021 at 11:33:35AM -0700, Dario Alcocer wrote:
> On 7/28/21 11:23 AM, Andrew Lunn wrote:
> > On Wed, Jul 28, 2021 at 11:07:37AM -0700, Dario Alcocer wrote:
> > > It appears the port link-state issue is caused by the mv88e6xxx switch
> > > driver. The function mv88e6xxx_mac_config identifies the PHY as internal and
> > > skips the call to mv88e6xxx_port_setup_mac.
> > >
> > > It does not make sense to me why internal PHY configuration should be
> > > skipped.
> >
> > The switch should do the configuration itself for internal PHYs. At
> > least that works for other switches. What value does CMODE have for
> > the port? 0xf?
> >
> > Andrew
> >
>
> Is CMODE available via the DSA debugfs? Here are the registers for port0,
> which should be lan1:
>
> root@dali:~# ls /sys/kernel/debug/dsa/switch0/
> port0/ port1/ port2/ port3/ port4/ port5/
> port6/ tag_protocol tree
> root@dali:~# ls /sys/kernel/debug/dsa/switch0/port0/
> fdb mdb regs stats vlan
> root@dali:~# cat /sys/kernel/debug/dsa/switch0/port0/regs
> 0: 100f
It is the lower nibble of this register. So 0xf.
Take a look at:
https://github.com/lunn/mv88e6xxx_dump/blob/master/mv88e6xxx_dump.c
The 1 in 100f means it has found the PHY. But there is no link,
10/Half duplex, etc.
> 1: 0003
This at least looks sensible. Nothing is forced, normal speed
detection should be performed. So what should happen is the link
speed, duplex etc from the internal PHY should directly appear in
register 0. There is no need for software to ask the PHY and then
configure the MAC.
Andrew
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-07-28 19:24 ` Andrew Lunn
@ 2021-07-28 19:37 ` Dario Alcocer
2021-07-28 20:47 ` Andrew Lunn
` (2 more replies)
0 siblings, 3 replies; 27+ messages in thread
From: Dario Alcocer @ 2021-07-28 19:37 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
On 7/28/21 12:24 PM, Andrew Lunn wrote:
> On Wed, Jul 28, 2021 at 11:33:35AM -0700, Dario Alcocer wrote:
>> On 7/28/21 11:23 AM, Andrew Lunn wrote:
>>> On Wed, Jul 28, 2021 at 11:07:37AM -0700, Dario Alcocer wrote:
>>>> It appears the port link-state issue is caused by the mv88e6xxx switch
>>>> driver. The function mv88e6xxx_mac_config identifies the PHY as internal and
>>>> skips the call to mv88e6xxx_port_setup_mac.
>>>>
>>>> It does not make sense to me why internal PHY configuration should be
>>>> skipped.
>>>
>>> The switch should do the configuration itself for internal PHYs. At
>>> least that works for other switches. What value does CMODE have for
>>> the port? 0xf?
>>>
>>> Andrew
>>>
>>
>> Is CMODE available via the DSA debugfs? Here are the registers for port0,
>> which should be lan1:
>>
>> root@dali:~# ls /sys/kernel/debug/dsa/switch0/
>> port0/ port1/ port2/ port3/ port4/ port5/
>> port6/ tag_protocol tree
>> root@dali:~# ls /sys/kernel/debug/dsa/switch0/port0/
>> fdb mdb regs stats vlan
>> root@dali:~# cat /sys/kernel/debug/dsa/switch0/port0/regs
>> 0: 100f
>
> It is the lower nibble of this register. So 0xf.
>
> Take a look at:
>
> https://github.com/lunn/mv88e6xxx_dump/blob/master/mv88e6xxx_dump.c
>
Many thanks for the link; I will build and install it on the target.
Hope it will work with the older kernel (5.4.114) we're using.
> The 1 in 100f means it has found the PHY. But there is no link,
> 10/Half duplex, etc.
>
>> 1: 0003
>
> This at least looks sensible. Nothing is forced, normal speed
> detection should be performed. So what should happen is the link
> speed, duplex etc from the internal PHY should directly appear in
> register 0. There is no need for software to ask the PHY and then
> configure the MAC.
>
Ok, so the internal PHY seems to be configured as expected.
Does this mean that the issue is caused by the link partner?
I did notice that the RJ45 link LED on each of the peer devices no
longer light up. Previously, the LED was coming on. Perhaps it's time to
check the following:
- confirm the network cable for each link peer is good
- confirm each link peer works by connecting to a 100baseT or 1000baseT
switch
Thanks again for all of your feedback!
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-07-28 19:37 ` Dario Alcocer
@ 2021-07-28 20:47 ` Andrew Lunn
2021-07-28 20:54 ` Dario Alcocer
2021-07-28 21:09 ` Andrew Lunn
2021-08-05 21:44 ` Dario Alcocer
2 siblings, 1 reply; 27+ messages in thread
From: Andrew Lunn @ 2021-07-28 20:47 UTC (permalink / raw)
To: Dario Alcocer; +Cc: netdev
> Many thanks for the link; I will build and install it on the target. Hope it
> will work with the older kernel (5.4.114) we're using.
Probably not. You need
commit b71a8d60252111d89dccba92ded7470faef16460
Author: Andrew Lunn <andrew@lunn.ch>
Date: Sun Oct 4 18:12:57 2020 +0200
net: dsa: mv88e6xxx: Add per port devlink regions
Add a devlink region to return the per port registers.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
5.4 we released in 2019-11-24.
When debugging issues like this, you really should be using a modern
kernel. At minimum 5.13, better still, net-next.
Andrew
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-07-28 20:47 ` Andrew Lunn
@ 2021-07-28 20:54 ` Dario Alcocer
0 siblings, 0 replies; 27+ messages in thread
From: Dario Alcocer @ 2021-07-28 20:54 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
On 7/28/21 1:47 PM, Andrew Lunn wrote:
>> Many thanks for the link; I will build and install it on the target. Hope it
>> will work with the older kernel (5.4.114) we're using.
>
> Probably not. You need
>
> commit b71a8d60252111d89dccba92ded7470faef16460
> Author: Andrew Lunn <andrew@lunn.ch>
> Date: Sun Oct 4 18:12:57 2020 +0200
>
> net: dsa: mv88e6xxx: Add per port devlink regions
>
> Add a devlink region to return the per port registers.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> 5.4 we released in 2019-11-24.
>
> When debugging issues like this, you really should be using a modern
> kernel. At minimum 5.13, better still, net-next.
You're absolutely right. The issue is we're relying on the upstream
socfpga Cyclone V kernel, and our custom board requires we rebase our
local fixes.
But, you're right: using net-next is probably what I try next, if commit
b71a8d6025 doesn't resolve this issue.
Thank you very much for all of the feedback!
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-07-28 19:37 ` Dario Alcocer
2021-07-28 20:47 ` Andrew Lunn
@ 2021-07-28 21:09 ` Andrew Lunn
2021-08-05 21:44 ` Dario Alcocer
2 siblings, 0 replies; 27+ messages in thread
From: Andrew Lunn @ 2021-07-28 21:09 UTC (permalink / raw)
To: Dario Alcocer; +Cc: netdev
> I did notice that the RJ45 link LED on each of the peer devices no longer
> light up. Previously, the LED was coming on. Perhaps it's time to check the
> following:
>
> - confirm the network cable for each link peer is good
> - confirm each link peer works by connecting to a 100baseT or 1000baseT
> switch
ethtool --cable-test lan1
Needs a reasonably modern kernel and ethtool :-)
And i don't know if the internal PHYs in that switch actually support
it, and the PHY driver has the needed callbacks for that PHY model.
Andrew
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-07-28 19:37 ` Dario Alcocer
2021-07-28 20:47 ` Andrew Lunn
2021-07-28 21:09 ` Andrew Lunn
@ 2021-08-05 21:44 ` Dario Alcocer
2021-08-06 16:03 ` Dario Alcocer
2021-08-07 17:44 ` Andrew Lunn
2 siblings, 2 replies; 27+ messages in thread
From: Dario Alcocer @ 2021-08-05 21:44 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
On 7/28/21 12:37 PM, Dario Alcocer wrote:
> On 7/28/21 12:24 PM, Andrew Lunn wrote:
>> Take a look at:
>>
>> https://github.com/lunn/mv88e6xxx_dump/blob/master/mv88e6xxx_dump.c
>>
>
> Many thanks for the link; I will build and install it on the target.
> Hope it will work with the older kernel (5.4.114) we're using.
I've got a dumb question: is mv88e6xxx_dump intended to be built on the
target, or do I use a cross compiler?
Unfortunately, the storage available on the target is too limited to
entertain installing autotools, gcc and glibc headers.
On the other hand, the Yocto environment I'm using to cross-compile
target binaries doesn't play nice with respect to kernel-source headers.
In particular, the generic 5.2 uapi/linux/devlink.h provided by the
build environment is missing various DEVLINK_CMD_* and DEVLINK_ATTR_*
enums that prevent compilation of mv88e6xxx_dump.c.
One alternative I investigated was applying the debugfs patch to 5.13.6,
but this resulted in many patch conflicts. Given this situation, it
seems using mv88e6xxx_dump would be the easier path.
Regarding the original problem, using 5.13.6 no longer results in
LOWERLAYERDOWN being reported; after a 5-6 second delay when bringing up
the port interface, the switch port comes up. The RJ45 LED on the link
peer turns on. However, pings do not make it to the link peer.
I will need to continue troubleshooting the switch configuration, so
building a working mv88e6xxx_dump seems like the next task for me to tackle.
Thanks in advance for any suggestions you may have.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-08-05 21:44 ` Dario Alcocer
@ 2021-08-06 16:03 ` Dario Alcocer
2021-08-06 23:46 ` Dario Alcocer
2021-08-07 17:44 ` Andrew Lunn
1 sibling, 1 reply; 27+ messages in thread
From: Dario Alcocer @ 2021-08-06 16:03 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
I got mv88e6xxx_dump working by doing the following:
* copying nexthop.h and rtnetlink.h from /usr/include/uapi/linux to
/usr/include/linux
* commenting out the undefined symbol references (see patch below)
diff --git a/desc-devlink.c b/desc-devlink.c
index 820121e..1876b65 100644
--- a/desc-devlink.c
+++ b/desc-devlink.c
@@ -182,24 +182,24 @@ static const struct pretty_nla_desc __attr_desc[] = {
NLATTR_DESC_STRING(DEVLINK_ATTR_FLASH_UPDATE_FILE_NAME),
NLATTR_DESC_STRING(DEVLINK_ATTR_FLASH_UPDATE_COMPONENT),
- NLATTR_DESC_STRING(DEVLINK_ATTR_FLASH_UPDATE_STATUS_MSG),
- NLATTR_DESC_U64(DEVLINK_ATTR_FLASH_UPDATE_STATUS_DONE),
- NLATTR_DESC_U64(DEVLINK_ATTR_FLASH_UPDATE_STATUS_TOTAL),
+ //NLATTR_DESC_STRING(DEVLINK_ATTR_FLASH_UPDATE_STATUS_MSG),
+ //NLATTR_DESC_U64(DEVLINK_ATTR_FLASH_UPDATE_STATUS_DONE),
+ //NLATTR_DESC_U64(DEVLINK_ATTR_FLASH_UPDATE_STATUS_TOTAL),
- NLATTR_DESC_U16(DEVLINK_ATTR_PORT_PCI_PF_NUMBER),
- NLATTR_DESC_U16(DEVLINK_ATTR_PORT_PCI_VF_NUMBER),
+ //NLATTR_DESC_U16(DEVLINK_ATTR_PORT_PCI_PF_NUMBER),
+ //NLATTR_DESC_U16(DEVLINK_ATTR_PORT_PCI_VF_NUMBER),
//DEVLINK_ATTR_STATS, /* nested */
- NLATTR_DESC_STRING(DEVLINK_ATTR_TRAP_NAME),
- NLATTR_DESC_U8(DEVLINK_ATTR_TRAP_ACTION),
- NLATTR_DESC_U8(DEVLINK_ATTR_TRAP_TYPE),
- NLATTR_DESC_FLAG(DEVLINK_ATTR_TRAP_GENERIC),
+ //NLATTR_DESC_STRING(DEVLINK_ATTR_TRAP_NAME),
+ //NLATTR_DESC_U8(DEVLINK_ATTR_TRAP_ACTION),
+ //NLATTR_DESC_U8(DEVLINK_ATTR_TRAP_TYPE),
+ //NLATTR_DESC_FLAG(DEVLINK_ATTR_TRAP_GENERIC),
//DEVLINK_ATTR_TRAP_METADATA, /* nested */
- NLATTR_DESC_STRING(DEVLINK_ATTR_TRAP_GROUP_NAME),
+ //NLATTR_DESC_STRING(DEVLINK_ATTR_TRAP_GROUP_NAME),
- NLATTR_DESC_U8(DEVLINK_ATTR_RELOAD_FAILED),
- NLATTR_DESC_U64(DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TS_NS),
+ //NLATTR_DESC_U8(DEVLINK_ATTR_RELOAD_FAILED),
+ //NLATTR_DESC_U64(DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TS_NS),
};
const struct pretty_nlmsg_desc devlink_msg_desc[] = {
@@ -264,16 +264,16 @@ const struct pretty_nlmsg_desc devlink_msg_desc[] = {
NLMSG_DESC(DEVLINK_CMD_HEALTH_REPORTER_DUMP_GET, attr),
NLMSG_DESC(DEVLINK_CMD_HEALTH_REPORTER_DUMP_CLEAR, attr),
NLMSG_DESC(DEVLINK_CMD_FLASH_UPDATE, attr),
- NLMSG_DESC(DEVLINK_CMD_FLASH_UPDATE_END, attr),
- NLMSG_DESC(DEVLINK_CMD_FLASH_UPDATE_STATUS, attr),
- NLMSG_DESC(DEVLINK_CMD_TRAP_GET, attr),
- NLMSG_DESC(DEVLINK_CMD_TRAP_SET, attr),
- NLMSG_DESC(DEVLINK_CMD_TRAP_NEW, attr),
- NLMSG_DESC(DEVLINK_CMD_TRAP_DEL, attr),
- NLMSG_DESC(DEVLINK_CMD_TRAP_GROUP_GET, attr),
- NLMSG_DESC(DEVLINK_CMD_TRAP_GROUP_SET, attr),
- NLMSG_DESC(DEVLINK_CMD_TRAP_GROUP_NEW, attr),
- NLMSG_DESC(DEVLINK_CMD_TRAP_GROUP_DEL, attr),
+ //NLMSG_DESC(DEVLINK_CMD_FLASH_UPDATE_END, attr),
+ //NLMSG_DESC(DEVLINK_CMD_FLASH_UPDATE_STATUS, attr),
+ //NLMSG_DESC(DEVLINK_CMD_TRAP_GET, attr),
+ //NLMSG_DESC(DEVLINK_CMD_TRAP_SET, attr),
+ //NLMSG_DESC(DEVLINK_CMD_TRAP_NEW, attr),
+ //NLMSG_DESC(DEVLINK_CMD_TRAP_DEL, attr),
+ //NLMSG_DESC(DEVLINK_CMD_TRAP_GROUP_GET, attr),
+ //NLMSG_DESC(DEVLINK_CMD_TRAP_GROUP_SET, attr),
+ //NLMSG_DESC(DEVLINK_CMD_TRAP_GROUP_NEW, attr),
+ //NLMSG_DESC(DEVLINK_CMD_TRAP_GROUP_DEL, attr),
};
const unsigned int devlink_msg_n_desc = ARRAY_SIZE(devlink_msg_desc);
diff --git a/mv88e6xxx_dump.c b/mv88e6xxx_dump.c
index 09a67c1..a744a74 100644
--- a/mv88e6xxx_dump.c
+++ b/mv88e6xxx_dump.c
@@ -220,17 +220,17 @@ static const enum mnl_attr_data_type
devlink_policy[DEVLINK_ATTR_MAX + 1] = {
[DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TS] = MNL_TYPE_U64,
[DEVLINK_ATTR_HEALTH_REPORTER_GRACEFUL_PERIOD] = MNL_TYPE_U64,
[DEVLINK_ATTR_FLASH_UPDATE_COMPONENT] = MNL_TYPE_STRING,
- [DEVLINK_ATTR_FLASH_UPDATE_STATUS_MSG] = MNL_TYPE_STRING,
- [DEVLINK_ATTR_FLASH_UPDATE_STATUS_DONE] = MNL_TYPE_U64,
- [DEVLINK_ATTR_FLASH_UPDATE_STATUS_TOTAL] = MNL_TYPE_U64,
- [DEVLINK_ATTR_STATS] = MNL_TYPE_NESTED,
- [DEVLINK_ATTR_TRAP_NAME] = MNL_TYPE_STRING,
- [DEVLINK_ATTR_TRAP_ACTION] = MNL_TYPE_U8,
- [DEVLINK_ATTR_TRAP_TYPE] = MNL_TYPE_U8,
- [DEVLINK_ATTR_TRAP_GENERIC] = MNL_TYPE_FLAG,
- [DEVLINK_ATTR_TRAP_METADATA] = MNL_TYPE_NESTED,
- [DEVLINK_ATTR_TRAP_GROUP_NAME] = MNL_TYPE_STRING,
- [DEVLINK_ATTR_RELOAD_FAILED] = MNL_TYPE_U8,
+ //[DEVLINK_ATTR_FLASH_UPDATE_STATUS_MSG] = MNL_TYPE_STRING,
+ //[DEVLINK_ATTR_FLASH_UPDATE_STATUS_DONE] = MNL_TYPE_U64,
+ //[DEVLINK_ATTR_FLASH_UPDATE_STATUS_TOTAL] = MNL_TYPE_U64,
+ //[DEVLINK_ATTR_STATS] = MNL_TYPE_NESTED,
+ //[DEVLINK_ATTR_TRAP_NAME] = MNL_TYPE_STRING,
+ //[DEVLINK_ATTR_TRAP_ACTION] = MNL_TYPE_U8,
+ //[DEVLINK_ATTR_TRAP_TYPE] = MNL_TYPE_U8,
+ //[DEVLINK_ATTR_TRAP_GENERIC] = MNL_TYPE_FLAG,
+ //[DEVLINK_ATTR_TRAP_METADATA] = MNL_TYPE_NESTED,
+ //[DEVLINK_ATTR_TRAP_GROUP_NAME] = MNL_TYPE_STRING,
+ //[DEVLINK_ATTR_RELOAD_FAILED] = MNL_TYPE_U8,
};
static int attr_cb(const struct nlattr *attr, void *data)
^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-08-06 16:03 ` Dario Alcocer
@ 2021-08-06 23:46 ` Dario Alcocer
2021-08-07 18:57 ` Andrew Lunn
0 siblings, 1 reply; 27+ messages in thread
From: Dario Alcocer @ 2021-08-06 23:46 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
Andrew,
Using 5.13.8 resolves the LOWERLAYERDOWN issue I observed when bringing
up a slave interface on 5.4.114. The interface comes up after a
15-second delay, with the Marvell PHY driver reporting a downshift event:
root@dali:~# ip addr add 192.0.2.1/24 dev lan1
root@dali:~# ip link set lan1 up
[ 264.992698] socfpga-dwmac ff700000.ethernet eth0: Register
MEM_TYPE_PAGE_POOL RxQ-0
[ 264.997303] socfpga-dwmac ff700000.ethernet eth0: No Safety Features
support found
[ 264.998167] socfpga-dwmac ff700000.ethernet eth0: IEEE 1588-2008
Advanced Timestamp supported
[ 264.999357] socfpga-dwmac ff700000.ethernet eth0: registered PTP clock
[ 265.000804] socfpga-dwmac ff700000.ethernet eth0: configuring for
fixed/gmii link mode
[ 265.002542] socfpga-dwmac ff700000.ethernet eth0: Link is Up -
1Gbps/Full - flow control rx/tx
[ 265.007121] mv88e6085 stmmac-0:1a lan1: configuring for phy/gmii link
mode
[ 265.015320] 8021q: adding VLAN 0 to HW filter on device lan1
[ 265.016921] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
root@dali:~# [ 280.856989] Marvell 88E1540 mv88e6xxx-0:00: Downshift
occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[ 280.858797] mv88e6085 stmmac-0:1a lan1: Link is Up - 100Mbps/Full -
flow control rx/tx
[ 280.859713] IPv6: ADDRCONF(NETDEV_CHANGE): lan1: link becomes ready
Unfortunately, the single-port DSA configuration showcase example (from
Documentation/networking/dsa/configuration.rst) still does not pass ICMP
via the lan1 port:
root@dali:~# ping 192.0.2.2
PING 192.0.2.2 (192.0.2.2): 56 data bytes
^C
--- 192.0.2.2 ping statistics ---
12 packets transmitted, 0 packets received, 100% packet loss
root@dali:~#
Running tcpdump indicates ARP packets are sent to eth0, but the lan1
link peer does not reply:
root@dali:~# tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:15:11.248264 MEDSA 1.1:0: IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from ea:38:64:39:ee:b2 (oui Unknown), length 548
12:15:13.805980 MEDSA 0.0:0: ARP, Request who-has 192.0.2.2 tell
192.0.2.1, length 28
12:15:14.849210 MEDSA 0.0:0: ARP, Request who-has 192.0.2.2 tell
192.0.2.1, length 28
12:15:15.889193 MEDSA 0.0:0: ARP, Request who-has 192.0.2.2 tell
192.0.2.1, length 28
12:15:16.238290 MEDSA 1.1:0: IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from ea:38:64:39:ee:b2 (oui Unknown), length 548
12:15:17.806438 MEDSA 0.0:0: ARP, Request who-has 192.0.2.2 tell
192.0.2.1, length 28
12:15:18.849208 MEDSA 0.0:0: ARP, Request who-has 192.0.2.2 tell
192.0.2.1, length 28
12:15:19.889200 MEDSA 0.0:0: ARP, Request who-has 192.0.2.2 tell
192.0.2.1, length 28
12:15:21.238306 MEDSA 1.1:0: IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from ea:38:64:39:ee:b2 (oui Unknown), length 548
12:15:21.806994 MEDSA 0.0:0: ARP, Request who-has 192.0.2.2 tell
192.0.2.1, length 28
12:15:22.849200 MEDSA 0.0:0: ARP, Request who-has 192.0.2.2 tell
192.0.2.1, length 28
12:15:23.889195 MEDSA 0.0:0: ARP, Request who-has 192.0.2.2 tell
192.0.2.1, length 28
12:15:26.238330 MEDSA 1.1:0: IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from ea:38:64:39:ee:b2 (oui Unknown), length 548
12:15:31.238361 MEDSA 1.1:0: IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from ea:38:64:39:ee:b2 (oui Unknown), length 548
12:15:31.259217 IP6 fe80::801d:a3ff:fea2:b66b > ip6-allrouters: ICMP6,
router solicitation, length 16
12:15:36.238375 MEDSA 1.1:0: IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from ea:38:64:39:ee:b2 (oui Unknown), length 548
12:15:50.405148 MEDSA 1.0:0: IP6 fe80::b8de:29ff:fed8:d469 >
ip6-allrouters: ICMP6, router solicitation, length 16
12:15:52.234783 MEDSA 1.0:0: IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from ba:de:29:d8:d4:69 (oui Unknown), length 548
12:15:57.235155 MEDSA 1.0:0: IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from ba:de:29:d8:d4:69 (oui Unknown), length 548
12:16:01.969215 MEDSA 0.0:0: IP6 fe80::801d:a3ff:fea2:b66b >
ip6-allrouters: ICMP6, router solicitation, length 16
12:16:02.234543 MEDSA 1.0:0: IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from ba:de:29:d8:d4:69 (oui Unknown), length 548
12:16:07.234883 MEDSA 1.0:0: IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from ba:de:29:d8:d4:69 (oui Unknown), length 548
^C
22 packets captured[ 977.987343] device eth0 left promiscuous mode
2
22 packets received by filter
0 packets dropped by kernel
root@dali:~#
Running tcpdump on the link peer shows no Ethernet frames are being
received.
Port registers for both switches:
root@dali:~# mv88e6xxx_dump --list
mdio_bus/stmmac-0:1a
mdio_bus/stmmac-0:1e
root@dali:~# mv88e6xxx_dump --ports --device mdio_bus/stmmac-0:1a
0 1 2 3 4 5 6
00 Port status 9d0f 100f 100f 100f 1e0f 0009 0d04
01 Physical control 0003 0003 0003 0003 003e 0003 0003
02 Jamming control 0000 0000 0000 ff00 0000 ff00 ff00
03 Switch ID 1761 1761 1761 1761 1761 1761 1761
04 Port control 043f 043f 043f 007c 053f 007c 007c
05 Port control 1 0000 0000 0000 0000 8000 0000 0000
06 Port base VLAN map 0010 0010 0010 0077 006f 005f 003f
07 Def VLAN ID & Prio 0000 0000 0000 0001 0000 0001 0001
08 Port control 2 0080 0080 0080 2080 0080 2080 2080
09 Egress rate control 0001 0001 0001 0001 0001 0001 0001
0a Egress rate control 2 0000 0000 0000 8000 0000 8000 8000
0b Port association vec 0000 0000 0000 0008 0010 0020 0040
0c Port ATU control 0000 0000 0000 0000 0000 0000 0000
0d Override 0000 0000 0000 0000 0000 0000 0000
0e Policy control 0000 0000 0000 0000 0000 0000 0000
0f Port ether type 9100 9100 9100 9100 9100 9100 9100
10 In discard low 0000 0000 0000 0000 0000 0000 0000
11 In discard high 0000 0000 0000 0000 0000 0000 0000
12 In filtered 0000 0000 0000 0000 0000 0000 0000
13 RX frame count 0105 0000 0000 0000 0000 0000 0000
14 Reserved 0000 0000 0000 0000 0000 0000 0000
15 Reserved 0000 0000 0000 0000 0000 0000 0000
16 LED control 0033 0033 0033 0033 0033 0033 0000
17 Reserved 0000 0000 0000 0000 0000 0000 0000
18 Tag remap low 3210 3210 3210 3210 3210 3210 3210
19 Tag remap high 7654 7654 7654 7654 7654 7654 7654
1a Reserved 0000 0000 0000 0000 0000 0000 0000
1b Queue counters 8000 8000 8000 8000 8000 8000 8000
1c Reserved 0000 0000 0000 0000 0000 0000 0000
1d Reserved 0000 0000 0000 0000 0000 0000 0000
1e Reserved 0000 0000 0000 0000 0000 0000 0000
1f Reserved 0000 0000 0000 0000 0000 0000 0000
root@dali:~# mv88e6xxx_dump --ports --device mdio_bus/stmmac-0:1e
0 1 2 3 4 5 6
00 Port status 1d0f 1d0f 100f 100f 1e0f 0009 0e03
01 Physical control 0003 0003 0003 0003 003e 0003 003e
02 Jamming control 0000 0000 ff00 ff00 0000 ff00 0000
03 Switch ID 1761 1761 1761 1761 1761 1761 1761
04 Port control 043f 043f 007c 007c 053f 007c 373f
05 Port control 1 0000 0000 0000 0000 8000 0000 0000
06 Port base VLAN map 0050 0050 007b 0077 006f 005f 003f
07 Def VLAN ID & Prio 0000 0000 0001 0001 0000 0001 0000
08 Port control 2 0080 0080 2080 2080 0080 2080 0080
09 Egress rate control 0001 0001 0001 0001 0001 0001 0001
0a Egress rate control 2 0000 0000 8000 8000 0000 8000 0000
0b Port association vec 0000 0000 0004 0008 0010 0020 0040
0c Port ATU control 0000 0000 0000 0000 0000 0000 0000
0d Override 0000 0000 0000 0000 0000 0000 0000
0e Policy control 0000 0000 0000 0000 0000 0000 0000
0f Port ether type 9100 9100 9100 9100 9100 9100 dada
10 In discard low 0000 0000 0000 0000 0000 0000 0000
11 In discard high 0000 0000 0000 0000 0000 0000 0000
12 In filtered 0000 0000 0000 0000 0000 0000 0000
13 RX frame count 010a 00d5 0000 0000 0000 0000 0073
14 Reserved 0000 0000 0000 0000 0000 0000 0000
15 Reserved 0000 0000 0000 0000 0000 0000 0000
16 LED control 0033 0033 0033 0033 0033 0033 0000
17 Reserved 0000 0000 0000 0000 0000 0000 0000
18 Tag remap low 3210 3210 3210 3210 3210 3210 3210
19 Tag remap high 7654 7654 7654 7654 7654 7654 7654
1a Reserved 0000 0000 0000 0000 0000 0000 0000
1b Queue counters 8000 8000 8000 8000 8000 8000 8000
1c Reserved 0000 0000 0000 0000 0000 0000 0000
1d Reserved 0000 0000 0000 0000 0000 0000 0000
1e Reserved 0000 0000 0000 0000 0000 0000 0000
1f Reserved 0000 0000 0000 0000 0000 0000 0000
Detailed info from switch 0, port 0, corresponding to lan1 port:
root@dali:~# mv88e6xxx_dump --port 0 --device mdio_bus/stmmac-0:1a
00 Port status 0x9d0f
Pause Enabled 1
My Pause 0
802.3 PHY Detected 1
Link Status Up
Duplex Full
Speed 100 or 200 Mbps
EEE Enabled 0
Transmitter Paused 0
Flow Control 0
Config Mode 0xf
01 Physical control 0x0003
RGMII Receive Timing Control Default
RGMII Transmit Timing Control Default
200 BASE Mode 100
Flow Control's Forced value 0
Force Flow Control 0
Link's Forced value Down
Force Link 0
Duplex's Forced value Half
Force Duplex 0
Force Speed Not forced
02 Jamming control 0x0000
03 Switch ID 0x1761
04 Port control 0x043f
Source Address Filtering controls Disabled
Egress Mode Unmodified
Ingress & Egress Header Mode 0
IGMP and MLD Snooping 1
Frame Mode Normal
VLAN Tunnel 0
TagIfBoth 0
Initial Priority assignment Tag & IP Priority
Egress Flooding mode Allow unknown DA
Port State Forwarding
05 Port control 1 0x0000
Message Port 0
Trunk Port 0
Trunk ID 0
FID[11:4] 0x000
06 Port base VLAN map 0x0010
FID[3:0] 0x000
VLANTable 4
07 Def VLAN ID & Prio 0x0000
Default Priority 0x0
Force to use Default VID 0
Default VLAN Identifier 0
08 Port control 2 0x0080
Force good FCS in the frame 0
Jumbo Mode 1522
802.1QMode Disabled
Discard Tagged Frames 0
Discard Untagged Frames 0
Map using DA hits 1
ARP Mirror enable 0
Egress Monitor Source Port 0
Ingress Monitor Source Port 0
Use Default Queue Priority 0
Default Queue Priority 0x0
09 Egress rate control 0x0001
0a Egress rate control 2 0x0000
0b Port association vec 0x0000
0c Port ATU control 0x0000
0d Override 0x0000
0e Policy control 0x0000
0f Port ether type 0x9100
10 In discard low 0x0000
11 In discard high 0x0000
12 In filtered 0x0000
13 RX frame count 0x010d
14 Reserved 0x0000
15 Reserved 0x0000
16 LED control 0x0033
17 Reserved 0x0000
18 Tag remap low 0x3210
19 Tag remap high 0x7654
1a Reserved 0x0000
1b Queue counters 0x8000
1c Reserved 0x0000
1d Reserved 0x0000
1e Reserved 0x0000
1f Reserved 0x0000
Detailed info for switch 0, port 4 and switch 1, port 4, which are the
DSA ports for both switches, using a SERDES link:
root@dali:~# mv88e6xxx_dump --port 4 --device mdio_bus/stmmac-0:1a
00 Port status 0x1e0f
Pause Enabled 0
My Pause 0
802.3 PHY Detected 1
Link Status Up
Duplex Full
Speed 1000 Mbps
EEE Enabled 0
Transmitter Paused 0
Flow Control 0
Config Mode 0xf
01 Physical control 0x003e
RGMII Receive Timing Control Default
RGMII Transmit Timing Control Default
200 BASE Mode 100
Flow Control's Forced value 0
Force Flow Control 0
Link's Forced value Up
Force Link 1
Duplex's Forced value Full
Force Duplex 1
Force Speed 1000 Mbps
02 Jamming control 0x0000
03 Switch ID 0x1761
04 Port control 0x053f
Source Address Filtering controls Disabled
Egress Mode Unmodified
Ingress & Egress Header Mode 0
IGMP and MLD Snooping 1
Frame Mode DSA
VLAN Tunnel 0
TagIfBoth 0
Initial Priority assignment Tag & IP Priority
Egress Flooding mode Allow unknown DA
Port State Forwarding
05 Port control 1 0x8000
Message Port 1
Trunk Port 0
Trunk ID 0
FID[11:4] 0x000
06 Port base VLAN map 0x006f
FID[3:0] 0x000
VLANTable 0 1 2 3 5 6
07 Def VLAN ID & Prio 0x0000
Default Priority 0x0
Force to use Default VID 0
Default VLAN Identifier 0
08 Port control 2 0x0080
Force good FCS in the frame 0
Jumbo Mode 1522
802.1QMode Disabled
Discard Tagged Frames 0
Discard Untagged Frames 0
Map using DA hits 1
ARP Mirror enable 0
Egress Monitor Source Port 0
Ingress Monitor Source Port 0
Use Default Queue Priority 0
Default Queue Priority 0x0
09 Egress rate control 0x0001
0a Egress rate control 2 0x0000
0b Port association vec 0x0010
0c Port ATU control 0x0000
0d Override 0x0000
0e Policy control 0x0000
0f Port ether type 0x9100
10 In discard low 0x0000
11 In discard high 0x0000
12 In filtered 0x0000
13 RX frame count 0x0000
14 Reserved 0x0000
15 Reserved 0x0000
16 LED control 0x0033
17 Reserved 0x0000
18 Tag remap low 0x3210
19 Tag remap high 0x7654
1a Reserved 0x0000
1b Queue counters 0x8000
1c Reserved 0x0000
1d Reserved 0x0000
1e Reserved 0x0000
1f Reserved 0x0000
root@dali:~# mv88e6xxx_dump --port 4 --device mdio_bus/stmmac-0:1e
00 Port status 0x1e0f
Pause Enabled 0
My Pause 0
802.3 PHY Detected 1
Link Status Up
Duplex Full
Speed 1000 Mbps
EEE Enabled 0
Transmitter Paused 0
Flow Control 0
Config Mode 0xf
01 Physical control 0x003e
RGMII Receive Timing Control Default
RGMII Transmit Timing Control Default
200 BASE Mode 100
Flow Control's Forced value 0
Force Flow Control 0
Link's Forced value Up
Force Link 1
Duplex's Forced value Full
Force Duplex 1
Force Speed 1000 Mbps
02 Jamming control 0x0000
03 Switch ID 0x1761
04 Port control 0x053f
Source Address Filtering controls Disabled
Egress Mode Unmodified
Ingress & Egress Header Mode 0
IGMP and MLD Snooping 1
Frame Mode DSA
VLAN Tunnel 0
TagIfBoth 0
Initial Priority assignment Tag & IP Priority
Egress Flooding mode Allow unknown DA
Port State Forwarding
05 Port control 1 0x8000
Message Port 1
Trunk Port 0
Trunk ID 0
FID[11:4] 0x000
06 Port base VLAN map 0x006f
FID[3:0] 0x000
VLANTable 0 1 2 3 5 6
07 Def VLAN ID & Prio 0x0000
Default Priority 0x0
Force to use Default VID 0
Default VLAN Identifier 0
08 Port control 2 0x0080
Force good FCS in the frame 0
Jumbo Mode 1522
802.1QMode Disabled
Discard Tagged Frames 0
Discard Untagged Frames 0
Map using DA hits 1
ARP Mirror enable 0
Egress Monitor Source Port 0
Ingress Monitor Source Port 0
Use Default Queue Priority 0
Default Queue Priority 0x0
09 Egress rate control 0x0001
0a Egress rate control 2 0x0000
0b Port association vec 0x0010
0c Port ATU control 0x0000
0d Override 0x0000
0e Policy control 0x0000
0f Port ether type 0x9100
10 In discard low 0x0000
11 In discard high 0x0000
12 In filtered 0x0000
13 RX frame count 0x0000
14 Reserved 0x0000
15 Reserved 0x0000
16 LED control 0x0033
17 Reserved 0x0000
18 Tag remap low 0x3210
19 Tag remap high 0x7654
1a Reserved 0x0000
1b Queue counters 0x8000
1c Reserved 0x0000
1d Reserved 0x0000
1e Reserved 0x0000
1f Reserved 0x0000
Detailed info for the CPU port connected to eth0:
root@dali:~# mv88e6xxx_dump --port 6 --device mdio_bus/stmmac-0:1e
00 Port status 0x0e03
Pause Enabled 0
My Pause 0
802.3 PHY Detected 0
Link Status Up
Duplex Full
Speed 1000 Mbps
EEE Enabled 0
Transmitter Paused 0
Flow Control 0
Config Mode 0x3
01 Physical control 0x003e
RGMII Receive Timing Control Default
RGMII Transmit Timing Control Default
200 BASE Mode 100
Flow Control's Forced value 0
Force Flow Control 0
Link's Forced value Up
Force Link 1
Duplex's Forced value Full
Force Duplex 1
Force Speed 1000 Mbps
02 Jamming control 0x0000
03 Switch ID 0x1761
04 Port control 0x373f
Source Address Filtering controls Disabled
Egress Mode Reserved
Ingress & Egress Header Mode 0
IGMP and MLD Snooping 1
Frame Mode Ether Type DSA
VLAN Tunnel 0
TagIfBoth 0
Initial Priority assignment Tag & IP Priority
Egress Flooding mode Allow unknown DA
Port State Forwarding
05 Port control 1 0x0000
Message Port 0
Trunk Port 0
Trunk ID 0
FID[11:4] 0x000
06 Port base VLAN map 0x003f
FID[3:0] 0x000
VLANTable 0 1 2 3 4 5
07 Def VLAN ID & Prio 0x0000
Default Priority 0x0
Force to use Default VID 0
Default VLAN Identifier 0
08 Port control 2 0x0080
Force good FCS in the frame 0
Jumbo Mode 1522
802.1QMode Disabled
Discard Tagged Frames 0
Discard Untagged Frames 0
Map using DA hits 1
ARP Mirror enable 0
Egress Monitor Source Port 0
Ingress Monitor Source Port 0
Use Default Queue Priority 0
Default Queue Priority 0x0
09 Egress rate control 0x0001
0a Egress rate control 2 0x0000
0b Port association vec 0x0040
0c Port ATU control 0x0000
0d Override 0x0000
0e Policy control 0x0000
0f Port ether type 0xdada
10 In discard low 0x0000
11 In discard high 0x0000
12 In filtered 0x0000
13 RX frame count 0x0073
14 Reserved 0x0000
15 Reserved 0x0000
16 LED control 0x0000
17 Reserved 0x0000
18 Tag remap low 0x3210
19 Tag remap high 0x7654
1a Reserved 0x0000
1b Queue counters 0x8000
1c Reserved 0x0000
1d Reserved 0x0000
1e Reserved 0x0000
1f Reserved 0x0000
Finally, here's the DSA info printed during boot:
Jan 1 00:00:08 (none) user.info kernel: [ 1.787590] libphy:
mv88e6xxx SMI: probed
Jan 1 00:00:08 (none) user.info kernel: [ 4.246782] mv88e6085
stmmac-0:1a lan1 (uninitialized): PHY [mv88e6xxx-0:00] driver [Marvell
88E1540] (irq=80)
Jan 1 00:00:08 (none) user.info kernel: [ 4.373236] mv88e6085
stmmac-0:1a lan2 (uninitialized): PHY [mv88e6xxx-0:01] driver [Marvell
88E1540] (irq=81)
Jan 1 00:00:08 (none) user.info kernel: [ 4.488280] mv88e6085
stmmac-0:1a lan3 (uninitialized): PHY [mv88e6xxx-0:02] driver [Marvell
88E1540] (irq=82)
Jan 1 00:00:08 (none) user.info kernel: [ 4.510657] mv88e6085
stmmac-0:1a: configuring for fixed/1000base-x link mode
Jan 1 00:00:08 (none) user.info kernel: [ 4.544236] mv88e6085
stmmac-0:1a: Link is Up - 1Gbps/Full - flow control off
Jan 1 00:00:08 (none) user.info kernel: [ 4.653347] mv88e6085
stmmac-0:1e lan4 (uninitialized): PHY [mv88e6xxx-2:00] driver [Marvell
88E1540] (irq=105)
Jan 1 00:00:08 (none) user.info kernel: [ 4.774293] mv88e6085
stmmac-0:1e dmz (uninitialized): PHY [mv88e6xxx-2:01] driver [Marvell
88E1540] (irq=106)
Jan 1 00:00:08 (none) user.info kernel: [ 4.797851] mv88e6085
stmmac-0:1e: configuring for fixed/1000base-x link mode
Jan 1 00:00:08 (none) user.info kernel: [ 4.823888] mv88e6085
stmmac-0:1e: Link is Up - 1Gbps/Full - flow control off
Jan 1 00:00:08 (none) user.info kernel: [ 4.832086] DSA: tree 0 setup
Any ideas on how to get ICMP working, using the DSA single-port
configuration example, are welcome.
Thanks!
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-08-05 21:44 ` Dario Alcocer
2021-08-06 16:03 ` Dario Alcocer
@ 2021-08-07 17:44 ` Andrew Lunn
1 sibling, 0 replies; 27+ messages in thread
From: Andrew Lunn @ 2021-08-07 17:44 UTC (permalink / raw)
To: Dario Alcocer; +Cc: netdev
On Thu, Aug 05, 2021 at 02:44:32PM -0700, Dario Alcocer wrote:
> On 7/28/21 12:37 PM, Dario Alcocer wrote:
> > On 7/28/21 12:24 PM, Andrew Lunn wrote:
> > > Take a look at:
> > >
> > > https://github.com/lunn/mv88e6xxx_dump/blob/master/mv88e6xxx_dump.c
> > >
> >
> > Many thanks for the link; I will build and install it on the target.
> > Hope it will work with the older kernel (5.4.114) we're using.
>
> I've got a dumb question: is mv88e6xxx_dump intended to be built on the
> target, or do I use a cross compiler?
I've always built it on the target. In order to make kernel
development work easy, i generally use Debian on everything. Sometimes
with a USB stick, or a big MMC card, sometimes NFS root. Once the
kernel works, then i will move to the production environment, which
generally makes a poor development environment, so should be avoided
as much as possible.
It should be possible to cross compile it, since it uses autotools.
Andrew
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-08-06 23:46 ` Dario Alcocer
@ 2021-08-07 18:57 ` Andrew Lunn
2021-08-09 16:28 ` Dario Alcocer
0 siblings, 1 reply; 27+ messages in thread
From: Andrew Lunn @ 2021-08-07 18:57 UTC (permalink / raw)
To: Dario Alcocer; +Cc: netdev
On Fri, Aug 06, 2021 at 04:46:08PM -0700, Dario Alcocer wrote:
> Andrew,
>
> Using 5.13.8 resolves the LOWERLAYERDOWN issue I observed when bringing up a
> slave interface on 5.4.114. The interface comes up after a 15-second delay,
> with the Marvell PHY driver reporting a downshift event:
>
> root@dali:~# ip addr add 192.0.2.1/24 dev lan1
> root@dali:~# ip link set lan1 up
> [ 264.992698] socfpga-dwmac ff700000.ethernet eth0: Register
> MEM_TYPE_PAGE_POOL RxQ-0
> [ 264.997303] socfpga-dwmac ff700000.ethernet eth0: No Safety Features
> support found
> [ 264.998167] socfpga-dwmac ff700000.ethernet eth0: IEEE 1588-2008 Advanced
> Timestamp supported
> [ 264.999357] socfpga-dwmac ff700000.ethernet eth0: registered PTP clock
> [ 265.000804] socfpga-dwmac ff700000.ethernet eth0: configuring for
> fixed/gmii link mode
> [ 265.002542] socfpga-dwmac ff700000.ethernet eth0: Link is Up - 1Gbps/Full
> - flow control rx/tx
> [ 265.007121] mv88e6085 stmmac-0:1a lan1: configuring for phy/gmii link
> mode
> [ 265.015320] 8021q: adding VLAN 0 to HW filter on device lan1
> [ 265.016921] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> root@dali:~# [ 280.856989] Marvell 88E1540 mv88e6xxx-0:00: Downshift
> occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
Humm, interesting. Two things pop to mind:
There is probably something wrong with your hardware. 1G requires 4
working pairs in the cable. If one pair is broken, the PHY will keep
trying to establish link, and fail. It will retry this a number of
times, and then drop to 100Mbps. That only requires 2 working pairs.
So get your hardware person to check the wiring from the switch to the
RJ-45 socket, and your cable.
Does the switch know the port is actually running at 100Mbps?
> Detailed info from switch 0, port 0, corresponding to lan1 port:
>
> root@dali:~# mv88e6xxx_dump --port 0 --device mdio_bus/stmmac-0:1a
> 00 Port status 0x9d0f
> Pause Enabled 1
> My Pause 0
> 802.3 PHY Detected 1
> Link Status Up
> Duplex Full
> Speed 100 or 200 Mbps
> EEE Enabled 0
> Transmitter Paused 0
> Flow Control 0
> Config Mode 0xf
O.K, so it does know the port is running at 100Mbps.
> Any ideas on how to get ICMP working, using the DSA single-port
> configuration example, are welcome.
Take a look at the port statistics. ethtool -S lan1 ? Do the counters
show the packets being sent out? They are probably broadcast packets,
ARP, not unicast ICMP.
Also ethtool -S eth0
At the end of the list, you see statistics for the CPU port.
Andrew
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-08-07 18:57 ` Andrew Lunn
@ 2021-08-09 16:28 ` Dario Alcocer
2021-08-10 20:58 ` Dario Alcocer
0 siblings, 1 reply; 27+ messages in thread
From: Dario Alcocer @ 2021-08-09 16:28 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
On 8/7/21 11:57 AM, Andrew Lunn wrote:
> On Fri, Aug 06, 2021 at 04:46:08PM -0700, Dario Alcocer wrote:
>> Any ideas on how to get ICMP working, using the DSA single-port
>> configuration example, are welcome.
>
> Take a look at the port statistics. ethtool -S lan1 ? Do the counters
> show the packets being sent out? They are probably broadcast packets,
> ARP, not unicast ICMP.
>
> Also ethtool -S eth0
>
> At the end of the list, you see statistics for the CPU port.
>
> Andrew
>
Andrew,
Well, I discovered that what I thought was physically lan1 was actually
lan4, just as you had mentioned in an earlier message. :-)
The ping test is working now with the lan4 link peer.
However, I did notice something interesting in the output from
mv88e6xxx_dump for the DSA ports. Apparently, the SERDES link between
the two switch chips is not passing traffic, since no frames are
received by either chip (note the "RX frame count" values below.)
Interestingly, both DSA ports report link is up, but that may be because :
root@dali:~# mv88e6xxx_dump --port 4 --device mdio_bus/stmmac-0:1a
00 Port status 0x1e0f
Pause Enabled 0
My Pause 0
802.3 PHY Detected 1
Link Status Up
Duplex Full
Speed 1000 Mbps
EEE Enabled 0
Transmitter Paused 0
Flow Control 0
Config Mode 0xf
01 Physical control 0x003e
RGMII Receive Timing Control Default
RGMII Transmit Timing Control Default
200 BASE Mode 100
Flow Control's Forced value 0
Force Flow Control 0
Link's Forced value Up
Force Link 1
Duplex's Forced value Full
Force Duplex 1
Force Speed 1000 Mbps
...
04 Port control 0x053f
Source Address Filtering controls Disabled
Egress Mode Unmodified
Ingress & Egress Header Mode 0
IGMP and MLD Snooping 1
Frame Mode DSA
...
13 RX frame count 0x0000
...
root@dali:~# mv88e6xxx_dump --port 4 --device mdio_bus/stmmac-0:1e
00 Port status 0x1e0f
Pause Enabled 0
My Pause 0
802.3 PHY Detected 1
Link Status Up
Duplex Full
Speed 1000 Mbps
EEE Enabled 0
Transmitter Paused 0
Flow Control 0
Config Mode 0xf
01 Physical control 0x003e
RGMII Receive Timing Control Default
RGMII Transmit Timing Control Default
200 BASE Mode 100
Flow Control's Forced value 0
Force Flow Control 0
Link's Forced value Up
Force Link 1
Duplex's Forced value Full
Force Duplex 1
Force Speed 1000 Mbps
...
04 Port control 0x053f
Source Address Filtering controls Disabled
Egress Mode Unmodified
Ingress & Egress Header Mode 0
IGMP and MLD Snooping 1
Frame Mode DSA
...
13 RX frame count 0x0000
...
This probably explains why the none of the ports on the first chip
(lan1, lan2, and lan3) work when running the ping test.
I will need to check with the hardware folks. The schematic indicates
some DNP parts that may, in fact, have not been installed. ;-)
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-08-09 16:28 ` Dario Alcocer
@ 2021-08-10 20:58 ` Dario Alcocer
2021-08-10 22:13 ` Andrew Lunn
0 siblings, 1 reply; 27+ messages in thread
From: Dario Alcocer @ 2021-08-10 20:58 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
Well, I misread the schematic; the DSA ports are connected via four pins
on each of the MV88E6176 chips (S_RXP, S_RXN, S_TXP, S_TXN):
S_RXP (PHY 0x1E) <---> S_TXP (PHY 0x1A)
S_RXN (PHY 0x1E) <---> S_TXN (PHY 0x1A)
S_TXP (PHY 0x1E) <---> S_RXP (PHY 0x1A)
S_TXN (PHY 0x1E) <---> S_RXN (PHY 0x1A)
As you mentioned before, 1G requires 4 pairs. Thus, it seems that
phy-mode = "1000base-x" and speed = <1000> cannot be used for the SERDES
link.
So far, I've tried phy-mode = "mii" with speed = <100>, with no success.
Are there more appropriate values I should use to configure the SERDES
phy-mode and speed device-tree resources?
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-08-10 20:58 ` Dario Alcocer
@ 2021-08-10 22:13 ` Andrew Lunn
2021-08-11 13:16 ` Dario Alcocer
0 siblings, 1 reply; 27+ messages in thread
From: Andrew Lunn @ 2021-08-10 22:13 UTC (permalink / raw)
To: Dario Alcocer; +Cc: netdev
On Tue, Aug 10, 2021 at 01:58:21PM -0700, Dario Alcocer wrote:
> Well, I misread the schematic; the DSA ports are connected via four pins on
> each of the MV88E6176 chips (S_RXP, S_RXN, S_TXP, S_TXN):
>
> S_RXP (PHY 0x1E) <---> S_TXP (PHY 0x1A)
> S_RXN (PHY 0x1E) <---> S_TXN (PHY 0x1A)
> S_TXP (PHY 0x1E) <---> S_RXP (PHY 0x1A)
> S_TXN (PHY 0x1E) <---> S_RXN (PHY 0x1A)
>
> As you mentioned before, 1G requires 4 pairs. Thus, it seems that phy-mode =
> "1000base-x" and speed = <1000> cannot be used for the SERDES link.
You are mixing up the link from a MAC to a PHY, and from a PHY over a
cable to another PHY.
An Ethernet cable has 4 pairs, and it is the PHYs job to generate and
receive the signals over these four pairs. How those signals look is
all part of the 802.3 standard, nothing you can configure.
There are a number of different ways you can connect a MAC to a PHY,
or a MAC to another MAC. The generic name for this is MII, Media
Independent Interface. The number of copper tracks between the MAC
and PHY varies. Gigabit MII has around 22 pins, here as Reduced
Gigabit MII has 11 pins. And a SERDES 100Base-X only has 4 pins.
So 1000base-x is correct.
I don't have the datasheet for the 6176, but i assume it is similar to
the 6352. The SERDES can be connected to either port4 or port5. The
S_SEL pin is used to configure this. For the 6352, S_SEL=1 means port
5. You can also configure the port to 100Base-FX or 1000Base-X/SGMII
using the S_MODE pin. S_MODE=1 means 1000Base-X or SGMII.
The CMODE, or Config mode, the lowest nibble of the port status
register, tells you what it is actually using. A value of 0xf means a
copper PHY. 0x8 is 100Base-FX. 0x9 = 1000Base-X, 0x0a = SGMII.
Andrew
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
2021-08-10 22:13 ` Andrew Lunn
@ 2021-08-11 13:16 ` Dario Alcocer
0 siblings, 0 replies; 27+ messages in thread
From: Dario Alcocer @ 2021-08-11 13:16 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
On 8/10/21 3:13 PM, Andrew Lunn wrote:
> On Tue, Aug 10, 2021 at 01:58:21PM -0700, Dario Alcocer wrote:
>> Well, I misread the schematic; the DSA ports are connected via four pins on
>> each of the MV88E6176 chips (S_RXP, S_RXN, S_TXP, S_TXN):
>>
>> S_RXP (PHY 0x1E) <---> S_TXP (PHY 0x1A)
>> S_RXN (PHY 0x1E) <---> S_TXN (PHY 0x1A)
>> S_TXP (PHY 0x1E) <---> S_RXP (PHY 0x1A)
>> S_TXN (PHY 0x1E) <---> S_RXN (PHY 0x1A)
>>
>> As you mentioned before, 1G requires 4 pairs. Thus, it seems that phy-mode =
>> "1000base-x" and speed = <1000> cannot be used for the SERDES link.
>
> You are mixing up the link from a MAC to a PHY, and from a PHY over a
> cable to another PHY.
>
> An Ethernet cable has 4 pairs, and it is the PHYs job to generate and
> receive the signals over these four pairs. How those signals look is
> all part of the 802.3 standard, nothing you can configure.
>
> There are a number of different ways you can connect a MAC to a PHY,
> or a MAC to another MAC. The generic name for this is MII, Media
> Independent Interface. The number of copper tracks between the MAC
> and PHY varies. Gigabit MII has around 22 pins, here as Reduced
> Gigabit MII has 11 pins. And a SERDES 100Base-X only has 4 pins.
>
> So 1000base-x is correct.
Ok, thanks for the explanation. I've put back 1000base-x for the DSA ports.
> I don't have the datasheet for the 6176, but i assume it is similar to
> the 6352. The SERDES can be connected to either port4 or port5. The
> S_SEL pin is used to configure this. For the 6352, S_SEL=1 means port
> 5. You can also configure the port to 100Base-FX or 1000Base-X/SGMII
> using the S_MODE pin. S_MODE=1 means 1000Base-X or SGMII.
>
> The CMODE, or Config mode, the lowest nibble of the port status
> register, tells you what it is actually using. A value of 0xf means a
> copper PHY. 0x8 is 100Base-FX. 0x9 = 1000Base-X, 0x0a = SGMII.
Thanks for this information. It was the key that helped me finally get
the SERDES link working.
The clue was that CMODE == 0x9 for 1000Base-X. I went back to look at
the CMODE dumped for each port from mv88e6xxx_dump, and I noticed that
port 5 had the lower nibble set to 0x9. It was then I realized I had
specified the wrong DSA ports for the SERDES link.
I corrected the error in the DSA device-tree fragment:
@@ -67,10 +67,10 @@
phy-handle = <&switch0phy2>;
};
- switch0port4: port@4 {
- reg = <4>;
+ switch0port5: port@5 {
+ reg = <5>;
phy-mode = "1000base-x";
- link = <&switch1port4>;
+ link = <&switch1port5>;
fixed-link {
speed = <1000>;
full-duplex;
@@ -112,9 +112,9 @@
label = "dmz";
};
- switch1port4: port@4 {
- reg = <4>;
- link = <&switch0port4>;
+ switch1port5: port@5 {
+ reg = <5>;
+ link = <&switch0port5>;
phy-mode = "1000base-x";
fixed-link {
speed = <1000>;
This change is what finally allowed pings to work using the lan1 port.
The register dumps for both DSA ports now show traffic going across the
SERDES link (note the non-zero value for "RX frame count"):
root@dali:~# mv88e6xxx_dump --port 5 mdio_bus/stmmac-0:1a
Using device <mdio_bus/stmmac-0:1a>
00 Port status 0x0e09
Pause Enabled 0
My Pause 0
802.3 PHY Detected 0
Link Status Up
Duplex Full
Speed 1000 Mbps
EEE Enabled 0
Transmitter Paused 0
Flow Control 0
Config Mode 0x9
01 Physical control 0x003e
RGMII Receive Timing Control Default
RGMII Transmit Timing Control Default
200 BASE Mode 100
Flow Control's Forced value 0
Force Flow Control 0
Link's Forced value Up
Force Link 1
Duplex's Forced value Full
Force Duplex 1
Force Speed 1000 Mbps
02 Jamming control 0x0000
03 Switch ID 0x1761
04 Port control 0x053f
Source Address Filtering controls Disabled
Egress Mode Unmodified
Ingress & Egress Header Mode 0
IGMP and MLD Snooping 1
Frame Mode DSA
VLAN Tunnel 0
TagIfBoth 0
Initial Priority assignment Tag & IP Priority
Egress Flooding mode Allow unknown DA
Port State Forwarding
05 Port control 1 0x8000
Message Port 1
Trunk Port 0
Trunk ID 0
FID[11:4] 0x000
06 Port base VLAN map 0x005f
FID[3:0] 0x000
VLANTable 0 1 2 3 4 6
07 Def VLAN ID & Prio 0x0000
Default Priority 0x0
Force to use Default VID 0
Default VLAN Identifier 0
08 Port control 2 0x0080
Force good FCS in the frame 0
Jumbo Mode 1522
802.1QMode Disabled
Discard Tagged Frames 0
Discard Untagged Frames 0
Map using DA hits 1
ARP Mirror enable 0
Egress Monitor Source Port 0
Ingress Monitor Source Port 0
Use Default Queue Priority 0
Default Queue Priority 0x0
09 Egress rate control 0x0001
0a Egress rate control 2 0x0000
0b Port association vec 0x0020
0c Port ATU control 0x0000
0d Override 0x0000
0e Policy control 0x0000
0f Port ether type 0x9100
10 In discard low 0x0000
11 In discard high 0x0000
12 In filtered 0x0000
13 RX frame count 0x01c5
14 Reserved 0x0000
15 Reserved 0x0000
16 LED control 0x0033
17 Reserved 0x0000
18 Tag remap low 0x3210
19 Tag remap high 0x7654
1a Reserved 0x0000
1b Queue counters 0x8000
1c Reserved 0x0000
1d Reserved 0x0000
1e Reserved 0x0000
1f Reserved 0x0000
root@dali:~# mv88e6xxx_dump --port 5 mdio_bus/stmmac-0:1e
Using device <mdio_bus/stmmac-0:1a>
00 Port status 0x0e09
Pause Enabled 0
My Pause 0
802.3 PHY Detected 0
Link Status Up
Duplex Full
Speed 1000 Mbps
EEE Enabled 0
Transmitter Paused 0
Flow Control 0
Config Mode 0x9
01 Physical control 0x003e
RGMII Receive Timing Control Default
RGMII Transmit Timing Control Default
200 BASE Mode 100
Flow Control's Forced value 0
Force Flow Control 0
Link's Forced value Up
Force Link 1
Duplex's Forced value Full
Force Duplex 1
Force Speed 1000 Mbps
02 Jamming control 0x0000
03 Switch ID 0x1761
04 Port control 0x053f
Source Address Filtering controls Disabled
Egress Mode Unmodified
Ingress & Egress Header Mode 0
IGMP and MLD Snooping 1
Frame Mode DSA
VLAN Tunnel 0
TagIfBoth 0
Initial Priority assignment Tag & IP Priority
Egress Flooding mode Allow unknown DA
Port State Forwarding
05 Port control 1 0x8000
Message Port 1
Trunk Port 0
Trunk ID 0
FID[11:4] 0x000
06 Port base VLAN map 0x005f
FID[3:0] 0x000
VLANTable 0 1 2 3 4 6
07 Def VLAN ID & Prio 0x0000
Default Priority 0x0
Force to use Default VID 0
Default VLAN Identifier 0
08 Port control 2 0x0080
Force good FCS in the frame 0
Jumbo Mode 1522
802.1QMode Disabled
Discard Tagged Frames 0
Discard Untagged Frames 0
Map using DA hits 1
ARP Mirror enable 0
Egress Monitor Source Port 0
Ingress Monitor Source Port 0
Use Default Queue Priority 0
Default Queue Priority 0x0
09 Egress rate control 0x0001
0a Egress rate control 2 0x0000
0b Port association vec 0x0020
0c Port ATU control 0x0000
0d Override 0x0000
0e Policy control 0x0000
0f Port ether type 0x9100
10 In discard low 0x0000
11 In discard high 0x0000
12 In filtered 0x0000
13 RX frame count 0x01c5
14 Reserved 0x0000
15 Reserved 0x0000
16 LED control 0x0033
17 Reserved 0x0000
18 Tag remap low 0x3210
19 Tag remap high 0x7654
1a Reserved 0x0000
1b Queue counters 0x8000
1c Reserved 0x0000
1d Reserved 0x0000
1e Reserved 0x0000
1f Reserved 0x0000
Many, many thanks for all the feedback that helped me finally solve this
issue!
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2021-08-11 13:16 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-22 22:55 Marvell switch port shows LOWERLAYERDOWN, ping fails Dario Alcocer
2021-07-23 13:41 ` Andrew Lunn
2021-07-23 18:21 ` Dario Alcocer
2021-07-23 18:25 ` Andrew Lunn
2021-07-23 18:36 ` Dario Alcocer
2021-07-23 21:58 ` Dario Alcocer
2021-07-24 17:34 ` Andrew Lunn
2021-07-25 2:26 ` Dario Alcocer
2021-07-25 2:36 ` Dario Alcocer
2021-07-27 1:39 ` Dario Alcocer
2021-07-28 18:07 ` Dario Alcocer
2021-07-28 18:23 ` Andrew Lunn
2021-07-28 18:33 ` Dario Alcocer
2021-07-28 19:24 ` Andrew Lunn
2021-07-28 19:37 ` Dario Alcocer
2021-07-28 20:47 ` Andrew Lunn
2021-07-28 20:54 ` Dario Alcocer
2021-07-28 21:09 ` Andrew Lunn
2021-08-05 21:44 ` Dario Alcocer
2021-08-06 16:03 ` Dario Alcocer
2021-08-06 23:46 ` Dario Alcocer
2021-08-07 18:57 ` Andrew Lunn
2021-08-09 16:28 ` Dario Alcocer
2021-08-10 20:58 ` Dario Alcocer
2021-08-10 22:13 ` Andrew Lunn
2021-08-11 13:16 ` Dario Alcocer
2021-08-07 17:44 ` Andrew Lunn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).