Date: Mon, 24 Nov 2025 03:17:22 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 290793] iovctl on mlx5en won't work Message-ID: <bug-290793-7501-DILpvKjYqM@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 #20 from Bjoern A. Zeeb <bz@FreeBSD.org> --- With new firmware the LinuxKPI error shows up as well (in addition to my instrumentation). Also the "undo" from mlx5_core in LinuxKPI pci_release_resource() results in a panic (assertion) inside pci(4). I do understand the problem and the workaround from the patch seems fine for now. It is the cause but the reasoning is wrong. pci_resource_len() calls lkpi_pci_get_bar() with true, which will create the resource and then in the follow-up bus_alloc_resource_any() fails (hence printing the error). If we make pci_resource_len() call lkpi_pci_get_bar() with false the bar won't be there and the == 0 check will fail. So in the end the check becomes pointless in this order. However I need to fix the callers to deal with the problem and see how to do error handling there. I'll likely not have time before mid-week to look again but I have to stop now. It's Mon 4:15AM. Thanks for all the help for getting me setup for this so I could debug it!!! Just so I do not lose it -- the panic. That's likely for someone else to look. mlx5_core2: WARN: wait_fw_init:779:(pid 5986): Waiting for FW initialization, timeout abort in 3 s mlx5_core2: WARN: wait_fw_init:779:(pid 5986): Waiting for FW initialization, timeout abort in 0 s mlx5_core2: Firmware over 5000 MS in pre-initializing state, aborting mlx5_core2: ERR: init_one:1710:(pid 5986): mlx5_load_one failed -16 panic: pci_vf_release_mem_resource: rman 0xfffff80049fb9e30 doesn't match for resource 0xfffff80001a71d80 cpuid = 7 time = 1763946040 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00ff27f760 vpanic() at vpanic+0x136/frame 0xfffffe00ff27f890 panic() at panic+0x43/frame 0xfffffe00ff27f8f0 pci_vf_release_mem_resource() at pci_vf_release_mem_resource+0xf6/frame 0xfffffe00ff27f920 linuxkpi_pci_release_regions() at linuxkpi_pci_release_regions+0x10/frame 0xfffffe00ff27f940 mlx5_pci_close() at mlx5_pci_close+0x73/frame 0xfffffe00ff27f970 init_one() at init_one+0x138f/frame 0xfffffe00ff27f9e0 linux_pci_attach_device() at linux_pci_attach_device+0x56b/frame 0xfffffe00ff27fa40 device_attach() at device_attach+0x45b/frame 0xfffffe00ff27fa90 bus_attach_children() at bus_attach_children+0x4a/frame 0xfffffe00ff27fab0 pci_iov_enumerate_vfs() at pci_iov_enumerate_vfs+0x3b6/frame 0xfffffe00ff27fb30 pci_iov_ioctl() at pci_iov_ioctl+0x844/frame 0xfffffe00ff27fbc0 devfs_ioctl() at devfs_ioctl+0xd1/frame 0xfffffe00ff27fc10 VOP_IOCTL_APV() at VOP_IOCTL_APV+0x51/frame 0xfffffe00ff27fc40 vn_ioctl() at vn_ioctl+0x160/frame 0xfffffe00ff27fcb0 devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfffffe00ff27fcd0 kern_ioctl() at kern_ioctl+0x2a1/frame 0xfffffe00ff27fd40 sys_ioctl() at sys_ioctl+0x12f/frame 0xfffffe00ff27fe00 amd64_syscall() at amd64_syscall+0x169/frame 0xfffffe00ff27ff30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00ff27ff30 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x378cf1afa03a, rsp = 0x378ced110678, rbp = 0x378ced1106d0 --- KDB: enter: panic [ thread pid 5986 tid 100225 ] Stopped at kdb_enter+0x33: movq $0,0x1217452(%rip) -- 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-DILpvKjYqM>