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: <20200719235202.6ee120b9@nic.cz>
Date:   Sun, 19 Jul 2020 23:52:02 +0200
From:   Marek Behun <marek.behun@....cz>
To:     Chris Healy <cphealy@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev <netdev@...r.kernel.org>
Subject: Re: bug: net: dsa: mv88e6xxx: serdes Unable to communicate on fiber
 with vf610-zii-dev-rev-c

On Sun, 19 Jul 2020 14:43:49 -0700
Chris Healy <cphealy@...il.com> wrote:

> > Hmm.
> >
> > What about the errata setup?
> > It says:
> > /* The 6390 copper ports have an errata which require poking magic
> >  * values into undocumented hidden registers and then performing a
> >  * software reset.
> >  */
> > But then the port_hidden_write function is called for every port in the
> > function mv88e6390_setup_errata, not just for copper ports. Maybe Chris
> > should try to not write this hidden register for SerDes ports.  
> 
> I just disabled the mv88e6390_setup_errata all together and this did
> not result in any different behaviour on this broken fiber port.

:-( In that case I really have no idea what could be the problem.

Another thing you could try is resoldering resistors on the board so
that the switches configure themselves into NOCPU mode and the port you
are talking about configures itself into the cmode you need
(was it 1000base-x or sgmii?). Disable DSA, write yourself sysfs API
via which you can read/write switch registers by yourself. Then you can
chech if the problem on the RX path occurs. If no, read all the
registers and compare their values with the ones the mv88e6xxx driver
configures. If yes, then we know that the problem is there even if the
switch is NOCPU mode and you can inform Marvell about the bug.

Marek

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ