netdev - Re: Load on RTL8168g/8111g stalls network for multiple seconds

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: <YL61ojQeppA471Lw@lunn.ch>
Date:   Tue, 8 Jun 2021 02:11:14 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Heiner Kallweit <hkallweit1@...il.com>
Cc:     Johannes Brandstätter <jbrandst@....eu>,
        netdev@...r.kernel.org
Subject: Re: Load on RTL8168g/8111g stalls network for multiple seconds

On Mon, Jun 07, 2021 at 10:39:06PM +0200, Heiner Kallweit wrote:
> On 07.06.2021 15:11, Johannes Brandstätter wrote:
> > Hi,
> > 
> > just the other day I wanted to set up a bridge between an external 2.5G
> > RTL8156 USB Ethernet adapter (using r8152) and the built in dual
> > RTL8168g/8111g Ethernet chip (using r8169).
> > I compiled the kernel as of 5.13.0-rc4 because of the r8125 supporting
> > the RTL8156.
> > This was done using the Debian kernel config of 5.10.0-4 as a base and
> > left the rest as default.
> > 
> > So this setup was working the way I wanted it to, but unfortunately
> > when running iperf3 against the machine it would rather quickly stall
> > all communications on the internal RTL8168g.
> > I was still able to communicate fine over the external RTL8156 link
> > with the machine.
> > Even without the generated network load, it would occasionally become
> > stalled.
> > 
> > The only information I could really gather were that the rx_missed
> > counter was going up, and this kernel message some time after the stall
> > was happening:
> > 
> > [81853.129107] r8169 0000:02:00.0 enp2s0: rtl_rxtx_empty_cond == 0
> > (loop: 42, delay: 100).
> > 
> > Which has apparently to do with the wait for an empty fifo within the
> > r8169 driver.
> > 
> > Until that the machine (an UP² board) using the RTL8168g ran without
> > any issues for multiple years in different configurations.
> > Only bridging immediately showed the issue when given enough network
> > load.
> > 
> > After many hours of trying out different things, nothing of which
> > showed any difference whatsoever, I tried to replace the internal
> > RTL8168g with an additional external USB Ethernet adapter which I had
> > laying around, having a RTL8153 inside.
> > 
> > Once the RTL8168g was removed and the RTL8153 added to the bridge, I
> > was unable to reproduce the issue.
> > Of course I'd rather like to make use of the two internal Ethernet
> > ports if I somehow can.
> > 
> > So is there anything I could try to do?

Using a bridge means the interface is in promiscuous mode. That is not
something typically used. What could be interesting is keep the
interface out of the bridge, but do:

ip link set [interface] promisc on

Then do some iperf test etc to see if you can reproduce the issue.

     Andrew