[Bug 235147] em(4) driver not working for Intel 82583V Gigabit chip

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235147

            Bug ID: 235147
           Summary: em(4) driver not working for Intel 82583V Gigabit chip
           Product: Base System
           Version: 12.0-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: kumba at gentoo.org

Trying to load FreeBSD 12.0-RELEASE on a small, six-port firewall appliance, a
Protectli FW6A (https://protectli.com/product/fw6a/).  The device's six ports
are powered by Intel's 82583V gigabit chipset, and supposed to be supported by
the em(4) driver.  I've opened a ticket with Protectli support, and they have
confirmed that 11.2-RELEASE will work, but have verified my observation that
12.0-RELEASE does not.  My suspicion is this is a regression from the iflib
updates done between 11.2 and 12.0.

I've tried a couple of things found in other bugs for the em(4) driver,
including disabling TSO, several sysctl tweakables, disabling MSI-X, different
ethernet cables, different ports, etc.  Nothing seems to work.  Also tried
forcing the igb(4) driver, to see if that would pick the ports up, but no go on
that.  Both the em(4) and igb(4) man pages say they can support the 82580
chipsets.

The port will take an IP address assigned statically, but cannot look one up
via DHCP.  It does seem capable of seeing ARP "Who am I?" requests, but cannot
see the responses and does not update the ARP tables w/ new MAC addresses, even
after fresh ping attempts (MAC and IPs below redacted).  It doesn't appear to
process any other ethertype protocol at all outside of ARP.  Though, I have not
verified that via tcpdump real well yet.

# arp -a
? (192.168.w.x) at xx:xx:xx:xx:xx:xx on em0 permanent [ethernet]
? (192.168.w.y) at (incomplete) on em0 expired [ethernet]
? (192.168.w.z) at (incomplete) on em0 expired [ethernet]

Some additional info from various utilities, with addresses masked:

# ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
       
options=81249b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LRO,WOL_MAGIC,VLAN_HWFILTER>
        ether xx:xx:xx:xx:xx:xx
        inet 192.168.w.x netmask 0xffffff00 broadcast 192.168.w.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>


dmesg:
pcib1: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
pci1: <ACPI PCI bus> on pcib1
em0: <Intel(R) PRO/1000 Network Connection> port 0xe000-0xe01f mem
0xdfe00000-0xdfe1ffff,0xdfe20000-0xdfe23fff irq 16 at device 0.0 on pci1
em0: attach_pre capping queues at 1
em0: using 1024 tx descriptors and 1024 rx descriptors
em0: msix_init qsets capped at 1
em0: pxm cpus: 2 queue msgs: 6 admincnt: 1
em0: using 1 rx queues 1 tx queues
em0: Using MSIX interrupts with 2 vectors
em0: allocated for 1 tx_queues
em0: allocated for 1 rx_queues
em0: Ethernet address: xx:xx:xx:xx:xx:xx
em0: netmap queues/slots: TX 1/1024, RX 1/1024
((repeat five more times to em5)
em0: link state changed to UP


If any additional information is needed to debug this, please let me know.

-- 
You are receiving this mail because:
You are the assignee for the bug.