Bug 239443 - Intel NIC vs ACPI sleep, network loses
Summary: Intel NIC vs ACPI sleep, network loses
Status: Closed DUPLICATE of bug 231828
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 12.0-RELEASE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-net (Nobody)
Keywords: IntelNetworking
Depends on:
Reported: 2019-07-25 14:30 UTC by Mason Loring Bliss
Modified: 2019-09-04 00:00 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Mason Loring Bliss freebsd_triage 2019-07-25 14:30:47 UTC
I don't know for sure that this is just related to ACPI sleep or if it happens
randomly as well, but my wired NIC has trouble where it will lose its address,
saying it is, say concurrently that it had no carrier, and then take 
out all the switches near it.

I didn't think to get a pcap, but I'd note all switches three hops out from 
the thing blinking madly on all ports.

Not yet having the culprit identified, we moved things yesterday so that the 
Thinkpad ended up being one switch closer to the central switch in the cellar,
and it knocked out most of the network in the house, rather than just my

I'm not sure how best to debug this. I can't have the thing loose on my 
network, but I can construct a DMZ and let it live in that for data 
collection. Before I dive into that, though, I'd love to get a list of data 
that would be maximally useful for me to collect.

The system in question is a Thinkpad T420, and the NIC is an Intel 82579LM. 
It's running updated FreeBSD 12-RELEASE.
Comment 1 Mason Loring Bliss freebsd_triage 2019-07-27 01:00:16 UTC
Random note, running if_em_updated.ko as noted various places has my NIC performing normally after waking. I haven't let it run long enough on my network to be confident that the issue won't return, and it's unclear what this implies even if I don't see the issue return, but it's a data point.
Comment 2 Mason Loring Bliss freebsd_triage 2019-09-04 00:00:34 UTC
I'm going to close this, as it's a duplicate of:


*** This bug has been marked as a duplicate of bug 231828 ***