netdev - Re: Linux kernel hangs if using RV1108 with MSZ8863 switch with two ports connected

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: <20181116234044.GA752@lunn.ch>
Date:   Sat, 17 Nov 2018 00:40:44 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Otavio Salvador <otavio.salvador@...ystems.com.br>
Cc:     netdev@...r.kernel.org, Heiko Stuebner <heiko@...ech.de>,
        david.choi@...rel.com, Andy Yan <andy.yan@...k-chips.com>
Subject: Re: Linux kernel hangs if using RV1108 with MSZ8863 switch with two
 ports connected

On Fri, Nov 16, 2018 at 04:28:29PM -0200, Otavio Salvador wrote:
> Hi,
> 
> I have a custom design based on Rockchip RV1108 that uses an MSZ8863
> switch running kernel 4.19.
> 
> The dts part is as follows:
> 
> &gmac {
> pinctrl-names = "default";
> pinctrl-0 = <&rmii_pins>;
> snps,reset-gpio = <&gpio1 RK_PC1 GPIO_ACTIVE_LOW>;
> snps,reset-active-low;
> clock_in_out = "output";
> status = "okay";
> };
> 
> RV1108 GMAC is connected to KSZ8863 port 3 and after kernel boots, I
> can put an Ethernet cable from my router to the uplink port of
> KSZ8863, which makes the RV1108 board and a Linux PC connected to the
> other KSZ8863 port to both get IP addresses.
> 
> So in this usecase the setup is working fine.
> 
> However, if the RV1108 board boots with both Ethernet cables to the
> KSZ8863 switch connected, then the kernel silently hangs.

Hi Otavio

By silently, you mean it prints nothing at all?

I would try building the kernel with all the lock debugging turned
on. That might find something even with your working case, if there is
a potential deadlock.

If the kernel dies very early, you might need to enable "kernel
low-level debugping print and EARLY_PRINTK, in order to see anything.

	  Andrew