Date: Wed, 11 Apr 2018 15:14:46 -0700 From: Dieter BSD <dieterbsd@gmail.com> To: freebsd-hackers@freebsd.org Subject: Re: Realtek re(4) driver Message-ID: <CAA3ZYrD3peAogr9AVTwTQ4=dCSBJGurpEsKF7D4WcJKbg4TSOQ@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
One problem I see with the Realtek Ethernet and the stock FreeBSD device driver is occasional pauses in Ethernet traffic. Observe with: netstat -w 1 -I re2 With reasonably decent network software and TCP, this is only a minor problem. However with buggy network software (like a "black box" with closed source firmware and maybe a transmit buffer that is *way* too small, and/or true real time requirements), and/or with a brain dead protocol like UDP, you can lose data. So I decided to try and find a way to demonstrate the problem using only 2 normal computers running FreeBSD, one with Realtek Ethernet. The easy way seemed to be to transfer a large file using UDP and look for errors. On machine with Realtek Ethernet: nc -4nul 55555 > /var/tmp/big_file_copied_via_udp On some other machine: nc -4u machine_with_realtek 55555 < big_file If you don't like 55555, pick another port number. ;-) I first tried a 2.9 GB file, which worked ok a few times, then I tried a 28 GB file and the copy was smaller than the original. Tried it a couple more times and also got different sizes which were smaller than the original. Then transferred it twice with tcp, getting the correct size both times, and the two copies passed cmp(1). original: 28132560000 bytes udp copy 1: 28131929216 (smaller) udp copy 2: 28132523136 (smaller) udp copy 3: 28132537472 (smaller) tcp copy 1: 28132560000 (correct) tcp copy 2: 28132560000 (correct) Ran time(1) on nc (using tcp): real 5m56.591s -> 78,893,073 B/s Next, transfer the opposite direction, with Realtek transmitting and non-Realtek receiving. Transferred with tcp, got the correct file size, and the copy passed cmp(1) against the original file. Attempts to transfer using udp seem to run into some sort of flow control problem, the nc processes hang. Sometimes a small amount of data gets through. Both machines are amd64 with ECC memory RTL8111F and stock FreeBSD 10.4 re(4) The other machine has nfe(4) running FreeBSD 8.2 re0@pci0:4:0:0: class=0x020000 card=0x012310ec chip=0x816810ec rev=0x07 hdr=0x00 re1@pci0:5:0:0: class=0x020000 card=0x012310ec chip=0x816810ec rev=0x07 hdr=0x00 re2@pci0:12:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x0c hdr=0x00 re0: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> re0: Chip rev. 0x2c800000 re1: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> re1: Chip rev. 0x2c800000 re2: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> re2: Chip rev. 0x4c000000 ================================================= Steven writes: >> http://12244.wpc.azureedge.net/8012244/drivers/rtdrivers/cn/nic/0007-rtl_bsd_drv_v194.01.tgz Gary writes: > This is the old if_rl driver by Bill Paul from 1998. Hard to > believe it's really superior to the newer version, which is also > based on later code from Bill Paul. The URL worked for me (using wget). 96,127 bytes. Thank you, Steven! tar tvzf 0007-rtl_bsd_drv_v194.01.tgz drwxrwxrwx 0 0 0 0 Dec 26 2016 rtl_bsd_drv_v194.01/ -rwxrwxrwx 0 0 0 1186892 Aug 29 2017 rtl_bsd_drv_v194.01/if_re.c -rwxrwxrwx 0 0 0 37071 Aug 25 2017 rtl_bsd_drv_v194.01/if_rereg.h -rwxrwxrwx 0 0 0 200 Jun 14 2016 rtl_bsd_drv_v194.01/Makefile -rwxrwxrwx 0 0 0 3172 Jan 3 2017 rtl_bsd_drv_v194.01/Readme.txt Huh? What is this about 1998? Looks like 2017-08-29 to me. The files are newer than FreeBSD 10.3's sources: -r--r--r-- 1 root wheel 111335 Mar 24 2016 re/if_re.c However, I have RTL8111E on UD5 mainboard, and 2x RTL8111F on PCIe card. The FreeBSD sources attempt to support these, but the Realtek sources do not mention these revisions, which seems odd when it is 1.5 years newer. # grep -i 8111e re/* rtl_bsd_drv_v194.01/* re/if_re.c: { RL_HWREV_8168E, RL_8169, "8168E/8111E", RL_JUMBO_MTU_9K}, re/if_re.c: { RL_HWREV_8168E_VL, RL_8169, "8168E/8111E-VL", RL_JUMBO_MTU_6K}, re/if_re.c: { RL_HWREV_8168EP, RL_8169, "8168EP/8111EP", RL_JUMBO_MTU_9K}, # grep -i 8111f re/* rtl_bsd_drv_v194.01/* re/if_re.c: { RL_HWREV_8168F, RL_8169, "8168F/8111F", RL_JUMBO_MTU_9K}, Which leaves me wondering if the Reaktek code supports the chips I have or not. Readme.txt says > for FreeBSD v4.x/5.x/6.x/7.x/8.x/9.x No mention of 10 or newer, which, again, seems odd when it is 1.5 years newer than 10.3. May or may not be a problem.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAA3ZYrD3peAogr9AVTwTQ4=dCSBJGurpEsKF7D4WcJKbg4TSOQ>