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

Re: [Xen-devel] ACPI shutdown unreliable with win7?

On Fri, 2015-05-29 at 14:28 +0100, Jan Beulich wrote:
> >>> On 29.05.15 at 15:14, <andrew.cooper3@xxxxxxxxxx> wrote:
> > On 29/05/15 14:04, Jan Beulich wrote:
> >>>>> On 29.05.15 at 14:54, <ian.campbell@xxxxxxxxxx> wrote:
> >>> On Fri, 2015-05-22 at 10:08 +0100, Ian Campbell wrote:
> >>>> If win7 doesn't shutdown given a power button request I'd be more
> >>>> inclined to remove the setting in osstest for those flights and let
> >>>> guest-stop go back to being never pass than to start making such changes
> >>>> to the VM config which I think would probably break the preceding
> >>>> suspend and migration tests (which aren't completely reliable, but are
> >>>> far more so than this shutdown one).
> >>> Does anyone have any ideas here or shall I propose:
> >> Unless we have a way to make an adjustment inside the guest for the
> >> power button to gain "shutdown" meaning, I think there's no alternative
> >> to the change below.
> > 
> > You can avoid advertising S3/S4 in the ACPI tables, which iirc causes
> > the same alteration to happen.
> > 
> > Hvmloader uses the platform/acpi_s{3,4} booleans to control whether the
> > relevant SSDTs are exposed.
> Which libxl even has settings for. That would perhaps be a better first
> try than disabling ACPI shutdown.

I've mentioned it at least twice now but nobody seems to think it is of
note that even with the current settings it does the right thing about 1
time in 10? Is Win7 really expected to behave so randomly here? 

Also, when the test fails the guest is also not hibernating either.

Plus I've queried the impact of change the ACPI s3/s4 settings on the
save/restore/migrate tests in the flight more than once and nobody has
responded to that either.


Xen-devel mailing list



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