Re: amd64-agp vs. swsusp

Michal Schmidt
2005-07-20T22:08:23Z

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