Re: amd64-agp vs. swsusp

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi!

> >>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().

Long time ago there were i386 problems because we assumed that kernel
is mapped in one big mapping and agp broke that assumption. Copying
pages backwards "fixed" it (and then we done proper fix). It should
not be, but it seems similar to this problem....

								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux