Re: [Xen-devel] [BUG] XEN domU crash when PV grub chainloads 32-bit domU grub

[Andreas Sundstrom <sunkan+lists.xen-devel@xxxxxxxx>]

Citerar Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>:

> Andreas Sundstrom, le Mon 21 Sep 2015 22:03:22 +0200, a Ãcrit :
> > 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=005a5ff0:
> 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?
No I had not tried that, one of the machines that I have used to replicate
the problem with had:
maxmem = 1024
memory = 512

First just removed the maxmem part as that is probably quite unusal.
No difference.

Then I set memory to 128 and at first I was not able to reproduce.
But I did some more tests while writing this response, and eventually it
failed with 128M as well.
Any use reason to try lower?

> > 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".
I just tried some with "set debug=all" at the top of the grub.cfg file.
And I could not see any difference in the output from the 1st. grub when
comparing a working chainload to a non-working (by diffing the output).

Adding the debug statement to the grub.cfg that is loaded by the 2nd.
grub (loaded from domU) gives no output at all when booting fails and
of course a lot of output when booting works.

So it seems quite clear to me that the actual chainloading/handover to
the 2nd. grub is where something goes wrong.

/Andreas



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