Realtek re(4) driver

[Dieter BSD]

Multiple people have found that FreeBSD's re(4) driver for Realtek
Ethernet chips has problems. Something like a rcp(1) with another
FreeBSD box merely runs slower due to the stalls, but if the other end
has buggy network code and/or if the transfer is forced to use UDP
(Unreliable Data Protocol) data is lost. :-(

Rumor has it that Realtek has a driver that works properly with FreeBSD.

FreeBSD's developers are apparently unable to:
a) Fix the existing FreeBSD re(4) device driver so that it works correctly.
b) Replace the existing FreeBSD re(4) device driver with Realtek's driver.
c) Make Realtek's driver into a port/pkg.
d) At least add a warning to the re(4) man page, with the URL for
Realtek's driver.

Therefore every user with Realtek Ethernet chips are forced to somehow
discover that Realtek has a working driver, then somehow obtain a copy
of this mythical driver, get it to compile and build a custom kernel.
They then need to write a test suite and verify that Realtek's driver
does in fact work properly for their applications.

I am currently suffering data loss due to this. Therefore I am
attempting to obtain a copy of the mythical Realtek device driver.
I managed to find

http://www.realtek.com.tw/Downloads/downloadsView.aspx?Langid=4&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false

But it does not work for me. It has a listing for

Description Version Update Time File Size Download Site 1
FreeBSD 7.x and 8.0 1.94 2017/9/15 93k Global

The machine with the re ports is running 10.3, hopefully the 7&8 code
will compile and work on 10. But the real problem is that clicking on
"Global" does not work. Some browsers do nothing. Firefox creates
a new window with http://www.realtek.com.tw/downloads/
which is going backwards. I was expecting something like a tar file
containing the source code.

I also tried google, and emailing a FreeBSD user that runs the Realtek
driver, but both pointed me to the above non-working URL. I'm
told that seamonkey works, but...

So my question is: could someone please tell me the URL that points
*directly* to the mythical Realtek device driver? (without
the broken javascheist garbage)

[Steven Hartland]

Try:
http://12244.wpc.azureedge.net/8012244/drivers/rtdrivers/cn/nic/0007-rtl_bsd_drv_v194.01.tgz

May or many not work depending on if its a per client download URL

Post by Dieter BSD
Multiple people have found that FreeBSD's re(4) driver for Realtek
Ethernet chips has problems. Something like a rcp(1) with another
FreeBSD box merely runs slower due to the stalls, but if the other end
has buggy network code and/or if the transfer is forced to use UDP
(Unreliable Data Protocol) data is lost. :-(
Rumor has it that Realtek has a driver that works properly with FreeBSD.
a) Fix the existing FreeBSD re(4) device driver so that it works correctly.
b) Replace the existing FreeBSD re(4) device driver with Realtek's driver.
c) Make Realtek's driver into a port/pkg.
d) At least add a warning to the re(4) man page, with the URL for
Realtek's driver.
Therefore every user with Realtek Ethernet chips are forced to somehow
discover that Realtek has a working driver, then somehow obtain a copy
of this mythical driver, get it to compile and build a custom kernel.
They then need to write a test suite and verify that Realtek's driver
does in fact work properly for their applications.
I am currently suffering data loss due to this. Therefore I am
attempting to obtain a copy of the mythical Realtek device driver.
I managed to find

http://www.realtek.com.tw/Downloads/downloadsView.aspx?Langid=4&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false

But it does not work for me. It has a listing for

Description Version Update Time File Size Download Site 1
FreeBSD 7.x and 8.0 1.94 2017/9/15 93k Global

The machine with the re ports is running 10.3, hopefully the 7&8 code
will compile and work on 10. But the real problem is that clicking on
"Global" does not work. Some browsers do nothing. Firefox creates
a new window with http://www.realtek.com.tw/downloads/
which is going backwards. I was expecting something like a tar file
containing the source code.
I also tried google, and emailing a FreeBSD user that runs the Realtek
driver, but both pointed me to the above non-working URL. I'm
told that seamonkey works, but...
So my question is: could someone please tell me the URL that points
*directly* to the mythical Realtek device driver? (without
the broken javascheist garbage)
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers

[Gary Jennejohn]

On Wed, 11 Apr 2018 00:05:59 +0100

Post by Steven Hartland
http://12244.wpc.azureedge.net/8012244/drivers/rtdrivers/cn/nic/0007-rtl_bsd_drv_v194.01.tgz
May or many not work depending on if its a per client download URL

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.

[snip]

[BERTRAND Joël]

Post by Gary Jennejohn
On Wed, 11 Apr 2018 00:05:59 +0100

Post by Steven Hartland
http://12244.wpc.azureedge.net/8012244/drivers/rtdrivers/cn/nic/0007-rtl_bsd_drv_v194.01.tgz
May or many not work depending on if its a per client download URL

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.
[snip]

I use a diskless workstation. With re driver provided by FreeBSD kernel
(9/10/11.x), system randomly crashed because ethernet driver stalls (and
datarate is always less than 300mbps). With official realtek driver
(v194.01), system now runs as expected (with datarate up to 1 Gbps).

Internal re driver is broken on this ethernet adapter (maybe on several
other adapters) :

***@pci0:2:0:0: class=0x020000 card=0x78511462 chip=0x816810ec rev=0x0c
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
class = network
subclass = ethernet

Regards,

JKB

[David Wolfskill]

Post by BERTRAND Joël
...
I use a diskless workstation. With re driver provided by FreeBSD kernel
(9/10/11.x), system randomly crashed because ethernet driver stalls (and
datarate is always less than 300mbps). With official realtek driver
(v194.01), system now runs as expected (with datarate up to 1 Gbps).
Internal re driver is broken on this ethernet adapter (maybe on several
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
class = network
subclass = ethernet
Regards,
JKB
....

In counterpoint, my build machine for the last few years has been a Dell
mini-tower I bought from Costco... with its original disk drive removed
(replaced by an SSD, then supplemented with 3 more for a poudriere
scratch-space). It runs a GENERIC kernel, tracking stable/11 & head
daily, using poudriere to build local packages weekly, and acting as an
NFS server for my "production" machines for their weekly updates.

Its NIC:

***@pci0:3:0:0: class=0x020000 card=0x05b71028 chip=0x816810ec rev=0x0c hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
class = network
subclass = ethernet

freebeast(11.1-S)[2] ifconfig re0
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
ether 98:90:96:d6:c9:6d
hwaddr 98:90:96:d6:c9:6d
inet 172.16.8.10 netmask 0xffffff00 broadcast 172.16.8.255
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex,master>)
status: active
freebeast(11.1-S)[3]

(It is connected to a "dumb" 16-port Netgear gigabit switch.)

I will admit that I avoid having the machine try to do too much
else while the production machines are using it as an NFS server
(serving /usr/src & /usr/obj, while (e.g.) "make installworld" runs
on the production machines), but other than that, I have no issues
involving performance and behavior of the NIC and its driver.

Peace,
david

[Alex Dupre]

Post by BERTRAND Joël
I use a diskless workstation. With re driver provided by FreeBSD kernel
(9/10/11.x), system randomly crashed because ethernet driver stalls (and
datarate is always less than 300mbps). With official realtek driver
(v194.01), system now runs as expected (with datarate up to 1 Gbps).

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

Anyone interested in taking the bounty or contributing to it? Perhaps
the FreeBSD Foundation should jump in?

[Gary Jennejohn]

On Wed, 11 Apr 2018 12:51:09 +0200

Post by Alex Dupre

Post by BERTRAND Joël
I use a diskless workstation. With re driver provided by FreeBSD kernel
(9/10/11.x), system randomly crashed because ethernet driver stalls (and
datarate is always less than 300mbps). With official realtek driver
(v194.01), system now runs as expected (with datarate up to 1 Gbps).

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724
Anyone interested in taking the bounty or contributing to it? Perhaps
the FreeBSD Foundation should jump in?

Reading the bugzilla shows that this is a comples problem with no
obvious error source.

One poster notes that he could transfer 300+GB of data error-free
using rsync, but with NFS he encountered problesm after a few GB.
To me this is an indictment of the NFS implementation used and
not of the re driver itself.

The same goes for some other posts. Everyone blames re, but AFAICT
no-one switched to a non-Realtek chip to run tests and prove that,
yes, re is really the cause of all the network problems.

I've been using re for many years in various incarnations - PCIe
cards and integrated on the mainboard. I've never experienced
any network instabilities. But I've never used one in a NFS
server under FBSD. I do, however, have one in a Linux NFS server
(which was at one time my primary FBSD box) and never observed
any problems.

In summary, this is one tough nut to crack.

[Alex Dupre]

Post by Gary Jennejohn
Reading the bugzilla shows that this is a comples problem with no
obvious error source.
One poster notes that he could transfer 300+GB of data error-free
using rsync, but with NFS he encountered problesm after a few GB.
To me this is an indictment of the NFS implementation used and
not of the re driver itself.

I agree that is a complex problem with a non obvious solution, I have
also used many re cards successfully and others not, but surely it's not
a NFS issue. I can tell you more, I've used successfully a re card for
years, and started seeing issues with the same card after upgrading my
upstream connection to gigabit. The only thing that link all bug reports
(and there are tons) is the use of re card sustaining gigabit (duplex)
transfers. And I couldn't find similar reports for other chipsets that
might lead to think it's a generic FreeBSD issue. Everything is
possible, but the main suspect is the re driver.

[Gary Jennejohn]

On Wed, 11 Apr 2018 17:19:18 +0200

Post by Alex Dupre

Post by Gary Jennejohn
Reading the bugzilla shows that this is a comples problem with no
obvious error source.
One poster notes that he could transfer 300+GB of data error-free
using rsync, but with NFS he encountered problesm after a few GB.
To me this is an indictment of the NFS implementation used and
not of the re driver itself.

I agree that is a complex problem with a non obvious solution, I have
also used many re cards successfully and others not, but surely it's not
a NFS issue. I can tell you more, I've used successfully a re card for
years, and started seeing issues with the same card after upgrading my
upstream connection to gigabit. The only thing that link all bug reports
(and there are tons) is the use of re card sustaining gigabit (duplex)
transfers. And I couldn't find similar reports for other chipsets that
might lead to think it's a generic FreeBSD issue. Everything is
possible, but the main suspect is the re driver.

One thing which did seem common was checksum offloading. My cards
don't seem to support that.

My Linux NFS server is serving clients with 1Gbps links - never
seen a problem. But the MTU is limited to 1500.

The re in my FBSD box uses a MTU of 4808. I've transferred lots
of data with a Linux device and a Windows machine also using that
setting and never saw a problem. Maybe I'm just lucky.

The Realtech Linux driver could be a place to start looking for useful
changes.

[Borja Marcos]

Post by Alex Dupre
I agree that is a complex problem with a non obvious solution, I have
also used many re cards successfully and others not, but surely it's not
a NFS issue.

I have this interface in an Intel NUC,

***@pci0:3:0:0: class=0x020000 card=0x20678086 chip=0x816810ec rev=0x15 hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
class = network
subclass = ethernet


and I have had serious problems running an iSCSI initiator with some work load. I tried both the
builtin “re” driver in FreeBSD and the 1.94.01 version driver available from the Realtek website
with similar results.


More or less the same workload on a different machine with Intel “em” cards and
the same FreeBSD version works.





Borja.

[Joerg Sonnenberger]

Post by Alex Dupre

Post by BERTRAND Joël
I use a diskless workstation. With re driver provided by FreeBSD kernel
(9/10/11.x), system randomly crashed because ethernet driver stalls (and
datarate is always less than 300mbps). With official realtek driver
(v194.01), system now runs as expected (with datarate up to 1 Gbps).

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724
Anyone interested in taking the bounty or contributing to it? Perhaps
the FreeBSD Foundation should jump in?

A starting point would be:
(1) what hardware offload features are enabled
(2) whether a specific direction is the problem
(3) correlate traffic on both ends, i.e. what packets are dropped "on
the wire"

The most likely cause of any problem here is a missing workaround for a
hardware bug or Realtek deciding that some specific tuning is necessary
for certain chips. It is nearly impossible to fix this kind of bugs
without having access to the hardware and a way to reproduce it.
Comparing with a working driver might be possible, but it is extremely
tideous.

Joerg

[Alex Dupre]

Post by Joerg Sonnenberger
The most likely cause of any problem here is a missing workaround for a
hardware bug or Realtek deciding that some specific tuning is necessary
for certain chips. It is nearly impossible to fix this kind of bugs
without having access to the hardware and a way to reproduce it.
Comparing with a working driver might be possible, but it is extremely
tideous.

I've just setup two machines with re interfaces (one onboard and one
with an external pci-ex card), connected point to point, but I was
unable to reproduce the issue. I can easily reproduce it on another
server, but that's a semi-production one, so I can do limited testing
(ie replace the if_re.ko kernel module, reboot, and do something for a
few minutes, then I have to revert to the working kernel module).

[Warner Losh]

Post by Alex Dupre

Post by Joerg Sonnenberger
The most likely cause of any problem here is a missing workaround for a
hardware bug or Realtek deciding that some specific tuning is necessary
for certain chips. It is nearly impossible to fix this kind of bugs
without having access to the hardware and a way to reproduce it.
Comparing with a working driver might be possible, but it is extremely
tideous.

I've just setup two machines with re interfaces (one onboard and one
with an external pci-ex card), connected point to point, but I was
unable to reproduce the issue. I can easily reproduce it on another
server, but that's a semi-production one, so I can do limited testing
(ie replace the if_re.ko kernel module, reboot, and do something for a
few minutes, then I have to revert to the working kernel module).

The rl/re cards have some code in them to cope with cable length to the
hub, since on the older cards this can greatly increase reliability.
Perhaps there's signal issue here? Also, the re drivers are known to have
some revs that have hardware offload features, but that said features don't
work. Ideally, if you had a completely reproducible scenario you could turn
off all the hardware offload and see if that fixes the problem.

Warner

[Vladimir Terziev]

Hi Dieter,

i have managed to download the driver from the link that you provided by just clicking the “Global” link.

Just let me know if you want me to send it to you.


Regards,

Vladimir

Post by Dieter BSD
Multiple people have found that FreeBSD's re(4) driver for Realtek
Ethernet chips has problems. Something like a rcp(1) with another
FreeBSD box merely runs slower due to the stalls, but if the other end
has buggy network code and/or if the transfer is forced to use UDP
(Unreliable Data Protocol) data is lost. :-(
Rumor has it that Realtek has a driver that works properly with FreeBSD.
a) Fix the existing FreeBSD re(4) device driver so that it works correctly.
b) Replace the existing FreeBSD re(4) device driver with Realtek's driver.
c) Make Realtek's driver into a port/pkg.
d) At least add a warning to the re(4) man page, with the URL for
Realtek's driver.
Therefore every user with Realtek Ethernet chips are forced to somehow
discover that Realtek has a working driver, then somehow obtain a copy
of this mythical driver, get it to compile and build a custom kernel.
They then need to write a test suite and verify that Realtek's driver
does in fact work properly for their applications.
I am currently suffering data loss due to this. Therefore I am
attempting to obtain a copy of the mythical Realtek device driver.
I managed to find

http://www.realtek.com.tw/Downloads/downloadsView.aspx?Langid=4&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false

But it does not work for me. It has a listing for

Description Version Update Time File Size Download Site 1
FreeBSD 7.x and 8.0 1.94 2017/9/15 93k Global

The machine with the re ports is running 10.3, hopefully the 7&8 code
will compile and work on 10. But the real problem is that clicking on
"Global" does not work. Some browsers do nothing. Firefox creates
a new window with http://www.realtek.com.tw/downloads/
which is going backwards. I was expecting something like a tar file
containing the source code.
I also tried google, and emailing a FreeBSD user that runs the Realtek
driver, but both pointed me to the above non-working URL. I'm
told that seamonkey works, but...
So my question is: could someone please tell me the URL that points
*directly* to the mythical Realtek device driver? (without
the broken javascheist garbage)
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-net

[Rodney W. Grimes]

Post by Alex Dupre

Post by BERTRAND Joël
I use a diskless workstation. With re driver provided by FreeBSD kernel
(9/10/11.x), system randomly crashed because ethernet driver stalls (and
datarate is always less than 300mbps). With official realtek driver
(v194.01), system now runs as expected (with datarate up to 1 Gbps).

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

I have put that bug back on a public bug list (***@freebsd.org) so
that it appears in the nag mails sent out periodically.

I think I might have some of that hardware around here, but not sure
if it is that specific chip. I do know that some "re(4)" cards
work just fine with FreeBSD, but others have issues, I suspect the
ones that have issues are ones that have hardware bugs that need
a specific software work around.

I do have this:
***@pci0:2:0:0: class=0x020000 card=0x84321043 chip=0x816810ec rev=0x06 hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'

and I use that pretty regular, including NFS, but rarely push more than
1 or 2 gigabyte through it in any one operation. (src tree size chunks go
in and out of that box).

Post by Alex Dupre
Anyone interested in taking the bounty or contributing to it? Perhaps
the FreeBSD Foundation should jump in?
--
Alex Dupre

[Mike Tancsa]

Post by Rodney W. Grimes

Post by Alex Dupre
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

that it appears in the nag mails sent out periodically.
I think I might have some of that hardware around here, but not sure
if it is that specific chip. I do know that some "re(4)" cards
work just fine with FreeBSD, but others have issues, I suspect the
ones that have issues are ones that have hardware bugs that need
a specific software work around.

Over the years I have had mixed results with re nics. Some work as
expected, others with issues. I think a big part of the problem is that
there are so many varieties out there. That being said, I run into
similar issues on Linux from time to time with these NICs, so its not
just a FreeBSD problem. Just the other week, on a new MSI RYZEN board
(MS-7A34), I found I could wedge the onboard NIC without too much effort
doing some network stress tests. (kernel is 4.4.0-119). Havent tried
this board on FreeBSD however.

---Mike

[Allan Jude]

Post by Dieter BSD
Multiple people have found that FreeBSD's re(4) driver for Realtek
Ethernet chips has problems. Something like a rcp(1) with another
FreeBSD box merely runs slower due to the stalls, but if the other end
has buggy network code and/or if the transfer is forced to use UDP
(Unreliable Data Protocol) data is lost. :-(
Rumor has it that Realtek has a driver that works properly with FreeBSD.
a) Fix the existing FreeBSD re(4) device driver so that it works correctly.
b) Replace the existing FreeBSD re(4) device driver with Realtek's driver.
c) Make Realtek's driver into a port/pkg.
d) At least add a warning to the re(4) man page, with the URL for
Realtek's driver.
Therefore every user with Realtek Ethernet chips are forced to somehow
discover that Realtek has a working driver, then somehow obtain a copy
of this mythical driver, get it to compile and build a custom kernel.
They then need to write a test suite and verify that Realtek's driver
does in fact work properly for their applications.
I am currently suffering data loss due to this. Therefore I am
attempting to obtain a copy of the mythical Realtek device driver.
I managed to find

http://www.realtek.com.tw/Downloads/downloadsView.aspx?Langid=4&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false

But it does not work for me. It has a listing for

Description Version Update Time File Size Download Site 1
FreeBSD 7.x and 8.0 1.94 2017/9/15 93k Global

The machine with the re ports is running 10.3, hopefully the 7&8 code
will compile and work on 10. But the real problem is that clicking on
"Global" does not work. Some browsers do nothing. Firefox creates
a new window with http://www.realtek.com.tw/downloads/
which is going backwards. I was expecting something like a tar file
containing the source code.
I also tried google, and emailing a FreeBSD user that runs the Realtek
driver, but both pointed me to the above non-working URL. I'm
told that seamonkey works, but...
So my question is: could someone please tell me the URL that points
*directly* to the mythical Realtek device driver? (without
the broken javascheist garbage)
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers

I think it would be useful to collect the 'pciconf -lv' output of the
re(4) devices that have issues, so they can be differentiated from the
ones that work fine.

This would be the first step to getting a developer setup with a
reliable reproduction platform, so the bug could be tracked down.

[Peter]

Post by Allan Jude
I think it would be useful to collect the 'pciconf -lv' output of the
re(4) devices that have issues, so they can be differentiated from the
ones that work fine.

Yes, but that would mean a structured approach, and not everybody loves
that. *vbeg*

I remember, in the old times there was a rule: on 100Mb never do
autonegotiate, on 1Gb always do autonegotiate - but that may vary
depending on device. I would think, that option, as well as respective
offloading capabilities, should also carefully checked for influences.

I have one of these pieces here, but it runs in 100Mb mode and sadly I
have no proper counterpart in reach to do full-speed testing.

[Borja Marcos]

Post by Allan Jude
I think it would be useful to collect the 'pciconf -lv' output of the
re(4) devices that have issues, so they can be differentiated from the
ones that work fine.

There we go. The machine is an Intel NUC6CAYB. Yep, sounds stupid. Intel using Realtek Ethernet chips. Sigh.

re0: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0xe000-0xe
0ff mem 0x91104000-0x91104fff,0x91100000-0x91103fff at device 0.0 on pci3
re0: Using 1 MSI-X message
re0: turning off MSI enable bit.
re0: Chip rev. 0x54000000
re0: MAC rev. 0x00100000
miibus0: <MII bus> on re0
rgephy0: <RTL8251 1000BASE-T media interface> PHY 1 on miibus0
rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
re0: Using defaults for TSO: 65518/35/2048
re0: Ethernet address: 94:c6:91::

***@pci0:3:0:0: class=0x020000 card=0x20678086 chip=0x816810ec rev=0x15 hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
class = network
subclass = ethernet


What I’ve observed is crazy packet loss and round trip times especially when running an iSCSI initiator with a lot
of filesystem activity.







Borja.

[Rodney W. Grimes]

Post by Allan Jude

Post by Dieter BSD
Multiple people have found that FreeBSD's re(4) driver for Realtek
Ethernet chips has problems. Something like a rcp(1) with another
FreeBSD box merely runs slower due to the stalls, but if the other end
has buggy network code and/or if the transfer is forced to use UDP
(Unreliable Data Protocol) data is lost. :-(
Rumor has it that Realtek has a driver that works properly with FreeBSD.
a) Fix the existing FreeBSD re(4) device driver so that it works correctly.
b) Replace the existing FreeBSD re(4) device driver with Realtek's driver.
c) Make Realtek's driver into a port/pkg.
d) At least add a warning to the re(4) man page, with the URL for
Realtek's driver.
Therefore every user with Realtek Ethernet chips are forced to somehow
discover that Realtek has a working driver, then somehow obtain a copy
of this mythical driver, get it to compile and build a custom kernel.
They then need to write a test suite and verify that Realtek's driver
does in fact work properly for their applications.
I am currently suffering data loss due to this. Therefore I am
attempting to obtain a copy of the mythical Realtek device driver.
I managed to find

http://www.realtek.com.tw/Downloads/downloadsView.aspx?Langid=4&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false

But it does not work for me. It has a listing for

Description Version Update Time File Size Download Site 1
FreeBSD 7.x and 8.0 1.94 2017/9/15 93k Global

The machine with the re ports is running 10.3, hopefully the 7&8 code
will compile and work on 10. But the real problem is that clicking on
"Global" does not work. Some browsers do nothing. Firefox creates
a new window with http://www.realtek.com.tw/downloads/
which is going backwards. I was expecting something like a tar file
containing the source code.
I also tried google, and emailing a FreeBSD user that runs the Realtek
driver, but both pointed me to the above non-working URL. I'm
told that seamonkey works, but...
So my question is: could someone please tell me the URL that points
*directly* to the mythical Realtek device driver? (without
the broken javascheist garbage)

I think it would be useful to collect the 'pciconf -lv' output of the
re(4) devices that have issues, so they can be differentiated from the
ones that work fine.

IIRC one of the "issues" with re type devies is that you can have
the exact same PCI vendor and device ID, but they are NOT the same
device. You have to read some additional realtek specific hwrev
register to know which card you actuall have. That is why another
person in this thread asked for dmesg output, as the driver decodes
these bits and spits out a proper info line.

Search for RL_HWREV in both if_rl.c and if_re.c, the re gets
this info from the if_rl.h header.

SO if you want to submit your pciconf -lv,
PLEASE include the dmesg output for the device.

Post by Allan Jude
This would be the first step to getting a developer setup with a
reliable reproduction platform, so the bug could be tracked down.

[BERTRAND Joël]

Post by Rodney W. Grimes
SO if you want to submit your pciconf -lv,
PLEASE include the dmesg output for the device.

I don't know if it's enough as I cannot reboot with FreeBSD officiel
driver. I use Realtek one :

Mar 24 21:35:06 pythagore kernel: re0: <Realtek PCIe GBE Family
Controller> port 0xe000-0xe0ff mem
0xf7d00000-0xf7d00fff,0xf0000000-0xf0003fff irq 19 at device 0.0 on pci2
Mar 24 21:35:06 pythagore kernel: re0: Using Memory Mapping!
Mar 24 21:35:06 pythagore kernel: re0: Using 1 MSI-X message
Mar 24 21:35:06 pythagore kernel: re0: version:1.94.01
Mar 24 21:35:06 pythagore kernel: re0: Ethernet address: d8:cb:8a:7d:10:59
Mar 24 21:35:06 pythagore kernel: re0: Ethernet address: d8:cb:8a:7d:10:59
Mar 24 21:35:06 pythagore kernel: re0: link state changed to UP

This adapter doesn't work as expected on diskless workstation with
kernel driver. No problem with Realtek driver.

***@pci0:2:0:0: class=0x020000 card=0x78511462 chip=0x816810ec rev=0x0c
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
class = network
subclass = ethernet

Regards,

JKB

[Steven Hartland]

Post by BERTRAND Joël

Post by Rodney W. Grimes
SO if you want to submit your pciconf -lv,
PLEASE include the dmesg output for the device.

I don't know if it's enough as I cannot reboot with FreeBSD officiel
Mar 24 21:35:06 pythagore kernel: re0: <Realtek PCIe GBE Family
Controller> port 0xe000-0xe0ff mem
0xf7d00000-0xf7d00fff,0xf0000000-0xf0003fff irq 19 at device 0.0 on pci2
Mar 24 21:35:06 pythagore kernel: re0: Using Memory Mapping!
Mar 24 21:35:06 pythagore kernel: re0: Using 1 MSI-X message
Mar 24 21:35:06 pythagore kernel: re0: version:1.94.01
Mar 24 21:35:06 pythagore kernel: re0: Ethernet address: d8:cb:8a:7d:10:59
Mar 24 21:35:06 pythagore kernel: re0: Ethernet address: d8:cb:8a:7d:10:59
Mar 24 21:35:06 pythagore kernel: re0: link state changed to UP
This adapter doesn't work as expected on diskless workstation with
kernel driver. No problem with Realtek driver.
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
class = network
subclass = ethernet

I know you said you couldn't do this, but it may well be very useful to
compare this to the output when using the built in FreeBSD driver as it
may highlight a key difference.

I'm thinking given the ages of the Realtek driver we could be looking at
a different operational mode, different MSI-X count etc.

Here's some other links with potentially relevant info:
https://forums.freebsd.org/threads/replacing-realtek-re-driver.55861/
https://unixblogger.com/2011/10/18/the-pain-of-an-realtek-rtl8111rtl8168-ethernet-card/

    Regards
    Steve

[Farhan Khan]

Post by BERTRAND Joël

Post by Rodney W. Grimes
SO if you want to submit your pciconf -lv,
PLEASE include the dmesg output for the device.

I don't know if it's enough as I cannot reboot with FreeBSD officiel
Mar 24 21:35:06 pythagore kernel: re0: <Realtek PCIe GBE Family
Controller> port 0xe000-0xe0ff mem
0xf7d00000-0xf7d00fff,0xf0000000-0xf0003fff irq 19 at device 0.0 on pci2
Mar 24 21:35:06 pythagore kernel: re0: Using Memory Mapping!
Mar 24 21:35:06 pythagore kernel: re0: Using 1 MSI-X message
Mar 24 21:35:06 pythagore kernel: re0: version:1.94.01
Mar 24 21:35:06 pythagore kernel: re0: Ethernet address: d8:cb:8a:7d:10:59
Mar 24 21:35:06 pythagore kernel: re0: Ethernet address: d8:cb:8a:7d:10:59
Mar 24 21:35:06 pythagore kernel: re0: link state changed to UP
This adapter doesn't work as expected on diskless workstation with
kernel driver. No problem with Realtek driver.
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
class = network
subclass = ethernet
I know you said you couldn't do this, but it may well be very useful to

compare this to the output when using the built in FreeBSD driver as it may
highlight a key difference.
I'm thinking given the ages of the Realtek driver we could be looking at a
different operational mode, different MSI-X count etc.
https://forums.freebsd.org/threads/replacing-realtek-re-driver.55861/
https://unixblogger.com/2011/10/18/the-pain-of-an-realtek-rt
l8111rtl8168-ethernet-card/
Regards
Steve
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers

Hi all, I would love to assist and perform testing in any way I can. I have
2 devices running Realtek devices. One is a 4-port NIC. If we can
narrow-down the issue and create a reproduceable failure, I might be able
to hunt through the code to help identify the problem (I am primarily
tapped on rtwn(4), but I would not mind lending an extra pair of eye-balls)

Laptop machine running 12.0-CURRENT:

***@pci0:3:0:0: class=0x020000 card=0x21de103c chip=0x813610ec rev=0x08
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8101/2/6E PCI Express Fast Ethernet controller'
class = network
subclass = ethernet

Think Server running 11.1-RELEASE-p8:

***@pci0:4:0:0: class=0x020000 card=0x012310ec chip=0x816810ec rev=0x07
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
class = network
subclass = ethernet
***@pci0:5:0:0: class=0x020000 card=0x012310ec chip=0x816810ec rev=0x07
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
class = network
subclass = ethernet
***@pci0:6:0:0: class=0x020000 card=0x012310ec chip=0x816810ec rev=0x07
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
class = network
subclass = ethernet
***@pci0:7:0:0: class=0x020000 card=0x012310ec chip=0x816810ec rev=0x07
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
class = network
subclass = ethernet
***@pci0:8:0:0: class=0x060401 card=0x30a517aa chip=0x88931283 rev=0x41
hdr=0x01
vendor = 'Integrated Technology Express, Inc.'
device = 'IT8893E PCIe to PCI Bridge'
class = bridge
subclass = PCI-PCI

[Dieter BSD]

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

***@pci0:4:0:0: class=0x020000 card=0x012310ec chip=0x816810ec rev=0x07 hdr=0x00
***@pci0:5:0:0: class=0x020000 card=0x012310ec chip=0x816810ec rev=0x07 hdr=0x00
***@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
=================================================

Post by Gary Jennejohn

Post by Steven Hartland
http://12244.wpc.azureedge.net/8012244/drivers/rtdrivers/cn/nic/0007-rtl_bsd_drv_v194.01.tgz

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

Post by Gary Jennejohn
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.

[Dieter BSD]

Built a kernel with Realtek's Ethernet driver.
The 8111E & 8111F work, although initial testing using nc(1) is being
a bit strange.

1st testing window:
re0 I tried the same copy a 28 GB file using nc(1) and udp.
The 1st & 3rd try gave the correct number of bytes, but
the 2nd try was short.
The other 2 ports (re1 re2) worked less well.

2nd testing window:
re0 (8111F on Syba 2 port PCIe card [1])
6 times 28 GB file using nc and udp 3 "plain" and 3 with -T reliability
1 "plain" copy worked correctly, the other 5 were short
re1 (2nd 8111F port on PCIe card)
all 5 attempts were short, 3 of 5 were very short:
28132560000 goal
27982918784 big_file_copied_via_udp_re1_0
27981835392 big_file_copied_via_udp_re1_1
587776 big_file_copied_via_udp_re1_2
608256 big_file_copied_via_udp_re1_3
606208 big_file_copied_via_udp_re1_Trel_0
re2 (8111E on UD5 mainboard)
all 6 attempts were short
32452608 big_file_copied_via_udp_re2rt_0
3932160 big_file_copied_via_udp_re2rt_1
399364096 big_file_copied_via_udp_re2_Trel_0
5963776 big_file_copied_via_udp_re2_Trel_1
4159488 big_file_copied_via_udp_re2_Trel_2
4827136 big_file_copied_via_udp_re2_2
28132560000 goal

One burst and then it fails:
input re2 output
packets errs idrops bytes packets errs bytes colls
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
3840 0 0 4078080 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0

For real world use, so far the Realtek driver is working at least as well
as the stock FreeBSD 10.3 driver, probably better. But it does lose data
with real world applications, (2 separate incidents so far) so it needs
improvement.

Some of the test results with nc(1) are kinda screwy. Maybe nc is the
wrong tool, maybe I'm using it wrong, I don't know.

Has anyone tried similar testing?
Suggestions of knobs to turn, or other things to try?

I need to receive data via UDP without dropping packets. Closed source sucks,
but I'm stuck with it, and thus with UDP.

[1] http://www.sybausa.com/index.php?route=product/product&manufacturer_id=11&product_id=130&page=25
$21.22

[Stefan Esser]

Post by Dieter BSD
test results with nc(1) are kinda screwy. Maybe nc is the
wrong tool, maybe I'm using it wrong, I don't know.
Has anyone tried similar testing?
Suggestions of knobs to turn, or other things to try?
I need to receive data via UDP without dropping packets. Closed source sucks,
but I'm stuck with it, and thus with UDP.

Well, but you know that the U in UDP means unreliable?

On a non-congested link, UDP packets should arrive at the receiver,
but the application has to deal with packet loss, since it cannot
be sure that it is used on a reliable link. Packet loss will cause
reduced throughput (as with TCP), unless it can be dealt with by FEC
or other means (which also reduce throughput).

Regards, STefan