Fails to load after Jun 15 update

jimp

Unfortunately, we might have to pull them back out. Apparently they break altq with igb. :(

foonus

Forgive my ignorance, but why would newer drivers be causing so much trouble in pfSense?
This whole issue was brought about by updating a Broadcomm driver, and now from what you are saying the Intel updated driver causes issues for some people as well.

Are both these drivers not released for FreeBSD by both companies? Isn't it their job to ensure that these things are tested before the drivers are released? Is this a quality control issue, or simply the fact that they are testing them on a kernel newer than what pfSense is running?

Rather disappointing that these large companies can release drivers in this state when they have people paid to maintain quality control, and the grief falls on the users and developers of this project that aren't being paid to deal with it.

jimp

@foonus:

Forgive my ignorance, but why would newer drivers be causing so much trouble in pfSense?
This whole issue was brought about by updating a Broadcomm driver, and now from what you are saying the Intel updated driver causes issues for some people as well.

Are both these drivers not released for FreeBSD by both companies? Isn't it their job to ensure that these things are tested before the drivers are released? Is this a quality control issue, or simply the fact that they are testing them on a kernel newer than what pfSense is running?

Rather disappointing that these large companies can release drivers in this state when they have people paid to maintain quality control, and the grief falls on the users and developers of this project that aren't being paid to deal with it.

Well we are on FreeBSD 8.3, the newer drivers are from 8-STABLE or HEAD/CURRENT. Sometimes the drivers depend on other features that are found there, but that we do not yet have. Usually they work fine, but on occasion there are changes to other subsystems that cause more subtle breakage.

foonus

In my case i am lucky since its running well now, will likely be using this snapshot until one is released with newer (fixed& > 2.3.9) Intel drivers due to the performance impact I have seen.

pfSense loads (now): <intel(r) 8="" 1000="" pro="" network="" connection="" version="" -="" 2.3.9="">- Works great for my setup - noticeable performance increase from 2.3.1
pfSense loads (before): <intel(r) 1000="" pro="" network="" connection="" version="" -="" 2.3.1="">- Over 2 years old, no longer supported by Intel!

Interesting that the Intel website shows the following for drivers:
2.3.8: This driver has been developed for FreeBSD 9.x kernel
2.3.7: This driver has been developed for use with FreeBSD 7.x kernel

7.x straight to 9.x right from Intel with no 8.3 in between. Also leads me to believe that the original 2.3.1 was for FreeBSD 7.x or prior.

What a mess.</intel(r)></intel(r)>

jimp

@foonus - Do you use traffic shaping? Have you tried using the shaper wizard with those igb drivers?

foonus

Luckily I don't run traffic shaping in this location, thus the reason I have made a hard copy of this snapshot with the new drivers!
I ran a test for you to confirm that there was a problem, simply ran the wizard to create it and it came back with:

There were error(s) loading the rules: pfctl: igb1: driver does not support altq - The line in question reads [ 0]:…

If you need any more done, let me know, will be glad to help.

jimp

There may not be much more we can do for now. I deactivated that last igb/em update. We could maybe compile a module that could be used/loaded as an alternate driver using that code.

Once we get 2.1 done, we'll be focusing on 2.2 on FreeBSD 10 which is leaps and bounds newer than what we have, driver-wise, all around.

athoik

Hello,

Same issue occurs with 2.1.RC0 (on vmware esxi 5.1).

The issue happens only on Pfsense17 with memory 6G. All others instances have 2G memory and no problem yet.

crash.png_thumb

athurdent

This could be totally unrelated, but I noticed the process bsnmpd there. I remember having an issue some time ago when using more that one virtual CPU/Core and collecting CPU info via SNMP (using Cacti). Turning off the CPU check or reducing the VM to only one CPU stopped the crashes.

msi

argh, yes they were backed out - but reason is valid:
https://github.com/pfsense/pfsense-tools/commit/0d63350445dad1e7281ba085cd9fa0e0fdd7e261