[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

--- Comment #5 from Joshua Kinard <kumba at gentoo.org> ---
(In reply to Krzysztof Galazka from comment #4)

I gave it a really quick test by trying to apply the diff from D18980 via 'cat
<patch> | patch -p2' while in /usr/src/sys, and rebuilding a GENERIC
12.0-RELEASE-p3 kernel on a secondary machine.  Copied the newer /boot/kernel
over to the networking appliance via USB and booted into the new kernel. 
Doesn't seem to have had any effect:

FreeBSD 12.0-RELEASE-p3 GENERIC amd64
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM
6.0.1)
[snip]
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: Using 1024 tx descriptors and 1024 rx descriptors
em0: Using 1 rx queues 1 tx queues
em0: Using MSI-X interrupts with 2 vectors
em0: Ethernet address: xx:xx:xx:xx:xx:xx
em0: netmap queues/slots: TX 1/1024, RX 1/1024
[snip]

# ifconfig -a
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 a.b.c.d netmask 0xffffff00 broadcast a.b.c.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host

I can't rule out that I need to apply other parts of that patch, but I find
that Phabricator interface to be incredibly confusing.  Is there a classic
gitweb sitting around somewhere that will cough up a standard unidiff patch of
the whole commit?  Or maybe the patch alone doesn't fix it?

---

So that said, the info on this chipset not being compatible w/ MSI-X was very
helpful, thank you.  I had to dig around, as the iflib change made obsolete the
old "hw.x.*" tunables in /boot/loader.conf (and that's all that stupid Google
wants to find right now), but I found the correct tunable names for newer iflib
stuff, and disabled MSI-X there.  After another reboot, we have contact:

# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=120 time=12.144 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=120 time=12.667 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=120 time=10.681 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=120 time=10.519 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 10.519/11.503/12.667/0.923 ms
root at armenelos:~ #

So!  It looks like the fix for these specific chips would be for em(4) to
automatically disable MSI-X when it detects the specific PCI ID of these
chipsets.

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