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: https://lists.freebsd.org/pipermail/freebsd-current/2018-September/071408.html 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
> CURRENT 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.)
> … not yet archived.) Sorry, I was looking at the wrong month. Found: FreeBSD 12.0-ALPHA7 em0 networking with resume from suspend: OK <https://lists.freebsd.org/pipermail/freebsd-current/2018-October/071456.html>
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!
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. dmesg: em0: TX(0) desc avail = 1024, pidx = 0 em0: TX(0) desc avail = 1024, pidx = 0 pciconf: 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
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.
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
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?
rgrimes mentioned that some work is in progress to have an errata+fix for this and other network-related fixes.
It worked with the Patch from PR#224059, but since the latest Update (12.0-RELEASE-p3) its broken again.
Having applied the patch from PR#224059 to FreeBSD 12.0-RELEASE-p3 the problem with suspend/resume has vanished on Lenovo X230.
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.
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.
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.
Copied from BZ#239443: Random note, running if_em_updated.ko as noted various places has my NIC performing normally after waking.
*** Bug 239443 has been marked as a duplicate of this bug. ***
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.
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?
(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.
Works for me since 12.1
Marking this closed/fixed since four reports including the original reporters have confirmed that it works.