Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Intel Ethernet Controller I225-LM Support?

    Scheduled Pinned Locked Moved Hardware
    189 Posts 19 Posters 84.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • stephenw10S
      stephenw10 Netgate Administrator
      last edited by

      You have any logs showing it detected but not attaching maybe?

      A 1 Reply Last reply Reply Quote 0
      • A
        arodd @stephenw10
        last edited by arodd

        @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.

        A 1 Reply Last reply Reply Quote 0
        • A
          arodd @arodd
          last edited by arodd

          @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
          
          1 Reply Last reply Reply Quote 0
          • A
            arodd
            last edited by arodd

            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.

            1 Reply Last reply Reply Quote 0
            • stephenw10S
              stephenw10 Netgate Administrator
              last edited by

              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

              N 1 Reply Last reply Reply Quote 0
              • N
                ndemmon @stephenw10
                last edited by

                @stephenw10

                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" :)

                1 Reply Last reply Reply Quote 0
                • stephenw10S
                  stephenw10 Netgate Administrator
                  last edited by

                  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
                  boot
                  

                  Steve

                  N 1 Reply Last reply Reply Quote 0
                  • N
                    ndemmon @stephenw10
                    last edited by

                    @stephenw10

                    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?

                    1 Reply Last reply Reply Quote 0
                    • stephenw10S
                      stephenw10 Netgate Administrator
                      last edited by

                      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

                      N 1 Reply Last reply Reply Quote 0
                      • N
                        ndemmon @stephenw10
                        last edited by

                        @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?

                        1 Reply Last reply Reply Quote 0
                        • stephenw10S
                          stephenw10 Netgate Administrator
                          last edited by stephenw10

                          You need to load it at boot by adding:

                          if_igc_load="YES"
                          

                          to /boot/loader.conf.local. Create that file if it doesn't exist.

                          I've done that in the past with quite a few different modules but not with igc specifically.

                          Steve

                          N 1 Reply Last reply Reply Quote 1
                          • N
                            ndemmon @stephenw10
                            last edited by ndemmon

                            @stephenw10
                            Woo hoo, "phy initialization error". Now I just have to fix the debug messages to actually print out debug information (like what values are being read and written to the phy so I can tell what it doesn't like in the error case). Just as an FYI, with more test cycles it's not tracking the link state of em0 anymore. The most reliable reproduction method is to halt the system (option 6 from the login menu) and then when I start the system via the on button the attach fails. Thinking maybe something doesn't get reset on that particular path, will update again if I find a fix and/or give up and just give an info dump.

                            Thanks for saving me the hours trying to find the loader.conf.local magic by myself.

                            N 1 Reply Last reply Reply Quote 0
                            • N
                              ndemmon @ndemmon
                              last edited by

                              @stephenw10

                              Found it.

                                      /* Make sure the PHY is in a good state. Several people have reported
                                       * firmware leaving the PHY's page select register set to something
                                       * other than the default of zero, which causes the PHY ID read to
                                       * access something other than the intended register.
                                       */
                                      ret_val = hw->phy.ops.reset(hw);
                              
                              

                              (igc_i225.c, line 168-ish)

                              phy->ops.reset = igc_null_ops_generic;
                              
                              

                              (igc_phy.c, line 37)
                              So something about that boot path leaves the phy's page select at non-default, which makes the phy revision come out unexpected. The code tries to fix this by issuing a reset of the phy, but nobody wrote and/or assigned the phy reset function. (Function tracing shows that igc_null_ops_generic() is getting called there instead.)

                              The problem is that that's not exactly a risk-free fix of throwing an actual phy reset into the boot path.

                              N 1 Reply Last reply Reply Quote 0
                              • N
                                ndemmon @ndemmon
                                last edited by

                                So if I throw in:

                                        phy->ops.acquire        = igc_acquire_phy_base;
                                        phy->ops.check_reset_block = igc_check_reset_block_generic;
                                        phy->ops.commit         = igc_phy_sw_reset_generic;
                                //Adding a reset function so phy_id always works.
                                        phy->ops.reset          = igc_phy_hw_reset_generic;
                                        phy->ops.release        = igc_release_phy_base;
                                

                                it passes my initial tests. Assuming that this phy works like most of the dozens of phys that I've worked with, it implements two copies of the first few standard registers, one copy that tracks the "host side" of the phy that connects to the MAC and one copy that tracks the "line side" where you plug in the cable. The software reset bit is in that register window, so software reset doesn't affect the page you're reading from (you just reset the half of the phy that the page select currently has selected) so it has to be the hw_reset function.

                                This WILL cause an extra link-flap at boot time...I don't really care for my home setup. If I was looking for something safer to do in public code, I'd probably leave the path that grabs the phyID alone, but if it failed I'd do the hardware reset and retry. Or you could manually select page 0 before grabbing the phyID, but who knows what other stale info the PHY has that might screw something else up.

                                Thanks for the help!

                                1 Reply Last reply Reply Quote 0
                                • stephenw10S
                                  stephenw10 Netgate Administrator
                                  last edited by stephenw10

                                  Ah, nice!

                                  Might be time to open a FreeBSD bug for that if nothing already exists.

                                  Is this you?: https://reviews.freebsd.org/D32772

                                  If not it looks like this is already being addressed. 😉

                                  That is in FreeBSD source now but not our fork yet.

                                  Steve

                                  1 Reply Last reply Reply Quote 0
                                  • X
                                    xiazuojie @Setarcos
                                    last edited by xiazuojie

                                    I think I have the same issue as @setarcos, that is very poor inbound packages (drops to zero) while outbound packages are working perfect at full 2.5GB speed.

                                    I've tested the same setup with debian 11 and everything is working fine. So there's definitely something wrong with the freebsd driver.

                                    The following is my setup and I've tried all the tricks mentioned in this thread:

                                    • i225-v b3 (which has supposedly fixed issues of early steppings) PCI-E adapter.
                                    • disabled onboard Broadcom BCM570x NIC at BIOS to avoid conflicts.
                                    • the NIC is connected to a TP-LINK TL-SH1008 switch at 2.5GB speed.
                                    • Truenas 12.0-U6.1 with the igc driver compiled from latest source from freebsd 12.0-stable dated Nov 13, 2021 (commit "igc: Use hardware routine for PHY reset").
                                    • disabled all hardware checksum and VLAN support as show below.
                                    • disabled all jails.
                                    root@freenas:~ # pciconf -lv | grep -A1 -B2 network
                                    igc0@pci0:2:0:0:        class=0x020000 card=0x00008086 chip=0x15f38086 rev=0x03 hdr=0x00
                                        vendor     = 'Intel Corporation'
                                        class      = network
                                        subclass   = ethernet
                                    
                                    root@freenas:~ # ifconfig
                                    igc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
                                            options=802020<JUMBO_MTU,WOL_MAGIC>
                                            ether 2c:53:4a:0a:f5:ec
                                            inet 10.1.1.12 netmask 0xffffff00 broadcast 10.1.1.255
                                            media: Ethernet autoselect (2500Base-T <full-duplex>)
                                            status: active
                                            nd6 options=9<PERFORMNUD,IFDISABLED>
                                    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 0x2
                                            inet 127.0.0.1 netmask 0xff000000
                                            groups: lo
                                            nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
                                    pflog0: flags=0<> metric 0 mtu 33160
                                            groups: pflog
                                    
                                    stephenw10S 2 Replies Last reply Reply Quote 0
                                    • stephenw10S
                                      stephenw10 Netgate Administrator @xiazuojie
                                      last edited by

                                      @xiazuojie said in Intel Ethernet Controller I225-LM Support?:

                                      Truenas 12.0-U6.1 with the igc driver compiled from latest source from freebsd 12.0-stable

                                      You see the same running pfSense?

                                      X 1 Reply Last reply Reply Quote 0
                                      • X
                                        xiazuojie @stephenw10
                                        last edited by xiazuojie

                                        Something I've noticed is that 6100 has i225-V B1 revision while both @setarcos and I have B3 revisions. I wonder if that makes any difference.

                                        @stephenw10 said in Intel Ethernet Controller I225-LM Support?:

                                        as far as I know though the only tested NIC is that in the 6100:
                                        igc0@pci0:4:0:0: class=0x020000 card=0x00008086 chip=0x15f38086 rev=0x01 hdr=0x00
                                        vendor = 'Intel Corporation'
                                        device = 'Ethernet Controller I225-V'
                                        class = network
                                        subclass = ethernet

                                        B3 revision supposedly fixes hardware issues of B1 revision.

                                        1 Reply Last reply Reply Quote 0
                                        • stephenw10S
                                          stephenw10 Netgate Administrator @xiazuojie
                                          last edited by

                                          @xiazuojie said in Intel Ethernet Controller I225-LM Support?:

                                          very poor inbound packages (drops to zero) while outbound packages are working perfect at full 2.5GB speed.

                                          Is it actually zero of just close to zero. @Setarcos was seeing nothing come in at all, not even ARP replies. Reading back now I see I didn't ask if they were running the current Coreboot version. Some early versions had a bug that presented like this.

                                          Steve

                                          SetarcosS X 2 Replies Last reply Reply Quote 0
                                          • SetarcosS
                                            Setarcos @stephenw10
                                            last edited by

                                            @stephenw10 I was (and still am) running ADI_PLCC-01.00.00.11 on my XG-7100

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.