Official Realtek Driver Binary 1.95 For 2.4.4 Release
-
That sounds more like something is actually linking at 100Mb. That NIC should pass far more than that with either driver.
Steve
-
Have 2.4.4-RELEASE-p3 the latest driver for RTL8111G or must I manualy update the driver to latest version?
I have problem WAN port stop working, disable the port and enable and it start working again... its happens with low load 10mbit maybe... within 1 hour or so...
-
you need to manually update https://drive.google.com/open?id=1lBg8AIRiRfGBGeXe9kgKtAAma0VjiYfC
copy to /boot/kernel , rename to if_re.ko
kldload if_re.ko
or build it yourselfto load it at boot
edit /boot/loader.conf.local
and paste
if_re_load=“YES"personally i've lost patience with realtek and at the end i bought an intel card
-
@kiokoman said in Official Realtek Driver Binary 1.95 For 2.4.4 Release:
you need to manually update https://drive.google.com/open?id=1lBg8AIRiRfGBGeXe9kgKtAAma0VjiYfC
copy to /boot/kernel , rename to if_re.ko
kldload if_re.ko
or build it yourselfto load it at boot
edit /boot/loader.conf.local
and paste
if_re_load=“YES"personally i've lost patience with realtek and at the end i bought an intel card
/root: kldstat
Id Refs Address Size Name
1 5 0xffffffff80200000 2ddcbe8 kernel
2 1 0xffffffff82fde000 7d290 if_re.ko
3 1 0xffffffff839fa000 10a0 cpuctl.koIs the drive active now ?
-
yes
-
@kiokoman said in Official Realtek Driver Binary 1.95 For 2.4.4 Release:
yes
These should be it ?
Now can I go to bad, and see if internett is still working tomorrow morning :)
Thank you very much !
-
The problem is still present...
Strange it is only a problem with WAN (re1) and not LAN (re0)... -
[2.4.4-RELEASE][root@firewall.test.net]/root: grep re1 /var/run/dmesg.boot
re1: <Realtek PCIe GBE Family Controller> port 0xd000-0xd0ff mem 0xa1104000-0xa1104fff,0xa1100000-0xa1103fff at device 0.0 on pci3
re1: Using Memory Mapping!
re1: Using 1 MSI-X message
re1: ASPM disabled
re1: version:1.95.00
re1: Ethernet address: 00:1e:06:45:02:83
re1: Ethernet address: 00:1e:06:45:02:83[2.4.4-RELEASE][root@firewall.test.net]/root: route -n
route: usage: route [-46dnqtv] command [[modifiers] args][2.4.4-RELEASE][root@firewall.test.net]/root: arp -an | grep re1
? (92.221.80.253) at 00:1e:06:45:02:83 on re1 permanent [ethernet]
? (92.221.80.1) at 00:02:00:01:00:01 on re1 expires in 97 seconds [ethernet][2.4.4-RELEASE][root@firewall.test.net]/root: tcpdump -c 20 -n -i re1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re1, link-type EN10MB (Ethernet), capture size 262144 bytes
03:49:11.244621 IP 92.221.80.253.49228 > XX.XX.XX.XX.XXX: 26302+ XXXXXXX (91)
03:49:11.244626 IP 92.221.80.253.49228 > XX.XX.XX.XX.XXX: 26302+ XXXXXXX. (91)
03:49:11.246135 IP 92.221.80.253.25525 > XX.XX.XX.XX.XXX: 28630+ XXXXXXX. (35)
03:49:11.246139 IP 92.221.80.253.25525 > XX.XX.XX.XX.XXX: 28630+ XXXXXXX. (35)
03:49:11.262982 IP 92.221.80.253.25525 > XX.XX.XX.XX.XXX: 42079+ XXXXXXX. (57)
03:49:11.262985 IP 92.221.80.253.25525 > XX.XX.XX.XX.XXX: 42079+ XXXXXXX. (57)
03:49:11.263013 IP 92.221.80.253.25525 > XX.XX.XX.XX.XXX: 23104+ XXXXXXX. (53)
03:49:11.263016 IP 92.221.80.253.25525 > XX.XX.XX.XX.XXX: 23104+ XXXXXXX. (53)
03:49:11.413788 IP 92.221.80.253.25525 > 109.247.114.4.53: 46408+ XXXXXXX. (41)
03:49:11.413793 IP 92.221.80.253.25525 > 92.220.228.70.53: 46408+ XXXXXXX. (41)
03:49:11.413823 IP 92.221.80.253.25525 > 109.247.114.4.53: 30408+ XXXXXXX. (41)
03:49:11.413826 IP 92.221.80.253.25525 > 92.220.228.70.53: 30408+ XXXXXXX. (41)
03:49:11.414619 IP 92.221.80.253.25525 > XX.XX.XX.XX.XXX: 9197+ XXXXXXX. (31)
03:49:11.414622 IP 92.221.80.253.25525 > XX.XX.XX.XX.XXX: 9197+ XXXXXXX. (31)
03:49:11.414695 IP 92.221.80.253.36009 > XX.XX.XX.XX.XXX: 247+ XXXXXXX. (31)
03:49:11.414699 IP 92.221.80.253.36009 > XX.XX.XX.XX.XXX: 247+ XXXXXXX. (31)
03:49:11.490012 IP 92.221.80.253.49228 > XX.XX.XX.XX.XXX: 26302+ XXXXXXX. (91)
03:49:11.490015 IP 92.221.80.253.49228 > XX.XX.XX.XX.XXX: 26302+ XXXXXXX. (91)
03:49:11.491250 IP 92.221.80.253.25525 > XX.XX.XX.XX.XXX: 28630+ XXXXXXX. (35)
03:49:11.491253 IP 92.221.80.253.25525 > XX.XX.XX.XX.XXX: 28630+ XXXXXXX. (35)
20 packets captured
20 packets received by filter
0 packets dropped by kernel -
@kiokoman are you sure the driver has been loaded ?
Just that I facing the same problem after also.... -
@gordon said in Official Realtek Driver Binary 1.95 For 2.4.4 Release:
re1: version:1.95.00
It shows it's loaded there. The FreeBSD in kernel driver doesn't show the version as far as I know. I only have 2.5 dev box up right now but:
[2.5.0-DEVELOPMENT][root@apu.stevew.lan]/root: grep re1 /var/run/dmesg.boot re1: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0x2000-0x20ff mem 0xf7c00000-0xf7c00fff,0xf7b00000-0xf7b03fff irq 17 at device 0.0 on pci2 re1: Using 1 MSI-X message re1: ASPM disabled re1: Chip rev. 0x2c000000 re1: MAC rev. 0x00200000 miibus1: <MII bus> on re1 re1: Using defaults for TSO: 65518/35/2048 re1: Ethernet address: 00:0d:b9:89:3f:11 re1: netmap queues/slots: TX 1/256, RX 1/256
Try commenting out the line in loader.conf.local and rebooting.
Steve
-
@gordon said in Official Realtek Driver Binary 1.95 For 2.4.4 Release:
[2.4.4-RELEASE][root@firewall.test.net]/root: grep re1 /var/run/dmesg.boot
re1: <Realtek PCIe GBE Family Controller> port 0xd000-0xd0ff mem 0xa1104000-0xa1104fff,0xa1100000-0xa1103fff at device 0.0 on pci3
re1: Using Memory Mapping!
re1: Using 1 MSI-X message
re1: ASPM disabled
> re1: version:1.95.00
re1: Ethernet address: 00:1e:06:45:02:83
re1: Ethernet address: 00:1e:06:45:02:83yes it is like stephenw10 say,
version 1.95.00 is the official driver, the one shipped with freebsd does not output the version when it load -
@kiokoman said in Official Realtek Driver Binary 1.95 For 2.4.4 Release:
@gordon said in Official Realtek Driver Binary 1.95 For 2.4.4 Release:
[2.4.4-RELEASE][root@firewall.test.net]/root: grep re1 /var/run/dmesg.boot
re1: <Realtek PCIe GBE Family Controller> port 0xd000-0xd0ff mem 0xa1104000-0xa1104fff,0xa1100000-0xa1103fff at device 0.0 on pci3
re1: Using Memory Mapping!
re1: Using 1 MSI-X message
re1: ASPM disabled
> re1: version:1.95.00
re1: Ethernet address: 00:1e:06:45:02:83
re1: Ethernet address: 00:1e:06:45:02:83yes it is like stephenw10 say,
version 1.95.00 is the official driver, the one shipped with freebsd does not output the version when it loadThank you,
I reinstalled pfsense today and are using WAN on re0 instead of re1 and LAN on re1, so fare so fare, new record in uptime... cross my fingers....
But I cannot understand these shall make any different ?
-
The driver provided by Realtek can commonly help if you're seeing watchdog timeout errors. But it sounds like that's not what you're seeing so it may not make any difference here. You have nothing to lose by trying it though.
Steve
-
@stephenw10
Problem is still present, card stop working and report DOWN in status underRemember both card is identical network card... strange it’s only WAN card who goes down.
Have now tried disabling «Disable hardware checksum offload»
Is it possible to make the card recycle DISABLE and then ENABLE when these happens, way around the problem until I find a fix?
-
«Disable hardware checksum
Was not fixing the problem....Does anybody know how I can auto disable and enable the card when it goes down?
-
try with
/etc/rc.d/netif restart re0 -
@kiokoman said in Official Realtek Driver Binary 1.95 For 2.4.4 Release:
try with
/etc/rc.d/netif restart re0Thank you, I need some script to detect when it shall happens also...
I found some things to try another place on these forum, so I have added these lines to the boot config:
net.inet.tcp.tso=0
hw.pci.enable_msix=0
hw.pci.enable_msi=0
hw.re.tso_enable=0to the boot loader config, and for now I haven`t seen the issue again, need more hours... will report back later.
-
Yes, definitely disable all hardware offloading features. Check what is still enabled using
ifconfig re1
.Did you try re-assigning the NICs? Does the fault follow re1 or remain on WAN?
It's likely you are downloading far more traffic that uploading. Whichever NIC is WAN is doing the receiving of that traffic and a number of those hardware offloading features are receive only.Steve
-
@stephenw10 said in Official Realtek Driver Binary 1.95 For 2.4.4 Release:
Yes, definitely disable all hardware offloading features. Check what is still enabled using
ifconfig re1
.Did you try re-assigning the NICs? Does the fault follow re1 or remain on WAN?
It's likely you are downloading far more traffic that uploading. Whichever NIC is WAN is doing the receiving of that traffic and a number of those hardware offloading features are receive only.Steve
I reinstalled the whole pfsense yesterday and then I swapped so re0 is WAN and re1 is LAN.
The problem have always followed the card I have assigned to be WAN.The problem has not accour after I disabled al the things mention above from the HW i the boot loader. But there is a strange thing the uptime on the box is never 1 hour and 47 minutes, but I have not restarted the box today..... I think there are something wrong with the clock... its not going correct... it`s deviate more and more from the "real time"....
Maybe there is a releation here ? lead time on the DHCP maybe got problem...
I will look into getting the clock correct first.
-
Make sure NTP is configured and working. All APUs are old now, the CMOS battery may be dead.
Edit: Is this an APU? Not sure where I pulled that from..
Steve