Having trouble getting my Intel I219-V attached to a driver

lncabin

I got a newly released ASRock Z590-ITX/ax that has two onboard NICs, a Realtek Dragon RTL8125BG and Intel I219-V.

I've been trying to get this to work on the 2.5.0 release.

I was able to get the Realtek working after compiling them on a Hyper-V setup using FreeBSD 12.2-Stable and git cloning pfSense's RELENG_2_5_0 src branch and rebuilding the world and kernel from that.

When I tried to do the same with Intel's latest 7.7.8 drivers and adding the if_em.ko to the kernel and if_em_load="YES" to the boot.loader.local, the driver still didn't attach to the NIC.

Also, when I checked with kldstat, the if_em.ko was not listed.

I'm wondering if I have an unsupported version of the I219-V as it calls it "Ethernet Connection (14) I219-V" in the pciconf.

I could be doing something wrong as I am a first time user of pfSense and I basically spent all weekend learning how to compile drivers and digging into these complexities.

uname

FreeBSD pfSense.home.arpa 12.2-STABLE FreeBSD 12.2-STABLE d48fb226319(devel-12) pfSense  amd64

pciconfig

hostb0@pci0:0:0:0:	class=0x060000 card=0x9b631849 chip=0x9b638086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    class      = bridge
    subclass   = HOST-PCI
pcib1@pci0:0:1:0:	class=0x060400 card=0x19011849 chip=0x19018086 rev=0x03 hdr=0x01
    vendor     = 'Intel Corporation'
    device     = '6th-9th Gen Core Processor PCIe Controller (x16)'
    class      = bridge
    subclass   = PCI-PCI
vgapci0@pci0:0:2:0:	class=0x030000 card=0x9bc81849 chip=0x9bc88086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    class      = display
    subclass   = VGA
none0@pci0:0:8:0:	class=0x088000 card=0x19111849 chip=0x19118086 rev=0x00 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model'
    class      = base peripheral
xhci0@pci0:0:20:0:	class=0x0c0330 card=0x43ed1849 chip=0x43ed8086 rev=0x11 hdr=0x00
    vendor     = 'Intel Corporation'
    class      = serial bus
    subclass   = USB
none1@pci0:0:20:2:	class=0x050000 card=0x00000000 chip=0x43ef8086 rev=0x11 hdr=0x00
    vendor     = 'Intel Corporation'
    class      = memory
    subclass   = RAM
none2@pci0:0:22:0:	class=0x078000 card=0x43e01849 chip=0x43e08086 rev=0x11 hdr=0x00
    vendor     = 'Intel Corporation'
    class      = simple comms
ahci0@pci0:0:23:0:	class=0x010601 card=0x43d21849 chip=0x43d28086 rev=0x11 hdr=0x00
    vendor     = 'Intel Corporation'
    class      = mass storage
    subclass   = SATA
pcib2@pci0:0:28:0:	class=0x060400 card=0x43bd1849 chip=0x43bd8086 rev=0x11 hdr=0x01
    vendor     = 'Intel Corporation'
    class      = bridge
    subclass   = PCI-PCI
pcib3@pci0:0:29:0:	class=0x060400 card=0x43b01849 chip=0x43b08086 rev=0x11 hdr=0x01
    vendor     = 'Intel Corporation'
    class      = bridge
    subclass   = PCI-PCI
isab0@pci0:0:31:0:	class=0x060100 card=0x43851849 chip=0x43858086 rev=0x11 hdr=0x00
    vendor     = 'Intel Corporation'
    class      = bridge
    subclass   = PCI-ISA
none3@pci0:0:31:4:	class=0x0c0500 card=0x43a31849 chip=0x43a38086 rev=0x11 hdr=0x00
    vendor     = 'Intel Corporation'
    class      = serial bus
    subclass   = SMBus
none4@pci0:0:31:5:	class=0x0c8000 card=0x43a41849 chip=0x43a48086 rev=0x11 hdr=0x00
    vendor     = 'Intel Corporation'
    class      = serial bus
none5@pci0:0:31:6:	class=0x020000 card=0x15fa1849 chip=0x15fa8086 rev=0x11 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Ethernet Connection (14) I219-V'
    class      = network
    subclass   = ethernet
igb0@pci0:1:0:0:	class=0x020000 card=0x50018086 chip=0x15218086 rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'I350 Gigabit Network Connection'
    class      = network
    subclass   = ethernet
igb1@pci0:1:0:1:	class=0x020000 card=0x50018086 chip=0x15218086 rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'I350 Gigabit Network Connection'
    class      = network
    subclass   = ethernet
igb2@pci0:1:0:2:	class=0x020000 card=0x50018086 chip=0x15218086 rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'I350 Gigabit Network Connection'
    class      = network
    subclass   = ethernet
igb3@pci0:1:0:3:	class=0x020000 card=0x50018086 chip=0x15218086 rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'I350 Gigabit Network Connection'
    class      = network
    subclass   = ethernet
re0@pci0:2:0:0:	class=0x020000 card=0x81251849 chip=0x812510ec rev=0x05 hdr=0x00
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8125 2.5GbE Controller'
    class      = network
    subclass   = ethernet
nvme0@pci0:3:0:0:	class=0x010802 card=0x500615b7 chip=0x500615b7 rev=0x00 hdr=0x00
    vendor     = 'Sandisk Corp'
    class      = mass storage
    subclass   = NVM

ifconfig

igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=e100bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,RXCSUM_IPV6,TXCSUM_IPV6>
	ether a0:36:9f:65:22:08
	inet6 fe80::a236:9fff:fe65:2208%igb0 prefixlen 64 scopeid 0x1
	media: Ethernet autoselect
	status: no carrier
	nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	description: LAN
	options=e100bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,RXCSUM_IPV6,TXCSUM_IPV6>
	ether a0:36:9f:65:22:09
	inet6 fe80::a236:9fff:fe65:2209%igb1 prefixlen 64 scopeid 0x2
	inet 10.0.0.100 netmask 0xffffff00 broadcast 10.0.0.255
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
igb2: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=e507bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
	ether a0:36:9f:65:22:0a
	media: Ethernet autoselect
	status: no carrier
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
igb3: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=e507bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
	ether a0:36:9f:65:22:0b
	media: Ethernet autoselect
	status: no carrier
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
re0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=201b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,WOL_MAGIC>
	ether a8:a1:59:6b:c9:be
	media: Ethernet autoselect
	status: no carrier
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
	options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
	inet6 ::1 prefixlen 128
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
	inet 127.0.0.1 netmask 0xff000000
	groups: lo
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
enc0: flags=0<> metric 0 mtu 1536
	groups: enc
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
pfsync0: flags=0<> metric 0 mtu 1500
	groups: pfsync
pflog0: flags=100<PROMISC> metric 0 mtu 33160
	groups: pflog

stephenw10

You really shouldn't need to compile anything for em at this point.

It sounds like what you did compile isn't loading anyway. Check the boot log for errors.

That device is not listed by the in-kernel driver in 2.5:
https://github.com/pfsense/FreeBSD-src/blob/RELENG_2_5_0/sys/dev/e1000/e1000_hw.h#L45

It's not in head either. It's not even in head in FreeBSD.

Is it actually shown in whatever you were compiling?

Steve

lncabin

@stephenw10

So after my original post, I was doing some more digging around and I discovered exactly what you just posted.

I was initially working with the latest file set from Intel's website.

I added this line to e1000_hw.h

#define E1000_DEV_ID_PCH_TGP_I219_V14		0x15FA

This to the em_vendor_info_array[] in if_em.c

{ 0x80086, E1000_DEV_ID_PCH_TGP_I219_V4, PCI_ANY_ID, PCI_ANY_ID, 0}

And then I got e1000_api.c and I didn't know exactly what the mac type was. I assumed it would be considered a new one not listed yet, e1000_pch_tgp but I also didn't know what or if there were any additional functions that would be needed to incorporate the newer Tiger Point PCH architecture.

Luckily, I found Linux's driver set and compared it. Linux's driver set actually supports I-219 all the way to V19, it looks like.

Looking at Linux's driver set, I saw it actually listed V14 right below V11 which assigned it's mac type as e1000_pch_cnp.

e1000_pch_cnp is also in FreeBSD's e1000_api.c. So, I inserted it's case into there.

	case E1000_DEV_ID_PCH_CMP_I219_V11:
        case E1000_DEV_ID_PCH_TGP_I219_V14:
		mac->type = e1000_pch_cnp;

And, then I guess I got a little carried away as during all this I was reading older forum posts from various places, trying to find out how to incorporate an unattached driver. And I thought I needed to recompile the kernel without if_em.ko and have it load as a separate file.

So, I did that and scp'd the new /boot/kernel over to my pfSense machine along with if_em.ko, adding the appropriate lines to the loader.conf.local, and it actually picked up em(0) for the I-219! But for some reason I lost all the igb's for my I350.

After that is when I discovered that configuration files in e1000 in pfSenses source modules folder were a bit different from Intel's files, even tho it says this file set is from version 7.7.8 which is the latest version.

I restarted and made clean installs of my pfSense machine and the virtual machine I was using to compile the file.

This time I modified the files in the /usr/src/sys/dev/e1000 folder, adding this line to if_em.c instead and the additional lines in the other two files.

	PVID(0x8086, E1000_DEV_ID_PCH_TGP_I219_V14, "Intel(R) PRO/1000 Network Connection")

I ran a make on it from the sys/modules/em folder and scp'd the new if_em.ko to my pfSense machine /boot/modules (finding where the Makefile put the .ko was a pain in the butt), adding the appropriate lines to the loader.conf.local file.

if_em_load="YES"
if_em_name="/boot/modules/if_em.ko"

Restarted and still nothing!

Tried to force load using kldload and it output that couldn't load as it was compiled from a different kernel or something.

I thought I was using the right virtual machine setup, installing FreeBSD 12.2-STABLE and cloning the devel-12 branch of the pfsense/FreeBSD-src to my virtual machine's /src folder. But I guess not.

This is the first time actually using a Unix OS and github.

I bet once I figure out how to get the appropriate virtual machine setup that compiling a new if_em.ko with those line additions above will get my I-219 working while keeping my igb's intact.

semada

@lncabin
I have a simillar problem. Any updates, please?

stephenw10

That device is now supported in FreeBSD head:
https://github.com/freebsd/freebsd-src/blob/main/sys/dev/e1000/e1000_hw.h#L167

Part of this commit which doesn't look to be anything too complex. Though it may significantly far from 12-stable.

Steve

lncabin

So, I updated to 2.5.2, which my I219-V (14) seems to be supported but I still can not get the driver to attach. Not sure where to go from here.

stephenw10

Mmm, it's in 2.5.2:
https://github.com/pfsense/FreeBSD-src/blob/RELENG_2_5_2/sys/dev/e1000/e1000_hw.h#L167

What does the boot log show when it tries to attach?
Anything more if you boot verbose?

Can you try a 2.6 snapshot?

Steve

lncabin

@stephenw10

Curiously,

Dashboard shows version as 2.5.2-RELEASE
but the kernal shows as FreeBSD 12.2-STABLE fd0f54f44b5c(RELENG_2_5_0) pfSense amd64

Wouldn't one expect 2.5.2-RELEASE to show as RELENG_2_5_2?

stephenw10

Ah, that's it, yes. We had to roll a bunch of changes in 2.5.2 after a performance regression was found. It was built on the 2.5.0 branch so doesn't have that NIC support.
It is in 2.6 snapshots though that are built on devel-12.

Steve

Woody 0

@stephenw10
Please forgive my lack of understanding, I literally just installed my first pfsense 2.5.2 installation and was hunting down an issue with a I219-V NIC not being recognized. First, I went to the github repository
https://github.com/pfsense/FreeBSD-src/blob/RELENG_2_5_2/sys/dev/e1000/e1000_hw.h to check for the supported hardware and it shows the I219-V I have is there.

Then I ran across this post, and I think what you are saying (and my uname -a would infer) is that my 2.5.2 installation is really a 2.5.0? And that if I want to have the I219-V driver I need to get a 2.6 snapshot? Also inferred: I should not rely on the github 2.5.2 source files as they are not in sync with the 2.5.2 download?

Like I said I'm new to pfsense, and if my hardware is not supported in the current build so be it. But putting out a build that is not in sync with the source files and not clearly documenting that divergence where a newer user like me can find it makes it nearly impossible to really troubleshoot these low level driver issues.

Woody

stephenw10

Yes, you will need to use a 2.6 snapshot to get support for that NIC with the in kernel driver.

No, github is not out of sync. The RELENG_2_5_2 branch was created with a number of additional features we expected to be in 2.5.2 release but we hit some issues in testing that could not be resolved in reasonable time. In order to make the bug fixes we had available as soon as possible we ended up building 2.5.2 on the RELENG_2_5_0 branch. It's not how we would normally do it but for a bug fix release a new branch is not normally required. There isn't a 2.5.1 branch for example.

Steve

Woody 0

@stephenw10
Thank you for the response and the explanation. While researching the I219-V problem I found some other forums where users where trying to resolve this issue by compiling their own drivers. I will try and find those posts and mention the 2.6 snapshot as a potential solution instead of compiling drivers and mucking with the kernel config.