Re: [Xen-users] Debugging DomU

["Chris (Christopher) Brand" <chris.brand@xxxxxxxxxxxx>]

Hi Julien,

>Hmmm... I remembered a similar issue on Xen which I though was fixed in 3.13.

I hunted around quite a bit, and didn't find anything. Nothing leaps out in the 
list of upstream kernel patches to mmu.c (there's a migration from meminfo to 
memblock, which I tried backporting with no effect on behaviour). Most of the 
reports of similar panics that I found, the recommendation was to ensure that 
u-boot was disabling the L2 cache before jumping to the kernel, which is 
presumably not helpful.

>There was some issue with CONFIG_ARM_PATCH_PHYS_VIRT, which is required in 
>order to boot Linux anywhere in the memory. The final result were 
>mis->computed depending on the CONFIG_VMSPLIT_*. Can you try to use different 
>one? FWIW, I'm using CONFIG_VMSPLIT_3G.

The result I reported was with CONFIG_ VMSPLIT_3G. With _1G and _2G, I don't 
see that same panic, and I see successful CMA memory allocation. I don't see 
any more boot messages after that, though, and xenctx reports a PC of 
0xffff000c. Hard to say whether that's better or worse :-/

Throwing some printk() calls into sanity_check_meminfo() shows that it decides 
that all the memory is highmem, and so passes 0 to 
memblock_set_current_limit(). That then seems to lead to the failure to find 
suitable blocks of memory to allocate, and hence the panic.

As an experiment, I tried changing the start of memory in the DTS from 
0x80000000. With that change, I can get the same result with CONFIG_VMSPLIT_3G 
as I got with the other configs above (PC=0xfff000c). That seems to indicate 
that this is the problem you recalled, but that there's yet another problem I'm 
hitting afterwards. I *think* I saw it go from __arm_ioremap_pfn() into 
do_DataAbort(), but I'm far from certain.

Thanks,

Chris


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