Recent Intel Ethernet driver fixes for FreeBSD
-
I just had to reinstall my spare pfsense machine with a nightly of October 11th 2012.
After an upgrade it rebooted and entered a bootloop.Because "cron" is an optional package in pfsense, my custom commands to turn off hardware vlan tagging haven't been executed yet (ifconfig em0 | grep -q VLAN_HWTAG && ifconfig em0 -vlanhwtag).
If I do an "ifconfig em0" it doesn't return "VLAN_HWTAGGING" anymore.It seems FreeBSD (or its driver) is now able to properly detect the absence of VLAN hardware tagging.
Can anyone confirm this?Can anyone confirm if this new driver is used in this version of pfsense?
-
FYI- Cron is an optional package but it is only an interface to the config.xml cron entries which are not optional. The lack of a cron package has zero bearing on cron jobs being executed. Same with shellcmd (which would be better for what you're doing than cron). The tag support is always present, the packages just offer you a way to view/manage them via the GUI.
As far as I can see, the drivers haven't been changed.
-
You are right…..!!!
I disabled this cronjob, rebooted the machine and now VLAN_HWTAGGING is still enabled by default.
I now also know why I thought cron wasn't running...
I did a "ps -ef | grep cron" on that console. When I didn't see "cron" I thought it wasn't running.
This isn't linux, but FreeBSD; Â I should have used 'ps x | grep cron'On another occasion I couldn't reach the pfsense until I entered these commands manually. Maybe I should have waited a bit longer then.
Although this cronjob fixes the problem I'm having with this motherboard and it's also saved in the config.xml, but I still don't think it's that elegant.
On a debian based system I would use a script in the folder /etc/network/if-up.d/
This script would execute everytime the interface goes up.
I didn't dare to put this script merely as an upstart job.Could you suggest a better method?
And even better….. why aren't VLAN's working whilst VLAN_HWTAGGING is enabled on this machine?Maybe I should just wait until these new drivers are being used on the nightly builds.
Do you know what they are waiting for?My redmine ticket with the request to have a checkbox to turn off VLAN_HWTAGGING got rejected.
One can already turn off "hardware checksum offloading" and some other features, so I don't really understand why.
It would help me a lot and also other users of this Intel motherboard that (on paper) looks like a perfect platform for pfsense.
It also took me a lot of time to find out it was the reason why I couldn't get my pfsense config working.
Surely a lot more than merely adding this option to pfsense.Are you in a position to get this changed?
-
frater, I don't think your problem is related to those recent intel driver fixes, so it would be much better to create own thread.
-
Should I post bounty for tarring up recent driver fixes or? :-\
-
Those experiencing issues with their Intel cards can thank Mat Simon for adding various patches for e1000 from FreeBSD 8-STABLE to pfSense 2.1-DEVEL:
https://github.com/bsdperimeter/pfsense-tools/commit/d1014000b73f995019d2c01badca659e49dad6e0
-
Sooo if I update to latest snapshot, this should be in?
And thanks to anyone involved!
-
If you take a snapshot from November 17th and thereafter yes.
I merely took the fixes from 8-STABLE, no heavy-lifting backports from the 9-STABLE, but I guess this is what you've been looking for.
(I'm mostly interested in the igb multiqueue patch, since I'm working with a multicore box and I350's here)Since I used git cherry-pick, the patches contain the commit message so you can check if it's what you've been waiting for.
I spent some time to identify and nuke disabled patches in the RELENG_8_3 directory, the ones mentioned initially are gone by now.
They were all already disabled and coming from the "dark ages" of 2.0.1 or even older ;-) -
Mat, since I noticed your comment at GitHub
>hopefully adding some more ore less interesting backport from 8-STABLE against Broadcom bge and bce.
this is just a heads-up that there were several MFCs for Broadcom bge merged into 8-STABLE today.
http://svnweb.freebsd.org/changeset/base/243537
http://svnweb.freebsd.org/changeset/base/243539
http://svnweb.freebsd.org/changeset/base/243542
http://svnweb.freebsd.org/changeset/base/243547
http://svnweb.freebsd.org/changeset/base/243550
http://svnweb.freebsd.org/changeset/base/243552 -
I have them on my radar since e1000, bge, bce cover quite what is used in most server boards these days.
But since both bge and bce make up a pretty bunch of patches I hesitated a bit.
If there are testers out there I might take take risk to ship them …It might be interesting for consumer that want to use them in combination with more recent chips present in latest Dell servers as I see.
Edit: Fixes are merged, bge and bce consumer are welcome to test and report back if anything was bricked up (hopefully not).
-
Latest updates of Intel drivers merged into FreeBSD 8.x:
http://lists.freebsd.org/pipermail/svn-src-all/2013-February/065589.html
Log:
 MFC of the E1000 drivers to STABLE/8, this includes the follow revisions
 plus a few tweaks:
 196969,196970,211516,214646,215781,215789,215808,215910,223350,
 223482,223831,228281,228393,229939,231796,232238,234665,235256,
 236406,238148,238151,238214,238765,238770,238953,238981,239105,
 239109,239304,240518,240693,240968,241037,241856,241885,243570,
 243857,245334,246128,246482,247064 -
…which broke the builds on stable, spamming tinderbox messages to the mailing list...
pass. :-)
-
Jim, I understand it was fixed a couple of posts later.
-
I'm sure it was, just pointing out that particular commit did break things. Would need to include any follow ups, if we pull them in.
-
Hmm currently I'm deprived of any FBSD build VM but I have the patches on my radar.
I'm not sure if it was just a temporary problem but apparently no more additionaly changes have been made on e1000 drivers (until now).Maybe we could update the e1000 backport series and see if things break :-)
Shall I send a pull request? -
May as well, perhaps under a different filename or method so that we can easily swap back to the other version if needed without completely reverting the work.
