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
|