On 22/12/16 12:19, Ian Jackson wrote:
Andrew Cooper writes ("Re: [Xen-devel] elbling1 (was Re: [xen-unstable test] 103788:
regressions - trouble: broken/fail/pass)"):
No. No similar problems I am aware of anywhere in XenRT (which haven't
ended up being down to human intervention in the firmware)
Indeed. I asked some XenRT folks about a while ago and they said they
hadn't seen it.
, I wonder whether either the physical machine setup
is (somewhat) unusual for some or all of the machines, or
whether there's something being run which with not too small a
likelihood causes the problem (and it being run often enough
simply guarantees the problem to surface every once in a while).
Is anything playing with EFI variables? This seems like the most likely
option.
We're basically using entirely BIOS booting, not EFI.
If the hardware supports EFI, then legacy BIOS will most likely be
implemented by CSM, meaning that the EFI variables in NVRAM are probably
still present in an E820 reserved region.
Another alternative is via IPMI. Lots of IPMI controllers these days
support a one-time setting of the next-boot device. This can be either
externally on the iDRAC/iLO/other interface, or internally via the
impi_* kernel modules.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
