[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Debugging DomU

  • To: Julien Grall <julien.grall@xxxxxxxxxx>
  • From: "Chris (Christopher) Brand" <chris.brand@xxxxxxxxxxxx>
  • Date: Thu, 28 May 2015 00:02:28 +0000
  • Accept-language: en-US
  • Cc: xen-users <xen-users@xxxxxxxxxxxxx>, Ian Campbell <ian.campbell@xxxxxxxxxx>
  • Delivery-date: Thu, 28 May 2015 00:03:54 +0000
  • List-id: Xen user discussion <xen-users.lists.xen.org>
  • Thread-topic: [Xen-users] Debugging DomU

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.



Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.