On 13.12.2018 23:10, Risto Pajula wrote:
>
> On 13.12.2018 6:52, Stephen Hemminger wrote:
>>
>> Did you disable ethernet flow control? Ethernet flow control is
>> usually a bad idea, it can cause head of line blocking. Unfortunately,
>> most devices default to on.
>
> Disable ethernet flow contr
On 13.12.2018 6:52, Stephen Hemminger wrote:
Did you disable ethernet flow control? Ethernet flow control is
usually a bad idea, it can cause head of line blocking. Unfortunately,
most devices default to on.
Disable ethernet flow control from where? The rtl8169 driver does not
support chan
On Thu, 13 Dec 2018 01:20:48 +0200
Risto Pajula wrote:
> Hello.
>
> I'm not able reproduce the actual problem anymore which was the high
> ping latency from the internal network.
>
> This starts to sound like some sort of voodoo, but...
>
> I tested replacing the switch to another brand where
Hello.
I'm not able reproduce the actual problem anymore which was the high
ping latency from the internal network.
This starts to sound like some sort of voodoo, but...
I tested replacing the switch to another brand where internal network
trtl8169 is connected. This did not have any effect
According to your description of the issue it doesn't need a very exotic
scenario to trigger it.
And due to the fact that Realtek network chips are used on a lot of consumer
mainboards, I would
assume quite some people are using such a mainboard for a use case like yours.
This makes it somewhat s
Hello.
I added some debug prints to diagnose the bug properly. I can send the
patches if you are willing to debug/try... for example this output is
produced:
96096: -0 [000] ..s. 232.466703:
rtl8169_start_xmit: RTLDBG221 eth1 rtl8169_start_xmit len: 1506 opts1:
B000 txpol
OK, then another idea .. At the very beginning of the mail thread it
was stated that the router has to network ports:
linux router: Linux computer with Dualcore Intel Celeron G1840, running
currently Linux kernel 4.20.0-rc2, and openSUSE Leap 15.0
eth1: Linux Routers internal (NAT) interface, 192.
Hello.
A freshly built 4.20.0-rc6-next-20181210-lp150.12.25-default waited me
when I got back from work, but unfortunately it did not help at all, it
behaved exactly in same manner.
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 19
Hello.
I have not yet tested with linux-next but I will, thanks for pointing
that out.
...But I have studied the problem a bit more, indeed it seems that the
rtl8169 transmission queue gets stuck.
Below is some trace log. Starting from 802026 a burst of frames is
forwarded from eth0 to eth
Did you test also with the latest linux-next kernel? Some recent changes like
2e6eedb4813e
"r8169: make use of xmit_more and __netdev_sent_queue" may have a positive
impact.
On 10.12.2018 00:28, Risto Pajula wrote:
>
> Hello.
>
> Old subject: "Re: IP fragmentation performance and don't fragmen
Hello.
Old subject: "Re: IP fragmentation performance and don't fragment bug
when forwarding
I have now been tracing the kernel and finding the bug seems difficult.
I think the bug is combination of several things, likely cause is that
it only occurs with rtl8169 and how it is using the n
11 matches
Mail list logo
