From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Thibault Subject: Re: [BUG] XEN domU crash when PV grub chainloads 32-bit domU grub Date: Wed, 23 Sep 2015 00:37:37 +0200 Message-ID: <20150922223737.GK2964@var.home> References: <5600628A.20202@zappa.cx> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <5600628A.20202@zappa.cx> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andreas Sundstrom Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org Andreas Sundstrom, le Mon 21 Sep 2015 22:03:22 +0200, a =E9crit : > Note that my original thought was that this bug probably is within GRUB. It's probably in the GRUB implementation of loading the domU GRUB, since you say that pvgrub1 loads it fine. > (XEN) domain_crash_sync called from entry.S: fault at ffff82d08021feb0 > compat_create_bounce_frame+0xc6/0xde So it's inside xen entry code... > (XEN) Guest stack trace from esp=3D005a5ff0: This looks like the end of the stack > (XEN) 00000010 00000000 0001e019 00010046 0016b38b 0016b38a 0016b389 > 0016b388 > (XEN) 0016b387 0016b386 0016b385 0016b384 0016b383 0016b382 0016b381 > 0016b380 [...] and this looks like a lot of consecutive numbers. Perhaps we simply somehow overflow? Did you try giving less memory to the domU? > I see no output from the domU grub (except when it works as it should > of course). Yes, as explained in another mail domU has to get to connect to the console before getting messages from there. Another way is to make console_io hypercalls, which should end up into xl dmesg. You may also want to enable grub debugging prints, by setting the debug variable to "all". Samuel