Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 08 Feb 2019 09:08:14 +0000
From:      bugzilla-noreply@freebsd.org
To:        net@FreeBSD.org
Subject:   [Bug 235147] em(4) driver not working for Intel 82583V Gigabit chip
Message-ID:  <bug-235147-7501-GAp0Gv8GZ7@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-235147-7501@https.bugs.freebsd.org/bugzilla/>
References:  <bug-235147-7501@https.bugs.freebsd.org/bugzilla/>

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

--- Comment #5 from Joshua Kinard <kumba@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/kern=
el
over to the networking appliance via USB and booted into the new kernel.=20
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=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 a.b.c.d netmask 0xffffff00 broadcast a.b.c.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=3D29<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 ve=
ry
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 Goog=
le
wants to find right now), but I found the correct tunable names for newer i=
flib
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=3D0 ttl=3D120 time=3D12.144 ms
64 bytes from 8.8.8.8: icmp_seq=3D1 ttl=3D120 time=3D12.667 ms
64 bytes from 8.8.8.8: icmp_seq=3D2 ttl=3D120 time=3D10.681 ms
64 bytes from 8.8.8.8: icmp_seq=3D3 ttl=3D120 time=3D10.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 =3D 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.

--=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-7501-GAp0Gv8GZ7>