[SOLVED] Ethernet issues after booting Windows (Intel I217-V (e1000e))

Untribium · 2015-01-07 19:46:40

[SOLUTION]
Turns out that the problem is related to WoL, and the solution is to turn of all the WoL features in the Windows Intel driver. This comes at a cost, as WoL will no longer be possible, but that won't be an issue for most people. Hope this helps :)

[ORIGINAL POST]
Hi everyone,

A few days ago I bought a new PC and installed Arch Linux and Windows7 in a dual-boot setup. After solving multiple issues (two daisy-chained Dell DisplayPort monitors with faulty firmware, yay...) I finally got everything to work as intended - except for the ethernet adapter, which is an Intel I217-V running on the e1000e kernel module and the most recent Intel driver on Windows. Essentially, whenever I boot from Windows to Linux without powering the machine down, the ethernet won't work under linux, similar to this.

tl;dr
Looked like a DHCP issue, but seems to be hardware/driver related. I have found a "solution", which, as implied by the problem description, is to completely unpower the PC ("removing" the power cord, not just turning it off) for a short time (< 1 min) before rebooting, but that's more of a workaround than anything and I'd really like to know what's actually going on.

Problem description:
- Boot Linux -> fine
- Boot Windows -> fine
- Boot Linux -> Ethernet "broken"
(- Boot Windows -> fine)

So after booting linux, I am unable to connect to the network using the ethernet adapter. At first I thought it had something to do with the DHCP, especially since it always worked after I had it turned off for the night (DHCP lease timeout?) and I found this in the logs:

Jan 07 02:24:01 origami kernel: e1000e 0000:00:19.0 eth0: registered PHC clock
Jan 07 02:24:01 origami kernel: e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 10:c3:7b:97:4f:aa
Jan 07 02:24:01 origami kernel: e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
Jan 07 02:24:01 origami kernel: e1000e 0000:00:19.0 eth0: MAC: 11, PHY: 12, PBA No: FFFFFF-0FF
...
Jan 07 02:24:01 origami kernel: e1000e 0000:00:19.0 eno1: renamed from eth0
...
Jan 07 02:24:03 origami NetworkManager[357]: <info> NetworkManager (version 0.9.10.1) is starting...
...
Jan 07 02:24:03 origami NetworkManager[357]: <info> (eno1): carrier is OFF
Jan 07 02:24:03 origami NetworkManager[357]: <info> (eno1): new Ethernet device (driver: 'e1000e' ifindex: 3)
Jan 07 02:24:03 origami NetworkManager[357]: <info> (eno1): exported as /org/freedesktop/NetworkManager/Devices/2
Jan 07 02:24:03 origami NetworkManager[357]: <info> (eno1): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
...
Jan 07 02:24:03 origami kernel: e1000e 0000:00:19.0: irq 28 for MSI/MSI-X
Jan 07 02:24:04 origami NetworkManager[357]: <info> (eno1): preparing device
Jan 07 02:24:04 origami NetworkManager[357]: <info> (eno1): created default wired connection 'Wired connection 1'
Jan 07 02:24:04 origami kernel: sd 7:0:0:3: [sdg] Attached SCSI removable disk
Jan 07 02:24:04 origami kernel: e1000e 0000:00:19.0: irq 28 for MSI/MSI-X
...
Jan 07 02:24:06 origami NetworkManager[357]: <info> (eno1): link connected
Jan 07 02:24:06 origami NetworkManager[357]: <info> (eno1): device state change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40]
Jan 07 02:24:06 origami NetworkManager[357]: <info> Auto-activating connection 'Wired connection 1'.
Jan 07 02:24:06 origami NetworkManager[357]: <info> Activation (eno1) starting connection 'Wired connection 1'
Jan 07 02:24:06 origami NetworkManager[357]: <info> Activation (eno1) Stage 1 of 5 (Device Prepare) scheduled...
Jan 07 02:24:06 origami NetworkManager[357]: <info> Activation (eno1) Stage 1 of 5 (Device Prepare) started...
Jan 07 02:24:06 origami NetworkManager[357]: <info> (eno1): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Jan 07 02:24:06 origami NetworkManager[357]: <info> NetworkManager state is now CONNECTING
Jan 07 02:24:06 origami NetworkManager[357]: <info> Activation (eno1) Stage 2 of 5 (Device Configure) scheduled...
Jan 07 02:24:06 origami NetworkManager[357]: <info> Activation (eno1) Stage 1 of 5 (Device Prepare) complete.
Jan 07 02:24:06 origami NetworkManager[357]: <info> Activation (eno1) Stage 2 of 5 (Device Configure) starting...
Jan 07 02:24:06 origami NetworkManager[357]: <info> (eno1): device state change: prepare -> config (reason 'none') [40 50 0]
Jan 07 02:24:06 origami NetworkManager[357]: <info> Activation (eno1) Stage 2 of 5 (Device Configure) successful.
Jan 07 02:24:06 origami NetworkManager[357]: <info> Activation (eno1) Stage 3 of 5 (IP Configure Start) scheduled.
Jan 07 02:24:06 origami NetworkManager[357]: <info> Activation (eno1) Stage 2 of 5 (Device Configure) complete.
Jan 07 02:24:06 origami NetworkManager[357]: <info> Activation (eno1) Stage 3 of 5 (IP Configure Start) started...
Jan 07 02:24:06 origami NetworkManager[357]: <info> (eno1): device state change: config -> ip-config (reason 'none') [50 70 0]
Jan 07 02:24:06 origami NetworkManager[357]: <info> Activation (eno1) Beginning DHCPv4 transaction (timeout in 45 seconds)
Jan 07 02:24:06 origami NetworkManager[357]: <info> dhcpcd started with pid 382
Jan 07 02:24:06 origami NetworkManager[357]: <info> Activation (eno1) Stage 3 of 5 (IP Configure Start) complete.
Jan 07 02:24:06 origami dhcpcd[382]: version 6.6.7 starting
Jan 07 02:24:06 origami kernel: e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Jan 07 02:24:06 origami kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready
Jan 07 02:24:06 origami NetworkManager[357]: dhcpcd[382]: version 6.6.7 starting
Jan 07 02:24:06 origami NetworkManager[357]: <info> (eno1): DHCPv4 state changed nbi -> preinit
Jan 07 02:24:06 origami dhcpcd[382]: DUID 00:01:00:01:1c:3b:61:dd:10:c3:7b:97:4f:aa
Jan 07 02:24:06 origami dhcpcd[382]: eno1: IAID 7b:97:4f:aa
Jan 07 02:24:06 origami NetworkManager[357]: dhcpcd[382]: DUID 00:01:00:01:1c:3b:61:dd:10:c3:7b:97:4f:aa
Jan 07 02:24:06 origami NetworkManager[357]: dhcpcd[382]: eno1: IAID 7b:97:4f:aa
Jan 07 02:24:06 origami dhcpcd[382]: eno1: rebinding lease of 192.168.0.64
Jan 07 02:24:06 origami NetworkManager[357]: dhcpcd[382]: eno1: rebinding lease of 192.168.0.64
Jan 07 02:24:07 origami dhcpcd[382]: eno1: soliciting an IPv6 router
Jan 07 02:24:07 origami NetworkManager[357]: dhcpcd[382]: eno1: soliciting an IPv6 router
Jan 07 02:24:11 origami dhcpcd[382]: eno1: DHCP lease expired
Jan 07 02:24:11 origami NetworkManager[357]: dhcpcd[382]: eno1: DHCP lease expired
Jan 07 02:24:11 origami NetworkManager[357]: <info> (eno1): DHCPv4 state changed preinit -> expire
Jan 07 02:24:11 origami dhcpcd[382]: eno1: soliciting a DHCP lease
Jan 07 02:24:11 origami NetworkManager[357]: dhcpcd[382]: eno1: soliciting a DHCP lease
Jan 07 02:24:20 origami dhcpcd[382]: eno1: no IPv6 Routers available
Jan 07 02:24:20 origami NetworkManager[357]: dhcpcd[382]: eno1: no IPv6 Routers available
...
Jan 07 02:24:52 origami NetworkManager[357]: <warn> (eno1): DHCPv4 request timed out.
Jan 07 02:24:52 origami dhcpcd[382]: received signal TERM from PID 357, stopping
Jan 07 02:24:52 origami dhcpcd[382]: eno1: removing interface
Jan 07 02:24:52 origami NetworkManager[357]: dhcpcd[382]: received signal TERM from PID 357, stopping
Jan 07 02:24:52 origami NetworkManager[357]: dhcpcd[382]: eno1: removing interface
Jan 07 02:24:52 origami NetworkManager[357]: <warn> (eno1): DHCP client pid 382 didn't exit, will kill it.
Jan 07 02:24:52 origami NetworkManager[357]: <info> (eno1): canceled DHCP transaction, DHCP client pid 382
Jan 07 02:24:52 origami NetworkManager[357]: <info> Activation (eno1) Stage 4 of 5 (IPv4 Configure Timeout) scheduled...
Jan 07 02:24:52 origami NetworkManager[357]: <info> Activation (eno1) Stage 4 of 5 (IPv4 Configure Timeout) started...
Jan 07 02:24:52 origami NetworkManager[357]: <info> Activation (eno1) Stage 4 of 5 (IPv4 Configure Timeout) complete.
Jan 07 02:24:52 origami NetworkManager[357]: <warn> (pid 382) unhandled DHCP event for interface eno1

Where the most interesting line is this one:

Jan 07 02:24:11 origami dhcpcd[382]: eno1: DHCP lease expired

Since it looked like a DHCP issue, I changed some stuff in the dhcpcd.conf (as described here and various forum threads, particularly this one).

Noony wrote:

[...]
In the leases file, I find that the "uid" is always 7 bytes for WinXP and 19 bytes for Linux. I finally found out that the TXT string is hashed from only the uid. Translating from octal, I found that the uid from Windows is just the MAC address prefixed with 01, and those same 7 bytes appear at the end of the 19-byte uid from Linux.
[...]

So I tried to check my lease files (/var/lib/dhcpcd/dhcpcd-eno1.lease), but it turns out that it's not in a readable format. However, dhcpcd outputs the DUID and the IAID (dhcpcd -d eno1) to the log file, so I compared this to the data I got from Windows (ipconfig /all), and - tada - the IAID did not match. So I manually set the IAID in the dhcpcd.conf to match what I found on Windows...but it still didn't work.
This is my dhcpcd.conf after the changes:

# See dhcpcd.conf(5) for details.

# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel

# Inform the DHCP server of our hostname for DDNS.
origami

# Use the hardware address of the interface for the Client ID.
#clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.

duid

interface eno1
iaid 286311291

# Persist interface configuration when dhcpcd exits.
persistent

# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Most distributions have NTP support.
option ntp_servers
# Respect the network MTU.
# Some interface drivers reset when changing the MTU so disabled by default.
#option interface_mtu

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate Stable Private IPv6 Addresses instead of hardware based ones
slaac private

# A hook script is provided to lookup the hostname if not set by the DHCP
# server, but it should not be run by default.
nohook lookup-hostname
noipv4ll

noarp

noipv6rs
noipv6

After that I tried connecting it using a static IP (and added a reservation in the router as well) like so:

# ip a add 192.168.0.64/24 dev eno1
# ip route a default via 192.168.0.1

where 192.168.0.1 is the ip of the router. While I still couldn't connect to internet, I was at least connected to a network. So I tried pinging my laptop, which didn't work and vice versa, which didn't work either - but then I did the same thing while running tcpdump, and the results are pretty interesting. PC to laptop didn't do anything on the laptop, but when I tried to ping the PC from the laptop, I found (in the PC's tcpdump), that it was getting the messages and sending replies, but those never made it to the laptop. So it seems, that the problem is not actually related to DHCP after all, but that the sent packets somehow don't make it. And as mentioned at the very top, cutting the power supply for a short while fixes it, so it must be related to some settings that persist a reboot, but sit in volatile memory.

This is the hardware:

# lspci -vvv | grep -A 20 Ethernet
00:when I booted the PC for the first time in the morning19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-V (rev 05)
	DeviceName:  Onboard LAN
	Subsystem: ASUSTeK Computer Inc. Device 859f
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 28
	Region 0: Memory at f7900000 (32-bit, non-prefetchable) [size=128K]
	Region 1: Memory at f793d000 (32-bit, non-prefetchable) [size=4K]
	Region 2: I/O ports at f080 [size=32]
	Capabilities: [c8] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
		Address: 00000000feeff00c  Data: 41d2
	Capabilities: [e0] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: e1000e
	Kernel modules: e1000e

and it runs on the e1000e module (updated to most recent stable version using a package from the AUR):

# modinfo e1000e                                                                                                                                                                                                                                         :(
filename:       /lib/modules/3.17.6-1-ARCH/updates/e1000e.ko
version:        3.1.0.2-NAPI
license:        GPL
description:    Intel(R) PRO/1000 Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
srcversion:     58C4B047D24A6394B168B0F
[...]
depends:        ptp
vermagic:       3.17.6-1-ARCH SMP preempt mod_unload modversions 
parm:           copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
parm:           TxIntDelay:Transmit Interrupt Delay (array of int)
parm:           TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)
parm:           RxIntDelay:Receive Interrupt Delay (array of int)
parm:           RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
parm:           InterruptThrottleRate:Interrupt Throttling Rate (array of int)
parm:           IntMode:Interrupt Mode (array of int)
parm:           SmartPowerDownEnable:Enable PHY smart power down (array of int)
parm:           KumeranLockLoss:Enable Kumeran lock loss workaround (array of int)
parm:           CrcStripping:Enable CRC Stripping, disable if your BMC needs the CRC (array of int)
parm:           EEE:Enable/disable on parts that support the feature (array of int)
parm:           Node:[ROUTING] Node to allocate memory on, default -1 (array of int)
parm:           debug:Debug level (0=none,...,16=all) (int)

Since I pretty much use Windows for gaming only, this isn't a huge issue, but it's bugging me that after spending hours and hours on this, I still don't have a "clean" solution. It seems to me that this is a hardware/driver issue, but if you have some more insight, that would be highly appreciated :)

Last edited by Untribium (2015-01-08 18:54:51)

alphaniner · 2015-01-07 20:01:22

I would compare the output of commands (s/a ip, lspci, ethtool) between a 'good boot' and a 'bad boot' and see if you can find any differences. Also check if there's a Windows utility to configure the NIC, maybe it's a power saving feature or such that can be disabled.

t0m5k1 · 2015-01-07 21:30:38

I would be inclined to check the BIOS or UEFI (depending on what the mobo uses) & then disable all non-essential features like WoL & pxie booting etc, maybe even going as far as to do a couple of boot's using the failsafe bois settings.

I had a little ddg using the search term "ASUSTeK Computer Inc. Device 859f" which did throw up the following link which proports a to WoL issue with similar hardware & OS (win7/Arch dual boot)
http://sourceforge.net/p/e1000/mailman/ … /32040173/

I am wondering if the Windows software/Driver combination for this hardware is more advanced & thus is enabling something that remains as you say in volatile memory perhaps on the mobo or the net chip itself!!

It is certainly an odd situation for sure so I'm gonna sub this thread & keep mooching on the web to see what I find ...I kinda like problems like this as they are odd but tend to pop up a few times & it's good to know how to deal with them

good luck & I'll post what I find.

Untribium · 2015-01-07 23:45:03

Thanks for the replies

alphaniner wrote:

I would compare the output of commands (s/a ip, lspci, ethtool) between a 'good boot' and a 'bad boot' and see if you can find any differences. Also check if there's a Windows utility to configure the NIC, maybe it's a power saving feature or such that can be disabled.

Okay, so I've run a few commands:

modinfo: identical

# modinfo e1000e
filename:       /lib/modules/3.17.6-1-ARCH/updates/e1000e.ko
version:        3.1.0.2-NAPI
license:        GPL
description:    Intel(R) PRO/1000 Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
srcversion:     58C4B047D24A6394B168B0F
alias:          pci:v00008086d000015A3sv*sd*bc*sc*i*
alias:          pci:v00008086d000015A2sv*sd*bc*sc*i*
alias:          pci:v00008086d000015A1sv*sd*bc*sc*i*
alias:          pci:v00008086d000015A0sv*sd*bc*sc*i*
alias:          pci:v00008086d00001559sv*sd*bc*sc*i*
alias:          pci:v00008086d0000155Asv*sd*bc*sc*i*
alias:          pci:v00008086d0000153Bsv*sd*bc*sc*i*
alias:          pci:v00008086d0000153Asv*sd*bc*sc*i*
alias:          pci:v00008086d00001503sv*sd*bc*sc*i*
alias:          pci:v00008086d00001502sv*sd*bc*sc*i*
alias:          pci:v00008086d000010F0sv*sd*bc*sc*i*
alias:          pci:v00008086d000010EFsv*sd*bc*sc*i*
alias:          pci:v00008086d000010EBsv*sd*bc*sc*i*
alias:          pci:v00008086d000010EAsv*sd*bc*sc*i*
alias:          pci:v00008086d00001525sv*sd*bc*sc*i*
alias:          pci:v00008086d000010DFsv*sd*bc*sc*i*
alias:          pci:v00008086d000010DEsv*sd*bc*sc*i*
alias:          pci:v00008086d000010CEsv*sd*bc*sc*i*
alias:          pci:v00008086d000010CDsv*sd*bc*sc*i*
alias:          pci:v00008086d000010CCsv*sd*bc*sc*i*
alias:          pci:v00008086d000010CBsv*sd*bc*sc*i*
alias:          pci:v00008086d000010F5sv*sd*bc*sc*i*
alias:          pci:v00008086d000010BFsv*sd*bc*sc*i*
alias:          pci:v00008086d000010E5sv*sd*bc*sc*i*
alias:          pci:v00008086d0000294Csv*sd*bc*sc*i*
alias:          pci:v00008086d000010BDsv*sd*bc*sc*i*
alias:          pci:v00008086d000010C3sv*sd*bc*sc*i*
alias:          pci:v00008086d000010C2sv*sd*bc*sc*i*
alias:          pci:v00008086d000010C0sv*sd*bc*sc*i*
alias:          pci:v00008086d00001501sv*sd*bc*sc*i*
alias:          pci:v00008086d00001049sv*sd*bc*sc*i*
alias:          pci:v00008086d0000104Dsv*sd*bc*sc*i*
alias:          pci:v00008086d0000104Bsv*sd*bc*sc*i*
alias:          pci:v00008086d0000104Asv*sd*bc*sc*i*
alias:          pci:v00008086d000010C4sv*sd*bc*sc*i*
alias:          pci:v00008086d000010C5sv*sd*bc*sc*i*
alias:          pci:v00008086d0000104Csv*sd*bc*sc*i*
alias:          pci:v00008086d000010BBsv*sd*bc*sc*i*
alias:          pci:v00008086d00001098sv*sd*bc*sc*i*
alias:          pci:v00008086d000010BAsv*sd*bc*sc*i*
alias:          pci:v00008086d00001096sv*sd*bc*sc*i*
alias:          pci:v00008086d0000150Csv*sd*bc*sc*i*
alias:          pci:v00008086d000010F6sv*sd*bc*sc*i*
alias:          pci:v00008086d000010D3sv*sd*bc*sc*i*
alias:          pci:v00008086d0000109Asv*sd*bc*sc*i*
alias:          pci:v00008086d0000108Csv*sd*bc*sc*i*
alias:          pci:v00008086d0000108Bsv*sd*bc*sc*i*
alias:          pci:v00008086d0000107Fsv*sd*bc*sc*i*
alias:          pci:v00008086d0000107Esv*sd*bc*sc*i*
alias:          pci:v00008086d0000107Dsv*sd*bc*sc*i*
alias:          pci:v00008086d000010B9sv*sd*bc*sc*i*
alias:          pci:v00008086d000010D5sv*sd*bc*sc*i*
alias:          pci:v00008086d000010DAsv*sd*bc*sc*i*
alias:          pci:v00008086d000010D9sv*sd*bc*sc*i*
alias:          pci:v00008086d00001060sv*sd*bc*sc*i*
alias:          pci:v00008086d000010A5sv*sd*bc*sc*i*
alias:          pci:v00008086d000010BCsv*sd*bc*sc*i*
alias:          pci:v00008086d000010A4sv*sd*bc*sc*i*
alias:          pci:v00008086d0000105Fsv*sd*bc*sc*i*
alias:          pci:v00008086d0000105Esv*sd*bc*sc*i*
depends:        ptp
vermagic:       3.17.6-1-ARCH SMP preempt mod_unload modversions 
parm:           copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
parm:           TxIntDelay:Transmit Interrupt Delay (array of int)
parm:           TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)
parm:           RxIntDelay:Receive Interrupt Delay (array of int)
parm:           RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
parm:           InterruptThrottleRate:Interrupt Throttling Rate (array of int)
parm:           IntMode:Interrupt Mode (array of int)
parm:           SmartPowerDownEnable:Enable PHY smart power down (array of int)
parm:           KumeranLockLoss:Enable Kumeran lock loss workaround (array of int)
parm:           CrcStripping:Enable CRC Stripping, disable if your BMC needs the CRC (array of int)
parm:           EEE:Enable/disable on parts that support the feature (array of int)
parm:           Node:[ROUTING] Node to allocate memory on, default -1 (array of int)
parm:           debug:Debug level (0=none,...,16=all) (int)

ethtool: identical

# ethtool eno1                                                                                                                                                                                                          :(
Settings for eno1:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Speed: 1000Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 1
	Transceiver: internal
	Auto-negotiation: on
	MDI-X: on (auto)
	Supports Wake-on: pumbg
	Wake-on: g
	Current message level: 0x00000007 (7)
			       drv probe link
	Link detected: yes

dmesg eno1: identical (except for timestamp)

# dmesg | grep eno1                                                                                                                                                                                                        :(
[    1.779300] e1000e 0000:00:19.0 eno1: renamed from eth0
[    3.124100] IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready
[    5.804601] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
[    5.804627] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready

dmesg e1000e: almost identical, "Modules linked" differs
bad

# dmesg | grep e1000e
[    1.604460] e1000e: Intel(R) PRO/1000 Network Driver - 3.1.0.2-NAPI
[    1.604461] e1000e: Copyright(c) 1999 - 2014 Intel Corporation.
[    1.604571] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[    1.604584] e1000e 0000:00:19.0: irq 28 for MSI/MSI-X
[    1.705886] Modules linked in: iTCO_vendor_support coretemp hwmon intel_rapl acpi_cpufreq(-) x86_pkg_temp_thermal intel_powerclamp kvm_intel(-) kvm rtl8821ae(C+) crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel mac80211 aes_x86_64 lrw gf128mul psmouse glue_helper ablk_helper cryptd serio_raw pcspkr i2c_i801(+) cfg80211 fan thermal rfkill battery wmi i915(+) button video drm_kms_helper snd_hda_intel(+) snd_hda_controller drm snd_hda_codec e1000e(O+) snd_hwdep snd_pcm intel_gtt i2c_algo_bit ptp snd_timer mei_me i2c_core mei snd shpchp pps_core lpc_ich soundcore processor sch_fq_codel ext4 crc16 mbcache jbd2 sd_mod sr_mod cdrom crc_t10dif crct10dif_common atkbd libps2 ahci libahci ehci_pci xhci_hcd ehci_hcd libata usbcore scsi_mod usb_common i8042 serio
[    1.778211] e1000e 0000:00:19.0 eth0: registered PHC clock
[    1.778215] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 10:c3:7b:97:4f:aa
[    1.778216] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[    1.778253] e1000e 0000:00:19.0 eth0: MAC: 11, PHY: 12, PBA No: FFFFFF-0FF
[    1.779300] e1000e 0000:00:19.0 eno1: renamed from eth0
[    3.021308] e1000e 0000:00:19.0: irq 28 for MSI/MSI-X
[    3.124020] e1000e 0000:00:19.0: irq 28 for MSI/MSI-X
[    5.804601] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx

good

# dmesg | grep e1000e
[...]
[    1.676203] Modules linked in: eeepc_wmi(+) asus_wmi sparse_keymap evdev led_class mac_hid iTCO_wdt iTCO_vendor_support coretemp hwmon intel_rapl acpi_cpufreq(-) x86_pkg_temp_thermal intel_powerclamp kvm crct10dif_pclmul rtl8821ae(C+) crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel i915(+) aes_x86_64 lrw mac80211 gf128mul psmouse glue_helper ablk_helper cryptd serio_raw pcspkr cfg80211 i2c_i801(+) thermal fan rfkill battery wmi button video drm_kms_helper snd_hda_intel(+) snd_hda_controller drm snd_hda_codec snd_hwdep e1000e(O+) snd_pcm intel_gtt mei_me ptp i2c_algo_bit snd_timer mei i2c_core lpc_ich snd pps_core shpchp soundcore processor sch_fq_codel ext4 crc16 mbcache jbd2 hid_generic usbhid hid sd_mod sr_mod cdrom crc_t10dif crct10dif_common atkbd libps2 ahci libahci libata ehci_pci
[...]

ip a: identical, except for missing IPv4
bad

# ip a
[...]
3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 10:c3:7b:97:4f:aa brd ff:ff:ff:ff:ff:ff
    inet6 fe80::12c3:7bff:fe97:4faa/64 scope link 
       valid_lft forever preferred_lft forever

good

# ip a
[...]
3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 10:c3:7b:97:4f:aa brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.64/24 brd 192.168.0.255 scope global dynamic eno1
       valid_lft 604723sec preferred_lft 604723sec
    inet6 fe80::12c3:7bff:fe97:4faa/64 scope link 
       valid_lft forever preferred_lft forever

lspci: a few differences, oddly enough none for the ethernet adapter
bad

00:02.0 Display controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
	DeviceName:  Onboard IGD
	Subsystem: ASUSTeK Computer Inc. Device 8534
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 30
	Region 0: Memory at f7400000 (64-bit, non-prefetchable) [size=4M]
	Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M]
	Region 4: I/O ports at f000 [size=64]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-Address: feeff00c  Data: 4182
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [a4] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: i915
	Kernel modules: i915

good

00:02.0 Display controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
	[...]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-Address: feeff00c  Data: 4192
	[...]

bad

00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05) (prog-if 30 [XHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8534
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 26
	Region 0: Memory at f7920000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: [70] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+Address: 00000000feeff00c  Data: 41e1
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_hcd

good

00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05) (prog-if 30 [XHCI])
	[...]
	Interrupt: pin A routed to IRQ 25
	[...]
	Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+Address: 00000000feeff00c  Data: 41b1
	[...]

bad

00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05) (prog-if 01 [AHCI 1.0])
	Subsystem: ASUSTeK Computer Inc. Device 8534
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 25
	Region 0: I/O ports at f0d0 [size=8]
	Region 1: I/O ports at f0c0 [size=4]
	Region 2: I/O ports at f0b0 [size=8]
	Region 3: I/O ports at f0a0 [size=4]
	Region 4: I/O ports at f060 [size=32]
	Region 5: Memory at f793a000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-Address: feeff00c  Data: 41c1
	Capabilities: [70] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [a8] SATA HBA v1.0 BAR4 Offset=00000004
	Kernel driver in use: ahci
	Kernel modules: ahci

good

00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05) (prog-if 01 [AHCI 1.0])
	[...]
	Interrupt: pin B routed to IRQ 26
	[...]
	Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-Address: feeff00c  Data: 41e1
	[...]

Stuff to note:
ethtool doesn't change, but:

Settings for eno1:
	[...]
	Supports Wake-on: pumbg
	Wake-on: g
	[...]

So if I understand the wiki article on WoL correctly, that means that WoL is on. I will check the UEFI next. Maybe I need to disable it in Windows so it doesn't send instructions to keep it on?

The rest looks pretty much as you would expect it, although the modules are interesting.

As for timing: I tried cutting the power for around 15 seconds, which wasn't enough. Then I monitored the LED on the LAN-adapter and turned the power back on right after the LED turned off (roughly 30 secs) and it works, so that confirms previous suspicions...

t0m5k1 wrote:

I had a little ddg using the search term "ASUSTeK Computer Inc. Device 859f" which did throw up the following link which proports a to WoL issue with similar hardware & OS (win7/Arch dual boot)
http://sourceforge.net/p/e1000/mailman/ … /32040173/

Now that is interesting! I can confirm that the card stays on (well...it's flashing, that's all I can say ), but that's pretty normal I think.

t0m5k1 wrote:

I would be inclined to check the BIOS or UEFI (depending on what the mobo uses) & then disable all non-essential features like WoL & pxie booting etc

Yes, I was thinking the same thing. I'll check that right now.

t0m5k1 wrote:

I kinda like problems like this as they are odd but tend to pop up a few times & it's good to know how to deal with them

Yeah it was fun for the first 10 hours No but seriously, I feel the same way, at least now that I have a somewhat acceptable workaround and a more permanent solution in sight

alphaniner · 2015-01-08 14:10:29

I was particularly hopeful you might find something in the WOL status as reported by ethtool, though now that I think about it that caused problems in Windows after booting to Linux rather than the other way around. On the Linux side, the only other thing I can think of is to change the debug parameter of the e1000e module. I've never done anything like that though, so I don't know what to expect. Maybe just a whole lot of gibberish dumped to dmesg/journal...

On the Windows side, I still think you should look into a config utility from Intel. It used to be called ProSet IIRC. As a workaround, you could also try disabling the NIC before rebooting. OFC you'll have to remember to enable it next time you boot to Windows. But if that works and you don't find a proper solution, you could probably find a way to do it automatically.

Last edited by alphaniner (2015-01-08 14:15:50)

Untribium · 2015-01-08 16:50:48

alphaniner wrote:

I was particularly hopeful you might find something in the WOL status as reported by ethtool, though now that I think about it that caused problems in Windows after booting to Linux rather than the other way around. On the Linux side, the only other thing I can think of is to change the debug parameter of the e1000e module. I've never done anything like that though, so I don't know what to expect. Maybe just a whole lot of gibberish dumped to dmesg/journal...
On the Windows side, I still think you should look into a config utility from Intel. It used to be called ProSet IIRC. As a workaround, you could also try disabling the NIC before rebooting. OFC you'll have to remember to enable it next time you boot to Windows. But if that works and you don't find a proper solution, you could probably find a way to do it automatically.

Yeah that makes sense. I guess whatever setting break it isn't written by the Linux driver (or Windows doesn't mind it), so the issue will have to be solved on the Windows side. I'll try running e1000e with the debug flag as well.
The Windows driver gives me this:

Not exactly sure how to go about it I guess I'm just gonna try disable everything and see if works. If so, then I can try turning them back on one by one to close in it.

As for BIOS options:

PCI-Express Native Power Management - Disabled

Intel Lan Controller - Enabled

Intel PXE OPROM - Disabled

Power-On by PCI-E - Disabled

Looks quite okay, I think. I'm guessing the second option would disable it completely which is not exactly what I want

Thanks for the support guys!

t0m5k1 · 2015-01-08 17:22:47

If this is at home I really don't think any of those power management options are required (that's just me though) & thinking about it I have a hunch that the linux driver is having trouble dealing with a device that is clearly reporting itself as managed by another driver when it would be expecting the device to have just been initialised.

I say this because that is a very advanced list of features that can be set in the device so it remains initialised whilst the OS is down, it makes sense to surmise that the device would not care how the OS was put down so long as it remains initialised so it can deal with the power management options.

These would be very nice in a server environment if it were in a rack in a DC because then it would make the job of the server admin less like a headache & all you would need is a managed switch/server that you could remote to & bring it up with all manner of choices other than just WoL.

Untribium · 2015-01-08 18:46:23

And we have a winner!
Turning off all the Power Management features does indeed fix the problem. Turned them off, booted linux as usual, found no issues. Then back to Windows, features back on, linux on, broken. So I consider that evidence enough to declare this problem solved (albeit by sacrificing WoL, which I don't mind at all)

t0m5k1 wrote:

If this is at home I really don't think any of those power management options are required (that's just me though) & thinking about it I have a hunch that the linux driver is having trouble dealing with a device that is clearly reporting itself as managed by another driver when it would be expecting the device to have just been initialised.
I say this because that is a very advanced list of features that can be set in the device so it remains initialised whilst the OS is down, it makes sense to surmise that the device would not care how the OS was put down so long as it remains initialised so it can deal with the power management options.

Sounds absolutely plausible and the fact that shutting the features off kinda confirms that. Although I was worried, that the "driver" would keep running despite the features being off, but thankfully, that is not the case

I will most likely go through the options one by one later today, for science

t0m5k1 · 2015-01-08 23:19:12

Glad to hear you fixed it

blackdog6621 · 2015-02-03 23:02:52

Just wanted to let you know I've been searching for a solution to this problem off and on for months and I finally stumbled on this thread. I don't think I ever would have stumbled on WoL and the Windows power management being the issue. You guys rock! Thanks so much!

...closes ~40 open tabs in Chrome...

Last edited by blackdog6621 (2015-02-03 23:04:51)

epinephrine · 2015-05-12 14:52:42

And here's another soul that is eternally grateful for this solution! WoL, who would have thought?

sebmil · 2015-06-20 12:54:59

Hi, just created a account to say thank you !
I had this same problem on Linux Mint and searched for hours, upgrading the BIOS, lowering cpu/pci/ram speeds and so, before discovering this post which solved everything.

Maybe the e1000e module could reset these settings on loading, that would save lot of time for people having the same issue.

Last edited by sebmil (2015-06-20 12:55:07)

bananapan · 2015-08-08 09:02:52

I've also created an account to say thankyou for this thread (another Linux Mint user).

The problem began when I installed Windows 10 (clean install) after previously using Windows 8.1. It took a while to find this thread (I didn't think the issue was adapter specific), but the issue for me was that my network connection would continually attempt connecting + disconnect and never have internet access. I must have had an older intel driver on Window 8.1 with the different defaults.

Thanks again!

Last edited by bananapan (2015-08-08 09:04:45)

Alkali · 2015-08-20 07:53:22

I am sincerely grateful that you all figured this out. I was having to cut my computer on and off from a connected power strip in order to get my ethernet to work in Linux. So I wanted to say thanks and report on the checkbox that actually causes the issue.

I only had to un-check the box "Wake on Magic Packet from power off state" and my wired connection works on both OS'es

So you can leave most of the power save settings in place, you only need to un-check the one box in order to have a working ethernet port. Great find and thanks again!

fellfromhell · 2015-09-23 14:02:34

I am so overjoyed at this solution.
A thousand thanks, this issue vexed me for many months.

jnko · 2015-11-03 09:57:42

My experience in this issue was:
- Whenever Windows 10 was booted before Linux (Debian 8 in my case, but this does not matter) Ethernet is not working.
- It works when computer was completely turned off before starting Linux

Disabling WoL and/or PXE was not a solution because we need it in out classrooms for administration

So it seems that the driver (e1000e) does not completely initializes (reset) the network interface while enabling.

My solution is quiet simple: Reset the PCI Device before starting the Network Interface

#!/bin/bash

#Get the PCI-Address of network card (Caution: This works ONLY with ONE NIC)
PCI=`/usr/bin/lspci | /bin/egrep -i 'network|ethernet' | /usr/bin/cut -d' ' -f1`
PCIPATH=`/usr/bin/find /sys -name *\${PCI} | /bin/egrep -i *pci0000*`

#echo "PCI    =$PCI"
#echo "PCIPATH=$PCIPATH"
#ls -la $PCIPATH

/usr/bin/logger -t "ResetNIC" "Resetting PCI NIC ${PCIPATH}"

#Reset the PCI Device completely (like Power-ON/Off)
echo 1 >${PCIPATH}/reset

Just execute this script ideally before NIC is going up and you are done.

Btw: You can reset nearly any PCI-device with this commands slightly modified...

Last edited by jnko (2015-11-03 10:00:48)

NealXGS · 2015-11-26 23:36:00

jnko wrote:

My experience in this issue was:
- Whenever Windows 10 was booted before Linux (Debian 8 in my case, but this does not matter) Ethernet is not working.
- It works when computer was completely turned off before starting Linux
Disabling WoL and/or PXE was not a solution because we need it in out classrooms for administration
So it seems that the driver (e1000e) does not completely initializes (reset) the network interface while enabling.
My solution is quiet simple: Reset the PCI Device before starting the Network Interface
#!/bin/bash

#Get the PCI-Address of network card (Caution: This works ONLY with ONE NIC)
PCI=`/usr/bin/lspci | /bin/egrep -i 'network|ethernet' | /usr/bin/cut -d' ' -f1`
PCIPATH=`/usr/bin/find /sys -name *\${PCI} | /bin/egrep -i *pci0000*`

#echo "PCI    =$PCI"
#echo "PCIPATH=$PCIPATH"
#ls -la $PCIPATH

/usr/bin/logger -t "ResetNIC" "Resetting PCI NIC ${PCIPATH}"

#Reset the PCI Device completely (like Power-ON/Off)
echo 1 >${PCIPATH}/reset
Just execute this script ideally before NIC is going up and you are done.
Btw: You can reset nearly any PCI-device with this commands slightly modified...

Great work, jnko!

This really get me out the headache.

Simply reset the PCI and everything is going well !

daveballan · 2021-01-03 14:09:38

I'm one of the people who registered specifically to post to this threat! Had the issue that following a reboot from Windows 10, none of my linux installs and live installs would connect to the wired ethernet. Disabling "PME" on the network interface in Windows is what fixed it for me (left the WOL settings enabled as they didn't fix the issue).

Thanks very much all! Problem with this issue was that is was difficult to google for, as I was looking for linux fixes, when the problem was actually in Windows...

V1del · 2021-01-03 15:24:35

While it's nice to hear that this still helped you, please don't dig out 5 year old solved threads: https://wiki.archlinux.org/index.php/Co … bumping%22

Closing.

Arch Linux

#1 2015-01-07 19:46:40

[SOLVED] Ethernet issues after booting Windows (Intel I217-V (e1000e))

#2 2015-01-07 20:01:22

Re: [SOLVED] Ethernet issues after booting Windows (Intel I217-V (e1000e))

#3 2015-01-07 21:30:38

Re: [SOLVED] Ethernet issues after booting Windows (Intel I217-V (e1000e))

#4 2015-01-07 23:45:03

Re: [SOLVED] Ethernet issues after booting Windows (Intel I217-V (e1000e))

#5 2015-01-08 14:10:29

Re: [SOLVED] Ethernet issues after booting Windows (Intel I217-V (e1000e))

#6 2015-01-08 16:50:48

Re: [SOLVED] Ethernet issues after booting Windows (Intel I217-V (e1000e))

#7 2015-01-08 17:22:47

Re: [SOLVED] Ethernet issues after booting Windows (Intel I217-V (e1000e))

#8 2015-01-08 18:46:23

Re: [SOLVED] Ethernet issues after booting Windows (Intel I217-V (e1000e))

#9 2015-01-08 23:19:12

Re: [SOLVED] Ethernet issues after booting Windows (Intel I217-V (e1000e))

#10 2015-02-03 23:02:52

Re: [SOLVED] Ethernet issues after booting Windows (Intel I217-V (e1000e))

#11 2015-05-12 14:52:42

Re: [SOLVED] Ethernet issues after booting Windows (Intel I217-V (e1000e))

#12 2015-06-20 12:54:59

Re: [SOLVED] Ethernet issues after booting Windows (Intel I217-V (e1000e))

#13 2015-08-08 09:02:52

Re: [SOLVED] Ethernet issues after booting Windows (Intel I217-V (e1000e))

#14 2015-08-20 07:53:22

Re: [SOLVED] Ethernet issues after booting Windows (Intel I217-V (e1000e))

#15 2015-09-23 14:02:34

Re: [SOLVED] Ethernet issues after booting Windows (Intel I217-V (e1000e))

#16 2015-11-03 09:57:42

Re: [SOLVED] Ethernet issues after booting Windows (Intel I217-V (e1000e))

#17 2015-11-26 23:36:00

Re: [SOLVED] Ethernet issues after booting Windows (Intel I217-V (e1000e))

#18 2021-01-03 14:09:38

Re: [SOLVED] Ethernet issues after booting Windows (Intel I217-V (e1000e))

#19 2021-01-03 15:24:35

Re: [SOLVED] Ethernet issues after booting Windows (Intel I217-V (e1000e))

Board footer