Method and programs for coping with operating system failures

• US 20050228769A1
• Filed: 12/06/2004
• Published: 10/13/2005
• Est. Priority Date: 04/12/2004
• Status: Abandoned Application

• Current Assignee: Hitachi, Ltd.
• Original Assignee: Hitachi, Ltd.
• Inventors: Kimura, Shinji, Wakai, Yoshinori, Takasugi, Masayoshi, Oshima, Satoshi
• Application Number:
  US11/003,430
• Publication Number:
  US 20050228769A1
• Time in Patent Office: Days
• US Class Current: 1/1
• CPC Class Codes: G06F 11/0706 the processing taking place on a specific hardware platform or in a specific software environment
• CPC Class Codes: G06F 11/0793 Remedial or corrective actions recovery from an exception in an instruction pipeline G06F9/3861; by retry G06F11/1402; for recovering from a failure of a protocol instance or entity H04L69/40

Abstract

In provision against an unrecoverable failure in a first OS, a second OS for undertaking failure processing is loaded onto a memory beforehand. On detecting a failure in the first OS, a gate driver saves the first OS, moves the second OS to its executable area within the memory, and starts up the second OS. After this, control is transferred to a failure-processing application program placed under the control of the second OS.

Claims

1. A method for coping with OS failures, said method comprising:

starting up a first OS by loading the first OS onto a memory of a computer;

loading a second OS onto the memory by securing a second OS area not erased from the first OS;

starting up the second OS upon detection of a failure in the first OS; and

executing failure processing of the first OS under control of the second OS.

2. The method according to claim 1, further comprising, before the failure occurs in the first OS, embedding in the first OS a hook for detecting the failure.

3. The method according to claim 1, further comprising updating hardware configuration definition information of the second OS according to a hardware configuration of the computer existing before the failure occurs in the first OS.

4. The method according to claim 3, further comprising reconstructing necessary device drivers by use of the second OS so that after the startup of the second OS, the device drivers remain in an area of the second OS in accordance with the hardware configuration definition information thereof.

5. The method according to claim 1, further comprising, before the startup of the second OS, saving the first OS in a reserved area of the memory and moving the second OS to an original area of the first OS.

6. The method according to claim 1, wherein said step of executing failure processing uses the second OS to record in storage the failure-causing first OS present on the memory.

7. The method according to claim 1, wherein a kernel of the second OS is the same as that of the first OS.

8. The method according to claim 7, further comprising, before the failure occurs in the first OS, extracting necessary device drivers from internal device drivers of the first OS and using the thus-extracted device drivers as that of the second OS.

9. A program allowing a computer in which a first OS operates to execute:

a function which secures an area of a second OS not erased from the first OS, and loads the second OS onto a memory of the computer;

a function which starts up the second OS when a failure in the first OS is detected; and

a function which transfers control to a failure-processing application program executed under control of the second OS.

10. The program according to claim 9, further allowing the computer to execute a function which, before the failure occurs in the first OS, embedding in the first OS a hook for detecting the failure.

11. The program according to claim 9, further allowing the computer to execute a function which updates hardware configuration definition information of the second OS according to a hardware configuration of the computer existing before the failure occurs in the first OS.

12. The program according to claim 11, further allowing the computer to execute a function which reconstructs necessary device drivers by use of the second OS so that after the startup of the second OS, the device drivers remain in an area of the second OS in accordance with the hardware configuration definition information thereof.

13. The program according to claim 9, further allowing the computer to execute a function which, before the startup of the second OS, saves the first OS in a reserved area of the memory and moves the second OS to an original area of the first OS.

14. The program according to claim 9, wherein a kernel of the second OS is the same as that of the first OS.

15. The program according to claim 14, further allowing the computer to execute a function which, before the failure occurs in the first OS, extracts necessary device drivers from internal device drivers of the first OS and uses the thus-extracted device drivers as that of the second OS.