Project

General

Profile

Actions

Bug #14142

open

kernel SMB stops NMI from inducing panic, printfs as hard and fast as it can instead

Added by Alex Wilson 2 months ago. Updated 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

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.

Actions #1

Updated by Alex Wilson 2 months ago

  • Description updated (diff)
Actions #2

Updated by Alex Wilson 2 months ago

  • Description updated (diff)
Actions #3

Updated by Gordon Ross 2 months ago

This is a cmn_err(CE_WARN, ...) call here:
http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/smbsrv/smb_server.c?r=4e065a9f#2494

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.

Actions

Also available in: Atom PDF