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
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
Xen-devel mailing list