Problems with net/realtek-re-kmod and FreeBSD 14.0

Argentum

Argentum

Dear All,

Seems that net/realtek-re-kmod is not working under FreeBSD 14.0.

I have 2 network devices -

Code: 
none0@pci0:2:0:0:       class=0x020000 rev=0x04 hdr=0x00 vendor=0x10ec device=0x8125 subvendor=0x10ec subdevice=0x0123
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8125 2.5GbE Controller'
    class      = network
    subclass   = ethernet
re0@pci0:5:0:0: class=0x020000 rev=0x0c hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x1043 subdevice=0x8554
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet

When loading re driver, installed from ports, neither interfaces will work. Device is recognized, but no traffic goes through. When I load the driver from base, the device=0x8168 works as expected, but the device=0x8125 is not recognized.

In other words, I would like to get the 'RTL8125 2.5GbE Controller' working under FreeBSD 14.0, but have not managed to do so.

What might be the problem?
Any experiences? Any help available?


 
getopt said:
www.freebsd.org

FreeBSD 14.0 Hardware Notes

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.
www.freebsd.org www.freebsd.org
Click to expand...
I do not see any help there. I do understand that RTL8125 is not supported by the base system. However the kernel module built from ports should support this device

net/realtek-re-kmod

Code: 
Realtek PCIe FE / GBE / 2.5G / 5G Ethernet Family Controller
kernel driver.

This is the official driver from Realtek with a few patches to
improve stability and performance. It can be loaded instead of
the FreeBSD driver built into the GENERIC kernel if you experience
issues with it (eg. watchdog timeouts), or your card is not supported.

Supported devices:

* 5G Gigabit Ethernet
  - RTL8126

* 2.5G Gigabit Ethernet
  - RTL8125 / RTL8125B(G)

* 10/100/1000M Gigabit Ethernet
  - RTL8111B / RTL8111C / RTL8111D / RTL8111E / RTL8111F / RTL8111G
    RTL8111H / RTL8118(A) / RTL8119i / RTL8111L / RTL8111K
  - RTL8168B / RTL8168E / RTL8168H
  - RTL8111DP / RTL8111EP(P) / RTL8111FP
  - RTL8411 / RTL8411B

* 10/100M Fast Ethernet
  - RTL8101E / RTL8102E / RTL8103E / RTL8105E / RTL8106E / RTL8107E
  - RTL8401 / RTL8402

There are no error messages, the driver is loaded and recognizes the device, but no traffic goes through. Also the driver from ports does not work with the other device - device=0x8168.

I am asking for help and experiences, not actually these hardware notes.
 
I have the same problem. 1.98 works fine, no traffic in 1.99 goes through. FreeBSD 13.2, Realtek 8125.

Is there a way to download the latest version in the 1.98 line from somewhere? I don't have it in the local cache.
 
Argentum said:
Seems similar, but not exactly. My system does not hang, but simply no packets go through the interface. Anyhow, seems that this driver is buggy at the moment. Hope that I have just to wait.
...and you say that 1.98 is working for you. Still, if I understand correctly, there were other problems with 1.98.
Click to expand...
I reported that bug and I think it maybe the same issue. My wording as non native speaker may have been not ideal. I meant the the network connection hangs, not the whole system (e.g. curl or ping „hangs“).
 
eofster said:
I have the same problem. 1.98 works fine, no traffic in 1.99 goes through. FreeBSD 13.2, Realtek 8125.

Is there a way to download the latest version in the 1.98 line from somewhere? I don't have it in the local cache.
Click to expand...
You can check out an older ports tree version and compile it.
I would recommend to run make install-missing-packages from current ports tree for the Realtek driver before, in order to avoid installation of dependencies from the „old“ ports tree.
If it works you can pkg lock realtek-re-kmod so that it does not get overwritten during package updates.
 
elgrande said:
I reported that bug and I think it maybe the same issue. My wording as non native speaker may have been not ideal. I meant the the network connection hangs, not the whole system (e.g. curl or ping „hangs“).
Click to expand...
Good that the issue has been reported. So, there is no need to report again. Tested the 1.99 driver on another machine without Realtek device. Loading this driver into kernel also kills traffic on another network interface, not related to Realtek at all. So, it seems to be a serious driver bug.
 
Argentum said:
Good that the issue has been reported. So, there is no need to report again. Tested the 1.99 driver on another machine without Realtek device. Loading this driver into kernel also kills traffic on another network interface, not related to Realtek at all. So, it seems to be a serious driver bug.
Click to expand...
Maybe you want to add this information to the bugzilla bug?
 
What are the expectations of having this in the kernel? Is it a question of Realtek releasing the sources or somebody taking their time to add this to the kernel? It seems like OpenBSD has it.
 
eofster said:
What are the expectations of having this in the kernel? Is it a question of Realtek releasing the sources or somebody taking their time to add this to the kernel? It seems like OpenBSD has it.
Click to expand...
This is a good question. Somebody has to take an initiative and commit to the next release...
 
I tried disabling LRO as suggested in Comment 4 of the bug report. I also disabled all the other hardware offloading features for good measure, and it seems to have restored network connectivity.

Code: 
re0: <Realtek PCIe 2.5GbE Family Controller> port 0xf000-0xf0ff mem 0xfce00000-0xfce0ffff,0xfce10000-0xfce13fff at device 0.0 on pci2
re0: Using Memory Mapping!
re0: Using 1 MSI-X message
re0: ASPM disabled
re0: version:1.99.04

re0@pci0:2:0:0: class=0x020000 rev=0x05 hdr=0x00 vendor=0x10ec device=0x8125 subvendor=0x1043 subdevice=0x87d7
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8125 2.5GbE Controller'
    class      = network
    subclass   = ethernet

I installed the binary package realtek-re-kmod-199.00_1 on 14.0-RELEASE-p4.
 
huggablemonad said:
I tried disabling LRO as suggested in Comment 4 of the bug report. I also disabled all the other hardware offloading features for good measure, and it seems to have restored network connectivity.
Click to expand...
Thanks! Will try this. See is this is LRO only or the other offload needs also be disabled.
 
Hi I am on 14. And it does work on my system. But to get it working you need to compile it yourself from ports. It is a kernel module. So it needs to mach exactly your version of the system.
 
larshenrikoern said:
Hi I am on 14. And it does work on my system. But to get it working you need to compile it yourself from ports. It is a kernel module. So it needs to mach exactly your version of the system.
Click to expand...
Normally the packages for 14 should fit afaik... For v198 it is no problem installing the package, for v199 though at least the RTL8125 chip seems to have problems.
Which network device do you have?
 
eofster said:
Please share the results! Not only for us now, but for the future readers.
Click to expand...
Did try it several ways and fiddled with the flags, but did not get it working. The latest setup was

Code: 
# sysctl -a |grep "hw.re."
hw.realmem: 17179869184
hw.re.max_rx_mbuf_sz: 9216
hw.re.interrupt_mitigation: 1
hw.re.config_soc_lan: 0
hw.re.s0_magic_packet: 0
hw.re.s5wol: 0
hw.re.phy_mdix_mode: 2
hw.re.phy_power_saving: 0
hw.re.eee_enable: 0
hw.re.lro_mbufq_depth: 0
hw.re.lro_entry_count: 0
hw.re.prefer_iomap: 0
hw.re.msix_disable: 1
hw.re.msi_disable: 1

There is no specific LRO flag, other than these two hw.re.lro_mbufq_depth and hw.re.lro_mbufq_depth.

The original was

Code: 
hw.realmem: 17179869184
hw.re.max_rx_mbuf_sz: 9216
hw.re.interrupt_mitigation: 1
hw.re.config_soc_lan: 0
hw.re.s0_magic_packet: 0
hw.re.s5wol: 0
hw.re.phy_mdix_mode: 2
hw.re.phy_power_saving: 1
hw.re.eee_enable: 0
hw.re.lro_mbufq_depth: 1024
hw.re.lro_entry_count: 128
hw.re.prefer_iomap: 0
hw.re.msix_disable: 0
hw.re.msi_disable: 1

Interesting that at some point few pings went through, but then it stopped. No messages.
 
larshenrikoern said:
Hi I am on 14. And it does work on my system. But to get it working you need to compile it yourself from ports. It is a kernel module. So it needs to mach exactly your version of the system.
Click to expand...
Of course, I did that. I have a custom kernel and the original re is removed from it. I can load both drivers and this is OK.
 
larshenrikoern said:
I do not know the chip but it is 2.5GB on a Asus Z690 D4 Motherboard
Click to expand...
You can get the chip from pciconf

Code: 
pciconf -lv|grep 2.5G
    device     = 'RTL8125 2.5GbE Controller'

... [some time later] This ugly hack did not help, but starting to disable all the offloads actually helped.

Now I am writing this letter through this driver. It is working!

Must check, which option exactly, but what I did is

Code: 
ifconfig re0 -rxcsum
ifconfig re0 -txcsum
ifconfig re0 -txcsum6

Must check which option exactly is the culprit.

At the moment it is working and I have:

Code: 
# ifconfig re0|grep options
        options=2018<VLAN_MTU,VLAN_HWTAGGING,WOL_MAGIC>
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
 
You must log in or register to reply here.
Back
Top