netdev - Re: secondary CPU port facing switch does not come up/online

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <eb0b71bb-4df3-ff3e-2424-a0d92b26741a@gmx.net>
Date:   Mon, 22 Jun 2020 07:39:00 +0000
From:   ѽ҉ᶬḳ℠ <vtol@....net>
To:     netdev@...r.kernel.org
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>, marek.behun@....cz
Subject: Re: secondary CPU port facing switch does not come up/online


On 21/06/2020 21:08, Florian Fainelli wrote:
> Le 2020-06-21 à 13:24, ѽ҉ᶬḳ℠ a écrit :
>> {"kernel":"5.4.46","hostname":"OpenWrt","system":"ARMv7 Processor rev 1
>> (v7l)","model":"Turris
>> Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"OpenWrt","version":"SNAPSHOT","revision":"r13600-9a477b833a","target":"mvebu/cortexa9","description":"OpenWrt
>> SNAPSHOT r13600-9a477b833a"}}
>> _____
>>
>> With the below cited DT both CPU ports facing the node's build-in switch
>> are brought online at boot time with kernel 4.14 but since having
>> switched to kernel 5.4 only one CPU port gets online. It is as if the
>> kernel discards the presence of the secondary CPU port. Kernel log only
>> prints for the offline port just a single entry:
>>
>> mvneta f1070000.ethernet eth0: Using hardware mac address
>>
>> Swapping eth1 to port6 and eth0 to port6 then eth0 is brought online but
>> eth1 is not. Removing port5 then the port6 listed port is brought
>> up/online.
>>
>> Once the node is booted the offline port can brought up with ip l set
>> up. This seems like a regression bug in between the kernel versions.
> There can only be one CPU port at a time active right now, so I am not
> sure why it even worked with kernel 4.14.

What is the reasoning, because DSA is not coded to handle multi-ports? 
DSA can be patched downstream (proposed patches to mainline kernel were 
not accepted) and is so is for the 4.14 instance but there is DSA patch 
available for the 5.4 instance yet. That aside I would assume that DSA 
is not in charge of handling the state of the CPU ports but rather PHY 
or PHYLINK?

I understand that dual CPU port chipset design is somewhat unusual but 
it is something unique and therefore a fringe case that is not supported 
by the kernel?

>   Could you please share kernel
> logs and the output of ip link show in both working/non-working cases?

Sure, does the ML accept attachments, if so which format, or you want 
two full kernel logs in the message body? Meantime, the short version:

4.14
dmesg -t | grep mvneta
mvneta f1070000.ethernet eth0: Using hardware mac address d8:58:d7:00:79:7c
mvneta f1030000.ethernet eth1: Using hardware mac address d8:58:d7:00:79:7a
mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:00:79:7b
mvneta f1034000.ethernet eth2: switched to 802.3z/1000base-x link mode
mvneta f1070000.ethernet eth0: configuring for fixed/rgmii link mode
mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
mvneta f1030000.ethernet eth1: Disable IP checksum for MTU greater than 
1600B
mvneta f1030000.ethernet eth1: configuring for fixed/rgmii link mode
mvneta f1030000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
mvneta f1034000.ethernet eth2: Link is Down
mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
mvneta f1034000.ethernet eth2: Link is Down
mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off

5.4
dmesg -t | grep mvneta
mvneta f1070000.ethernet eth0: Using hardware mac address d8:58:d7:00:79:7c
mvneta f1030000.ethernet eth1: Using hardware mac address d8:58:d7:00:79:7a
mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:00:79:7b
mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
mvneta f1030000.ethernet eth1: Disable IP checksum for MTU greater than 
1600B
mvneta f1030000.ethernet eth1: configuring for fixed/rgmii link mode
mvneta f1030000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
mvneta f1034000.ethernet eth2: Link is Down
mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
mvneta f1034000.ethernet eth2: Link is Down
mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off



Download attachment "OpenPGP_0xF4F735931F05C5CE.asc" of type "application/pgp-keys" (3112 bytes)

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (841 bytes)