Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 23 Jan 2019 10:09:46 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 235147] em(4) driver not working for Intel 82583V Gigabit chip
Message-ID:  <bug-235147-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235147

            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@FreeBSD.org
          Reporter: kumba@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 por=
ts
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 ha=
ve
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, differ=
ent
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 g=
o 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 can=
not
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=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
=20=20=20=20=20=20=20
options=3D81249b<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=3D29<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.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-235147-227>