Re: [Xen-devel] pvgrub "Error 9: Unknown boot failure" booting Debian Jessie kernel (Was: Re: [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported)

[Juergen Gross <jgross@xxxxxxxx>]

On 01/12/15 08:15, Juergen Gross wrote:
> On 30/11/15 17:56, Ian Campbell wrote:
>> On Mon, 2015-11-30 at 16:25 +0000, Ian Campbell wrote:
>>> (d54) Pinning the boot page table pfn 4be3 / mfn 1bfd71/1bfd71
>>> (d54) pin_table: MFN 1bfd71
>>> (XEN) mm.c:2417:d54v0 Bad type (saw 1400000000000001 != exp 
>>> 7000000000000000) for mfn 165b81 (pfn 4d81)
>>
>> I added a "BUG_ON(*pt_pfn == 0x4d81);" to mini-os's new_pt_frame, which
>> after some messing with gdb to decode produced this stack trace:
>>
>> 716e7: arch_do_exit + 9 in section .text
>> 66176: do_exit + 28 in section .text
>> 6ff68: new_pt_frame + 134 in section .text
>> 70401: need_pgt + 410 in section .text
>> 706ec: do_map_frames + 284 in section .text
>> 66e72: sbrk + 130 in section .text
>> 7768e: _sbrk_r + 30 in section .text
>> 74fa3: _malloc_r + 1219 in section .text
>> 76f3f: _realloc_r + 511 in section .text
>> 31035: unsafe_flush + 46 in section .text
>> 38bc7: unxz + 480 in section .text
>> 310fa: xc_dom_decompress_unsafe + 110 in section .text
>> 38cec: xc_try_xz_decode + 45 in section .text
>> 286ff: xc_dom_probe_bzimage_kernel + 891 in section .text
>> 24613: xc_dom_find_loader + 89 in section .text
>> 24d83: xc_dom_parse_image + 58 in section .text
>> 19d06: kexec + 1012 in section .text
>> 03c27: pv_boot + 97 in section .text
>> 08e4b: boot_func + 52 in section .text
>> 0ab16: run_script + 294 in section .text
>> 10848: run_menu + 3133 in section .text
>> 10fb2: cmain + 1444 in section .text
>> 04447: main + 303 in section .text
>> 66991: call_main + 581 in section .text
>> 03423: thread_starter + 9 in section .text
>>
>> I'm not quite sure what to make of this, in particular I don't see anything
>> in kexec.c which obviously looks after unmapping the heap or brk areas.
> 
> Nah, this backtrace shows a normal allocation path while
> uncompressing the kernel image. I'd expect something like that.
> Why shouldn't mini-os make use of pfn 4d81 somewhere?
> 
> I guess there is something wrong either in mini-os's memory
> allocator (not very likely) or in kexec_allocate(). I'll try to
> check those.

Hmm, kexec_allocate() seems to be a little bit fishy.

I suspect a problem in the loop for the case new_pfn == i. I think
in this case the p2m list will be written with a wrong entry.

Ian, could you verify via:

diff --git a/stubdom/grub/kexec.c b/stubdom/grub/kexec.c
index 8fd9ff9..9421023 100644
--- a/stubdom/grub/kexec.c
+++ b/stubdom/grub/kexec.c
@@ -131,6 +131,8 @@ int kexec_allocate(struct xc_dom_image *dom)
        /* Store destination PFN of currently requested page. */
        pages_moved2pfns[i] = new_pfn;

+       BUG_ON(new_pfn == i);
+
        /* Put old page at new PFN */
        dom->p2m_host[new_pfn] = old_mfn;


Juergen

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