FS#62699 - Intel Gigabit Ethernet doesn't work. e1000e: Detected Hardware Unit Hang

Attached to Project: Arch Linux
Opened by Damian Nowak (Nowaker) - Wednesday, 22 May 2019, 03:10 GMT
Last edited by freswa (frederik) - Thursday, 20 February 2020, 21:26 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Motherboard: Asus Maximus VII Impact
Ethernet: e1000e
Linux: 5.1.3.arch1-1
Pacman: everything up-to-date as of 5/21/2019

Neither netctl nor NetworkManager will acquire an IP from DHCP. A manual`dhcpcd eno1` always timeouts.

Why this is a bug and not a PEBKAC:

- When I connect the cable from my Intel ethernet to a USB ethernet adapter, it works. (`dhcpcd enp0s20u2u1` on a USB ethernet adapter works just fine. Initiating a connection via Network Manager KDE applet works just fine)
- Windows 10 works on this interface just fine.

I followed suggestions from https://serverfault.com/questions/616485/e1000e-reset-adapter-unexpectedly-detected-hardware-unit-hang:

- ethtool -K eth0 gso off gro off tso off - did not work (even after rmmod and modprobe)
- ethtool -K eth0 tx off rx off - likewise

(Interface name was replaced with the correct interface name, obviously)

Relevant sections from dmesg:

```
[Tue May 21 21:50:02 2019] e1000e 0000:00:19.0 eno1: Detected Hardware Unit Hang:
TDH <0>
TDT <1>
next_to_use <1>
next_to_clean <0>
buffer_info[next_to_clean]:5.1.3.arch1-1

time_stamp <ffff8b5d>
next_to_watch <0>
jiffies <ffff8d80>
next_to_watch.status <0>
MAC Status <40080080>
PHY Status <7949>
PHY 1000BASE-T Status <0>
PHY Extended Status <3000>
PCI Status <10>
```

Worth noting e1000e works for me just fine on a different motherboards - Gigabyte Z97M-D3H and Gigabyte Z97N-WIFI.
This task depends upon

Closed by  freswa (frederik)
Thursday, 20 February 2020, 21:26 GMT
Reason for closing:  No response
Additional comments about closing:  This seems pretty stalled to me. If it's still an issue. Please fill a re-open request. Thank you :)
Comment by Jan de Groot (JGC) - Wednesday, 22 May 2019, 08:44 GMT
Something that could help you (as you state Windows 10 works, so I assume you're dual-booting): https://bbs.archlinux.org/viewtopic.php?id=191981
As for Gigabyte boards working: Z97M-D3H has Realtek LAN, Gigabyte Z97N-WIFI has Intel I218V and Atheros LAN while Asus board has I217V. Don't know if you're dual-booting with the gigabyte board.

It seems the Windows drivers put the hardware in a state where linux drivers can't initialize correctly.

Comment by Damian Nowak (Nowaker) - Wednesday, 22 May 2019, 10:00 GMT
Yes, I dual boot for video gaming. I had three of these boards recently, as my Z97N-WIFI died (dual boot working just fine), then used a spare Asus as a backup (Ethernet worked for me just once on Linux, and then never again, after my first Windows dual boot), and then used my replacement Z97M-D3H (I thought it has a e1000e card, not a Realtek). And yes, sounds like the solution in the forum should fix the issue. Thanks for finding and passing this! With this information in hand, should we keep this ticket open, or rather reach out to kernel/e1000e developers with a bug report? e1000e should properly set the state on interface init, that's for sure.
Comment by Jan de Groot (JGC) - Wednesday, 22 May 2019, 10:36 GMT
Can you try to disable hybrid shutdown (fast boot) in Windows?
Comment by Damian Nowak (Nowaker) - Thursday, 23 May 2019, 17:50 GMT
I followed each suggestion - yours and from the thread you mentioned. None works:

- Disable fast boot in Windows (as per https://www.windowscentral.com/how-disable-windows-10-fast-startup)
- Disable certain features in BIOS: Wake on LAN, PXE boot, etc.
- Disable power management options in Intel Driver - not doable, this driver is no longer provided by Intel
- echo 1 > /sys/devices/pci0000:00/0000:00:19.0/reset
- ethtool -K eno1 gso off gro off tso off
- ethtool -K eno1 tx off rx off
Comment by Oleksandr Natalenko (post-factum) - Monday, 27 May 2019, 07:42 GMT
Plz check if [1] and [2] fix your issue.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git/commit/?h=dev-queue&id=4d42556200cc6095c0e6ad319dd533e2a504a645
[2] https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git/commit/?h=dev-queue&id=d2788db09a50890a6f7dec95359ea3653d0908a2
Comment by Damian Nowak (Nowaker) - Monday, 27 May 2019, 07:54 GMT
Thank you. I installed a different motherboard in the meantime, but I'll be making another PC build with the affected I217V motherboard next weekend. I'll report back as soon as I try it out.
Comment by Damian Nowak (Nowaker) - Tuesday, 04 June 2019, 01:09 GMT
I put the affected motherboard back in but I couldn't reproduce the issue in these environments:

- a fresh pacstrapped Arch with kernel 5.1.6
- Arch ISO 201903

On a second thought, I should have also checked my existing Arch installation. Which I'll do in a couple days, and report back.
Comment by Damian Nowak (Nowaker) - Tuesday, 24 September 2019, 20:34 GMT
Closing because I don't have a way to reproduce at the moment. If I ever end up putting my Linux disks into the computer with I218, I'll report back.

Loading...