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

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

On Fri, Apr 26, 2013 at 9:10 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Thu, 2013-04-25 at 18:02 +0100, Ben Guthro wrote:
>> On Thu, Apr 25, 2013 at 8:00 AM, Ben Guthro <ben@xxxxxxxxxx> wrote:
>> > Since this is something that XenClient really relies on working, it
>> > has been a pain point with every upgrade of Xen for us.
>> > It is enormously time consuming to debug on every upgrade, and has a
>> > long tail in discovering problems (I started debugging S3 last Aug on
>> > xen-unstable, prior to 4.2 being cut)
>> >
>> > How can we work with the community to try to get some sort of
>> > regression testing for this feature that we rely on in our product?
>> I am still interested in ideas for getting this into automated
>> testing, and any ideas people may have for this.
> CCing Ian Jackson who runs the test infrastructure.
> Contributing new tests is now less onerous than it once was (i.e. it
> might even possible at all). There is some info at
> http://lists.xen.org/archives/html/xen-devel/2012-10/msg01517.html
> although the branch may be out of date -- Ian was working on merging the
> standalone branch at one point.
> 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.
>       * Would s3 ever be expected to work on the sorts of whitebox
>         server systems which form the osstest pool or do we need to
>         investigate additional hardware?
>       * How hardware specific are the s3 failures -- we obviously can't
>         have one of every laptop ever ;-)

When I discussed this with Ben before, it seemed that almost any
testing would be a very large improvement.  Namely, it seemed to me
that even if the test just did a "null suspend" -- i.e., shut the
entire system down as though about to do a suspend but then just
resume without pulling the trigger -- would shake out a lot of bugs
(as well as make it very easy for devs that don't normally care about
suspending their machine to fix things).  Having an RTC wake-up would
be the next thing to do after that.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.