Replacing realtek "re" driver

DoBoY

New Member


Messages: 8

I'm been up for 18 days with my compiled driver so far. Performance is very good on a 120Mbit WAN link. I push it to the max for hours and still no more "watchdog timeout" errors anymore.
 

chrcol

Well-Known Member

Reaction score: 22
Messages: 397

guys I managed to purchase a jetway dual port intel i350 mini pcie card for my braswell N3150 NUC.

I did find it odd I only managed to find one retailer worldwide selling it and now its vanished of their website, very odd. It is listed on jetway's site but they dont sell direct.

For those who are looking tho and do have a mini pcie slot, then the model number is ADMPEIDLA and I see there is one on ebay albeit not cheap.

Mine was £50 for a 2 port card, the one on ebay is even more.

However it has been reliable and the shipped igb drivers are compatible.

minipc.de and mercateo have them also actually.
 

mmac

New Member

Reaction score: 4
Messages: 8

Hello everyone! Today i assembled my next DIY home server based on ASRock J4205-ITX running FBSD 11.0-RELEASE-p7. After the installation and initial configuration, i run some first (disappointing) tests on my new hardware. By the way, the machine is pretty good in its power consumption which is about 18 watts in active/idle with two spinning HDDs. The main purpose of the machine should be "headless file serving", therefore it has to feed several gigabytes of AVCHD-Files from my Handycam.

And here is the problem: the NIC is going to say goodbye (watchdog-messages in screen terminal) each time the network traffic goes up by copying large files.

The internal NIC is a:

Code:
re0@pci0:1:0:0:    class=0x020000 card=0x81681849 chip=0x816810ec rev=0x11 hdr=0x00
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device      = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
    class        = network
    subclass   = ethernet
And this is the Reason why i'm now here. I tried to compile the actual driver from Realtek according to the steps described in this thread without success. The point is that the driver version related to the description is v191 but i only found v192 on Realtek's page. Is there any chance that the built-in driver is going to be updated in future FBSD patches, or did i really have to compile the driver by myself? Imho FBSD is currently unusable with Realtek cards, and I dont want to add another (pci-)nic only because there is a software bug. :(

Thank you all! :)
 

mmac

New Member

Reaction score: 4
Messages: 8

I followed the instructions and build my own kernel with the latest realtek driver "if_re.ko" (v192) as a module. First load tests with some large files (+4 Gigabytes) shows no more watchdog interrupts. This workaround works very well.

Thank you all! :)
 

SpaceAdventureCobra

New Member


Messages: 3

Hi. I have just finished building my pfsense firewall with 2x onboard NICs, and having some trouble with the firewall becoming non-responsive from time to time, I have come here to this forum post, because my logs says re0: watchdog timeout.

I googled before I bought my system and I read that Realtek 8168 NICs was stable. This is my motherboard; https://www.gigabyte.com/Motherboard/GA-J3455N-D3H-rev-10#ov - but it is not stable,, after putting VLANs etc on the LAN side of it and pushing heavy traffic it sometimes requires shutting it off and on due to NICs becoming unresponsive (it does answer ping requests though, but no routing..)

Anyways;

Reading this forum post, and this one - https://forums.freebsd.org/threads/55306/ I am thinking the solution will be to load the Realtek driver as a module. It has now updated to v1.94, http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false - and I am wondering if anyone has success with using that one? I cannot seem to find the other versions of this driver.

Running pfsense with a 2.4.2-RELEASE-p1 (amd64)
built on Tue Dec 12 13:45:26 CST 2017
FreeBSD 11.1-RELEASE-p6

Code:
[2.4.2-RELEASE][root@pfSense.localdomain]/root: pciconf -v -l
re0@pci0:3:0:0:   class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x0c hdr=0x00
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
re1@pci0:4:0:0:   class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x0c hdr=0x00
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
[2.4.2-RELEASE][root@pfSense.localdomain]/root:
 

SpaceAdventureCobra

New Member


Messages: 3

Anyone else having trouble with this, I found some more information here: in comment #42 the user "franco" stated (...) Realtek released the FreeBSD driver version 1.93 with built-in support for FreeBSD 11.0. All the more reason to go forward (...)
https://forum.opnsense.org/index.php?topic=4183.30

And it seems to me that the existing Realtek driver from FreeBSD should have been replaced by version Opnsense 17.1.2,, and downloading it now Opnsense is version 17.7.5, so it should work "out of the box" without any fiddling.

Hm, already started to know my way around pfsense, such a shame to switch to Opnsense :)

Now if someone could just point to to the "doubleclick this" install_new_driver_realtek_setup.exe file to setup the new drivers :eek:
 

borjam

New Member


Messages: 3

I have had similar problems with a NUC6AYH, with one of those hideous re GbE interfaces. Unfortunately it's not possible to replace it.

In my case it kinda worked, but I tried to do something a bit stupid (like running an Elasticsearch node on it, and, to make it worse, using a iSCSI volume as its storage) and the interface would die with a watchdog error after a minute or so.

I am running 11.1-STABLE from two or three weeks ago. I reproduced the problem several times and, interestingly, when forcing a reboot with the interface frozen I got this error:

Code:
<5>re0: link state changed to UP
re0: watchdog timeout
<5>re0: link state changed to DOWN
<5>re0: link state changed to UP
Waiting (max 60 seconds) for system process `vnlru' to stop... done
Waiting (max 60 seconds) for system process `syncer' to stop... g_vfs_done():da0[WRITE(offset=14498955264, length=131072)]error = 6
g_vfs_done():da0[WRITE(offset=14499086336, length=131072)]error = 6
g_vfs_done():da0[WRITE(offset=14499250176, length=131072)]error = 6
g_vfs_done():da0[WRITE(offset=21167616, length=1024)]error = 6
panic: cannot reassign paging buffer
cpuid = 0
KDB: stack backtrace:
#0 0xffffffff806e5bb7 at kdb_backtrace+0x67
#1 0xffffffff8069fb26 at vpanic+0x186
#2 0xffffffff8069f993 at panic+0x43
#3 0xffffffff80762043 at reassignbuf+0x273
#4 0xffffffff8074336e at bdirty+0x2e
#5 0xffffffff807421ca at brelse+0x10a
#6 0xffffffff80744cc7 at bufdone+0x87
#7 0xffffffff805f26b2 at g_io_deliver+0x202
#8 0xffffffff805ef952 at g_disk_done+0x122
#9 0xffffffff802df933 at dadone+0x18a3
I have updated to the latest driver downloaded from here,

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

It was simple. Compiling a kernel without the re device, compiling this module and replacing the if_re.ko from the kernel directory with this new one.

It had a silly problem when compiling but it was trivial to fix. It failed to find one of its include files because it searched for a different path.

Other than that it's running solid for several hours now. It is losing a packet now and then (I am keeping a ping to check that), but nothing serious.
 

tingo

Daemon

Reaction score: 371
Messages: 1,966

Did you also create a bug report for the bug with the FreeBSD driver related to your hardware?
 

borjam

New Member


Messages: 3

Not yet. Besides, it survived for several hours but the driver crashed this morning.

The machine is alive but the network interface is failing. So, something else to look at :/

I'll create a bug report if I can get more information. And unfortunately it's not possible to replace the bloody Ethernet interface. It's on the motherboard and there's no PCI slots to install a proper card. Sigh.
 

logic

New Member

Reaction score: 1
Messages: 1

Just an update for this thread for FreeBSD 11.2-RELEASE in December 2018:
  1. At this time, RealTek have reorganized their site. It is no longer possible to create a download link directly to a software download. Instead, you navigate to the download you want, provide your e-mail address, and then receive an e-mail with a link in it. After following the link, my experience was that you get 120 seconds within which to successfully answer a CAPTCHA before which the link becomes permanently invalid (for me it was a simple mathematical question, and the CAPTCHA result was the mathematical answer, not literally the characters from the CAPTCHA -- it says "6 + 3", the CAPTCHA answer is "9"). I have no idea why their FreeBSD driver source code is protected by such a complicated mechanism, but in order to download the latest driver, at the time of writing, you should follow these steps:
    1. Browse to www.realtek.com.
    2. For me, the page loads in Traditional Chinese, but this can be changed to English with a drop-down in the top-right.
    3. Open the hamburger menu and select Downloads -> Computer Network ICs.
    4. Select any 8111 or 8168 item in the list and click "Software". For the FreeBSD driver, they all ultimately direct you to the identical download link.
    5. In the list of downloads, look for the section titled "Unix (Linux)", under which there is an item "FreeBSD 7.x and 8.0".
    6. Click "Download" to begin the dance described above.
  2. The latest driver as I write this is version 1.95, and despite the specific ancient FreeBSD versions listed on their site, it does not require patching to build and work as-is on 11.2-RELEASE. It actually contains sections separated off by [FONT=Courier New]#if OS_VER < VERSION(11,0)[/FONT], so the code is fully-aware of the latest kernel versions.
  3. The steps described earlier in this thread by Shadowcaster on October 11, 2016 work, omitting the patching referenced in step 6. Simply place the two files from the 1.95 / 0008 source distribution into the [FONT=Courier New]sys/dev/re[/FONT] directory and build.
  4. After rebooting to a kernel that treated [FONT=Courier New]if_re[/FONT] as a module, I was apparently able to switch from the old module to the new one without rebooting, simply using [FONT=Courier New]kldunload if_re[/FONT] followed by [FONT=Courier New]kldload if_re[/FONT]. The log output from the [FONT=Courier New]kldload[/FONT] command indeed lists the loaded version as being 1.95, whereas the bundled driver did not output a version at all.
  5. For anyone curious, there is rather a substantial difference between the bundled driver and that supplied by Realtek. For starters, the code is literally an order of magnitude larger. Both files are attributed to Bill Paul, with actually a newer year in the smaller file in the FreeBSD source distribution. The larger file from Realtek appears to contain functions that send microcode to the NIC controller chips. I am assuming the older attribution in Realtek's version is simply a result of the code having diverged from an earlier version and then been maintained and upgraded without changes to the attribution. :)
 

opmetal

New Member


Messages: 7

This worked perfectly! Thanks, Logic.

Just an update for this thread for FreeBSD 11.2-RELEASE in December 2018:
  1. At this time, RealTek have reorganized their site. It is no longer possible to create a download link directly to a software download. Instead, you navigate to the download you want, provide your e-mail address, and then receive an e-mail with a link in it. After following the link, my experience was that you get 120 seconds within which to successfully answer a CAPTCHA before which the link becomes permanently invalid (for me it was a simple mathematical question, and the CAPTCHA result was the mathematical answer, not literally the characters from the CAPTCHA -- it says "6 + 3", the CAPTCHA answer is "9"). I have no idea why their FreeBSD driver source code is protected by such a complicated mechanism, but in order to download the latest driver, at the time of writing, you should follow these steps:
    1. Browse to www.realtek.com.
    2. For me, the page loads in Traditional Chinese, but this can be changed to English with a drop-down in the top-right.
    3. Open the hamburger menu and select Downloads -> Computer Network ICs.
    4. Select any 8111 or 8168 item in the list and click "Software". For the FreeBSD driver, they all ultimately direct you to the identical download link.
    5. In the list of downloads, look for the section titled "Unix (Linux)", under which there is an item "FreeBSD 7.x and 8.0".
    6. Click "Download" to begin the dance described above.
  2. The latest driver as I write this is version 1.95, and despite the specific ancient FreeBSD versions listed on their site, it does not require patching to build and work as-is on 11.2-RELEASE. It actually contains sections separated off by [FONT=Courier New]#if OS_VER < VERSION(11,0)[/FONT], so the code is fully-aware of the latest kernel versions.
  3. The steps described earlier in this thread by Shadowcaster on October 11, 2016 work, omitting the patching referenced in step 6. Simply place the two files from the 1.95 / 0008 source distribution into the [FONT=Courier New]sys/dev/re[/FONT] directory and build.
  4. After rebooting to a kernel that treated [FONT=Courier New]if_re[/FONT] as a module, I was apparently able to switch from the old module to the new one without rebooting, simply using [FONT=Courier New]kldunload if_re[/FONT] followed by [FONT=Courier New]kldload if_re[/FONT]. The log output from the [FONT=Courier New]kldload[/FONT] command indeed lists the loaded version as being 1.95, whereas the bundled driver did not output a version at all.
  5. For anyone curious, there is rather a substantial difference between the bundled driver and that supplied by Realtek. For starters, the code is literally an order of magnitude larger. Both files are attributed to Bill Paul, with actually a newer year in the smaller file in the FreeBSD source distribution. The larger file from Realtek appears to contain functions that send microcode to the NIC controller chips. I am assuming the older attribution in Realtek's version is simply a result of the code having diverged from an earlier version and then been maintained and upgraded without changes to the attribution. :)
 

xenospn

New Member

Reaction score: 1
Messages: 1

has anyone tried Realtek "re" driver on new FreeBSD 12.0, yet?
Seems like it's the same driver from 11.2.

Also, FYI: The RealTek 1.95 driver fails to build on 12.0-RELEASE:

Code:
/usr/src/sys/dev/re/if_re.c:7507:9: error: no member named 'tqh_first' in 'struct ifmultihead'; did you mean 'cstqh_first'?
        TAILQ_FOREACH(ifma,&ifp->if_multiaddrs,ifma_link)
        ^
/usr/src/sys/sys/queue.h:725:15: note: expanded from macro 'TAILQ_FOREACH'
        for ((var) = TAILQ_FIRST((head));                               \
                     ^
/usr/src/sys/sys/queue.h:722:36: note: expanded from macro 'TAILQ_FIRST'
#define TAILQ_FIRST(head)       ((head)->tqh_first)
                                         ^
/usr/src/sys/net/if_var.h:94:1: note: 'cstqh_first' declared here
CK_STAILQ_HEAD(ifmultihead, ifmultiaddr);
^
/usr/src/sys/contrib/ck/include/ck_queue.h:232:15: note: expanded from macro 'CK_STAILQ_HEAD'
        struct type *cstqh_first;/* first element */                    \
                     ^
/usr/src/sys/dev/re/if_re.c:7507:9: error: no member named 'tqe_next' in 'struct ifmultiaddr::(anonymous at /usr/src/sys/net/if_var.h:554:2)'; did you mean 'cstqe_next'?
        TAILQ_FOREACH(ifma,&ifp->if_multiaddrs,ifma_link)
        ^
/usr/src/sys/sys/queue.h:727:14: note: expanded from macro 'TAILQ_FOREACH'
            (var) = TAILQ_NEXT((var), field))
                    ^
/usr/src/sys/sys/queue.h:831:46: note: expanded from macro 'TAILQ_NEXT'
#define TAILQ_NEXT(elm, field) ((elm)->field.tqe_next)
                                             ^
/usr/src/sys/net/if_var.h:554:2: note: 'cstqe_next' declared here
        CK_STAILQ_ENTRY(ifmultiaddr) ifma_link; /* queue macro glue */
        ^
/usr/src/sys/contrib/ck/include/ck_queue.h:241:15: note: expanded from macro 'CK_STAILQ_ENTRY'
        struct type *cstqe_next;        /* next element */                      \
 

RobCrowston

New Member


Messages: 2

Also, FYI: The RealTek 1.95 driver fails to build on 12.0-RELEASE:

Code:
/usr/src/sys/dev/re/if_re.c:7507:9: error: no member named 'tqh_first' in 'struct ifmultihead'; did you mean 'cstqh_first'?
        TAILQ_FOREACH(ifma,&ifp->if_multiaddrs,ifma_link)
        ^
This can be repaired by invoking sed -i -e 's/TAILQ_FOREACH/CK_STAILQ_FOREACH/g' if_re.c.
 

fkoczan

New Member

Reaction score: 1
Messages: 1

I have made FreeBSD 12 package.
I dont consider it my work - I have just packed it in one archive. It is stable for me on 12.0 p3 more than
"sed -i -e 's/TAILQ_FOREACH/CK_STAILQ_FOREACH/g' if_re.c"
trick and I have compared my binary with above binary. Above sims to hang on high load from Intel card at my bench.
 

FabricioGuzzy

Member


Messages: 27

I have made FreeBSD 12 package.
I dont consider it my work - I have just packed it in one archive. It is stable for me on 12.0 p3 more than
"sed -i -e 's/TAILQ_FOREACH/CK_STAILQ_FOREACH/g' if_re.c"
trick and I have compared my binary with above binary. Above sims to hang on high load from Intel card at my bench.
Hello Fkoczan,
I just compiled your MOD version of it (V1.95) . Now testing (Burn in) - So far, so good.
Is that working fine for you after all?

Thanks Much!
Fabricio.
 
Top