Hi.

On Saturday 24 June 2006 16:41, Benjamin Herrenschmidt wrote:
> Also note that it might be useful to implement something I've been
> carrying around as a patch for debugging suspend on the mac, is what I
> call "fake suspend". I did it as a kernel argument that turns the real
> suspend into a fake suspend, but we should be smarter.
>
> The idea is, as I may have described already, to do the whole driver
> suspend/resume without actually putting the system to sleep in between
> (whatver you do to ACPI to go to S3, whatever I do to the PMU to finish
> the suspend process on macs). In addition, you can have the video device
> "mark" (with flags maybe) the device chain all the way up from the video
> device so that it's skipped by the suspend and resume calls. (that is
> the console is not actually suspended).
>
> That allows you to exercise pretty much 99% of the driver suspend and
> resume code. It's not perfect as the chips will usually never do the D3
> -> D3cold transition, and thus will not be in the same state on resume
> than with a real suspend, but it's already a lot.
>
> Then, you can do a script running fake suspend cycles over and over
> again, while doing things like playing MP3s out of a USB disk while
> copying files to an NFS server etc etc etc... and wait for it to
> crash :)

That would be useful, but it would be even more useful if you could reset 
hardware to the boot-time configuration between the suspend and resume calls, 
because that difference is what really causes the problems.

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia