https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235147
--- Comment #5 from Joshua Kinard <ku...@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@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.
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
