kernel SMB stops NMI from inducing panic, printfs as hard and fast as it can instead
We've got a box which is using kernel SMB which seems to hang occasionally. When it hangs, the kernel is still responding to ping, typed characters on serial console do echo, but userland is unresponsive, both on serial console (login prompts don't work at all) and over the network (TCP connection attempts just hang and time out).
NMI on this machine works fine normally to trigger a dump or enter kmdb -- the tweakables to panic on NMI are set in
/etc/system. However, in this hang situation when we issue an NMI this happens:
WARNING: SMB Session: taskq_dispatch failed WARNING: SMB Session: taskq_dispatch failed WARNING: SMB Session: taskq_dispatch failed WARNING: SMB Session: taskq_dispatch failed WARNING: SMB Session: taskq_dispatch fail...
The system prints this to the serial console at maximum baud rate, apparently forever. A second NMI never seems to do anything to it, either, and we resort to a hard reset.
Updated by Gordon Ross 4 months ago
This is a cmn_err(CE_WARN, ...) call here:
The system must be receiving a flood of connections. (Under attack?)
Why would all of these be going to the console? I don't think that's normal.