| On Mon, Nov 14, 2005 at 11:51:08AM +0000, Ewan Mellor wrote:
> On Mon, Nov 14, 2005 at 05:31:00AM -0600, Charles Duffy wrote:
> 
> > Since this issue was obviously happening only for me, I went looking for 
> > potential causes specific to my configuration.
> > 
> > My init scripts start xend with trace_start.
> > 
> > I backed this out (to just use "start"), rebooted, and everything came 
> > up normally. Rebooted again, likewise. Changed it back to trace_start, 
> > rebooted again, same failure as described in the thread this should be 
> > attached to. Changed it to start again, works.
> > 
> > So -- for the initial issue, I have a workaround by way of avoiding 
> > trace_start, but I'd argue that it's quite certainly a bug that 
> > trace_start has side effects of this variety. Should I file a bug, or 
> > does someone else have it?
> 
> 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.
I found it.  xs_watch is racing with xs_read_watch, meaning that the watch can
fire before xs_watch has put the appropriate entry in its internal lists.
A patch is being tested at the moment, and will push today.
This is the bug affecting Charles Duffy, Friedmund Lassmann, and Hien Nguyen
(bug #392).
This has been in the code since early September -- it is only now that we are
using watches in Xend to check for hotplug success or failure that it has
become apparent.
Ewan.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
 |