--- /dev/null
+
+# HG changeset patch
+# User Olaf Hering <olaf@aepfle.de>
+# Date 1350549301 -3600
+# Node ID b3b03536789abbf2c4b7d62377034c1f14c6340c
+# Parent 019ca95dfa34efc71b1707f785b5112573e7d02e
+hotplug/Linux: close lockfd after lock attempt
+
+When a HVM guest is shutdown some of the 'remove' events can not claim
+the lock for some reason. Instead they try to grab the lock in a busy
+loop, until udev reaps the xen-hotplug-cleanup helper.
+After analyzing the resulting logfile its not obvious what the cause is.
+The only explanation is that bash (?) gets confused if the same lockfd
+is opened again and again. Closing it in each iteration seem to fix the
+issue.
+
+This was observed with sles11sp2 (bash 3.2) and 4.2 xend.
+
+Signed-off-by: Olaf Hering <olaf@aepfle.de>
+Acked-by: Ian Campbell <Ian.campbell@citrix.com>
+[ ijc -- added the comment ]
+Committed-by: Ian Campbell <ian.campbell@citrix.com>
+
+diff -r 019ca95dfa34 -r b3b03536789a tools/hotplug/Linux/locking.sh
+--- a/tools/hotplug/Linux/locking.sh Thu Oct 18 09:35:00 2012 +0100
++++ b/tools/hotplug/Linux/locking.sh Thu Oct 18 09:35:01 2012 +0100
+@@ -59,6 +59,9 @@ claim_lock()
+ print "y\n" if $fd_inum eq $file_inum;
+ ' "$_lockfile" )
+ if [ x$rightfile = xy ]; then break; fi
++ # Some versions of bash appear to be buggy if the same
++ # $_lockfile is opened repeatedly. Close the current fd here.
++ eval "exec $_lockfd<&-"
+ done
+ }
+
+
Patch10: xen-quemu-softloat-c99.patch
Patch11: xen-qemu.patch
Patch12: xen-scripts-locking.patch
+Patch13: xen-close_lockfd_after_lock_attempt.patch
URL: http://www.xen.org/products/xenhyp.html
%{?with_opengl:BuildRequires: OpenGL-devel}
%{?with_sdl:BuildRequires: SDL-devel >= 1.2.1}
%patch10 -p1
%patch11 -p1
%patch12 -p1
+%patch13 -p1
# stubdom sources
ln -s %{SOURCE10} %{SOURCE11} %{SOURCE12} %{SOURCE13} %{SOURCE14} stubdom