Intel Ethernet Controller I225-LM Support?
-
After disabling UDP checksum offloading, my I225-LMs are working great. I'm able to pull ~940 mbit/sec down and ~1100 mbit/sec upload hooked into an AT&T BGW-320. I'm provisioned for gigabit service so the cards seem to be working as expected.
-
@bk150 Same here. The outstanding question being, when will the driver get fixed so that HW offloading can be enabled again?
-
@jerseymike it's already fixed in the 2.6.0 development builds :)
I would think the particular fixed could be implemented in the next 2.5.3 release but either way it should be working in 2.6.
-
@bk150 So I guess my next question is...
is 2.6.0 stable enough to use right now? LOL
-
@jerseymike I guess it depends on your use case. I definitely wouldn't use it in production at a business but for home use, depends on how understanding your family members are
I don't see any issue with using 2.5.2 with the UDP checksum hardware offloading disabled as my understanding is that it's still doing the UDP checksum, it's just in software instead of running on the network controller hardware itself. I would think this is sufficient for most cases as high loads of UDP traffic is pretty rare.
-
Ok so thats f***** up it works in their own appliance but not public release? Stingy holding out on us lol. Not being mean just saying...
-
It was just unfortunate timing. We had a bunch of cool fixes for things in the 2.5.2 branch, including this. We had to eventually build 2.5.2 on the 2.5.0 branch because it was going to take too long to get everything fixed and tested when there were security patches ready to go.
I have 2.6 running on a bunch of things without issue but there are still some outstanding things, most notably captive portal. https://redmine.pfsense.org/issues/12217
That may be fixed in tomorrows snap though.But check the list and decide for yourself:
https://redmine.pfsense.org/projects/pfsense/issues?query_id=106Steve
-
I am soooo damn slow... I just now realized your an admin and work with Netgate lol. Thanks for the heads up sir!
I'm just like everyone else, WE want "the" answer or answers and don't pay attention to everything else/details.
Goes to show READ EVERYTHING BEFORE doing ANYTHING!
-
I'm running the latest 2.6.0 snapshot with the QNAP QXG-2G2T-I225 and it is detected in the initial boot, but doesn't detect any interfaces and then shuts down. There are no other nics enabled(onboard is disabled in the BIOS). Maybe this specific device id isn't enabled, though I would have expected it to be a popular option. Has anyone else successfully gotten this specific card working? It is significantly cheaper than the 10Gb Intel varieties that support 2.5Gb 10GbaseT.
-
@arodd I've had inconsistent results as well using two of the single interface versions of the QNAP i225s - QXG-2G1T-I225. Also running 2.60. Sometimes the driver loads and others it does not. Currently running 2.6.0.a.20210907.0100 with success.
-
You have any logs showing it detected but not attaching maybe?
-
@stephenw10 I think I would need to fetch them via serial interface or something. It shuts down as soon as it boots up since there are no interfaces detected so there isn't an opportunity to fetch them and log to a flash drive or anything. Will see if I can get a serial port to dump the boot log.
Edit: Scratch that my unit doesn't have a serial port. Will try and find another way to capture them if the boot/system log persists on disk after multiple boots.
-
@stephenw10 dmesg.txt
Was able to fetch everything via single user mode, attached the dmesg output. The igc0 specific lines are below. This is from the latest 2.6.0.a.20210910.0100. Looks to be the same issue as previous posters, but still occurring in 2.6.x.igc0: <Intel(R) Ethernet Controller I225-LM> mem 0xf7c00000-0xf7cfffff,0xf7d00000-0xf7d03fff irq 16 at device 0.0 on pci3 igc0: Setup of Shared code failed, error -2 igc0: IFDI_ATTACH_PRE failed 6 device_attach: igc0 attach returned 6 igc0: <Intel(R) Ethernet Controller I225-LM> mem 0xf7900000-0xf79fffff,0xf7a00000-0xf7a03fff irq 18 at device 0.0 on pci6 igc0: Setup of Shared code failed, error -2 igc0: IFDI_ATTACH_PRE failed 6 device_attach: igc0 attach returned 6 igc0: <Intel(R) Ethernet Controller I225-LM> mem 0xf7c00000-0xf7cfffff,0xf7d00000-0xf7d03fff irq 16 at device 0.0 on pci3 igc0: Setup of Shared code failed, error -2 igc0: IFDI_ATTACH_PRE failed 6 device_attach: igc0 attach returned 6 igc0: <Intel(R) Ethernet Controller I225-LM> mem 0xf7900000-0xf79fffff,0xf7a00000-0xf7a03fff irq 18 at device 0.0 on pci6 igc0: Setup of Shared code failed, error -2 igc0: IFDI_ATTACH_PRE failed 6 device_attach: igc0 attach returned 6 igc0: <Intel(R) Ethernet Controller I225-LM> mem 0xf7c00000-0xf7cfffff,0xf7d00000-0xf7d03fff irq 16 at device 0.0 on pci3 igc0: Setup of Shared code failed, error -2 igc0: IFDI_ATTACH_PRE failed 6 device_attach: igc0 attach returned 6 igc0: <Intel(R) Ethernet Controller I225-LM> mem 0xf7900000-0xf79fffff,0xf7a00000-0xf7a03fff irq 18 at device 0.0 on pci6 igc0: Setup of Shared code failed, error -2 igc0: IFDI_ATTACH_PRE failed 6 device_attach: igc0 attach returned 6 -
So it turns out my issue was related to booting via BIOS vs. UEFI. Realized this when it attached and was working in the installer CD via UEFI. Switched the install over to UEFI and everything is working now.
Update: Things work fine without VLANs, but traffic isn't flowing when using VLAN interfaces.
-
Try disabling any vlan hardware off-loading options. I'd start with VLAN_HWFILTER if it's enabled on that variant.
The driver 2.6. is now identical to what we build in 21.05.1 (or 21.09) so oy must be some hardware difference.
Steve
-
FYI, the Dell Optiplex I'm trying to use has the same driver attach problem reported above, if the internal NIC is linked up at boot time then the igc driver won't attach to my QNAP card.
The difference is that I'm an actual *nix kernel developer who knows how crazy that sounds...there must be some timing issue involved. I'd be willing to dive in on my free time and do some debugging or info gathering, but I'm currently hampered by the fact that I haven't touched FreeBSD ever so I'm doing things like searching for links on "this is how you build the kernel" :)
-
I would start by booting with verbose enabled and see if the driver gives any sort of useful error output when it fails to attach.
Also that can change the timing so you may find it does attach when booting verbose, if it is a timing issue. I have seen that before with other hardware.At the loader prompt:
set boot_verbose=1 bootSteve
-
no new messages with boot_verbose. Looking at the source code, this makes sense as the debug output is all wrapped in a compile-time #define that's turned off. Any hints how to recompile the kernel so I can dig into this?
-
You don't need to recompile the kernel for most drivers, you can just compile the module and load it in preference to the in-kernel driver. I haven't actually tried that for igc though.
Steve
-
@stephenw10
This is where the "I've never touched freeBsd" bit is hitting me. I got the pfsense source code loaded onto a freebsd vm. While I couldn't get "make" working from {SRCROOT}/sys/modules/igc (some error about a bad definition of struct thread that implies to me that the include path was messed up but that was about as far as I was going to take it), I did get "make buildkernel" working fine from {SRCROOT}, and I went and found if_igc.ko in /usr/obj/...And I think I'm stuck. I added a string/device_printf to an always-run path (right before the call to igc_setup_init_funcs() that's returning the error). I can grep for the string in my built if_igc.ko file and it's there. I made an assumption that if I replaced the /boot/kernel/if_igc.ko file on the pfsense box with the one I built, I'd get my debug printf in either dmesg -a, /var/log/dmesg.boot, or /var/log/* somewhere.
I did not, it's like it's still using the original driver to boot. What bit of FreeBSD magic am I missing?
