Recent Intel Ethernet driver fixes for FreeBSD

dhatz

You might also want to bump php to version 5.3.15 which has been released several weeks ago:

http://www.freshports.org/lang/php53

w0w

Hmm… I see at least 3 different patches for the em driver
https://redmine.pfsense.org/projects/pfsense-tools/repository/revisions/master/show/patches/RELENG_8_3

e1000-releng8.patch 68,35 КБ
e1000_head.tgz - just sources from head
if_em_vlan_txcsum.RELENG_8.diff

it's not those patches what dhatz talking about, but I want to ask what was the way they applied?
Pfsense uses sources from HEAD and applying both e1000-releng8.patch and f_em_vlan_txcsum.RELENG_8.diff
or ?

P.S. It would be good to change affected version of http://redmine.pfsense.org/issues/2588 to 2.1 also ::)

frater

Does it fix my problem I'm having with vlan hw tagging?
http://forum.pfsense.org/index.php/topic,48155.15.html

I created a ticket, but it was rejected
http://redmine.pfsense.org/issues/2577

w0w

It could fix, but it should not :) I can't see anything that fixes tagging, but I am not freebsd guru.

frater

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?

jimp

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.

frater

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?

w0w

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.

w0w

Should I post bounty for tarring up recent driver fixes or? :-\

dhatz

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

maverick_slo

Sooo if I update to latest snapshot, this should be in?

And thanks to anyone involved!

msi

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 ;-)

dhatz

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

msi

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).

dhatz

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

jimp

…which broke the builds on stable, spamming tinderbox messages to the mailing list...

pass. :-)

dhatz

Jim, I understand it was fixed a couple of posts later.

jimp

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.

msi

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?

jimp

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.