[9.302-2][BUG] Adapter E1000E hangs/reset

Probably never, if you don't provide the necessary information:

- Exact chip type
- PCI PnP ID (ven & dev), output of "lspci -vn" for NIC
- Output of "ethtool -k ethX"

Probably never, if you don't provide the necessary information:

- Exact chip type
- PCI PnP ID (ven & dev), output of "lspci -vn" for NIC
- Output of "ethtool -k ethX"

Well, this issue has been reported by several people during this last months and some of them included the info you asked, if there's intent from Sophos to correct this, they can and could ask for this information or other if needed.

Here is the info you asked:

This is the adapter that gives problems (Intel 82579LM adapter) below is the info for the 2 adapters I have, don't know what is the one for this.

Note: I have disable TSO to avoid the hanging.

utm9-lan:/home/login # lspci -vn

00:19.0 0200: 8086:1502 (rev 04)
        Subsystem: 8086:2036
        Flags: bus master, fast devsel, latency 0, IRQ 42
        Memory at f7d00000 (32-bit, non-prefetchable) [size=128K]
        Memory at f7d35000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at f080 [size=32]
        Capabilities: [c8] Power Management version 2
        Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [e0] PCI Advanced Features
        Kernel driver in use: e1000e
        Kernel modules: e1000e


02:00.0 0200: 8086:10d3
        Subsystem: 8086:2036
        Flags: bus master, fast devsel, latency 0, IRQ 18
        Memory at f7c00000 (32-bit, non-prefetchable) [size=128K]
        I/O ports at e000 [size=32]
        Memory at f7c20000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: [c8] Power Management version 2
        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [e0] Express Endpoint, MSI 00
        Capabilities: [a0] MSI-X: Enable+ Count=5 Masked-
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Device Serial Number 7c-05-07-ff-ff-3c-79-8d
        Kernel driver in use: e1000e
        Kernel modules: e1000e

utm9-lan:/home/login # ethtool -k eth0
Features for eth0:
rx-checksumming: on
tx-checksumming: on
        tx-checksum-ipv4: off [fixed]
        tx-checksum-ip-generic: on
        tx-checksum-ipv6: off [fixed]
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: on
        tx-scatter-gather: on
        tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
        tx-tcp-segmentation: off
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp6-segmentation: off
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: on
loopback: off [fixed]
rx-fcs: off
rx-all: off
utm9-lan:/home/login #

BTW: The second adapter in your lspci output appears to be a different one: Intel 82574L, which is already addressed by Sophos via /etc/udev/rules.d/20-nic.rules.

If simply disabling TSO helps, it's easy to workaround this. Create a file /etc/udev/rules.d/21-my-nic.rules:

SUBSYSTEM=="net", ACTION=="add", ATTRS{vendor}=="0x8086", ATTRS{device}=="0x1502", RUN+="/lib/udev/nic-disable-tso"

Reboot, done. Lasts until you install an Up2Date with a new udev package.

IMO Intel is to blame here for producing such bad hardware - so many errata in so many different chips.

IMO Intel is to blame here for producing such bad hardware - so many errata in so many different chips.

I'll not discuss this, but it seems this is happening on linux systems, I've never seen this problem  on windows machines, in fact this same board I use on UTM also use another one on windows 7 and never had problems.

I'll not discuss this, but it seems this is happening on linux systems, I've never seen this problem  on windows machines, in fact this same board I use on UTM also use another one on windows 7 and never had problems.

That's probably because on Windows, performance options like TSO are disabled by default.

BTW: The second adapter in your lspci output appears to be a different one: Intel 82574L, which is already addressed by Sophos via /etc/udev/rules.d/20-nic.rules.

Hi Mario, I must have missed the announcement for this workaround; which 9.2x versions is it in?

Thank you,
Barry

Huh, why announce? I guess this NIC has been addressed together with the other ones, especially those inside the official appliances.

Probably because this NIC was properly identified during the 9.2 Beta (enough info, as requested above).

BTW I doubt Sophos monitores this Beta subforum anymore since 9.300 is released, so I think the workaround posted above won't make it into next release (if ever). I think you need to create a support ticket.

BTW I doubt Sophos monitores this Beta subforum anymore since 9.300 is released, so I think the workaround posted above won't make it into next release (if ever). I think you need to create a support ticket.

Hi,

According to this post (https://www.astaro.org/beta-versions/utm-9-3-beta/54753-question-answered-when-will-board-stopped-being-monitored-bugs-9-3x.html) they will monitor this sub forum until the beginning of the next year. 

Regards.

Thanks for reporting. We are now tracking this as Mantis ID #32902