Re: Powerdown problem on XEN | ACPI S5

[Atom2 <ariel.atom2@web2web.at>]

Andrew,
that does not sound too promising at the moment. Is there anything else 
I could provide to come to a resolution given that I/O virtualization is 
what the system is supposed to do.

You mention ACPI tables - I have no clue how to provide those, but I am 
more than happy to do what I can?

Ian (Campbell) originally diverted me to Jan (Beulich) who seemed to 
have an idea before you thankfully jumped in. Jan's idea seemed to also 
revolve around ACPI - although not tables, but registers:

quote from Jan Beulich:
 > It would be particularly interesting to know whether perhaps
 > some of the ACPI registers live in memory space on that
 > system - I already have a patch queued up (but not submitted
 > yet) that fixes problems in that case.

@Jan: would it make sense to go down that route?

Thanks again to everybody for their help so far.


Am 14.08.13 22:38, schrieb Andrew Cooper:
> On 14/08/13 21:24, Atom2 wrote:
>> Am 14.08.13 22:18, schrieb Andrew Cooper:
>> [...]
>>>
>>> Ok thanks.
>>>
>>> Do you mind confirming whether S5 works with "iommu=off" on the Xen
>>> command line?
>>>
>>> ~Andrew
>>>
>> Yes, that works: The system powers off after issuing
>>      shutdown -h now
>> from the dom0.
>
> So it is certainly an iommu interaction issue, which was sadly suspected
> given that we have seen similar problems in the past.
>
> Curiously, there are two IOMMUs on the system.  I am not familiar enough
> with Cougar Point chipsets to know how they are layed out.  Perhaps the
> ACPI tables might have more information.
I'm just curios, but where did you see two IOMMUs?
>
> ACPI interaction with Xen is tricky at the best of times.  Xen as no AML
> interpreter, so relies on Linux in dom0 to most of the ACPI legwork.
>
> My best guess at the moment is that something in the ACPI code for S5 is
> turning off enough of the PCH that Xen can no longer talk to the one of
> the IOMMUs.
>
> ~Andrew
>