* 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-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
* 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
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).