[Xen-devel] Re: Hot plug scripts not working c/s 19355

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

Dan Magenheimer wrote:
> Well I've been struggling with this on and off since Friday and
> am having major problems because there are now many parts that
> I'm no longer sure how to synchronize.  The tools now seem to
> be dependent on ioemu but I don't know how (or if its possible)
> to synchronize versions of the ioemu git tree with a specific
> xen hg changeset.  Rolling xen tools back to 19187 worked fine,
> but I couldn't roll the tools back to tip due to a compile error
>
> ioemu-dir/hw/pt-msi.c:95: error: too few arguments to xc_domain_update_msi_irq
>
> I did a git pull in ioemu-dir and no longer got the compile error
> but it didn't help (same hotplug problem) and now I can't rollback
> xen tools to 19187 because I get the opposite compile error.
> So my test machine, which HAD been working at least with tools 19187
> is now useless unless I solve the problem.
>   
Yeah, having xen-unstable in two different source systems is extremely 
brittle; I don't think its sustainable for much longer.
> (BTW, I tried reverting 19342 and it didn't solve the problem.)
>
> I was able to do a fresh tip build and install on a new test machine
> (that previously had no xen on it at all), so I suspect my problem was
> due to a mismatch between dom0 and "something else" so am now in the
> process of rebuilding dom0 from latest.
>
> Argh!  I thought bisecting was supposed to be easy!
>
> With so many interdependent parts (and two different change-tracking
> tools needed), perhaps its time to start being more careful about
> describing version interdependencies between them?
>
> Or maybe if I were sufficiently knowledgeable about both mercurial
> and git, this wouldn't be a problem?
No, its all a big pain, especially since there are multiple bugs with 
similar symptoms.
There was the original hotplug script bug in xen-unstable, which now 
appears to be fixed.
There was also a pvops dom0 bug, which turned out to be an upstream bug 
in vsprintf()'s handling of "%.*s", which is also now fixed.
And there may well be some other bugs...

   J

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