Hello Xen community, This is my first time reporting a bug, so please let me know if I make any faux-pas so that I may correct them in the future. I checked out Xen-4.1-testing from the Mercurial repository on Wednesday (4/25/12) and attempted to compile it with "make world" on a machine running a recent install of Debian 6 (squeeze) and encountered an error described in the following text (tail-end of stderr): ... git clone git://xenbits.xensource.com/qemu-xen-4.1-testing.git ioemu-remote.tmp Cloning into ioemu-remote.tmp... remote: Counting objects: 80598, done. remote: Compressing objects: 100% (22869/22869), done. remote: Total 80598 (delta 60933), reused 76719 (delta 57621) Receiving objects: 100% (80598/80598), 29.20 MiB | 6.08 MiB/s, done. Resolving deltas: 100% (60933/60933), done. + [ a2d2123a7dfc4d116011d51f48df786a3b853537 ] + cd ioemu-remote.tmp + git branch -D dummy + : + git checkout -b dummy a2d2123a7dfc4d116011d51f48df786a3b853537 fatal: reference is not a tree: a2d2123a7dfc4d116011d51f48df786a3b853537 make[1]: *** [ioemu-dir-find] Error 128 make[1]: Leaving directory `/home/misiu/Xen/xen-4.1-testing.hg/tools'' make: *** [tools/ioemu-dir] Error 2 I later determined that the error could be isolated within "make tools" Curiously, I was able to checkout and compile code from the same repository the previous day (4/24/12) on the same machine without any problems. I have not managed to find any previous bug or configuration problems that quite match up to this, but I did notice that there was a single revision to the repository between these two periods. The revision in question can be found at "xenbits.xen.org/hg/xen-4.1-testing.hg/rev/99517f769cc8" and specifically refers to the area in question (QEMU git access). I have now attempted to compile the current (4/25/12) release of 4.1-testing on two different machines, both running Debian 6, and obtained the same results (shown above). I hope I have provided enough information to address the situation and if, to my embarrassment, it turns out to be an issue on my end I would appreciate advice as to how to overcome the problem. Thanks, Misiu. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Thu, 2012-04-26 at 17:38 +0100, misiu godfrey wrote:> Hello Xen community, > > This is my first time reporting a bug, so please let me know if I make > any faux-pas so that I may correct them in the future. > > I checked out Xen-4.1-testing from the Mercurial repository on > Wednesday (4/25/12)Are you using the staging or non-staging version? What was the exact URL you cloned? [...]> + git checkout -b dummy a2d2123a7dfc4d116011d51f48df786a3b853537 > fatal: reference is not a tree: > a2d2123a7dfc4d116011d51f48df786a3b853537This seems to be there now and it "works for me" (tm). Might just have been skew with the staging tree -- can you try again? Ian.
On Fri, Apr 27, 2012 at 8:23 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:> Are you using the staging or non-staging version? What was the exact URL> you cloned? >I have, to my knowledge, been using the non-staging version. The exact URL I have been cloning is: " http://xenbits.xen.org/hg/xen-4.1-testing.hg"> > [...] > > + git checkout -b dummy a2d2123a7dfc4d116011d51f48df786a3b853537 > > fatal: reference is not a tree: > > a2d2123a7dfc4d116011d51f48df786a3b853537 > > This seems to be there now and it "works for me" (tm). Might just have > been skew with the staging tree -- can you try again? >I just re-ran "make world" on both of my machines to the same erroneous result. Specifically, I am running two Debian 6 machines, one of which is in a VMware virtual machine running over Windows 7 (for testing), and the other is a Sun Ultra 40. Misiu. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Fri, 2012-04-27 at 16:58 +0100, misiu godfrey wrote:> > > On Fri, Apr 27, 2012 at 8:23 AM, Ian Campbell > <Ian.Campbell@citrix.com> wrote: > > > Are you using the staging or non-staging version? What was > the exact URL > > you cloned? > > > I have, to my knowledge, been using the non-staging version. > The exact URL I have been cloning is: > "http://xenbits.xen.org/hg/xen-4.1-testing.hg"That is the non-staging tree, good.> [...] > > + git checkout -b dummy > a2d2123a7dfc4d116011d51f48df786a3b853537 > > fatal: reference is not a tree: > > a2d2123a7dfc4d116011d51f48df786a3b853537 > > > This seems to be there now and it "works for me" (tm). Might > just have > been skew with the staging tree -- can you try again? > > > I just re-ran "make world" on both of my machines to the > same erroneous result. Specifically, I am running two Debian 6 > machines, one of which is in a VMware virtual machine running over > Windows 7 (for testing), and the other is a Sun Ultra 40.I use Debian 6 too, without issue, so I surmise this isn''t a git issue. If you cd into the ioemu-remote dir then what do: git show a2d2123a7dfc4d116011d51f48df786a3b853537 git show origin/master say? What happens if you then run "git fetch origin" in that dir? From the top-level what does "make tools/ioemu-dir-force-update" do? Last resort you could try nuking the ioemu-remote dir and rebuilding. Ian.
From: misiu godfrey <misiu.godfrey@gmail.com> Date: Fri, 27 Apr 2012 12:41:28 -0400 Subject: Re: [Xen-devel] Xen-4.1-testing fails to "make tools" To: Ian Campbell <Ian.Campbell@citrix.com> On 4/27/12, Ian Campbell <Ian.Campbell@citrix.com> wrote:> > If you cd into the ioemu-remote dir then what do: > git show a2d2123a7dfc4d116011d51f48df786a3b853537 > git show origin/master > say?For the following results I assume "ioemu-remote dir" refers to "ioemu-remote.tmp, as there is no such directory "ioemu-remote" present. My file listing is as shown: root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg/tools# ls blktap debugger include libxen ocaml security vtpm_manager xenpaging xm-test blktap2 examples ioemu-remote.tmp libxl pygrub sv xcutils xenpmd check firmware libaio Makefile python tests xenbackendd xenstat console flask libfsimage memshr remus vnet xenballoon xenstore cross-install hotplug libxc misc Rules.mk vtpm xenmon xentrace root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg/tools# cd ioemu-remote.tmp/ root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg/tools/ioemu-remote.tmp# git show a2d2123a7dfc4d116011d51f48df786a3b853537 fatal: bad object a2d2123a7dfc4d116011d51f48df786a3b853537 root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg/tools/ioemu-remote.tmp# git show origin/master commit 06d2e688405932841e9a1c27e2eaaef315298a66 Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Date: Thu Mar 1 18:58:27 2012 +0000 qemu-xen: ignore console disconnect events for console/0 The first console has a different location compared to other PV devices (console, rather than device/console/0) and doesn''t obey the xenstore state protocol. We already special case the first console in con_init and con_initialise, we should also do it in con_disconnect. This patch should be applied to 4.1 too. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> (cherry picked from commit 2503d4d5a29e7af8dffd1e11229e11c1917d2ccf) diff --git a/hw/xen_console.c b/hw/xen_console.c index 0a2374c..f036b8d 100644 --- a/hw/xen_console.c +++ b/hw/xen_console.c @@ -253,6 +253,8 @@ static void con_disconnect(struct XenDevice *xendev) { struct XenConsole *con = container_of(xendev, struct XenConsole, xendev); + if (!xendev->dev) + return; if (con->chr) qemu_chr_add_handlers(con->chr, NULL, NULL, NULL, NULL); xen_be_unbind_evtchn(&con->xendev); (END)> What happens if you then run "git fetch origin" in that dir?"git fetch origin" seems to complete without any feedback, as shown: root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg/tools/ioemu-remote.tmp# git fetch origin root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg/tools/ioemu-remote.tmp#> From the top-level what does "make tools/ioemu-dir-force-update" do?root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg# make tools/ioemu-dir-force-update make -C tools ioemu-dir-force-update make[1]: Entering directory `/home/misiu/Xen/xen-4.1-testing.hg/tools'' set -ex; \ if [ "a2d2123a7dfc4d116011d51f48df786a3b853537" ]; then \ cd ioemu-remote; \ git fetch origin; \ git reset --hard a2d2123a7dfc4d116011d51f48df786a3b853537; \ fi + [ a2d2123a7dfc4d116011d51f48df786a3b853537 ] + cd ioemu-remote cd: 1: can''t cd to ioemu-remote make[1]: *** [ioemu-dir-force-update] Error 2 make[1]: Leaving directory `/home/misiu/Xen/xen-4.1-testing.hg/tools'' make: *** [tools/ioemu-dir-force-update] Error 2 root@godfrey2:/home/misiu/Xen/xen-4.1-testing.hg#> Last resort you could try nuking the ioemu-remote dir and rebuilding.I removed the ioemu-remote.tmp dir and remade to the same result. Misiu.
(readding xen-devel, please watch the CC lines) On Fri, 2012-04-27 at 17:41 +0100, misiu godfrey wrote:> On 4/27/12, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > > > If you cd into the ioemu-remote dir then what do: > > git show a2d2123a7dfc4d116011d51f48df786a3b853537 > > git show origin/master > > say?[...] Thanks for all that. I''ve just thought to actually check the staging vs. regular trees: http://xenbits.xen.org/gitweb/?p=staging/qemu-xen-4.1-testing.git;a=summary http://xenbits.xen.org/gitweb/?p=qemu-xen-4.1-testing.git;a=summary and it turns out that the regular tree is lagging behind the staging one, including the very commits in question, sorry for not looking at this sooner. These aren''t supposed to get out of sync with the main repos, so clearly something is up. I''ve CC''d Ian Jackson who looks after this stuff but unfortunately he''s on vacation until some time late next week. As a workaround you could set QEMU_REMOTE in .config (or edit Config.mk) to refer to git://xenbits.xensource.com/staging/qemu-xen-4.1-testing.git instead of the non-staging version. Ian.
On Fri, Apr 27, 2012 at 2:16 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:> > > > As a workaround you could set QEMU_REMOTE in .config (or edit Config.mk) > > to refer to git://xenbits.xensource.com/staging/qemu-xen-4.1-testing.git > > instead of the non-staging version. > >I have implemented the workaround and everything is compiling fine so far as I can see. Thanks for your help, and I will keep an eye out for some sort of re-synch in the future. Misiu. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Ian Campbell writes ("Re: [Xen-devel] Xen-4.1-testing fails to "make
tools""):> I''ve just thought to actually check the staging vs. regular trees:
> http://xenbits.xen.org/gitweb/?p=staging/qemu-xen-4.1-testing.git;a=summary
> http://xenbits.xen.org/gitweb/?p=qemu-xen-4.1-testing.git;a=summary
> and it turns out that the regular tree is lagging behind the staging
> one, including the very commits in question, sorry for not looking at
> this sooner.
This is a snafu of some kind on my part.
The qemu-xen-* trees aren''t supposed to have separate push gates and
the staging trees for them are a leftover wart. However I seem to
have accidentally pushed some changesets to staging instead of main.
I have now fixed this by pushing the missing changesets. In the
future I think I will try to retire the staging trees entirely.
Ian.