Re: [Xen-devel] Debugging a weird hardware fault.

[Keir Fraser <keir@xxxxxxx>]

On 02/08/2011 07:14, "Andrew Cooper" <andrew.cooper3@xxxxxxxxxx> wrote:

> Just for information, this turned out to be a BIOS bug.  It was setting
> a 6 second timer when executing _PTS, which hit the system reset if
> PM1{a,b} had not been hit when the timer expired.  As Xen does all of
> its shutdown after the call to _PTS and before PM1{a,b}, there is a
> significant time gap, which was falling fowl of the timer in most cases.

Six seconds though, that's quite a long time! Is it a big box?

> In this case, it seems likely that a BIOS fix can be done, as Supermicro
> do provide a custom BIOS for the NetScalar box in question.
> 
> However, If anyone else comes across this issue, we did make a software
> solution.  You can replace /etc/init.d/halt (or equivalent for your
> chosen dom0 distro) to KEXEC reboot into a native kernel which listens
> for a special command line parameter and calls pm_power_off_prepare()
> and pm_power_off() after the ACPI module has initialized[1].
> 
> This issue does however show that Xen itself is in breach of the ACPI
> spec, which is a dangerous situation to be in given the fragility of
> APCI at the best of times.  In due course, I will put my mind to solving
> the dom0-Xen ACPI interaction problems if the question is still open.

Yes, this is ultimately the issue. It's going to be a pain to fix properly,
unfortunately.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel