Re: amd64-agp vs. swsusp

[Michal Schmidt <xschmi00@stud.feec.vutbr.cz>]

Rafael J. Wysocki wrote:
> On Tuesday, 19 of July 2005 23:26, Michal Schmidt wrote:
>>I have rebuilt agpgart and amd64-agp into the kernel and now it has 
>>resumed successfully for the first time. Thank you for the hint!
>>
>>But I still wonder, why that makes a difference.
> 
> 
> Before resume the module is not present.  When it gets loaded from the
> image it probably runs with the assumption that the hardware was initialized
> which is not correct.

It seems that the module doesn't even get a chance to run after resume. 
I've put some printks and udelays into kernel/power/swsusp.c and other 
places and I've found that the spontaneous reset occurs already in 
swsusp_arch_resume(), ie. before the drivers get their resume methods 
called. This is what I have in swsusp_suspend() now:
	...
         save_processor_state();
         if ((error = swsusp_arch_suspend()))
                 printk(KERN_ERR "Error %d suspending\n", error);
         /* Restore control flow magically appears here */
         restore_processor_state();
         printk(KERN_INFO "processor state restored!\n");/*I added this*/
         BUG_ON (nr_copy_pages_check != nr_copy_pages);
         restore_highmem();
         device_power_up();
	...

I'm recording the screen during resuming with a digital camera to see if 
the added printk is displayed before the reset and I am now sure that 
the reset occurs before that. The last thing I see is:

Stopping tasks: --|
Freeing memory... done (0 pages freed)
swsusp: Need to copy 8121 pages

Then on the next frame of the recorded MPEG, the display is already 
beginning to dim as the computer is resetting.

I also tried putting a printk before restore_processor_state(), but I'm 
not sure if it is safe to use printk there.
So I tried putting a loop of 5000 x udelay(1000) there to see if the 
reset would be delayed by 5s. It was not delayed, so I think that the 
reset occurs before restore_processor_state().

Michal