suspend2 status report

Background:

       This is work is based on suspend2 patch for 2.4.21 ( )

But this patch only supports i386 architecture, not support MIPS , and this patch is not very maturate ( suspend2 is the first name of TuxOnIce , TuxOnice is very maturate now, but it is fit for 2.6.x kernel , not fit for 2.4 version) . After my evaluation of porting time, we decide suspend2 patch(for 2.4.21 kernel) as our scratch line.

 

 

So what we did is as follows :

fixed existed bugs in this patch: I have fixed some bugs to make it can run on Redhat9.0 ( whose kernel is 2.4.21)

make it support MIPS architecture: added or modify some architecture-dependent functions . for example , send signal .

in future : make it support usb stick as swap partition( currently , only support IDE harddisk as swap partition)

 

Advantage : hibernate can restore old environment quickly , just like the hibernate function in laptop.

Lack function : now , hibernate/suspend can’t support usb stick as swap partition to store image, because currently suspend2 patch can’t support SCSI ( kernel will use usb-storage and scsi to emulate disk) . so what we need to do is to make suspend2 patch support SCSI

 

 

 

Suspend progress Table  (done)

 

 

Freezing system activity.	The first main stage in suspending is to stop all other activity. This is achieved in stages. First, we stop tasks from submitting new I/O using hooks in the system calls for reading, writing and at a number of other places as well as at the kernel threads that start I/O. If any tasks are syncing,we wait for them to complete. We then do our own sync, just in case no syncs were running. Next, we stop all the others tasks. Some are signaled  and put in a 'refrigerator'. Others are simply not scheduled again until we decide to wake them up.	Done
Image preparation.	For a successful suspend, you need to have enough disk space to store the image and enough memory for the various limitations of Software Suspend's algorithm. You can also specify a maximum image size. In order to attain to those constraints, Software Suspend may 'eat' memory. If, after freezing processes, the constraints aren't met, Software Suspend will thaw all the other processes and begin to eat memory until its calculations indicate the constraints are met. It will then freeze processes again and recheck its calculations. During this cycle, it also allocates the storage needed to save the image and prepares all the meta data that records what will be saved and where.	Done
Storage of meta data and image.( including pageset2 and pageset1)	Software Suspend stores data in two pagesets. Pageset 2 contains pages on the active and inactive lists; essentially the page cache. Pageset 1 contains all other pages, including the kernel.   We use two pagesets for one important reason: We need to make an atomic copy of the kernel to ensure consistency of the image. Without a second pagedir, we would be limited to an image that was at most half the amount of memory available. Using two pagesets allows us to store a full image of memory in most cases. Since pageset 2 pages won't be needed in saving pageset 1, we first save pageset 2 pages. We can then suspend drivers and make our atomic copy of the remaining pages using both pageset 2 pages and any other pages that are free. While saving both pagesets, we are careful not to corrupt the image. We immediately shoot down pages that are added to the page cache, and we allocate a special memory pool of extra pages that can be used by during suspending. All of the pages in this pool are saved along with the rest of the pageset 1 pages, even if they're not used. This saves us having to worry about the image becoming inconsistent while we're saving pageset 2.	Saving pageset2	Done
		Saving pageset1	done
Save a second copy of the pagedirs.	To reload pagedir 1 at resume time, we need to know where the data is    stored. This requires the saving of a second copy of the pagedirs.	Done
Save the suspend header.	We save our settings and other parameters needed for    reloading pagedir 1 in a 'suspend header'.	Done
Set the swap header.	Finally, we edit the swap header for our resume2= swap file/partition. The  swap signature is changed to record what kind of header it originally was (swapspace 1 or 2) and the bdev and first block and block size details of the suspend header.	Done
Power down.	Or reboot if we're debugging and the appropriate option is selected.   Note: now in our STB, we only make it while(1)	Done

 

 

 

 

Resume Progress Table ( on going)

 

Resume progress should be reverse of suspend/hibernate progress.

 

 

Parse storage location(for example :/dev/hda2)	parse storage image location :  in our case , image is saved in swap partition(located in IDE harddisk) , when suspend , we will save image into this swap partition, so when resume , we must tell kernel where is the storage , kernel will read the first block into a page , and judge if it has swap signature found.	Done
Checking for image	Kernel will check if swap partition has a image	Done
Reading suspend header	Suspend header includes important information , for example , where we should copy saved pagesets into which locations in RAM , and how many physical pages we saved	Done
Test for the existence of an image and attempt to load Pageset1 to RAM	Attempt to read the header and pageset1(kernel & process data ) of a suspend image  to temporary locations	Done
Copy Pageset1 to original place	Copy pageset1 backups into original place	on going
restore_processor_context	restore_processor_context	on going
Reading Pageset2 ( page caches)	Will be able to read back secondary pagedir (if applicable).	On going