From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0E8C63B27CC for ; Tue, 7 Apr 2026 17:51:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775584304; cv=none; b=IW1kVbz2qGPKiw4j2U944unqRBlsvjq51Zqnvc2g4VoxSY/nCKYnMZopkDpHyc+nfe0Am3QQvKvDnFr23CnlVRlo1s1otRSJzi+vN/QfWPKqyzRVTtofEnFpUyq1e/qxwWXl0K9OfYnsrouqNNCpC5Y1dqfmiPqSVYl7zG37F+U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775584304; c=relaxed/simple; bh=rCRd9xh2E6AYMTXvbWlnPHIZt8POyzE6O3D3gY1rbFs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LgLcs1DeyRVcdUTrLHhGv9i7+hX4rbAhQ0jdTDoKStKVfeI03IIBHDvmoKXKTRSLMZnjD9b9f3TXz5mU5Cp294MQKGhnXrMEJKZLAlT8jDFaSvMIdLYBn8b7VUv3UiTCeUG8uW+3QroJzGKrSXbOXuDSUWMe3XLTM8cbE2UK204= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=gmByzjuD; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="gmByzjuD" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775584299; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5ASjBu3QvMlzkMJwSBe8z5P/+CHNBllSdP3WKPgRQhY=; b=gmByzjuDEmOhqdbvcNvfBTSiiq7u9185x+EFlE+eQUuo2Y5+rK4tEumLpZDD5UgQ06BKep fAzHJg0C3nRo8CnzaGx7AZMB6cKqTRVBn6pYv7aIGQeAICAQJc6nUmZBxgSIyZiwnhR06h knoMsp00w3dQq1W9o2R1EFQl0Ax9HBY= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-582-KSZ3tVLoOqaMA4JWU3LfDA-1; Tue, 07 Apr 2026 13:51:38 -0400 X-MC-Unique: KSZ3tVLoOqaMA4JWU3LfDA-1 X-Mimecast-MFC-AGG-ID: KSZ3tVLoOqaMA4JWU3LfDA_1775584297 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9E0021956058; Tue, 7 Apr 2026 17:51:37 +0000 (UTC) Received: from hp-dl380pgen9-07.khw.eng.rdu2.dc.redhat.com (hp-dl380pgen9-07.khw.eng.rdu2.dc.redhat.com [10.6.10.143]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 14661300019F; Tue, 7 Apr 2026 17:51:36 +0000 (UTC) From: Tony Camuso To: openipmi-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org Cc: minyard@acm.org, tcamuso@redhat.com Subject: [PATCH 2/2] Documentation: ipmi: Update BMC reset behavior for watchdog Date: Tue, 7 Apr 2026 13:51:34 -0400 Message-ID: <20260407175134.3367345-3-tcamuso@redhat.com> In-Reply-To: <20260407175134.3367345-1-tcamuso@redhat.com> References: <20260407175134.3367345-1-tcamuso@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 Update the IPMI watchdog BMC reset documentation to describe the current behavior: when the BMC resets while the watchdog is active, the driver detects the communication failure and initiates an orderly system reboot rather than attempting to retry and recover. Document the panic and hang prevention mechanisms, BMC failure detection via completion code classification in the message handler, the bmc_reset_shutdown guard that prevents further IPMI operations during shutdown, and the late response handling for the msg_in_flight flag. Signed-off-by: Tony Camuso --- Documentation/driver-api/ipmi.rst | 61 +++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) diff --git a/Documentation/driver-api/ipmi.rst b/Documentation/driver-api/ipmi.rst index f52ab2df2569..dbdc1440d16e 100644 --- a/Documentation/driver-api/ipmi.rst +++ b/Documentation/driver-api/ipmi.rst @@ -734,6 +734,67 @@ device to close it, or the timer will not stop. This is a new semantic for the driver, but makes it consistent with the rest of the watchdog drivers in Linux. +BMC Reset Behavior +------------------ + +When the BMC (Baseboard Management Controller) resets while the IPMI +watchdog is active, the hardware watchdog timer state on the BMC is +lost. The driver detects this condition and initiates a clean system +reboot rather than leaving the system running without watchdog +protection. + +The driver handles BMC resets as follows: + +1. **Panic prevention:** The static message structures (``smi_msg`` and + ``recv_msg``) are guarded by an ``msg_in_flight`` atomic flag. If a + previous message is still queued in the IPMI layer, new operations + return ``-EBUSY`` instead of reusing the structures (which would cause + a ``list_add`` corruption BUG). + +2. **Hang prevention:** ``wait_for_completion_timeout()`` with a 5-second + timeout replaces the indefinite ``wait_for_completion()`` in both + ``__ipmi_heartbeat()`` and ``_ipmi_set_timeout()``. This prevents + tasks from blocking in D state when the BMC is unresponsive. + +3. **BMC failure detection:** When ``ipmi_wdog_msg_handler()`` receives + a non-zero completion code while the watchdog is active, it sets the + ``bmc_reset_shutdown`` flag and calls ``orderly_reboot()``. Error + classification distinguishes three categories: + + - ``TIMER_NOT_INIT`` (0x80): the BMC lost the watchdog timer state. + - Vendor-specific codes (0x81-0xBE): BMC-specific error responses. + - Standard IPMI completion codes (0xC0+): general BMC errors. + + All produce a critical-level log message:: + + IPMI Watchdog: BMC error: watchdog timer not initialized (0x80 on cmd 0x22) + IPMI Watchdog: BMC communication lost with watchdog active, initiating system reboot + +4. **Clean shutdown:** Once ``bmc_reset_shutdown`` is set, all BMC + communication paths (``_ipmi_set_timeout()``, ``__ipmi_heartbeat()``, + ``wdog_reboot_handler()``) return immediately without attempting + further IPMI operations. This prevents panics, stack traces, and + hangs during the reboot sequence. + +5. **Late response handling:** The ``msg_in_flight`` flag is cleared in + ``ipmi_wdog_msg_handler()`` after the message is freed. This handles + late responses arriving after a completion timeout, ensuring the flag + does not remain set permanently. + +The system reboot after a BMC reset is the expected and correct +behavior. The hardware watchdog timer lives on the BMC, and when +that timer state is lost, the system must be restarted to restore +watchdog protection. + +Administrators performing supervised BMC maintenance (firmware updates, +manual resets) should disarm the watchdog before the operation:: + + systemctl stop watchdog + +And restart it after the BMC has fully recovered:: + + systemctl start watchdog + Panic Timeouts -------------- -- 2.53.0