3.14 r8152: v1.09.9 TX timeouts when in promiscous mode

[Grant Grundler]

Hayes,
I've updated chromeos 3.14/3.18/4.4 kernels to v1.09.9 r8152 driver
and this problem just started happening on a system that uses
chromeos-3.14:

[ 9122.502558] r8152 2-1.1:1.0 eth0: Promiscuous mode enabled
[ 9132.429971] r8152 2-1.1:1.0 eth0: Tx timeout
[ 9132.497812] usb 2-1.1: reset SuperSpeed USB device number 4 using xhci_hcd
[ 9132.508710] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called
with disabled ep ffff880077eef900
[ 9132.508737] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called
with disabled ep ffff880077eef940
[ 9132.508758] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called
with disabled ep ffff880077eef980

This doesn't happen with the 4.4 backport and I'll assume it's not a
problem upstream either.

I suspect the issue is around how r8152 driver is handling TX packets
when in promiscuous mode and bridge mode turns on promiscuous mode.
The bridge is used to allow containers running on the same host talk
with devices connected to the network behind the RTL USB NIC.

Any suggestions for debugging this?

I've reproduced this with RTL8153 (0x5c20: Linksys, Monoprice) and
RTL8153B (0x6010: unbranded sample devices)

Steps to reproduce:
USB_IFACE='eth1'
DHCPD_IFACE='lxcbr0'
SERVER_ADDRESS=192.168.231.1
SERVER_NETMASK=255.255.255.0

# chromeos specific: kills all dhcpcd instances
stop shill

# setup the bridge with eth1
brctl addbr ${DHCPD_IFACE}
brctl setfd ${DHCPD_IFACE} 0
ifconfig ${DHCPD_IFACE} ${SERVER_ADDRESS} netmask ${SERVER_NETMASK} up
ifconfig ${USB_IFACE} up
brctl addif ${DHCPD_IFACE} ${USB_IFACE}

# restore eth0
start shill BLACKLISTED_DEVICES=${DHCPD_IFACE},$(USB_IFACE}

# confirm br is setup correctly
brctl show lxcbr0

# load it: assumes client on the other end is running netserver
NETPERF=/usr/local/bin/netperf
H=192.168.231.2
$NETPERF -H $H -t TCP_MAERTS -B "RX Mbps" -i 10 -P 0 -v 0 -- -s 256K -S 256K
$NETPERF -H $H -t TCP_STREAM -B "TX Mbps" -i 10 -P 0 -v 0 -- -s 256K -S 256K

[ check dmesg output for TX timeouts. Rx will complete. Tx test will "hang".]


cheers,
grant

[Grant Grundler]

On Tue, Jan 30, 2018 at 12:07 AM, Hayes Wang <haye...@realtek.com> wrote:
> Hi, Grant,
>
> Do you apply the following patch?
> https://patchwork.kernel.org/patch/5572291/

Thank you! I missed that one. :(

I had applied the "support ndo_features_check" patch chromeos-3.18
branch several months before but not to chromeos-3.14:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/350574


I knew one patch was missing from chromeos-3.14 but didn't check for
any others. My bad and thanks for pointing it out.


> You could refer to the following links for the history.
> https://www.spinics.net/lists/netdev/msg306183.html
> https://www.spinics.net/lists/netdev/msg309743.html
> https://www.spinics.net/lists/netdev/msg310721.html

Let me first get the two branches into the same state and then I'll
see what else needs to be done.

cheers!
grant

>
> Best Regards,
> Hayes

> ------Please consider the environment before printing this e-mail.

[Grant Grundler]

On Tue, Jan 30, 2018 at 10:38 AM, Grant Grundler <grun...@chromium.org> wrote:
> On Tue, Jan 30, 2018 at 12:07 AM, Hayes Wang <haye...@realtek.com> wrote:
>> Hi, Grant,
>>
>> Do you apply the following patch?
>> https://patchwork.kernel.org/patch/5572291/
>
> Thank you! I missed that one. :(
>
> I had applied the "support ndo_features_check" patch chromeos-3.18
> branch several months before but not to chromeos-3.14:
> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/350574

Ah - just found out why I didn't port this to 3.14 kernel:
/mnt/host/source/src/third_party/kernel/v3.14/drivers/net/usb/r8152.c:4921:2:
error: unknown field 'ndo_features_check' specified in initializer
.ndo_features_check = rtl8152_features_check,
^
/mnt/host/source/src/third_party/kernel/v3.14/drivers/net/usb/r8152.c:4921:2:
error: initialization from incompatible pointer type [-Werror]

Let me look more closely at what this all does and then I can decide
how to proceed.

cheers,
grant

[Grant Grundler]

On Tue, Jan 30, 2018 at 6:49 PM, Hayes Wang <haye...@realtek.com> wrote:
> Hi,
>

> Maybe you could refer to the attached patch used by realtek vendor driver for the kernel which is earlier than 3.18.

Hayes, Thank you!

That patch was enough of a clue for me to try disabling TSO [1] and
that is sufficient workaround for now. I haven't decided if I should
disable TSO by default for this particular kernel or try to make this
patch work. Either way, the workaround takes away the urgency.

cheers!
grant

[1] ethtool -k eth0 tso off
This ethtool command will fail with other NIC drivers which do not
support TSO.