Bug #16101
open
Kernel Panic with if_qlnxe driver loaded via kldload
Added by Kris Phillips 27 days ago.
Updated 17 days ago.
Category:
Operating System
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
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.
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.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by