[SOLVED] Zotac nano ci323 LAN Drops after a few days

Started by brady1408, January 02, 2017, 02:59:20 AM

Previous topic - Next topic
Working kernel module for FreeBSD 10.3 and opnsense 16.7.  Compiled from realtek source V1.92.

tested on opensense 16.7.  Running for two days streaming directv now.  Installer included.

Working kernel module for FreeBSD 11 and opnsense 17.1.  Compiled from realtek source V1.92.

tested on opensense 17.1.  It was tested for kernel loading and general i/o.  not load tested.  Installer included.

January 26, 2017, 06:31:24 PM #17 Last Edit: January 26, 2017, 06:34:14 PM by franco
Question: How does this even compile under FreeBSD 11.0 when taskqueue_enqueue_fast() is not in the OS anymore? I don't see a replacement for taskqueue_enqueue(). ;)

It's also useful to know that the module cannot be loaded without a replacement kernel without re, right?

for bsd11 I found this patch, don't remember where ether pfsense or FreeBSD forums:

--- if_re.c 2016-07-19 13:50:27.716636000 -0400
+++ if_re.c.Patched 2016-07-19 13:52:06.534495000 -0400
@@ -47,6 +47,8 @@
* This driver also support Realtek 8139C+, 8110S/SB/SC, RTL8111B/C/CP/D and RTL8101E/8102E/8103E.
*/

+#define       M_DONTWAIT      M_NOWAIT
+
#include <sys/param.h>
#include <sys/systm.h>
#include <sys/sockio.h>
@@ -57,6 +59,7 @@
#include <sys/taskqueue.h>

#include <net/if.h>
+#include <net/if_var.h>
#include <net/if_arp.h>
#include <net/ethernet.h>
#include <net/if_dl.h>
@@ -5529,7 +5532,7 @@

                 sc->re_desc.tx_last_index = (sc->re_desc.tx_last_index+1)%RE_TX_BUF_NUM;
                 txptr=&sc->re_desc.tx_desc[sc->re_desc.tx_last_index];
-                ifp->if_opackets++;
+ if_inc_counter(ifp, IFCOUNTER_OPACKETS, 1);
                 ifp->if_drv_flags &= ~IFF_DRV_OACTIVE;
         }

@@ -5672,7 +5675,7 @@
                 }

                 eh = mtod(m, struct ether_header *);
-                ifp->if_ipackets++;
+ if_inc_counter(ifp, IFCOUNTER_IPACKETS, 1);
#ifdef _DEBUG_
                 printf("Rcv Packet, Len=%d \n", m->m_len);
#endif
@@ -5747,7 +5750,7 @@
#if OS_VER < VERSION(7,0)
         re_int_task(arg, 0);
#else
-        taskqueue_enqueue_fast(taskqueue_fast, &sc->re_inttask);
+        taskqueue_enqueue(taskqueue_fast, &sc->re_inttask);

         return (FILTER_HANDLED);
#endif
@@ -5827,7 +5830,7 @@

#if OS_VER>=VERSION(7,0)
         if (CSR_READ_2(sc, RE_ISR) & RE_INTRS) {
-                taskqueue_enqueue_fast(taskqueue_fast, &sc->re_inttask);
+                taskqueue_enqueue(taskqueue_fast, &sc->re_inttask);
                 return;
         }
#endif


as for loading the module without replacing the kernel it woks as long as you set it to load (if_re_load="YES") in loader.conf.local.  I verified this by checking dmesg, Version 1.92 loaded.  You can not mix kernel modules with different OS's 10.3, 11.  the kernel module must be compiled for that kernel/OS version  but, I suspect you already know that.

I don't mean to impede any development.  if you can get the proper driver built into 17.1 please do.  Please, please!

Franco, 

I did not apply the patch to the 10.3 module only the 11 module.  Do you think I should have?  Do you have a better Patch?

Hey,

Ok, better. :) I posted a similar patch: https://github.com/opnsense/src/commit/fc62dbeab5043

I built a full kernel with the new driver by replacing the FreeBSD one: https://github.com/opnsense/src/commit/9ab694091b

On OPNsense 17.1, this kernel can be installed by just running the command(s):

# opnsense-update -kr 17.1-re
# /usr/local/etc/rc.reboot

Last but not least, this kernel doesn't need a loader.conf fixup.

If it works for all testers we will consider merging it into an OPNsense 17.1.x release.


Cheers,
Franco

Great!  Thanks!  I will start testing your kernel when 17.1 is stable I guess on the 31th.  My wife will kill me if the router crashes while I am at work.  I hope this gets backported to FreeBSD.  According the forums the pfsense and freenas guys are having trouble too.

I have a Qotom Thin Mini PC with Intel Celeron j1900 processor onboard, quad core 2.42 GHz, 4GB RAM 64GB SSD, dual LAN dual display serial port(thank goodness for copy and paste).
I initially installed OPNSense, but it kept failing. Wife and family would contact me, irate as they were unable to go online.
Then I tried Sophos, and that too failed.
Then I tried the one that starts with a P, and had pretty good luck with that. It would run dangerously warm and only locked up a few times.
I was bored this past Tuesday and took it back down and re-installed OPNSense, RC1 and have all of my traffic running through the proxy for one machine only.  The four cores are running about 40 C and the sensor on the unit says 27 C.
So, with all of that in mind, is it possible that your unit locked up due to heat issues? Once they get warm, they do some really wonky things.

February 06, 2017, 07:53:43 PM #23 Last Edit: February 06, 2017, 08:30:28 PM by the-mk
Quote from: franco on January 26, 2017, 10:31:33 PM
...
# opnsense-update -kr 17.1-re
# /usr/local/etc/rc.reboot
...
Cheers,
Franco

did the update of the kernel as you described - after rebooting the OPNsense-box - it was still working :) can browse the net and write this post!

now performing some iperf tests between two BananaPis, one at LAN (client), one at WAN (server). Seems like I have a "weak" network-cable since it only transfers with around 100Mbps - but it is still transferring!

How long should it take until it fails with the old driver/kernel?

EDIT: after replacing that 100Mpbs cable it was hitting the OPNsense box with iperf for more than 30 minutes and I still can post here without any reboot :)

I like the new driver - thank you franco!

Thanks for the report. :)

I'm still waiting for another user and a test on a hardware that I have here, but it looks good and the change will be queued up for the development track soon. And if that works out ok we may be looking at inclusion in a 17.1.x release in a month or so.


Cheers,
Franco

Quote from: franco on February 07, 2017, 09:06:31 AM
Thanks for the report. :)

I'm still waiting for another user and a test on a hardware that I have here, but it looks good and the change will be queued up for the development track soon. And if that works out ok we may be looking at inclusion in a 17.1.x release in a month or so.


Cheers,
Franco

Hi,
i have CI323 with 16GB memory and 128GB SSD.
I just found this post , and i will test today if is working.
Currently i'm using a gigabit pppoe connection and hang at upload.
Let's see after patch.

just tried latest kernel on ci323 and it's working great.
Also note that enabling powerd, with hiadadaptive it's working ok with pppoe connnection.

Thanks, I'll upload another kernel for 17.1.1 in a few days, likely changing to the driver by default in 17.1.2 if all goes well.

after about 48 hours still online with the new networkdriver/kernel...
rebooted after the "loadtest" with iperf to reset interface statistics and had around 2 GB traffic since then (didn't have the chance stream a movie this week...).
looking forward to the next update - are there special steps to do before the next upgrade or does the "manually changed" kernel stay?

Not yet, need to reinstall after upgrade to normal 17.1.1 kernel for safety reasons.

If IPS tests work well here locally I'm very sure 17.1.2 will switch re(4) permanently.


Cheers,
Franco