Date: Sat, 22 Nov 2025 11:45:11 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 290793] iovctl on mlx5en won't work Message-ID: <bug-290793-7501-eZeqN32H44@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-290793-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-290793-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290793 --- Comment #7 from David BOYER <jcduss13@gmail.com> --- (In reply to David BOYER from comment #3) What's the call graph into this? I had answered yesterday but just gor a message reading that a collision occured. I can only find mlx5_core/mlx5_main.c::request_bar -> pci_request_regions() which ends up at the end of a loop in lkpi_pci_request_region(). ==> The same for me You made me actually look at Linux code and there you end up in __pci_request_region() which has the same checks at the beginning it seems: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/pci.c#n3935 So the problem is likely elsewhere in the LinuxKPI emulation or in mlx5. My understanding is that pci_resource_len may return 0 on FreeBSD while linux reports the right size. Then, on FreeBSD, pci_request_region exits because pci_resource_len == 0, bus_alloc_resource_any is not called and the memory is not allocated. Why linux reports the right size ? https://wiki.osdev.org/PCI reads "To determine the amount of address space needed by a PCI device, you must save the original value of the BAR, write a value of all 1's to the register, then read it back. The amount of memory can then be determined by masking the information bits, performing a bitwise NOT ('~' in C), and incrementing the value by 1. The original value of the BAR should then be restored". If I read correctly, this is done by pci_read_bases, found in "drivers/pci/probe.c". It purpose is to find the BAR memory size. Also the error logged: mlx5_core2: lkpi_pci_request_region: failed to alloc bar 0 type 3 rid 16 comes from after that check? So if it would fail and return we would not see this? Is that a secondary problem? Yes, it comes after. Because the memory allocation step did not run (pci_resource_len == 0). If you say "On FreeBSD, the BAR size of VFs can temporarily be 0 and." Would we assume mlx5core to only call pci_request_regions() once they are properly initialized? I guess we can say they are not properly initialized because it is done by the kernel (on linux) not by the driver itself. Please note that I am not an expert at all and had not read sourcecode of linux and FreeBSD before, so I may be wrong somewhere, especially in my wording. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-290793-7501-eZeqN32H44>