Having an apparent choice between upgrading my realtek-re-kmod-197.00 to either realtek-re-kmod198-198.00.1402000 or realtek-re-kmod-1100.00.1402000_1 while upgrading from 13.4-RELEASE to 14.2-RELEASE, I chose the latter. But it could not even bring the interface up, let alone make it operable. So I went to realtek-re-kmod198-198.00.1402000 and everything in fine.
I'm NOT having an issue on 14.2-RELEASE. I did need to recompile it, however, for the iflib change. FWIW.
I upgraded my kernel to 14.2-RELEASE on January 1, and I compiled (and tried to use) kmod 1100 on January 2. I'll try recompiling it a little later, but I'm still in the process of upgrading the rest of my ports for 14.2-RELEASE.
The specific Realtek part I have is: vendor=0x10ec device=0x8168 subvendor=0x1458 subdevice=0xe000 RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller
FTR my device is: re0@pci0:2:0:0: class=0x020000 rev=0x05 hdr=0x00 vendor=0x10ec device=0x8125 subvendor=0x1e50 subdevice=0x9001 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8125 2.5GbE Controller' class = network subclass = ethernet
(In reply to George Mitchell from comment #3) RTL8168 supported by re(4) from base: https://man.freebsd.org/cgi/man.cgi?query=re Why do you use re from ports?
Because the base system re(4) driver unpredictably hangs up on my system. See bug #166724.
I have a similar problem with 14.2-STABLE (although the tag is now 14.3); the base driver loads and appears to run however it takes timeouts if and only if an Intel WiFi6 equipped device talks with it at high speed. It watchdog resets itself but this is obviously unsuitable. Disabling txsum/rxsum/txsum6/rxsum6 reduces but does NOT stop the behavior. A Pixel phone (different chipset obviously) does not trigger it. Nor does my desktop on a RealTek 2.5g hardwired card. Attempting to load 098 resulted in a borked interface that would not get an ARP from my upstream internet provider's default route (!!); loading 100 failed to solicit an IP6 address. Neither logged anything amiss, however, and I have no idea if they would reset as without a path outbound..... yeah. Am I headed for only using boxes with Intel interfaces? :-)
(In reply to karl from comment #7) Further commentary -- the prior version does not time out (and seems to be ok - we'll see), but the current version (the subject of this report) appears to be unable to resolve ARPs on non-octet netmasks! Specifically, it won't get outbound to my ISP at all -- and the ISP has a non-octet netmask on the address it assigns me. The internal interface is reachable and works and an attempt to "arp" the default gateway (which I do get from the upstream) fails -- and of course so does anything that's supposed to go there....
(In reply to karl from comment #8) I spoke too soon -- the previous version gets ARPs from my upstream sometimes. Which means after a while the connection dies...... Between the timeouts on the included re driver and the kmod ones dying in even worse ways as they don't trip the watchdog thus they don't restart that's not so good -- at least here.
Disabling checksum offloading "fixes" the problem, if you consider that backward step a fix.
Note that there is a newer version now available: realtek-re-kmod198-198.00.1403000 This one doesn't have the checksum issue but under serious load from iperf3 it displays insane numbers of retries (although no drops and speed is reasonable) *and* has issues with negotiating 2.5Gbps connections.
(In reply to karl from comment #11) realtek-re-kmod198 NEVER had the checksum problem. It's this 1100 version that has the problem. (I've never had problems with realtek-re-kmod198, but I've never tried iperf3.)
(In reply to George Mitchell from comment #12) -198 had all sorts of other issues for me in gateway (dual-NIC, must turn off TSO/LRO on the outside interface) use. So does this latest one in the retry area which is serious in gateway use because it introduces highly-variable latencies on high speed data flows which in turn end up doing quite a bit of damage to end-to-end throughput.
(In reply to karl from comment #13) Admittedly, my network is (usually) not running anywhere near its rated 1Gbps speed, and it has fewer than a dozen devices. So our use cases differ.