Bug #16101
closed
Kernel Panic in ``if_qlnxe`` kernel module when loaded via ``kldload``
100%
Description
Customer reported that when loading the kernel driver for if_qlnxe on a QLogic 2x25GE QL41232HQCU, it causes a kernel panic.
This was reported by another customer in 2.7.2 and it was believed to be fixed in Plus on the newer FreeBSD, but it does not appear to be.
Attached are the kernel dumps.
Files
Updated by
Updated by Kristof Provost 6 months ago
I'm rather confused by this panic.
`fault virtual address = 0x0` and `instruction pointer = 0x20:0x0` pretty much mean we're following a NULL function pointer.
The backtrace also points to get_operstate_ether(), where we call if_ioctl(ifp, ...). That used to not check if the if_ioctl function pointer was NULL, so we've seen panics like this before (though with other nic drivers, where that could happen).
The fix for that is in 24.11. In fact, both dump_iface (actually, get_operstate_ether(), but that's inlined by the compiler) and if_ioctl() now check the if_ioctl function pointer for NULL. Despite that this still looks like we've followed a NULL ifp->if_ioctl pointer.
qlnx_init_ifnet() also sets the ioctl pointer before calling ether_ifattach(), so even without those checks we shouldn't see this panic.
It's very confusing. Given that we should indeed confirm with the user if this panic is reliably reproducible, and if it is it may be worth trying to get a core dump to see if we can get further hints out of that.
Updated by Kris Phillips 6 months ago
Kristof Provost wrote in #note-2:
I'm rather confused by this panic.
`fault virtual address = 0x0` and `instruction pointer = 0x20:0x0` pretty much mean we're following a NULL function pointer.
The backtrace also points to get_operstate_ether(), where we call if_ioctl(ifp, ...). That used to not check if the if_ioctl function pointer was NULL, so we've seen panics like this before (though with other nic drivers, where that could happen).
The fix for that is in 24.11. In fact, both dump_iface (actually, get_operstate_ether(), but that's inlined by the compiler) and if_ioctl() now check the if_ioctl function pointer for NULL. Despite that this still looks like we've followed a NULL ifp->if_ioctl pointer.qlnx_init_ifnet() also sets the ioctl pointer before calling ether_ifattach(), so even without those checks we shouldn't see this panic.
It's very confusing. Given that we should indeed confirm with the user if this panic is reliably reproducible, and if it is it may be worth trying to get a core dump to see if we can get further hints out of that.
According to the customer, this issue presents itself reliably as soon as they do a kldload to load the driver in. They can reliably produce this issue.
What commands/flags need to be set to get the information we need out of a coredump? I'll ask the customer to provide it.
Updated by Steve Wheeler 3 months ago
- Status changed from New to Waiting on Merge
Updated by Jim Pingle about 2 months ago
- Project changed from pfSense Plus to pfSense
- Subject changed from Kernel Panic with if_qlnxe driver loaded via kldload to Kernel Panic in ``if_qlnxe`` kernel module when loaded via ``kldload``
- Category changed from Operating System to Operating System
- Status changed from Waiting on Merge to Resolved
- Assignee set to Kristof Provost
- Target version set to 2.8.1
- % Done changed from 0 to 100
- Plus Target Version set to 25.07
The commit for this was merged into Plus 25.07 (a61e724cd35ec027584e7a03fdc36edb740b7415) and CE 2.8.1 (780a99fddd147ccf02509ce49d5f69956dd62270) branches