pfSense

How repeatable is this?

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.