Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 24 Nov 2019 16:40:52 -0800
From:      Mark Millard <marklmi@yahoo.com>
To:        freebsd-amd64@freebsd.org
Subject:   FreeBSD head vs. ThreadRipper 1950X X399 AORUS gaming 7's EtherNet : Am I the only one with it not working?
Message-ID:  <F668211B-5D7A-47F0-91CC-9484C1E032D7@yahoo.com>
References:  <F668211B-5D7A-47F0-91CC-9484C1E032D7.ref@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
I (sometimes) have access to an Threadripper 1950X based X399 AORUS
Gaming 7 system. (Not used for gaming.) The notes below are about
that context. Currently, I'm mostly checking if my context is unique
for some reason.

I'll start off noting that Fedora (currently 31) and Windows 10 Pro
x64 (1903) have had no troubles with using the EtherNet or WiFi from
this board, simply rebooting the machine in the same physical and
networking context. Such is still true. The FreeBSD configuration
tend to be near simplest. The same is true for the other OS's. Nearly
all network activity is just local area network activity unless I'm
updating software.

Historically I've used the FreeBSD drive booted under HyperV a lot,
in part because the networking always worked well in FreeBSD in that
context.

I conclude that the hardware is okay and that FreeBSD is the odd-ball
thing involved, at least for native booting. (But I've no useful
detail of how it is odd-ball at this point.)

I'll note that the Threadripper system is my only native FreeBSD
amd64 context and it is the only context that I've been having
FreeBSD networking problems in. The cortex-a7, cortex-a53,
cortex-a57, and old PowerMac contexts seem to be doing fine for
such activity.


In this note I focus on EtherNet, since it seem to be effectively
non-functional. (WiFI is also odd, but somewhat functional. When
FreeBSD is native-booted I depend on the WiFi, despite poor
performance. Again Fedora and Windows 10 do not show problems.)
I recently jumped from -r352341 to -r355027 but the behavior has
been the same for EtherNet.

I count dhclient not being able to get an assignment as example
of non-functional. (Again, no such problems rebooting using the
Fedora or Windows 10 drives.) I deleted FreeBSD's very-old
ip4 fall-back address information file in order to make it hard
to miss when DHCP activity was not assigning an address.

FYI, in case of similar EtherNet hardware on other boards:

alc0: <Killer E2500 Gigabit Ethernet> port 0x1000-0x107f mem =
0xba000000-0xba03ffff irq 27 at device 0.0 numa-domain 0 on pci5
alc0: 11776 Tx FIFO, 12032 Rx FIFO
alc0: Using 1 MSIX message(s).
alc0: 4GB boundary crossed, switching to 32bit DMA addressing mode.
miibus0: <MII bus> numa-domain 0 on alc0
atphy0: <Atheros F1 10/100/1000 PHY> PHY 0 on miibus0
atphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, =
1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
alc0: Using defaults for TSO: 65518/35/2048
alc0: Ethernet address: . . .

Anyone else had such problems in a somewhat similar context?
Is having numa domains fairly unique to my context?

My time for such things is currently rather limited, but if there
are basic things to check on I'd eventually use any notes to help
isolate what to look at in more detail. (Jumping directly to a
solution seems unlikely: more stages/steps.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F668211B-5D7A-47F0-91CC-9484C1E032D7>