From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: vif backend configuration times out
Date: Thu, 9 Aug 2012 16:34:06 +0200 [thread overview]
Message-ID: <20120809143406.GA9317@aepfle.de> (raw)
In-Reply-To: <1344501152.32142.78.camel@zakaz.uk.xensource.com>
On Thu, Aug 09, Ian Campbell wrote:
> > 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.
>
> When you say "finally" do you mean that it takes an unusually long time?
'finally' is wrongly worded. It gets into state 2, I notice no delay.
> Is this kernel tree available somewhere convenient (i.e. which doesn't
> involves unpacking .src.rpms and applying patches etc).
Its available via git, see http://kernel.opensuse.org/git
The webui is here:
http://kernel.opensuse.org/cgit/kernel/tree/?h=SLE11-SP2
> I checked netback_probe in the linux-2.6.18-xen.hg tree (which I believe
> relates at least somewhat to the SLES kernel) and it switches to
> XenbusStateInitWait just before calling the function which triggers the
> hotplug script -- so libxl's behaviour of waiting for
> XenbusStateInitWait before running the hotplug scripts would seem to be
> correct. I couldn't find anything before this point which would cause
> the driver to block. So if your observation is that your kernel is
> blocking in state 1 or taking an inordinate amount of time to get to
> state 2 then that is what you need to dig into.
Indeed, netback_probe is appearently never called in my case. I will
check why that happens.
> Have you reinstalled your udev rules etc? They changed recently and I
> suspect they need to be up to date to work with the latest scripts.
> Although you don't appear to be getting to that point so I don't think
> it would matter (yet).
Its all coming from xen*.rpm packages, no manual install. The rules are
from xen-unstable.
> You didn't answer my question about error nodes in xenstore.
I dont see any error nodes in xenstore.
> You could, experimentally, try increasing LIBXL_INIT_TIMEOUT to some
> enormous time.
Thanks for the hint. I will see what I find.
Olaf
next prev parent reply other threads:[~2012-08-09 14:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-06 17:39 vif backend configuration times out Olaf Hering
2012-08-07 5:42 ` Ian Campbell
2012-08-07 15:25 ` Olaf Hering
2012-08-07 15:33 ` Ian Campbell
2012-08-08 17:28 ` Olaf Hering
2012-08-09 8:32 ` Ian Campbell
2012-08-09 14:34 ` Olaf Hering [this message]
2012-08-10 7:41 ` Olaf Hering
2012-08-10 12:59 ` Olaf Hering
2012-08-14 10:18 ` Ian Campbell
2012-08-14 11:30 ` Olaf Hering
2012-08-14 13:04 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120809143406.GA9317@aepfle.de \
--to=olaf@aepfle.de \
--cc=Ian.Campbell@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.