Re: vif backend configuration times out

[Olaf Hering <olaf@aepfle.de>]

On Tue, Aug 07, Ian Campbell wrote:

> On Tue, 2012-08-07 at 16:25 +0100, Olaf Hering wrote:
> > On Tue, Aug 07, Ian Campbell wrote:
> > 
> > > On Mon, 2012-08-06 at 18:39 +0100, Olaf Hering wrote:
> > > > With current xen-unstable 25733:353bc0801b11 the attached hvm.cfg does
> > > > not start anymore with a SLES11SP2 dom0 kernel, but it starts if I run a
> > > > 3.5 pvops dom0 kernel. I have no modifications other than the stubdom -j
> > > > patch.
> > > > 
> > > > The output from this command is attached:
> > > > xl -vvvv create -d -f /root/xenpaging/sles11sp2_full_xenpaging_local.cfg 2>&1 | tee xl-create-`uname -r`.txt &
> > > > 
> > > > Any ideas how to fix this timeout error?
> > > 
> > > The tools are waiting for the backend to move from state 1
> > > (XenbusStateInitialising) to state 2 (XenbusStateInitWait). A backend
> > > driver typically makes that transition at the end of its probe function
> > > -- what is the SLES11SP2 netback waiting for? Or is it failing to init,
> > > in which case perhaps there is an error node in XS?
> > 
> > I think there is a difference between the two kernels. The pvops kernel
> > goes into state 2 right away (I cant tell from repeated xenstore-ls runs
> > if it had also state 1).
> > The sles11 kernel remains in state 1.
> 
> What is it waiting for?

I have no idea, have to browse code debug it.
A quick test with plain sles11sp2+xend and xm start -p shows that
/local/domain/0/backend/vif/1/0/state finally gets into state 2.

Looks like something to fix before 4.2.


> >  Did the expectations of libxl
> > change recently? xl create used to work not too long ago.
> 
> I don't think the expectation has changed but the implementation is
> probably more picky since Roger's hotplug patches.
> 
> > xm does not work either, so the change is most likely in the scripts.
> 
> If you are switching from xl to xm then you should either reboot or
> remove libxl/disable_udev in xenstore manually.
> 
> Other than that nor much has changed in the scripts either. Are you sure
> it isn't the kernel which has changed?

The kernel is ok.

Olaf