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
|
Home