|Publication number||US6910142 B2|
|Application number||US 09/917,413|
|Publication date||Jun 21, 2005|
|Filing date||Jul 28, 2001|
|Priority date||Jul 28, 2001|
|Also published as||DE10231993A1, US20030070066|
|Publication number||09917413, 917413, US 6910142 B2, US 6910142B2, US-B2-6910142, US6910142 B2, US6910142B2|
|Inventors||Edward A Cross, Michael S Allison, Christopher S Kroeger|
|Original Assignee||Hewlett-Packard Development Company, L.P.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (6), Referenced by (11), Classifications (12), Legal Events (5)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present invention relates generally to computer systems, and more particularly, to a system that provides notification, to the associated operating system, of removal and replacement of I/O devices during operation of a multiple cell, multiprocessor computer system running multiple operating systems.
In a computer system comprising multiple processors and operating systems, there are a number of problems associated with removing and inserting (swapping) cards containing I/O (or other) devices while the system is operating. These problems include detection of card removal and insertion, and providing notification thereof to the operating systems associated with the card slots containing the particular cards being swapped.
In addition, when access to these I/O cards is gained via intrusion into a cabinet containing the cards, most previously known computer systems typically ignore the intrusion and risk computer system failure if a card is removed while the system is running.
Furthermore, these prior systems also typically perform I/O device discovery every time the systems are re-booted, since they are unable to determine whether I/O devices were added or removed prior to a particular boot operation, and are thus unable to determine the I/O device configuration at boot time without re-scanning for I/O devices.
Previous computer systems having multiple processors and operating systems have also not effectively dealt with other problems presented by detection and routing of platform events associated with the insertion and removal of I/O cards while the system is operating.
An additional problem is encountered in prior systems having latches that indicate when an I/O card has been removed from its slot. When an I/O card is removed from a slot, the slot associated with the latch causes the power to the slot to be turned off. Once the slot is detected by the system as being powered down, it is marked as deconfigured. Therefore, after a card is re-inserted in the slot, the slot (i.e., the card) is not available for use until after a re-boot operation on the partition is performed, and the slot is reset.
The present system solves the above problems and achieves an advance in the field by providing a mechanism for removing and installing I/O hardware while a computer system is operating. The system includes a novel method for detecting and routing information concerning the occurrence of events associated with the removal and replacement of system I/O cards from their respective slots.
The architecture of the present system includes one or more partitions, each including a plurality of cells, each containing multiple RISC processors, low-level I/O firmware, a local service processor, scratch RAM, external registers, a memory and I/O manager, and interfacing hardware. Each partition runs its own operating system (OS).
Each cell is connected to a peripheral backplane containing a plurality of peripheral I/O card slots via a switch on the system backplane, which also connects the cell to a supervisory processor, which sends card slot status information to the appropriate cell.
Each I/O (typically PCI) card slot has an associated latch which provides an indication, to the supervisory processor, that a platform event has occurred. Platform events include inserting or removing an I/O (peripheral device interface) card to/from a card slot, and opening an access panel that provides access to the I/O cards. The access panel has an intrusion door with a latch connected to a switch for indicating the open or closed state of the intrusion door. A ‘doorbell’ button is located adjacent to each card slot for indicating that a user is ready to remove an I/O card from the slot.
When a platform event occurs, the supervisory processor notifies the local service processor in the cell containing the firmware and OS responsible for controlling the card associated with the particular event. The local service processor then notifies the firmware and OS responsible for the relevant slot. The supervisory processor has knowledge of which partition should be notified of particular events, so it notifies only the service processors in the relevant partition. Communication between the supervisory processor, local service processor, and firmware is accomplished via scratch RAM, which is cheaper than general purpose hardware registers.
More specifically, when a doorbell button is pressed, the following sequence takes place:
The board may then be removed from the slot for replacement. When a board is re-inserted into the slot, a latch interrupt is generated, and the following steps are performed:
Therefore, after a card is re-inserted in the slot, the card is available for use, without waiting for a re-boot operation on the partition.
A further aspect of the present system is the inclusion of an intrusion latch on the access panel to the cabinet containing the I/O cards. When the access panel is opened, the supervisory processor is notified of the event. Intrusion events are reported to the appropriate OS in a manner similar to the doorbell and latch events described above. If no intrusion is detected between successive boot operations, boot time is significantly reduced by avoiding initial scanning for non-existent devices. The present method handles intrusion events by reporting an event only once to the appropriate entities.
System 100 also includes a supervisory processor 130, core I/O devices 140, and mass storage 114 interconnected, via system backplane 110 and switch 112, with cells 101 and PCI backplane 120. Each cell 101* includes a one or more main processors 106 (typically 4), a local service processor 105, external hardware registers 107, memory & I/O manager 109, scratch RAM 104, and interfacing hardware 108. Each main processor 106* in a given partition is associated with one instance of the OS (operating system) 103. Each processor 106 has associated firmware, hereinafter referred to as platform dependent code (PDC) 102, for managing low-level I/O functions including booting the OS 103 across one or more cells 101. There is one PDC image per cell, therefore all processors 106 in a given cell 101* share the same PDC 102.
The supervisory processor, herein after referred to as the main service processor (MSP)130, performs functions including receiving notification of events and sending event information to each cell 101*. Local service processor (LSP) 105 coordinates event handling between main service processor 130 and main processors 106. In an exemplary embodiment, processors 106* are RISC processors, which perform the major computing functions in system 100.
Each card slot 150* in PCI backplane 120 has a card insertion latch 165* and a manually activated switch (e.g., a pushbutton switch) 155* associated therewith. Switch 155* functions as a ‘doorbell’ to provide notification to that a user is ready to replace an I/O card in one of the slots 150*. Each group of card slots 150 is accessed through an access panel 170, the open or closed condition of which is detectable via a switch 175.
At step 220, local service processor 105 sets the event-corresponding bit in the interrupt pending register. At step 225, LSP notifies OS 103 of the intrusion event, and OS 103 then notifies PDC 102. At step 230, the intrusion event is cleared by PDC 102, since all concerned entities have now been informed of the intrusion. At step 235, main service processor 130 resets the intrusion state, for each affected card slot, in the intrusion status register.
After the next time the system is booted, at step 237, a check is made of previously saved uncleared intrusion events or any new intrusion events by main service processor 130, at step 240, to determine whether an intrusion occurred since the last boot. If access panel 170 has not been opened since the previous boot, then, at step 245, PDC 102 does not have to scan for new devices, since the device configuration is known to be unchanged. Therefore, by avoiding scanning for non-existent devices, the present system allows the boot process to occur more quickly when no intrusion has occurred between boot operations. If, however, it is determined that an intrusion occurred since the last boot, then at step 250 the previously pending interrupt is generated for the intrusion event, and PDC 102 scans for new devices, at step 255.
At step 218, PDC 102 moves the intrusion event data in external register 107 to inter-communication memory (ICM) 104 of FIG. 1. Intrusion event processing then continues at step 225, described below.
If, at step 216, it was determined that the shared memory has been initialized, then, at step 219, local service processor 105 writes intrusion event data to ICM in block 104. At step 220, local service processor 105 sets the event-corresponding bit in the interrupt pending register, and at step 225, OS 103 sends a message to PDC 102 (via an event handler) to clear the event from the event register. At step 230, the intrusion event is cleared by PDC 102 at the request of the OS 103. At step 235, main service processor 130 resets the intrusion state, for each affected card slot, in the intrusion status register, and intrusion event processing continues at step 237 in
At step 320, local service processor 105 writes the card slot identifying information (e.g., slot N) to an area in scratch RAM (ICM) 104 reserved for doorbell data. At step 325, LSP 105 causes an interrupt for slot N to be sent to its associated OS 103. When the interrupt is serviced, at step 330, the OS issues a call to a PDC function to get the doorbell event from ICM 104. The PDC function sends the doorbell event and physical location to the OS 103, at step 335.
At step 340, the I/O driver(s) (located on core I/O card 140) for the slot 150 associated with the doorbell 155 is (are) quiesced. OS 103 then turns off power to card slot N, at step 345, by notifying the appropriate controller (not shown) to power down the slot. At step 346, an attention light 156 is optionally illuminated to notify the user that it is OK to remove the I/O board (in slot N) associated with the doorbell that was pressed. At step 350, the board is removed from slot N, and at step 355, a board is (re)inserted into the slot. Insertion of a board into the slot causes closure of a latch (switch) 165 associated with the slot, which in turn triggers a latch interrupt. This latch interrupt is sent to main service processor 130 at step 360, and doorbell/latch processing continues at step 505 in
At step 425, I/O discovery takes place. I/O discovery is part of the PDC boot process. During boot, PDC 102 initializes processors 106, ICM 104, and I/O devices. When the PDC finds and initializes I/O, the I/O discovery phase occurs. During this step, PDC 102 reads the latch status from ICM 104. Next, at step 430, PDC 102 checks the latch status for each card slot 150. If a given latch 165 is closed, the PDC powers up the associated slot (step 440); if a given latch is open, the PDC does not power up the slot (step 435).
At step 525, OS 103 receives the interrupt and requests the latch status from PDC 102. At step 530, PDC 102 reads the latch status from ICM 104. At step 531, PDC 102 checks the latch status for each card slot 150. If a given latch is open, the PDC does not power up the slot (step 532), if a given latch 165 is closed, then at step 533, PDC 102 sends a slot “power down” message to OS 103. At step 535, OS 103 shuts down the I/O driver for the relevant slot 150, and at step 540, PDC 103 powers down the slot.
While exemplary embodiments of the present invention have been shown in the drawings and described above, it will be apparent to one skilled in the art that various embodiments of the present invention are possible. For example, the specific configuration of the system as shown in
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5784576 *||Oct 31, 1996||Jul 21, 1998||International Business Machines Corp.||Method and apparatus for adding and removing components of a data processing system without powering down|
|US6138194 *||Jun 8, 1998||Oct 24, 2000||Micron Electronics, Inc.||Apparatus for sensing movement of a bus card and automatically removing power from the bus card|
|US6181030 *||Mar 30, 1999||Jan 30, 2001||International Business Machines Corporation||Computer power supply system having switched remote voltage sensing and sense voltage averaging for hot pluggable adapter cards|
|US6286066 *||Dec 15, 1998||Sep 4, 2001||Dell U.S.A., L.P.||Hot-plug interface for detecting adapter card insertion and removal|
|US6658507 *||Aug 31, 1998||Dec 2, 2003||Wistron Corporation||System and method for hot insertion of computer-related add-on cards|
|US6771510 *||Dec 27, 2002||Aug 3, 2004||Unisys Corporation||Expansion card retention device|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7039820 *||Apr 24, 2003||May 2, 2006||International Business Machines Corporation||Method for detecting and powering off unused I/O slots in a computer system|
|US7228563 *||Feb 6, 2003||Jun 5, 2007||Symantec Corporation||Shell code blocking system and method|
|US7260752 *||Feb 19, 2004||Aug 21, 2007||International Business Machines Corporation||Method and apparatus for responding to critical abstracted platform events in a data processing system|
|US7287281||Jun 17, 2003||Oct 23, 2007||Symantec Corporation||Send blocking system and method|
|US7437759 *||Feb 17, 2004||Oct 14, 2008||Symantec Corporation||Kernel mode overflow attack prevention system and method|
|US8001313||Nov 20, 2008||Aug 16, 2011||International Business Machines Corporation||Insertion and removal of computing cards in server I/O slots|
|US8190805 *||Nov 25, 2009||May 29, 2012||Fujitsu Limited||Information processing apparatus and method for reconfiguring the information processing apparatus|
|US8612642 *||Jun 21, 2010||Dec 17, 2013||Canon Kabushiki Kaisha||Information processing apparatus and control method thereof|
|US20040158729 *||Feb 6, 2003||Aug 12, 2004||Symantec Corporation||Shell code blocking system and method|
|US20040215985 *||Apr 24, 2003||Oct 28, 2004||International Business Machines Corporation||Method, apparatus and computer program product for detecting and powering off unused I/O slots in a computer system|
|US20050193271 *||Feb 19, 2004||Sep 1, 2005||International Business Machines Corporation||Method and apparatus for responding to critical abstracted platform events in a data processing system|
|U.S. Classification||713/324, 710/302, 713/320, 710/301, 713/300, 710/304, 713/323|
|International Classification||H04L12/24, G06F3/00|
|Cooperative Classification||G05B19/0428, G05B2219/24025|
|Jan 18, 2002||AS||Assignment|
Owner name: HEWLETT-PACKARD COMPANY, COLORADO
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CROSS, EDWARD A.;ALLISON, MICHAEL S.;KROEGER, CHRISTOPHER S.;REEL/FRAME:012531/0483;SIGNING DATES FROM 20011029 TO 20011030
|Sep 30, 2003||AS||Assignment|
Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY L.P.,TEXAS
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD COMPANY;REEL/FRAME:014061/0492
Effective date: 20030926
|Dec 22, 2008||FPAY||Fee payment|
Year of fee payment: 4
|Aug 11, 2009||CC||Certificate of correction|
|Oct 18, 2012||FPAY||Fee payment|
Year of fee payment: 8