Browse Prior Art Database

The method and apparatus for saving the common volatile data in multiple subsystems across reset reloads.

IP.com Disclosure Number: IPCOM000243747D
Publication Date: 2015-Oct-16
Document File: 3 page(s) / 42K

Publishing Venue

The IP.com Prior Art Database

Abstract

Method for saving volatile data in a service processor based server system across reset reloads. The data mentioned here is common between the service processor subsystem and the host boot subsystem. The host boot subsystem is present and running only during the initialization of the server but the some of this volatile data needs to survive across multiple boot sequences. To facilitate this, a method making use of an in memory database running in the service processor subsystem is proposed.

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

Page 01 of 3

The method and apparatus for saving the common volatile data in multiple subsystems across reset reloads.

Disclosed is a method for saving common volatile data in multiple subsystems across reset reloads in a server.

Server hardware components like processor, memory, service processor, memory buffer are represented as targets and are created during build time from a set of XML files. These XML files describe the hardware topology and connections in detail between the various hardware components in a server. Each target created during build time is associated with a set of attributes each one of them representing a unique characteristic of the target. This target attribute model which mirrors the server hardware topology, is compiled into a binary image and loaded into the service processor memory during the boot process. The target attribute model abstracts the hardware and ensures that all hardware access from other entities and handled in a structured way.

With this model, the disadvantages are:


Some of the attributes are volatile attributes and those needs to be persisted across resets of the service processor.

And these attributes are accessed multiple times during the initial boot process and hence cannot be moved to non-volatile because of flash wear out. Synching the non-volatile attribute data during a firmware code update is not possible if there are any changes in the attribute set due to addition or deletion of attributes or change in the type or size of an existing attribute. This is since, the target attribute model is memory mapped and any change in the structure between two firmware versions would result in alignment mismatch and data corruption.

In a multi node server with redundant service processors where one service processor is acting as the master controller, a switch over to the redundant slave service processor is done when there are error conditions. This ensures availability of the server during error scenarios. In such fail-over situations, we need to ensure the target attribute data from the existing master service

processor is synched over correctly to the new master service processor. With the existing target attribute model, in case of errors there is a high chance of memory mapped data being inaccessible. This will prevent us from synching the latest correct data to the new master service

processor.

The problem solved with this solution is to ensure data persistency across resets of service

processor in a server and also across firmware code updates.

To overcome the above problem mentioned, the solution proposed is to make use of an in memory database running on the service processor which will have the latest updated data of all targets at any point of time.

Tables and relations between them are defined and created during the build time which will hold the data for all the necessary hardware components in a server. Default data from the XML files which describes the hardware topology is read and fi...