From: Andrew Lunn <andrew@lunn•ch>
To: Heiner Kallweit <hkallweit1@gmail•com>
Cc: "Johannes Brandstätter" <jbrandst@2ds•eu>, netdev@vger•kernel.org
Subject: Re: Load on RTL8168g/8111g stalls network for multiple seconds
Date: Tue, 8 Jun 2021 02:11:14 +0200 [thread overview]
Message-ID: <YL61ojQeppA471Lw@lunn.ch> (raw)
In-Reply-To: <a4e4902d-5534-6c66-63f5-d88059604c78@gmail.com>
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
next prev parent reply other threads:[~2021-06-08 0:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-07 13:11 Load on RTL8168g/8111g stalls network for multiple seconds Johannes Brandstätter
2021-06-07 20:39 ` Heiner Kallweit
2021-06-07 20:54 ` Heiner Kallweit
2021-06-08 0:11 ` Andrew Lunn [this message]
2021-07-06 14:43 ` Johannes Brandstätter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YL61ojQeppA471Lw@lunn.ch \
--to=andrew@lunn$(echo .)ch \
--cc=hkallweit1@gmail$(echo .)com \
--cc=jbrandst@2ds$(echo .)eu \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox