[linux-pm] [PATCH 2/2] Fix console handling during suspend/resume

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

 



Hi!

> > > But I've said that before, and nobody cared last time either. For some 
> > > reason, people continue to think that suspend should be a single phase, 
> > > with us sending down "suspend" to each device.
> > 
> > Actually we already have
> > 
> > 	device_suspend()
> > 	device_power_down()
> > 
> > calls (badly missnamed, some people believe), so it is two phase for
> > now for s2ram. s2disk is more complex...
> 
> No we don't.
> 
> We have the above _calls_, but it doesn't matter one whit, since that's 
> not actually what the calls _do_.
> 
> There's no driver infrastructure to call down to the driver to say "save 
> your state, but don't suspend". None. Zero. Nada. Zip.
> 
> In order for this to actually _work_, you need to have
> 
> 	device_save_state();
> 		.. calls down to each device, saving their      ..
> 		.. state BUT NOT SUSPENDING THEM!               ..
> 		.. This phase can return an error, and can do   ..
> 		.. things like memory allocations.              ..
> 
> 		.. If an error happens here, we just return. We ..
> 		.. do NOT "restore" any state, because there IS ..
> 		.. NO STATE TO RESTORE - we've not actually     ..
> 		.. _changed_ anything ..
> 
> 		.. In other words, for a regular PCI device     ..
> 		.. this function does "pci_save_state()". Not   ..
> 		.. _anything_ else!                             ..
> 
> 	save_image_to_disk();
> 		.. NONE OF THE DEVICES ARE SUSPENDED! So all the  ..
> 		.. idiotic crap about trying to keep the "suspend ..
> 		.. device" alive would be the obvious crap it is! ..

This does not work, sorry, stop right here.

To save image to disk, you need to have an _image_. To have an image,
you need atomic copy, so that it is consistent. To achieve atomic
copy, you need other CPUs stopped, and you need DMAs stopped.

To have DMAs stopped, you need to "freeze" the devices.

> See? WE DO NOT DO THIS. I told people we needed to do this _years_ ago. I 
> tried to push through the two-phase suspend. I tried to explain why. I 
> clearly failed, because we do _nothing_of_the_sort_ right now.

I believe your solution does not work, sorry.

> PS. I'll also argue that we'd probably be better off with two separate 
> phases on resume too, partly to just be consistent, but partly because we 
> want to do some things with interrupts disabled, and some things with 
> interrupts enabled. Again, we have this INSANE situation where we call the 
> same "resume" function for _different_ devices first with interrupts 
> disabled, and then with interrupts enabled. Gaah! Idiotic, and hard as 
> hell to even understand!

Yes, this part is misdesigned.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux