Re: [Xen-devel] [PATCH] Introduce an s3 test

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ben Guthro writes ("Re: [PATCH] Introduce an s3 test"):
> On 05/01/2013 06:56 AM, Ian Jackson wrote:
> >> +# check log for resume message
> >> +poll_loop(4*$timeout, 2, 's3-confirm-resumed',
> >> +  target_cmd_output($ho,"xl dmesg | grep 'ACPI S' | tail -1 | " .
> >> +          "grep -n 'Finishing wakeup from S3 state'"));
> >
> > Why does this need a poll loop ?  Surely after the machine comes out
> > of suspend it should be up right away ?
> 
> This is a bit of a "first pass" in a test environment I've never used 
> before. I modeled this after other tests I found in the same dir. If 
> this is inappropriate, then I suspect you are correct.

Maybe you should be using guest_check_up ?

> I put it in the loop for the case of networking taking some time to come 
> back online, so if the ssh command failed it would be retried. 

How long is it supposed to take to come back online ?  "4*$timeout"
seems (a) a bit arbitrary (b) rather long with your existing value of
$timeout.

> Additionally, I have found that the RTC wakeup mechanism is not very 
> accurate in its timing.

How unfortunate.

> > I'm not sure I follow this.  Wouldn't messed up timer queues cause
> > other trouble in the guest ?
> 
> Yes, but it has been a common point of failure / problems after S3. I 
> put this here as a placeholder to verify that everything is still as it 
> should be.

Err, OK.

> >> +# - Check for kernel Oops
> >> +# - Check for Xen WARN
> >
> > These are a good idea but should perhaps be a separate test step.
> 
> Wouldn't you want a warning/oops that was provoked by S3 to be 
> associated with that test?

Hrm.  Well in principle this is surely true of any test.

Can we make warnings/oopses fatal ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel