Re: [Xen-devel] elbling1 (was Re: [xen-unstable test] 103788: regressions - trouble: broken/fail/pass)

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

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.

I have two theories:

 * Wild accesses do something weird.  (Why would it preferentially
   affect the boot order?  Other things sometimes change too but less
   frequently.  I can't remember ever losing the serial console setup,
   so it's not just "corrupted, reset to defaults".)

 * Something somewhere (in the firmware?) spots that the host is
   "failing to boot" and deliberately messes with the boot order "in
   the hope that it will help".  This is a bit odd because in the
   "Xen crashes on boot" case, a sequence of failing Xen boots (after
   a Xen crash, Xen will reboot) will normally be followed by poweroff
   and then a netboot of a working d-i image.

Perhaps it would be worth telling Xen not to reboot on crash...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel