This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] I cannot get any message from domU by console / pv_ops d

To: Michael D Labriola <mlabriol@xxxxxxxx>, Ian.Campbell@xxxxxxxxxx
Subject: Re: [Xen-devel] I cannot get any message from domU by console / pv_ops domU kernel crashes with xen_create_contiguous_region failed
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Tue, 22 Dec 2009 10:40:10 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, ?????? <peb1611@xxxxxxxxx>, xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 22 Dec 2009 07:48:54 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <OFA9DD0CBA.CD926D6D-ON85257694.0050EAF5-85257694.0053BB4E@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20091222143203.GA2785@xxxxxxxxxxxxxxxxxxx> <OFA9DD0CBA.CD926D6D-ON85257694.0050EAF5-85257694.0053BB4E@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.19 (2009-01-05)
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 
and Ian's is right. Under 4.0 it I've no trouble exchanging the MFNs even 
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 
                } 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 

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'

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>