Abstract:
The invention discloses a method for preserving crash dump data in case of operating system crash in a diskless device. The method and the system according to the invention uses two stage booting where in a primary and a secondary kernel are loaded. The primary kernel is a compact kernel that comprises a limited set of functionality and the secondary kernel is a fully functional kernel used for running applications. In case of a crash of the secondary kernel, the kernel prepares a jump back to the primary kernel. Then the primary kernel preserves the crash dump support data and secondary kernel&#39;s RAM contents by sending it to a remote system which can store it on a nonvolatile memory.

Description:
FIELD OF THE INVENTION 
     The invention relates to information and computing systems that are running an operating system. Particularly invention relates to preserving crash dump information on diskless systems. 
     BACKGROUND OF THE INVENTION 
     As the electronic devices have turned into complex, most of them have been equipped with an operating system. Operating system is loaded into the memory of the device when the device is turned on. Because of the complexity of the tasks that need to be processed with such devices also the operating systems have turned into complex pieces of software. It is commonly known that complex pieces of software do not function perfectly as they have bugs that usually derive from programming errors. When a regular piece of software crashes because of a bug, it is common to start a debugging tool and check the reason of the crash. However, this might not be possible in case of operating system crash. If the operating system crashes the only solution to continue using it might be rebooting. During the reboot all crash information will be lost. Thus, the debugging is not possible. 
     This problem has been solved by storing the contents of the RAM memory. In ordinary computers RAM-contents can be stored into a swap partition on a disk. After a crash the computer is booted again but the swap is not cleared. Thus, the contents of the memory during the crash can be analyzed and debugged. Naturally, this solution does not work in a diskless system as there is no swap partition to be used. 
     One solution could be sending the crash information over a network connection to another computing device that has disk or other storage media for storing the information. However, the communication over a network connection requires properly functioning network device driver and protocol stack. This might not be the case if the system crashes during the boot up sequence. Furthermore, this solution is not applicable if the device does not have network connection at all or the network connection is not suitable for transferring such a data or there is no device that could receive the information. 
     It is also possible to preserve the information during the boot up sequence. If a crash is notified, the bootloader requests the BIOS to preserve the contents of the RAM during the boot. When new operating system boots up the preserved data is sent to a remote system that has a disk or other means for storing preserved information. The drawback of the solution is that the method requires support from the BIOS. However, all systems do not have a BIOS that supports this type of behavior. Thus, this method cannot be applied in every system. 
     The most sophisticated prior art method uses primary and secondary kernels. During the boot up the operating system&#39;s primary kernel kernel loads the secondary kernel in some predefined location of the memory. Upon crash, the primary kernel jumps to the secondary kernel and which sends the crash information to a remote system, which has a disk or other storage media. However, if the primary kernel crashes during the boot up sequence, it is possible that the secondary kernel has not been loaded yet. Thus, the method is not applicable in cases where primary kernel crashes before loading the secondary kernel. 
     Thus, there is a need for mechanism for preserving crash information so that a BIOS support is not needed and it must work reliably in all cases of OS problems in a diskless system. Furthermore, the solution should not relay too much on the crashed operating system to preserve the RAM contents. 
     SUMMARY OF THE INVENTION 
     The invention discloses a system and a method for preserving crash dump data in a diskless device. The invention uses two stage booting for booting a primary and a secondary kernel. The secondary kernel is a normal operating system kernel that is used for running application programs. The primary kernel is a stripped down version of the secondary kernel. The purpose of the primary kernel is to load secondary kernel and then act as a back up system to which the secondary kernel can jump in case of crash. 
     The jumping back to the primary kernel is implemented by turning the processor to the unprotected mode. As the unprotected mode does not support virtual memory, the code has to be in virtual address space such that its physical address is exactly same as its virtual address. Thus the code can be executed even if the virtual memory is not available in the unprotected mode. After the jump the primary kernel checks if the secondary kernel has crashed. If the secondary kernel has crashed, the primary kernel preserves the crash dump data. Preserving can be done, for example, by storing the data into a non-volatile memory or by sending it over a network to a remote system. After preserving the crash dump data the primary kernel can boot up the system properly by resetting processor, memory and other components that might have stale information that might affect to the stability of the system. 
     The benefit of the invention is that it is independent and does not require any assistance from the hardware. Furthermore, the method and the system according to the invention is not hardware or software dependent. Thus, the invention is suitable for any hardware component where storing crash dump data is beneficial. The solution is reliable and preserves the crash dump data in all OS problems. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The accompanying drawings, which are included to provide a further understanding of the invention and constitute a part of this specification, illustrate embodiments of the invention and together with the description help to explain the principles of the invention. In the drawings: 
         FIG. 1  is a block diagram of the of an example embodiment of the present invention, 
         FIG. 2  is a flow chart of an example embodiment of the present invention, and 
         FIG. 3  is a memory structure diagram of an example implementation. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     Reference will now be made in detail to the embodiments of the present invention, examples of which are illustrated in the accompanying drawings. 
     In  FIG. 1  a block diagram of an example embodiment of the invention is disclosed. The invention is applied in an environment that includes a device that is used and which comprises data that needs to be preserved after a crash. In  FIG. 1  there are two devices  13  and  19  presented. In the following example device  13  is the device that requires preserving the crash dump data and device  19  is a device that is connected to a communication network and capable of communicating with the device  13 . In the example the device  19  is similar to the device  13  but it is a not requirement. 
     The device  13  comprises a CPU  10 , a non-volatile memory  11 , data communication means  12  and a memory  14 . Similarly device  19  comprises a CPU  15 , a non-volatile memory  16 , data communication means  17  and a memory  18 . Non-volatile memories  11  and  16  are optional. However, if they are present, they could be, for example, a flash memory  11  and a hard disk  16 . It is possible arrange a hard disk into the device  13  also, but the invention is particularly meant for preserving crash dump data in a diskless system. Devices  13  and  19  are connected with a network connection. The connection may be any suitable network connection. For example, if devices  13  and  19  are cellular mobile communication network components, the network would be a mobile communication network. In the following example the state of the memory  14  will be preserved in case of the crash. 
     In  FIG. 2  a flow chart of a method accordance to the invention is disclosed. In the method a primary and a secondary kernels are used. The method initiates by booting up a primary kernel, step  20 . The primary kernel prepares the booting of a secondary kernel, step  21 , and boots it, step  22 . Typically this is done by using a multistage boot loader that boots up both kernels. The secondary kernel is made available for the applications and the primary kernel is typically a stripped version of the secondary kernel. After the boot up sequence the operating system is fully functional and may be used normally and the user will not notice any difference until a crash situation will occur. 
     Firstly, a crash situation is detected, step  23 . After a crash situation the secondary kernel prepares a jump to the primary kernel, step  24 . Preparing the jump comprises for example shutting down drivers that can be shut down. Furthermore, the preparing comprises an important step of turning processor from the protected mode to the unprotected mode. The preparation furthermore comprises a code that sets up segmentation, page and interrupt tables and clears internal caches and buffers. As the unprotected mode does not support virtual memory, the code has to be in virtual address space such that its physical address is exactly same as its virtual address. Thus the code can be executed even if the virtual memory is not available in the unprotected mode. Furthermore, the secondary kernel stores crash dump information to a location, that can be read later. Such locations are for example processor registers, a non-volatile memory, or other similar. If the information contains lot of data, it may be stored into RAM memory and the secondary kernel passes only a pointer to the memory location. The actual jump is typically implemented via a boot loader. The secondary kernel is arranged to execute a jump after the preparation procedure is done, step  25 . 
     The primary kernel starts booting up the system, step  26 . During the boot up the procedure the primary kernel determines if a crash situation has occurred previously, step  27 . If a crash situation has occurred, the primary kernel starts preserving the state of the secondary kernel. For example, if the secondary kernel has stored crash dump support data (like kernel load address, kernel name, time of crash, bitmap of kernel pages etc) into a memory location, the primary kernel fetches the pointer to the memory location and then retrieves the crash dump support information. Then crash dump support data and secondary kernel&#39;s RAM contents are preserved by sending it to a remote system, step  28 . If the device comprises a disk or other storable media, the information may be stored on it. After preserving the data, the device may be booted normally by resetting processor, memory and other devices that might affect to the functioning of the operating system. At this stage, the system is ready for rebooting, step  29 . 
     In  FIG. 3  a memory structure diagram of an example implementation is disclosed. The figure illustrates how primary and secondary kernels are arranged in the memory. The actual X and Y memory addresses are operating environment dependent and can be chosen by adjusting operating environment, for example, by choosing the operating system or amount of memory. 
     According to a method disclosed in  FIG. 2  a following example implementation framework is provided. The implementation framework is designed to work in Intel based PC compatible environment and it comprises ten steps. Similar implementation according to method disclosed in  FIG. 2  may be modified to other environments also. 
     1. In primary kernel preserve the pointer to the BIOS Interrupt Descriptor Table—IDT. 
     2. When the secondary kernel crashes create crash dump support data structure, which describes the state of the crashed kernel like physical address of the kernel base and its size, bit map of the kernel pages etc. 
     3. Preserve the crash dump support data on compact FLASH. It requires only few Kilo Bytes of space. 
     4. Manipulate the crashed kernel&#39;s page tables to get a PA==VA mapped page and relocate the text segment&#39;s function exit_to_bootloader( ) to this page and transfer control to it. 
     Note: Creating PA==VA address space 
     
         
         
           
             i. Statically define a page of memory aligned at page boundary. Any piece of code can be stored in this page. 
             ii. At run time determine the physical address (PA) of that page 
             iii. Extract page directory component of physical address (bit  31 - 20 )
           pd_offset=(PA&gt;&gt;22) &amp; 0xFFFF FC00   
         
             iv. Extract page table component of physical address (bit  12 - 21 )
           pt_offset=(PA&gt;&gt;12) &amp; 0xFFFF FC00   
         
             v. Obviously, page offset will be 0x0. Just ensure that. 
             vi. Extract page directory entry and page table entry of that physical address (PA) and preserve those values 
           
         
       
    
     
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 old_pde = *(CR3 + pd_offset * 4) 
               
               
                   
                 pt_address = old_pde &amp; 0xFFFF F000 
               
               
                   
                 if (pt_address != 0) { 
               
               
                   
                   old_pte = *(pt_address + pt_offset * 4) 
               
               
                   
                   } 
               
               
                   
                   
               
             
          
         
       
         
         
           
             vii. Write new page directory table entry 
           
         
       
    
     
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                    if (pt_address == 0) { 
               
               
                   
                     Allocate a new page for page table whose 
               
               
                   
                 physical address is PAT 
               
               
                   
                     *(CR3 + pd_offset * 4) = PAT &amp; 0xFFFF F000 
               
               
                   
                     Set the page table permissions and flags 
               
               
                   
                 in lower 12 bits. 
               
               
                   
                     pt_address = PAT 
               
               
                   
                     } 
               
               
                   
                    *(pt_address + pt_offset * 4) = PA &amp; 0xFFFF 
               
               
                   
                 F000 
               
               
                   
                    Set the page permissions and flags in lower 
               
               
                   
                 12 bits. 
               
               
                   
                   
               
             
          
         
       
         
         
           
             viii. Now do a long jump to PA and flush TLB. 
             ix. Now we have PA==VA address space. 
           
         
       
    
     5. exit_to_bootloader( ) function disables all interrupts, watchdog, paging mode and protected mode. Then flushes TLB, instruction cache etc. Backs out the earlier changes to the crashed kernel&#39;s RAM copy of page table without reloading those changes into the processor&#39;s memory management unit. Creates a simple GDT, LDT tables as BIOS does before jumping to bootloader and loads BIOS IDT and then jumps to 0:7C00 address in real mode of the processor. 
     6. Address 0:7C00 contains first stage of the bootloader called Master Boot Record (MBR), and which loads the second stage of the bootloader and then primary kernel. 
     7. During the initial stage of booting primary kernel notices that previous secondary kernel was crashed. If so it won&#39;t alter the physical memory region of the previous crashed secondary kernel. 
     8. Once it has booted all the way up, user level dump client interprets the crashed secondary kernel RAM using the crash dump support data structure and transfers the RAM contents to remote system through network interface. 
     9. After the completion of the dump transfer the card is cleanly reset and rebooted. 
     10. The server process on remote system preserves the secondary kernel&#39;s RAM contents on local hard disk. 
     Note that this implementation assumes that primary or secondary kernel doesn&#39;t alter the BIOS address space below 1 MB region. So when the control is transferred from secondary kernel to bootloader it can access the same BIOS resources. 
     In an alternative solution it is possible to allocate two spare pages for storing page directory table and page table and fill it with original contents and then modify the spare pages and then update CR3 register. While dumping the image original page tables can be used. 
     It is obvious to a person skilled in the art that with the advancement of technology, the basic idea of the invention may be implemented in various ways. The invention and its embodiments are thus not limited to the examples described above; instead they may vary within the scope of the claims.