Can you help me with the Intel i225-v network adapter?

I use a trple boot computer: Gentoo Linux, Windows 11 and - newly installed - FreeBSD. Used a hackintosh installation as well, but it won‘t boot any longer after a hardware upgrade. As boot selector i use rEFInd.
So, booting linox or windows, the Intel i225-v network interface works like a charm.
 
igc0@pci0:12:0:0: class=0x020000 rev=0x03 hdr=0x00 vendor=0x8086 device=0x15f3 subvendor=0x1043
This device is supported in 14.0. My guess is may be some default settings are different between freebsd & linux. I suggest asking on the freebsd-net@freebsd.org mailing list.


sys/dev/igc/if_igc.c:53: PVID(0x8086, IGC_DEV_ID_I225_V, "Intel(R) Ethernet Controller I225-V"),
sys/dev/igc/igc_api.c:106: case IGC_DEV_ID_I225_V:
sys/dev/igc/igc_hw.h:17:#define IGC_DEV_ID_I225_V 0x15F3
 
I'd like to know the following:

* What BIOS version is being used
* Does it (the Intel NIC) work from a cold boot using install media for 14.0?
 
I used Debian6 and compiled the kernel. It turned out bugus. Now is faster. Try to include the NIC.
 
I finally came around testing on one of the topton quad-I225 appliances (those ~150-200$ aliexpress routers) with a fresh FreeBSD-14.0-RELEASE memstick. We run those with OpenBSD where the I225 was working for several versions without any hassle (IIRC I set them up with 6.9 or 7.0):

Code:
# pciconf -lv | grep -B4 ethernet
igc0@pci0:1:0:0:        class=0x020000 rev=0x03 hdr=0x00 vendor=0x8086 device=0x15f3 subvendor=0x8086 subdevice=0x0000
    vendor     = 'Intel Corporation'
    device     = 'Ethernet Controller I225-V'
    class      = network
    subclass   = ethernet
igc1@pci0:2:0:0:        class=0x020000 rev=0x03 hdr=0x00 vendor=0x8086 device=0x15f3 subvendor=0x8086 subdevice=0x0000
    vendor     = 'Intel Corporation'
    device     = 'Ethernet Controller I225-V'
    class      = network
    subclass   = ethernet
igc2@pci0:3:0:0:        class=0x020000 rev=0x03 hdr=0x00 vendor=0x8086 device=0x15f3 subvendor=0x8086 subdevice=0x0000
    vendor     = 'Intel Corporation'
    device     = 'Ethernet Controller I225-V'
    class      = network
    subclass   = ethernet
igc3@pci0:4:0:0:        class=0x020000 rev=0x03 hdr=0x00 vendor=0x8086 device=0x15f3 subvendor=0x8086 subdevice=0x0000
    vendor     = 'Intel Corporation'
    device     = 'Ethernet Controller I225-V'
    class      = network
    subclass   = ethernet
# ifconfig igc0 up
# dhclient igc0
DHCPDISCOVER on igc0 to 255.255.255.255 port 67 interval 3
DHCPOFFER from 10.50.53.4
DHCPREQUEST on igc0 to 255.255.255.255 port 67
DHCPACK from 10.50.53.4
bound to 10.50.53.181 -- renewal in 300 seconds.
# ping 10.50.53.1
PING 10.50.53.1 (10.50.53.1): 56 data bytes
64 bytes from 10.50.53.1: icmp_seq=0 ttl=255 time=0.464 ms
64 bytes from 10.50.53.1: icmp_seq=1 ttl=255 time=0.418 ms
64 bytes from 10.50.53.1: icmp_seq=2 ttl=255 time=0.390 ms
^C
--- 10.50.53.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.390/0.424/0.464/0.030 ms

I also tested with a 13.-2-RELEASE memstick and I also immediately got a link and a DHCP lease; it just works OOTB. But again: this is the "standard" variant (subvendor=0x8086), so I'd nag ASUS for a clean firmware (probably without any "lan guard" snakeoil...) because their NIC is *not* what they advertised...
I've been avoiding ASUS for exactly that reason for years now - they did the same with I219 chipsets and other hardware that is advertised as some standard e.g. intel component but in fact isn't and hence won't work with stock (intel) drivers.
 
It works wirh the open source kernel drivers from Linux.
You keep coming back to the point that the I225-V NIC works with Windows and Linux -- which is completely unastonishing, since ASUS would have no market for their motherboard if they did not address those usage cases.

Two significant points from the discussions above are:
  1. the Intel I225-V NIC works with FreeBSD, as I demonstrated with FreeBSD14.0 and sko demonstrated with both FreeBSD 13.2 and 14.0 (in pretty much identical ways); and
  2. diizzy is telling us the I225-V is working with FreeBSD 14.0 on a motherboard identical to yours, but BIOS revisions above 1602 cause serious problems.
So, to move forward, do the definitive baseline tests. If the failure is confirmed, downgrade the BIOS and repeat.

If all that fails, follow the advice of bakul, contact the freebsd-net@freebsd.org mailing list.
 
But I still cannot understand, why an open source driver in Linux works perfectly but cannot be adopted to FreeBSD. I will not downgrade the BIOS.
I did the basic tests again, upgraded to 15.0 and did them once again, same result, zero packages over the line.
 
But I still cannot understand, why an open source driver in Linux works perfectly but cannot be adopted to FreeBSD. I will not downgrade the BIOS.
You may wish to file a bug report with ASUS as well as FreeBSD. That may eventually help fix the driver or the bios. Complaining here won’t help you.

Opensource can only work if people help out. If you are capable, you may wish to atleast temoprarily downgrade the bios to help debug. If that is beyond your ability, that is fine. In that case at least file a bug report, with details on which bios version you’re running etc.

Yoy can of course give up on FreeBSD and run Linux but then you’d have wasted a bunch of your time (& that of others). At least make it worth something! Operators are standing by to accept your bug reports;-)
 
In NetBSD there is a „aq“ driver, which works perfectly with my other network chip from Aquantia, so that it‘s one problem less.
I‘d rather stick to FreeBSB, but not without a working internet connection.
 
The AX88179 chipset wired USB Ethernet adapters work at gigabit speed on both FreeBSD and Linux, provided you plug them into a USB 3.2 Gen 2 port (your motherboard has four). I recommended one above, and pointed to a tweak they require at boot time.
 
The BIOS update could have included a update to the Intel Networking firmware found onboard.
The newer BIOS could have fixed an ACPI problem.

I don't think you can 'blame' anybody who fixes a problem. Did you read the BIOS release notes?
Usually they cover what was fixed and some add history of BIOS upgrades to top of file.
 
The BIOS update could have included a update to the Intel Networking firmware found onboard.
The newer BIOS could have fixed an ACPI problem.

I don't think you can 'blame' anybody who fixes a problem. Did you read the BIOS release notes?
Usually they cover what was fixed and some add history of BIOS upgrades to top of file.
It's not a NIC firmware issue, read the referenced PR in post #56
 
Back
Top