netdev - Re: Marvell switch port shows LOWERLAYERDOWN, ping fails

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: <11b81662-e9ce-591c-122a-af280f1e1f59@helixd.com>
Date:   Wed, 28 Jul 2021 12:37:14 -0700
From:   Dario Alcocer <dalcocer@...ixd.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org
Subject: Re: Marvell switch port shows LOWERLAYERDOWN, ping fails

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@...i:~# ls /sys/kernel/debug/dsa/switch0/
>> port0/        port1/        port2/        port3/        port4/ port5/
>> port6/        tag_protocol  tree
>> root@...i:~# ls /sys/kernel/debug/dsa/switch0/port0/
>> fdb    mdb    regs   stats  vlan
>> root@...i:~# 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!