Browse Prior Art Database

Remote Diagnostic Data Capture

IP.com Disclosure Number: IPCOM000108877D
Original Publication Date: 2005-Mar-23
Included in the Prior Art Database: 2005-Mar-23
Document File: 2 page(s) / 28K

Publishing Venue

IBM

Abstract

The publication describes a design that provides the capability to remotely capture data, specifically system dumps, for x86 systems.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 55% of the total text.

Page 1 of 2

Remote Diagnostic Data Capture

A program is disclosed that provides the capability to capture information, specifically system dumps, during a system failure using a single operating system device driver that is independent of the system platform and service processor architecture.

Diagnostic Data Capture

All x86 Intel system's firmware create an extended BIOS data area (EBDA) in low system memory. In addition, all x86 Intel servers have a system management interrupt (SMI) that operates in its own memory address space outside the context of the operating system. This interrupt can be triggered from the operating system using a platform dependent implementation such as doing port IO to a specific port.

Operating system support to capture dump data in conjunction with the following design provides a mechanism that allows a platform independent device driver to transmit system dump data to a service processor. It provides a platform independent interface to the platform dependent code executing in the context of the system management interrupt. Architecturally, this provides a mechanism for transmitting a system dump to any device built upon any bus standard that the system management interrupt handler can communicate.

Diagnostic Data Capture BIOS Interface

The EBDA provides a mechanism for sharing data between components executing in the context of the operating system and the system's management interrupt. The Diagnostic Data Capture design uses the EBDA and system management interrupt to communicate with the service processor. The system firmware defines and initializes the following data structure in the EBDA when a supported service processor is present.

Value

Firmware_DDC_s struc

Signature byte 8 dup (?) _SMGR_,0,0

Version byte ? 1

OwnershipStatus byte ? 0 == unknown

1 == os 2 == bios

ActiveCmd byte ? 0 == no operation/command complete

1 == get ownership status 2 == start bios ownership 3 == send 4 == receive

CommandStatus byte ? 0 == success

2 == send failed 3 == receive failed 254 == invalid command 255 == device not present

CmdAddressType byte ? 1 == IO 2 == MMIO

CmdGranularity byte ? 8 == byte

16 == word 32 == dword

CmdOffset byte ? Platform dependent

Reserve1 byte ? 0 == reserved for alignment

CmdAddress dword ? Platform dependent

CmdPortValue dword ? Platform dependent

1

Page 2 of 2

SendBufferPtr dword ? Physical address below the 4GB boundary

SendBufferLen dword ? Length of data contained in the SendBufferPtr

ReceiveBufferPtr dword ? Physical address below the 4GB boundary

ReceiveBufferLen dword ? Length of data to receive

Firmware_DDC_s ends

The data structure contains the following information:

1) A Signature that allows the OS device driver to locate the firmware support structure in the Extended BIOS Data Area (EBDA). This notifies the DDC OS device driver that the firmware supports DDC and that a supported service processor is prese...