> -----Original Message----- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > Paul Durrant > Sent: 06 June 2017 16:52 > To: 'Jan Beulich' <jbeul...@suse.com> > Cc: xen-devel (xen-de...@lists.xenproject.org) <xen- > de...@lists.xenproject.org> > Subject: Re: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot > > > -----Original Message----- > > From: Jan Beulich [mailto:jbeul...@suse.com] > > Sent: 06 June 2017 16:11 > > To: Paul Durrant <paul.durr...@citrix.com> > > Cc: xen-devel (xen-de...@lists.xenproject.org) <xen- > > de...@lists.xenproject.org> > > Subject: Re: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot > > > > >>> On 06.06.17 at 16:32, <paul.durr...@citrix.com> wrote: > > > I've been having fun setting up a new test rig... > > > > > > I have a skull canyon NUC and I put debian stretch (rc4) on it (so that's > > > a > > > 4.9 kernel) and then tried building and installing the latest Xen > > > staging-4.9 > > > code. The system failed to boot... basically it got stuck before even > > > managing to get sufficiently into Xen to spit out anything on the console. > > > Xen 4.8 OTOH booted just fine so I started bisecting and after 14 > iterations > > > I got down to the following commit is being the problem: > > > > > > commit c0655e492e6b33e26ec9cd33f59725d0db89cdd0 > > > Author: Juergen Gross <jgr...@suse.com> > > > Date: Fri Mar 24 14:18:54 2017 +0100 > > > > > > x86: split boot trampoline into permanent and temporary part > > > > > > The hypervisor needs a trampoline in low memory for early boot and > > > later for bringing up cpus and during wakeup from suspend. Today this > > > trampoline is kept completely even if most of it isn't needed later. > > > > > > Split the trampoline into a permanent part and a temporary part > needed > > > at early boot only. Introduce a new entry at the boundary. > > > > > > Reduce the stack for wakeup code in order for the permanent > > > trampoline to fit in a single page. 4k of stack seems excessive, about > > > 3k should be more than enough. > > > > > > Add an ASSERT() to the linker script to ensure the wakeup stack is > > > always at least 3k. > > > > > > Signed-off-by: Juergen Gross <jgr...@suse.com> > > > Reviewed-by: Jan Beulich <jbeul...@suse.com> > > > > > > To verify this I checked out master, reverted that commit, and tried > > > again. > > > The NUC still booted fine. > > > > Well, interesting, but I don't think it is very realistic to expect any > > fix with just the information you supply. There must be something > > rather special about that system, and likely it would help if we > > knew what that is. E.g. an unusual E820 map. Worse would be if > > they used memory outside of properly marked E820 regions in a > > way colliding with what we do. > > > > Otherwise I'm afraid we need to hope for you to debug the issue. > > > > Yes, I was posting this more a heads-up for the moment, so that 4.9 does not > go out with this regression. > > I will try to figure out what is going on... My initial thoughts on looking > at what > the patch does are that it may be something to do with the fact I am using a > vga console rather than a serial one. I need to try another 4.9 on another > system (gigabyte brix) to see if the problem manifests there too. I'll also > have > to play with the BIOS settings on the skull canyon. >
The problem definitely doesn't manifest on the brix, so the next theory is that it is something to do with the BIOS of the skull canyon. Paul > Paul > > > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
