https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296201
--- Comment #1 from Giovanni Manzoni <[email protected]> --- Here's the update to add to the bug, in English. It's written to be honest and incontestable: it removes the unproven ACI claim, foregrounds the Linux-works evidence, and clearly labels the backport experiment as non-conclusive. Update / correction to this report I need to correct and substantially update my original description. Important correction: My earlier statement that the driver "hangs in attach_pre during ACI init" is not confirmed and should be disregarded. That observation came from an out-of-tree experiment (see below) that was not KBI-compatible with the running kernel, so it does not reliably indicate where the official driver fails. I have not been able to observe the official in-tree driver's behavior on a KBI-matched kernel, so I cannot currently pinpoint the failure location. Confirmed, hardware-independent fact (the key new evidence): The exact same E610-XT2 card, in the same slot of the same machine, works perfectly under Linux. Booting an Ubuntu 25.x live USB, the in-kernel ixgbe driver attaches both ports and links at 10G with no issues. This confirms the hardware, the card NVM/firmware, and the platform (IOMMU/AMD-Vi, ASPM, Above-4G decoding, PCIe) are all good. The problem is specific to the FreeBSD ix(4)/E610 driver path. What I actually observed on FreeBSD (and its limitation) The shipped driver does not bind the E610 (the released kernel I tested predates the E610 device IDs, so the device shows as none@). When I attempted to provide an E610-capable ix module, the device never attached. However, my test kernel and module were not a clean KBI match (details below), so I cannot attribute the failure to the driver logic itself — it may be entirely a build/KBI artifact on my side. I am reporting this primarily on the strength of the "Linux works, FreeBSD does not yet" evidence above, and to ask whether E610-XT2 (8086:57b0, subdevice 0x0002, rev 0x00) is known to attach on any FreeBSD build. Out-of-tree experiment — NOT conclusive, for context only To get an E610-capable driver onto an older kernel I (a) backported the E610 commit dea5f973 onto an older source base, and (b) built the Intel out-of-tree ix-3.4.38 against that same base. In both cases loading the module caused a page fault in kobj_class_compile1() during device_probe/device_set_driver, i.e. before the driver's own attach code ran. This is consistent with a KBI mismatch between my module and the running kernel (my source base did not exactly match the running kernel's __FreeBSD_version/patches), so it is almost certainly a build artifact and not a FreeBSD driver bug. I mention it only to explain that my earlier "ACI hang" observation was unreliable and to avoid sending anyone down that path. Request Can the maintainers confirm whether the E610-XT2 (device 0x57b0, subdevice 0x8086:0x0002, rev 0x00) is expected to attach with the current in-tree ix(4) E610 support (D50067 / commit dea5f973)? If a clean reproduction on a stock FreeBSD-RELEASE would help, I can install FreeBSD 15.x RELEASE on this machine and post a full verbose dmesg from the in-tree driver — please let me know if that is useful and I'll provide it. -- You are receiving this mail because: You are the assignee for the bug.
