RTL8153B very unstable on Orange Pi R1 Plus LTS - Kernel > 6.6.
Description
Orange Pi R1 Plus LTS (rk3328) NIC RTL8153B via internal USB3 is unstable on Kernel > 6.6. This NIC has been problematic since Kernel 5.x but workarounds have been possible. Tweaking the timing on previous timed down up workarounds doesn’t work for >6.6. Firmware is already the latest available.
Symptoms: The NIC appears to be initialized and usually obtains DHCP IP address. The tx_packets counter counts packets transmitted although they are possibly not transmitted, and error counters show no errors, but most comms are not actually succeeding. Ping shows 60% to 100% packet loss.
A reboot will often but not always fix the issue on Jammy.
Via ssh to the other NIC or via TTL, ethtool -r lan0 resolves the issue intermittently. This soft resets the RTL8153B. More often than not the reset is bad. Sometimes it takes three or more resets to get it working (testing between resets so that the next reset doesn’t break it again). Once it is working it continues to work until reboot.
Because I haven’t found a reliable way to programmatically detect the issue, I have not been able to script a reliable workaround.
Orange Pi R1 Plus LTS (rk3328) NIC RTL8153B via internal USB3 is unstable on Kernel > 6.6. This NIC has been problematic since Kernel 5.x but workarounds have been possible. Tweaking the timing on previous timed down up workarounds doesn’t work for >6.6. Firmware is already the latest available.
Symptoms: The NIC appears to be initialized and usually obtains DHCP IP address. The
tx_packetscounter counts packets transmitted although they are possibly not transmitted, and error counters show no errors, but most comms are not actually succeeding. Ping shows 60% to 100% packet loss.A reboot will often but not always fix the issue on Jammy.
Via ssh to the other NIC or via TTL,
ethtool -r lan0resolves the issue intermittently. This soft resets the RTL8153B. More often than not the reset is bad. Sometimes it takes three or more resets to get it working (testing between resets so that the next reset doesn’t break it again). Once it is working it continues to work until reboot.Because I haven’t found a reliable way to programmatically detect the issue, I have not been able to script a reliable workaround.