Re: [Xen-devel] I cannot get any message from domU by console / pv_ops domU kernel crashes with xen_create_contiguous_region failed

[Michael D Labriola <mlabriol@xxxxxxxx>]

xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 12/22/2009 04:49:25 PM:

> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote on 12/22/2009 
> 03:37:09 PM:
> 
> > On Tue, Dec 22, 2009 at 03:07:21PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > A also can't seem to pass devices through (unless I'm doing it 
> wrong). 
> > > > When trying to pass my soundcard do the domU, it appears to be 
> > > > appropriately hidden from dom0 via xen-pciback.hide kernel param 
> > > > (/var/log/messages says 'pciback 0000:00:1b.0: seizing device') 
> > but when I 
> > > > try to start my domU with iommu=soft and pci=["00:1b.0"] I get 
> adozen or 
> > > 
> > > You are doing it right.
> > > 
> > > > so "BUG: scheduling while atomic" messages w/ call traces.  My 
domU 
> > > > eventually starts up ok, but lspci returns with no output.
> > > 
> > > Hmm, I wonder if this patch is in your tree:
> > > 
> > > commit 1aa61698354ca0582b07eb865e0432a13b459f11
> > > Author: Ian Campbell <ian.campbell@xxxxxxxxxx>
> > > Date:   Thu Dec 17 14:08:25 2009 +0000
> > > 
> > >     xen: fix hang on suspend.
> > > 
> > > and causing this (or maybe the pciback driver is the culprit and
> > > the above patch exposes a bug?).
> > 
> > Bummer. Can't blame Ian for it :-(
> > 
> > I updated dom0 with that patch and I am not seeing the failure you 
> described.
> 
> Yes, I have that commit too.
> 
> 
> > 
> > > 
> > > Try reverting that patch and seeing what happens. I the meantime let
> > > me compile a new Dom0 with the above mentioned commit and see if I 
get
> > > the failure too.
> > 
> > Instead of that recommendation try enabling debug options. You can do 
> this
> > the manual way:
> > 
> > diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
> > index cc3b51b..ae1648a 100644
> > --- a/drivers/pci/xen-pcifront.c
> > +++ b/drivers/pci/xen-pcifront.c
> > @@ -30,7 +30,7 @@
> >  #define INVALID_GRANT_REF (0)
> >  #define INVALID_EVTCHN    (-1)
> > 
> > -
> > +#define DEBUG 1
> >  struct pci_bus_entry {
> >     struct list_head list;
> >     struct pci_bus *bus;
> > diff --git a/drivers/xen/blkback/blkback.c 
> b/drivers/xen/blkback/blkback.c
> > index 815c0c6..a871a2c 100644
> > --- a/drivers/xen/blkback/blkback.c
> > +++ b/drivers/xen/blkback/blkback.c
> > @@ -64,7 +64,7 @@ MODULE_PARM_DESC(reqs, "Number of blkback requests
> > to allocate");
> > 
> >  /* Run-time switchable: /sys/module/blkback/parameters/ */
> >  static unsigned int log_stats = 0;
> > -static unsigned int debug_lvl = 0;
> > +static unsigned int debug_lvl = 1;
> >  module_param(log_stats, int, 0644);
> >  module_param(debug_lvl, int, 0644);
> > 
> > 
> > Or fiddle with the debug_lvl in /sys/ namespace. 
> > 
> > That might shed some light on what is happening. Also do provide the
> > output of Dom0, DomU and the lspci -vvv in Dom0 please.
> > 
> 
> Recompiled with debug turned on as shown.  Attached /var/log/messages 
from 
> dom0 and domU, lscpi output, and my kernel .config.
> 
> Any chance it's PREEMPT related?

Turning PREEMPT off entirely made all the "scheduling while atomic" 
messages on dom0 go away.

With our witout PREEMPT, I can successfully pass PCI devices to an old 
2.6.18-xen domU as long as the devices are page-aligned.  I only can't 
pass PCI devices into pv_ops domUs.  Is the PCI frontend code even in 
xen/master?

-Mike

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel