On Tue, Dec 22, 2009 at 10:14:34AM -0500, Michael D Labriola wrote:
> xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 12/22/2009 09:32:03 AM:
>
> > > > (early) [ 0.000000] Kernel panic - not syncing:
> > > > <3>xen_create_contiguous_region failed
> >
> > This implies you did not have enough DMA32 memory in the hypervisor
> > for the guest.
> > Meaning at least 64MB. When you launch your guest, run 'xm info' and
> > see what you have. The latest
> > from xen-unstable tries to have _at least_ that amount of memory
> available
> > for the guest. Here is what I see:
> >
> > free_memory : 3938
> > node_to_cpu : node0:0-1
> > node_to_memory : node0:3938
> > node_to_dma32_mem : node0:3514
> >
> > The node_to_dma32_mem needs to have at least 64.
>
> I'm using Xen 3.4.2. xm info doesn't have a 'node_to_dma32_mem' entry at
> all. I wasn't setting dom0 memory constraints via grub before, so I tried
> adding dom0_mem=512M. That makes free_memory=3533 on my system. Still
> get the same panic.
All of your memory is below 4GB, so you should not be hitting the problem
I thought you had (not enought memory under 4GB).
Maybe Xen 3.4.2 logic is much different than 4.0 when it comes to exchanging
MFNs
and Ian's is right. Under 4.0 it I've no trouble exchanging the MFNs even
without
any PCI devices being passed in.
Can you try this patch to help narrow down the problem:
diff --git a/arch/x86/xen/pci-swiotlb.c b/arch/x86/xen/pci-swiotlb.c
index ecdbfe2..37fd0e3 100644
--- a/arch/x86/xen/pci-swiotlb.c
+++ b/arch/x86/xen/pci-swiotlb.c
@@ -960,7 +960,7 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long
nslabs)
dma_bits);
} while (rc && dma_bits++ < max_dma_bits);
if (rc)
- panic(KERN_ERR "xen_create_contiguous_region failed\n");
+ panic(KERN_ERR "xen_create_contiguous_region failed:
rc: %d\n", rc);
i += slabs;
} while(i < nslabs);
And also ensure that your command line for Xen has: console=com1,vga
guest_loglvl=all
And tell me what environemtn you are using? Is the hypervisor a 64-bit
while dom0 is 32bit or 64bit? Is DomU 32bit or 64bit?
>
> > Or you can add 'iommu=off' to your boot arguments that should
> > disable the SWIOTLB.
>
> Is iommu=off for dom0 or domU boot args. If it's dom0, is it for the
> hypervisor or the kernel? I've tried adding it to all 3 places, but I
> still get the same panic message.
Well that is a surprise. My recollection of the code vs what is there
confirms that the code logic is a bit brute. It turns on SWIOTLB
irregardless of any flags you pass in. So nevermind the 'iommu=off'
attempt.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home