Recent Intel Ethernet driver fixes for FreeBSD

  • As a quick heads-up, please note that in recent weeks there have been numerous commits to the FreeBSD Intel Ethernet drivers, fixing issues.

    svn commit: r235553 - in stable/8/sys: dev/e1000 i386/conf

    svn commit: r236162 - stable/8/sys/dev/e1000

    82574L hangs (with r233708 e1000 driver).
    Thu Aug 9 23:31:26 UTC 2012

    On Thu, Aug 9, 2012 at 8:25 AM, Barney Cordoba <barney_cordoba at="""">wrote:

    –- On Fri, 5/11/12, Barney Cordoba <barney_cordoba at="""">wrote:

    FWIW, I've got an X7SPE-HF-D525 MB with 82574L running on a
    7.0 driver
    that seems to work pretty well. It panics once in a blue
    moon when we
    overload it (like 200Mb/s of traffic) but it generally works


    Has anything been done or patched regarding this problem?


    Ever since r235553 the 82574L has been stable for me, collectively
    passing ~1.2Tb/s for the past 4 months without issue.  We did have
    some issues with switches not liking the fallout of what r236162 fixed
    that we updated to, but the cards themselves were fine.  If you pull
    the current e1000 from 8-STABLE you'll get up to r236162.</barney_cordoba></barney_cordoba>

  • Rebel Alliance Developer Netgate

    Open a feature request in redmine, would get better attention there. Last time this happened we just tarred up the driver and added it to our patches.

  • I have two boards with 82574L NIC and same problems there, so I've found this thread and created request now.


    Looks like I accidentally duplicated request  :- is the right one. Thanks!

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

  • Hmm… I see at least 3 different patches for the em driver

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

    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 to 2.1 also  ::)

  • Does it fix my problem I'm having with vlan hw tagging?,48155.15.html

    I created a ticket, but it was rejected

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

  • 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?

  • Rebel Alliance Developer Netgate

    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:

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

  • 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:

     MFC of the E1000 drivers to STABLE/8, this includes the follow revisions
     plus a few tweaks:

  • Rebel Alliance Developer Netgate

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

  • Rebel Alliance Developer Netgate

    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?

  • Rebel Alliance Developer Netgate

    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.

Log in to reply