International Business Machines Corporation

Lenovo (singapore) Pte. Ltd.

Stephen A Knight

David R Engebretsen

Jaimeson Saley

Bruce Wile

Adam Charles Lange-Pearson

David Lee Hermsmeier

Benjamin R Garbers

Harvey Gene Kiel

Thomas R Forrer, Jr

Pamela A Wright

Robert Russell Nelson

Mark Arnold Boegel

Timothy O'Callaghan

Wayne D Walters

Douglas O Bolstad

Todd Andrew Gilbertsen

A distributed network switch includes multiple switch modules connected by one or more physical cables. One switch module may determine which connector port of a remote switch module is connected by physical cable based on information received from the remote switch module, including link identifiers, and further based on a physical topology predetermined about the type of remote switch module.

Constructing and verifying switch fabric cabling schemes

When testing or validating a hardware system, a script file representing a portion of the firmware may be used to test the system instead of using the firmware code itself. For example, the script file may be plurality of register commands that perform the same initialization sequence as the firmware. Before connecting the hardware system to firmware drivers, the script file may be used to debug the initialization sequence. Instead of generating this script file manually, a firmware testing tool may be used. While executing the firmware, the tool may record the different register access commands performed during the initialization process. The script file is then generated programmatically using these recorded commands without requiring input from the system designer. The generated script file may then be tested on the hardware system to determine whether the command sequence in the script file forces the hardware system into the desired state.

Firmware generated register file for use in hardware validation

A distributed switch may include a plurality of special-purpose processors that control the different functions of the switch. To enable some special services, however, the distributed switch may need one of these processors to perform the role of a master. When a processor is powered on, the processor may publish a corresponding unique ID. Before electing the master, the special-purpose processors may use a discovery process to identify the network topology of the switch and evaluate the published IDs to determine which processor should be the master. If all the processors nominate the same master processor, then that processor is elected as the master and may finish configuring the distributed switch to enable the special services.

Selecting a master processor from an ambiguous peer group

Techniques are disclosed to reduce crossover between traffic from switch elements of different switch domains in a distributed switch. Addition of a first switch element to the distributed switch is detected. The distributed switch includes multiple switch elements at least subsequent to the addition, and each switch element has a switch element identifier and a fabric identifier. The respective fabric identifiers of the first switch element and of a second switch element are retrieved. The second switch element is communicably connected to the first switch element via a link, and the link is configured to allow only command traffic to be transmitted via the link. Upon a determination that the fabric identifier of the first switch element does not match the fabric identifier of the second switch element, then no command is issued specifying to reconfigure the link to allow at least one additional traffic type, different from command traffic.

Fencing off switch domains

An embodiment of this invention provides a system and method for a diagnostic computer application executing on a host computer to extract vendor unique diagnostic information from an attached peripheral device. The peripheral device is pre-configured to respond with device unique information in response to certain standard interface protocol inquiries. Standard interface inquiry commands are used to extract detailed instructions from the device. These instructions may contain device unique small computer system interface (SCSI) command sequences, for example. The command sequences allow a user of the host computer to extract detailed data from the peripheral device about the peripheral device's operational, performance and health statistics.

System and method to provide device unique diagnostic support with a single generic command

A tracing technique is disclosed for an application program that is only permitted to access virtual storage, not physical storage, via a Protect Mode Addressing scheme. The application program contains an initialization statement that initializes a trace address T1 to be equal to a virtual address V1 contained in a data area under the control of the application program. A statement in the application program then requests a pinned virtual address V2 that maps to a predetermined physical address P from a device driver. If the device driver exists, the trace address T1=virtual address V2. A memory mapper maps address V2 to physical address P and writes the information to physical address P. A conventional logic analyzer monitors the bus for any writes to physical address P and captures the contents of the bus upon the detection of this condition.

Tracing technique for application programs using protect mode addressing

A computer system comprises a CPU, a main memory, and plurality of I/O Processors (IOPs), coupled to each other by a system I/O bus. The IOPs perform slave processing functions relating to I/O devices. A simulation protocol is defined for the IOPs, whereby the host CPU can command an IOP to execute a simulation script. The simulation script defines one or more I/O devices to be simulated, and specifies a simulated workload associated with the devices. The IOP executes the simulation script by sending simulated input streams to the host and receiving output destined for the simulated I/O devices from the host on the system I/O bus. An IOP may simulate multiple I/O devices, and may simulate I/O devices concurrently with servicing real I/O devices. In typical use, one or more applications programs will execute on the CPU concurrently with the execution of one or more simulation scripts in the IOPs attacked to the system I/O bus. The behavior of the system under such conditions can be used for capacity planning forecasts, for developing and debugging the application software, for reproducing and diagnosing intermittent error conditions, or for performing other tasks in which it is necessary to determine the characteristics of the system under hypothetical conditions.

Growing community of inventors

Rochester, MN, United States of America

Stephen A Knight