Jetway JNF9D-2550 + Jetway AD3RTLANG 3 x Gigabit LAN Port Daughter Board
-
@JoeMcJoe:
edit: I just did the update and it does show all of the 5 re0 to re04 Ethernet ports available, plus 5 USB ports for some reason.
Update to a pfSense 2.1 snapshot build?
@JoeMcJoe:
If I install the latest 2.1 snapshot and I find issues with other parts of the install, is it easy to step back to 2.0.2, using the firmware update option?
You might lose access to ports re0 and re1 if you go back. Does that matter?
I suspect the re driver in pfSense 2.0.2 (based on FreeBSD 8.1) doesn't get the response it expects when the driver is attempting to initialise them but the driver in pfSense 2.1 (based on FreeBSD 8.3) does. It might be informative to compare the startup output of the two versions. The pfSense shell command dmesg will display the startup output of the most recently loaded operating system.
-
yes, I updated to this snapshot build.
2.1-BETA1 (i386) - built on Fri Dec 21 04:09:13 EST 2012 - FreeBSD router.tetch.com 8.3-RELEASE-p5 FreeBSD 8.3-RELEASE-p5 #1: Fri Dec 21 04:35:58 EST 2012 root@snapshots-8_3-i386.builders.pfsense.org:/usr/obj./usr/pfSensesrc/src/sys/pfSense_SMP.8 i386I only need 3 ports at the moment, but its good to know that the other main two re0/re1 are recognised by the new version of the OS.
I didn't keep a copy of the older dmesg output.thanks very much for your help
-
Is it ok to run the 64 bit version of Pfsense on this system?
Intel shows the cpu being used as 64 bit capable.http://www.jetwaycomputer.com/NF9D.html
http://ark.intel.com/products/65470/Intel-Atom-Processor-D2550-%281M-Cache-1_86-GHz%29When installing the software, the pfsense menu graphics were all messed up, only half the characters were readable sometimes, made it tricky.
-
Hmm I thought a fix had gone in for that.
http://redmine.pfsense.org/issues/2595Steve
-
I did the original install with 2.0.1, looks like that was fixed in the 2.1 beta release, from reading that report.
-
Hello,
me too I have the same problem on pfSense 2.0.2.I saw the link http://redmine.pfsense.org/issues/2595 and the other http://freshbsd.org/commit/freebsd/r237203
My question is:
Can it work if I change the file head/sys/dev/fb/fbreg.h, as in the link above, on my pfSense 2.0.2?
Thanks, bye. -
See http://forum.pfsense.org/index.php/topic,58150.0.html to fix the issue with the onboard NICs not showing up in 2.0.2. The solution is for i386 only
-
I saw that link (thank you the same), but I have x64 version. :(
-
I have compiled the driver for x64 systems. You can download it here http://forum.pfsense.org/index.php/topic,58150.msg311249.html. I have not tested it since my router is currently running i386 build.
-
Really, thank you very much I'll try.
Thanks -
Update: I think that your x64 drivers works… 'cause from the pfSense interface I can see my other 2 NICs!! Thanks again! :)
-
@IuZ:
Update: I think that your x64 drivers works… 'cause from the pfSense interface I can see my other 2 NICs!! Thanks again! :)
You are welcome, I'm glad it worked.
-
Hi,
I'm running the exact same hardware setup (well, CPU frequency appart, it's a NF9D-2700+AD3RTLANG), and I'm experiencing very nasty things with both onboard Realtek 8111EVL NICs (let's call them 8111EVIL). When network activity goes up, they completly go mad and error message shows "reX: watchdog timeout" with link going up and down continuously.I first check cables and all, and checked that nor BIOS nor hardware was in cause: I can reproduce the problem with 100% success on pfsense beta 2.1 (so with the re driver from FreeBSD 8.3) on i386 and amd64. OpenWRT (linux 3.3.8 kernel) doesn't seem to show the symptom (although the test slightly differed, the pfsense box was recieving traffic, not the desktop):
+-----pfsense---+ | | 8111EVL 8110SC | | DMZ LAN | | server switch GS108Tv2 | Desktop
I generate traffic from the server to the desktop box (using nc on both machine). This traffic saturate the gigabit link, and immediatly the DMZ NIC (so the 8111EVIL interface) goes "watchdog timeout".
If I do generate traffic from desktop to server, it won't trigger it (same commands).It's not only a matter of raw throughtput (as for packet per second, I don't know) because my WAN interface which is the other 8111EVIL NIC and is connected to a 100Mbps fiber transciever suffers from this too (and traffic can vary from 20Mbps to 60Mbps in both way, "watchdog" symptom seems really random).
What I tried:
Disabling MSI/MSI-X: no impact.
Disabling all "hardware accelerated" stuff: no impact.My question is: what can I try next? What data can I gather if I can help for a freebsd re driver fix?
-
Not terribly constructive I know but I paid the extra and got the intel daughter card. May be a cost effective fix, for 3 decent ports.
-
Not terribly constructive I know but I paid the extra and got the intel daughter card. May be a cost effective fix, for 3 decent ports.
The 3 realtek ports on daughter-board are fine (8110SC). Used them for years (had them on a previous jetway mobo that "died").
The 2 realtek ports on the mother board are causing trouble (8111EVL). -
I'm experiencing very nasty things with both onboard Realtek 8111EVL NICs (let's call them 8111EVIL). When network activity goes up, they completly go mad and error message shows "reX: watchdog timeout" with link going up and down continuously.
I SUSPECT your 8111EVL devices are PCI-Express devices and the devices on the daughter card are PCI devices sharing a single PCI bus. It is likely then that the 8111EVL devices can accept data at a much higher rate than it leave the box out the daughter card devices which are limited by the PCI bus speed. Consequently data going out the daughter card devices (under heavy load) will "bank up" on the transmit queue of the daughter card device and (if the driver is dumb about this) the transmit watchdog timer will go off because it takes "too long" for the transmit queue to empty.
Data from the DMZ to the internet could suffer a similar problem, not because of bus speed limitations but because the channel speed to the internet is much slower than the channel speed to the server.
Are you interested in doing some experiments to attempt to tune things a bit better? I suggest reassigning your interfaces so the daughter card provides the pfSense WAN interface and the two onboard devices are used for LAN and DMZ. Then try your test again from DMZ to LAN and see if any watchdog timeouts are reported and note the interface reporting them.
Please also post the output of pfSense shell commands:```
dmesg
pciconf -l
sysctl -a | grep re
/etc/rc.bannerThe re driver MIGHT provide some tunables that could be adjusted to attempt to stop the messages. @elgo: > I generate traffic from the server to the desktop box (using nc on both machine). This traffic saturate the gigabit link, What sort of traffic is this? I presume some sort of datagram traffic (UDP?) rather than TCP. @elgo: > If I do generate traffic from desktop to server, it won't trigger it (same commands). In that direction incoming data rate is limited by the PCI bus and will be lower than the rate at which traffic can leave the system over the PCI Express bus so is unlikely to back up on the transmit queue.
-
I don't know if this will help you.
I have run the iperf on both the onboard and daughter network ports, as a server, I was maxing out at about 500 Mbps.
The CPU was almost at 100%, I assume that is where the slowdown was.Have you tried an internal iperf test from a PC on a gigabit network?
-
Thank you for your interest, gentlemen.
@wallabybob: you are totally right about PCIe/8111EVL and PCI/8110SC.
As for re driver tunable, I tried MSI/MSIX and intr_filter but not hw.re.prefer_iomap which I don't understand. No luck. Though I see a dev.re.%d.int_rx_mod I didn't test… well, can be worth the try.
As for the shell commands, I'll post their output soon, as for now the pfsense box has been temporary taken out of "the production network" :).Yesterday I simplified my test case (which may be what you thought about, JoeMcJoe):
+-----pfsense---+ | 8111EVL | DMZ | server
I generate traffic from the server (TCP traffic or UDP with -u option, it doesn't affect results: cat /dev/zero | nc -vv -u pfsense_IP pfsense_port) and recieve it on pfsense box (nc -l other_options_i_dont_remember > /dev/null).
"reX: watchdog timeout" visible on dmesg output on pfsense box and on its VGA console.
Same test with pfsense generating traffic and server recieving it won't trigger this error message.
During this test, no CPU core on pfsense box was used at 100% (maybe a core at 70% max by NIC related "intr" thread. Remember it's a 4 cores as it's a hyperthreaded dual atom).So the PCIe/PCI rate problem was a smart guess, but It's not involved in this test case.
-
Please also post the output of pfSense shell commands:```
dmesg
pciconf -l
sysctl -a | grep re
/etc/rc.bannerI filtered the output of sysctl to what seems really related to re.
-
Thanks for the additional information.
When you run the "nc" test which pfsense interface is the server connected to? DMZ (re1)?
Which interfaces are reported in the "rex: watchdog timeout" messages? (The driver includes the comment Tx completion interrupt which seems to be lost on PCIe based controllers under certain situations. but the watchdog function also looks for received frames.)
Interface re0 runs a bunch of VLANs including (apparently) a VLAN for the PPPoE WAN interface. Correct?
Which interfaces are members of the bridge interface?
Are you using jumbo frames?