Re: [Xen-devel] S3 is broken again in xen-unstable

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-04-26 at 13:19 +0100, Ben Guthro wrote:
> On Fri, Apr 26, 2013 at 4:10 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:

> > Some questions:
> >       * How automatable is s3?
> >       * In particular can we automate the wakeup? s3 is save to RAM
> >         IIRC, and most power control in the test system is done with PDU
> >         power cycling.
> 
> I spoke with George Dunlap  a bit about this while I was over in the
> UK a few weeks ago, and drew up an example shell script for this:
> http://xen.markmail.org/thread/ghj2ffngemccq6p4
> Marek also weighed in, and included some of his own tests, and experiences.
> 
> In my experience, this mechanism is about as reliable as your RTC. On
> some systems you might tell it to sleep for 30s, and it will wake in
> 10s.
> 
> That said, when things go wrong, the machine does need to be power
> cycled...so if you are not physically located near the machine under
> test, you would need a PDU as a recovery mechanism, I suppose.

That'#s OK, all the systems in the test harness would have to have PDU
for the other test cases (initial install etc) anyway.

> >> Would it be helpful to maintain a branch in my xenbits repo that could
> >> be a rebased version of konrad's acpi-s3 patches against Linus' latest
> >> kernel?
> >
> > What is keeping those out of Linus' tree?
> 
> Added Konrad here, but I believe he is on vacation this week.
> This has been a bullet point on his OSS presentation, as outstanding
> pvops work for at least 3 years now.
> 
> IIRC, the x86 guys NACK'ed the change as being too invasive.
> I googled around a bit, but can't seem to find the thread about it.

I wonder if it might be something like that :-/

> > Once we have a test case in the standard flights then we can consider
> > the options around new flights testing other trees.
> 
> I'm not sure I understand this point.
> Are you saying you want to see a test that fails in the standard test
> flight first...because without Konrad's patches, it will be guaranteed
> not to work.

Right. AIUI the flights (and I may be using the wrong term here) are
somewhat uniform and and few in number and get run with various
combinations inputs (Xen tree, Linux tree, Qemu tree), so there is
effectively one "test Linux PV kernel flight" and one "test Xen PV
guests flight" etc, so we want to get S3 into those flights, with the
existing set of "* tree" inputs.

IOW we should add a new row to the grid
http://www.chiark.greenend.org.uk/~xensrcts/logs/17816/ for s3 testing
and then we can consider adding a new column with a different set of
tree's as input.

Ian J may have a different opinion on how to approach, but he's away
until mid next week.

> ...and without other changesets queued up for the 3.10 merge window,
> non-boot CPUs will always have incorrect C-states.

It's OK to add the tests before things work.

Ian.



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