Bug 231828 - em(4) is unusable after suspend/resume
Summary: em(4) is unusable after suspend/resume
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
: 239443 (view as bug list)
Depends on:
Reported: 2018-09-30 17:21 UTC by pete
Modified: 2020-04-27 17:12 UTC (History)
15 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description pete 2018-09-30 17:21:45 UTC
There are several reports that when using an em(4) device on 12-CURRENT the NIC is unusable until after a reboot or kld_unload/kld_load of the if_em kernel module.

upon resume there are messages like this in the dmesg buffer:

in6_purgeaddr: err=65, destination address delete failed
lo0: link state changed to DOWN
lo0: link state changed to UP
Link state changed to down
em0: link state changed to DOWN
em0: TX(0) desc avail = 1024, pidx = 0
em0: TX(0) desc avail = 1024, pidx = 0
em0: TX(0) desc avail = 1024, pidx = 0
em0: TX(0) desc avail = 1024, pidx = 0
em0: TX(0) desc avail = 1024, pidx = 0
em0: TX(0) desc avail = 1024, pidx = 0
em0: TX(0) desc avail = 1024, pidx = 0
em0: TX(0) desc avail = 1024, pidx = 0
em0: TX(0) desc avail = 1024, pidx = 0
em0: TX(0) desc avail = 1024, pidx = 0
em0: TX(0) desc avail = 1024, pidx = 0
em0: TX(0) desc avail = 1024, pidx = 0

there is a mailing list thread about the issue here:

my device info via pciconf:
em0@pci0:0:31:6:        class=0x020000 card=0x30d017aa chip=0x15b78086 rev=0x31 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Ethernet Connection (2) I219-LM'
    class      = network
    subclass   = ethernet
Comment 1 Graham Perrin 2018-10-02 00:36:52 UTC

Please, which revision? 

From <https://lists.freebsd.org/pipermail/freebsd-current/2018-September/071331.html>: 

>> I just fixed a bug in devd that would cause this, …

(I replied to the list, my reply is not yet archived.)
Comment 2 Graham Perrin 2018-10-02 00:41:23 UTC
> … not yet archived.)

Sorry, I was looking at the wrong month. Found: 

FreeBSD 12.0-ALPHA7 em0 networking with resume from suspend: OK
Comment 3 pete 2018-10-02 02:34:52 UTC
I can confirm that this works after updating my system to:

12.0-ALPHA8 b6728160ea4(master)

(hash is from the github mirror).  so i think we can close this as we are all set.  Thanks for the heads up Graham!
Comment 4 Chris 2019-01-20 11:56:00 UTC
Not sure if I should reply to a closed bug. I am unable to use the network after suspend/resume with a 12.0-RELEASE r341666 GENERIC amd64 kernel.

Suspend/resume works, except there is no network traffic. ifconfig down/up does not restore it. There have been times where it did resume properly, but usually does not.

em0: TX(0) desc avail = 1024, pidx = 0
em0: TX(0) desc avail = 1024, pidx = 0

em0@pci0:0:31:6:        class=0x020000 card=0x86721043 chip=0x15b88086 rev=0x31 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Ethernet Connection (2) I219-V'
    class      = network
    subclass   = ethernet
Comment 5 Michael Dexter 2019-01-21 21:22:50 UTC
I can confirm this issue on 12.0R with the Intel Corporation 82579LM Lewisville em device in an HP Z420. This issues does not appear to be ready for resolved status.
Comment 6 Kurt Jaeger freebsd_committer 2019-01-21 21:43:11 UTC
Please look at the patch in PR#224059 and check if the problem is solved if this patch is applied. The patch is only in 12-STABLE, so post-12.0p2
Comment 7 Chris 2019-01-22 17:15:47 UTC
I have applied the patch from PR#224059 and suspended my machine at least 8 times today without any issues. Thanks!

Do we know if 12.0 will be updated, or will I need to keep applying the patch until 12.1 is released?
Comment 8 Kurt Jaeger freebsd_committer 2019-01-22 20:44:22 UTC
rgrimes mentioned that some work is in progress to have an errata+fix
for this and other network-related fixes.
Comment 9 link_gun2004+bugZFBSD 2019-02-09 00:34:17 UTC
It worked with the Patch from PR#224059, but since the latest Update (12.0-RELEASE-p3) its broken again.
Comment 10 Krystian Bacławski 2019-03-29 16:19:48 UTC
Having applied the patch from PR#224059 to FreeBSD 12.0-RELEASE-p3 the problem with suspend/resume has vanished on Lenovo X230.
Comment 11 Daniel Ebdrup Jensen freebsd_committer 2019-06-17 13:57:52 UTC
Another mitigation of this issue that works without building a new kernel and that I've confirmed working is installing net/intel-em-kmod from ports or packages.
Comment 12 Philipp Engel 2019-06-25 19:56:55 UTC
Can confirm that installing net/intel-em-kmod fixes the issue. Does anybody know when the patch will be rolled out in FreeBSD 12.0-RELEASE? I have had hoped for p4.
Comment 13 Mason Loring Bliss freebsd_triage 2019-07-25 18:26:12 UTC
Random note, I opened https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239443 this morning, which may show a slightly more aggressive breakage than this ticket, but seems similar.

I'll try installing the module from ports.
Comment 14 Mason Loring Bliss freebsd_triage 2019-09-02 01:41:22 UTC
Copied from BZ#239443:

Random note, running if_em_updated.ko as noted various places has my NIC performing normally after waking.
Comment 15 Mason Loring Bliss freebsd_triage 2019-09-04 00:00:34 UTC
*** Bug 239443 has been marked as a duplicate of this bug. ***
Comment 16 Mason Loring Bliss freebsd_triage 2019-10-21 20:25:22 UTC
The base driver in 12.1-RC* appears to not suffer from this bug. I'll report back if it consistently sleeps and wakes without misbehaving.
Comment 17 Daniel Ebdrup Jensen freebsd_committer 2020-04-26 10:55:30 UTC
Pete, would you be okay with me closing this bug as fixed? It works on my T420 as of 12.1, and it seems to work for Mason too.
Or would you to test first?
Comment 18 pete 2020-04-27 16:12:44 UTC
(In reply to Daniel Ebdrup Jensen from comment #17)
Please do - this hasn't been an issue on my end for quite a while.  I think I actually closed the issue back in 2018.
Comment 19 link_gun2004+bugZFBSD 2020-04-27 16:34:17 UTC
Works for me since 12.1
Comment 20 Daniel Ebdrup Jensen freebsd_committer 2020-04-27 17:12:01 UTC
Marking this closed/fixed since four reports including the original reporters have confirmed that it works.