[9.312] Intel 82572EI e1000e Hardware Unit Hang

Sorry, the UTM is disabling TSO on eth0 (i217-v), but NOT on eth1.

lspci -v
01:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06)
        Subsystem: Intel Corporation PRO/1000 PT Server Adapter
        Flags: bus master, fast devsel, latency 0, IRQ 44
        Memory at f7e20000 (32-bit, non-prefetchable) [size=128K]
        Memory at f7e00000 (32-bit, non-prefetchable) [size=128K]
        I/O ports at e000 [size=32]
        Capabilities: [c8] Power Management version 2
        Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [e0] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Device Serial Number 00-15-17-ff-ff-2d-68-3b
        Kernel driver in use: e1000e
        Kernel modules: e1000e

Barry

lspci -vv:
01:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06)
        Subsystem: Intel Corporation PRO/1000 PT Server Adapter
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 8086:107d(rev 06)
        Subsystem: 8086:1084
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

ISTM this line in  /etc/udev/rules.d/20-nic.rules should disable TSO for eth1, but I don't see any message about TSO in dmesg other than from eth0

# e1000e: disable TSO for 82572EI (errata 7, #30669)
SUBSYSTEM=="net", ACTION=="add", ATTRS{vendor}=="0x8086", ATTRS{device}=="0x107d", RUN+="/lib/udev/nic-disable-tso"
S

Barry

I think any 8257x chpset is unable to be used in Linux due to a combination of bad hardware design and bad drivers.  Intel has shown no desire to fix this despite multiple bug reports.  Use the 210 series of chipsets instead or switch to the broadcom netextreme II cards too.  Another workaround is to instlal hyper-v onto the hardware and then run the UTM on that.  You then get the windows drivers for the hardware and the UTM only sees compatible nics that work well.

The fix is in progress but i would not trust these chipsets yet.
https://bugzilla.redhat.com/show_bug.cgi?id=785806

Thanks. I do have a Broadcom PCIe NIC, but it's incompatible with this motherboard for some reason (and Gigabyte isn't interested in fixing it).

It is behaving much better after I manually disabled TSO (the udev script isn't doing it for this NIC).

I did get one more reset though, although it is a different error message:
[42706.839176] e1000e 0000:01:00.0 eth0: Reset adapter unexpectedly
[42715.379607] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
[42715.379720] e1000e 0000:01:00.0 eth0: Link Speed was downgraded by SmartSpeed


Barry

It still seems to be fine with TSO manually disabled.

I also opened a support ticket with Sophos last weekend; they responded that they will look into it.

Barry

Hi,

I have a UTM Home running 9.312 on a Gigabyte Z97 motherboard and it has the Intel i217-v NIC onboard as eth0 and I have PCIe Intel NIC as eth1.  I am also getting this on eth0:

e1000e 0000:01:00.0 eth0: Reset adapter unexpectedly
e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx

It seems to happen when I am running a large download from internal machine that has Gigabit NIC - my external router is only 100 Mbps and Internet is only 12 Mbps.

Is there anything I can do to fix this?
Thanks.

http://www.mouser.com/pdfdocs/i217brief.pdf

Design is Highly Compatible with the
Intel® 82579 GbE Controller

use a different nic..that chipset and or chipset emulation has linux kernel issues.

The intel 210 card is a good alternative.