Re: Timing out waiting for vbd device *only when xend started with trace_start*

[Charles Duffy <cduffy@spamcop.net>]

[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]

Ewan Mellor wrote:
> This is showing up intermittently with our regression tests.  It seems to be a
> race of some sort, which would be consistent with it going away or coming back
> when you fiddle with the logging -- all you are doing is changing the timing
> of things so that it appears or does not appear.
> 
> If you export XENSTORED_TRACE=1 before starting Xend and Xenstored, then you
> will get a log file in /var/log/xenstored-trace.log.  This information is
> interesting to me, because it shows the ordering over time of the store
> events, which makes it easier to piece together what's going on.

It does indeed feel like a race condition. Unfortunetly, setting 
XENSTORED_TRACE impacts the timing such as to make it nonreproducible.

> Also, could you put a line in
> /usr/lib/python/xen/xend/server/DevController.py, to log entry into the
> hotplugStatus function (the syntax is log.debug("hotplugStatus entered"), and
> it goes below the def hotplugStatus(): line).

Done; xend.log attached. No xenstored.trace yet for the reason described 
above.

Since the issue appears to be happening when xend is running below full 
speed but xenstored is not, I'm wondering if some mechanism to 
artificially slow xend (running it in valgrind?) would be effective in 
permitting the issue to be reproduced with tracing in place on both 
processes. I'll look into it, unless you have other suggestions.

[-- Attachment #2: xend.log.bz2 --]
[-- Type: application/x-bzip2, Size: 2293 bytes --]

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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