offline-network-hardware-fault-diagnosis

Correlate iBMC events, kernel messages, and configuration data to localize network hardware faults.

3|2|Updated Apr 24, 2026
One-click install
npx skills add https://github.com/openeuler-mirror/witty-diagnosis-agent --skill offline-network-hardware-fault-diagnosis-openeuler-mirror
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: offline-network-hardware-fault-diagnosis
Source: https://github.com/openeuler-mirror/witty-diagnosis-agent/tree/main/skills/offline-network-hardware-fault-diagnosis
Command: npx skills add https://github.com/openeuler-mirror/witty-diagnosis-agent --skill offline-network-hardware-fault-diagnosis-openeuler-mirror

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve?

This Skill solves the complexity of diagnosing intermittent or critical network hardware failures in servers by correlating disparate logs from iBMC, OS messages, and system configuration tools.

Core Features & Use Cases

  • Multi-Source Correlation: Automatically aligns iBMC hardware events, kernel dmesg logs, and system configuration data to reconstruct the fault propagation chain.
  • Physical Root Cause Localization: Pinpoints failures to specific physical components like PCIe slots, SFP modules, or network interface controllers (NICs).
  • Use Case: When a server experiences frequent link flapping or PCIe bus errors, this Skill analyzes the provided log bundle to determine if the root cause is a faulty SFP module, a loose PCIe riser, or a driver-level firmware mismatch.

Quick Start

Use the offline-network-hardware-fault-diagnosis skill to analyze the server log directory located at /tmp/server_logs.

Frequently Asked Questions about offline-network-hardware-fault-diagnosis

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I diagnose intermittent network hardware failures using server logs?

To diagnose intermittent network hardware failures, this Skill correlates iBMC hardware events, kernel dmesg logs, and system configuration data from your log bundle to identify the root cause. It pinpoints faulty physical components like PCIe slots or SFP modules.

What is the best way to find the physical root cause of PCIe bus errors in Linux?

The best way to find the physical root cause of PCIe bus errors is to analyze server log bundles by correlating kernel messages with iBMC hardware events. This process localizes faults to specific PCIe BDF addresses and slot identifiers.

Can I use this to troubleshoot network link flapping on my server?

Yes, you can troubleshoot network link flapping by providing the server log directory. The Skill analyzes the logs to determine if the root cause is a faulty SFP module, a loose PCIe riser, or a driver-level firmware mismatch.

How does multi-source log correlation work for network hardware diagnosis?

Multi-source log correlation works by automatically aligning iBMC hardware events, kernel dmesg logs, and system configuration data. This reconstruction of the fault propagation chain enables precise physical localization of network hardware failures.

Do I need specific dependencies to run offline network hardware fault diagnosis?

No specific dependencies are required to run offline network hardware fault diagnosis. You only need to provide the server log directory, such as /tmp/server_logs, containing the necessary iBMC, kernel, and system configuration logs.

Why does my server experience frequent link flapping after a firmware update?

Frequent link flapping after a firmware update may stem from a driver-level firmware mismatch. By analyzing your server log bundle, the Skill correlates hardware events and system configuration to confirm this or identify physical faults like loose PCIe risers.