diff --git a/lvm2-2_02_99-fire-pvscan-cache-on-change-event-for-md-devs.patch b/lvm2-2_02_99-fire-pvscan-cache-on-change-event-for-md-devs.patch
new file mode 100644
index 0000000..bb1e09e
--- /dev/null
+++ b/lvm2-2_02_99-fire-pvscan-cache-on-change-event-for-md-devs.patch
@@ -0,0 +1,50 @@
+commit 2ac217d408470dcecb69b83d9cbf7a254747fa5b
+Author: Peter Rajnoha <prajnoha@redhat.com>
+Date:   Fri May 3 13:20:07 2013 +0200
+
+    udev: fire pvscan --cache properly on CHANGE event for MD devices
+    
+    Commit 756bcabbfe297688ba240a880bc2b55265ad33f0 restricted the
+    situations at which the LVM autoactivation fires - only on ADD
+    event for devices other than DM. However, this caused a problem
+    for MD devices...
+    
+    MD devices are activated in a very similar way as DM devices:
+    the MD dev is created on first appeareance of MD array member
+    (ADD event) and stays *inactive* until the array is complete.
+    Just then the MD dev turns to active state and this is reported
+    to userspace by CHANGE event.
+    
+    Unfortunately, we can't differentiate between the CHANGE event
+    coming from udev trigger/WATCH rule and CHANGE event coming from
+    the transition to active state - MD would need to add similar logic
+    we already use to detect this in DM world. For now, we just have
+    to enable pvscan --cache on *all* CHANGE events for MD so the
+    autoactivation of the LVM volumes on top of MD works.
+    
+    A downside of this is that a spurious CHANGE event for MD dev
+    can cause the LVM volumes on top of it to be automatically activated.
+    However, one should not open/change the device underneath until
+    the device above in the stack is removed! So this situation should
+    only happen if one opens the MD dev for read-write by mistake
+    (and hence firing the CHANGE event because of the WATCH udev rule),
+    or if calling udev trigger manually for the MD dev.
+    
+    (No WHATS_NEW here as this fixes the commit mentioned
+    above and which has not been released yet.)
+---
+ udev/69-dm-lvm-metad.rules.in | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/udev/69-dm-lvm-metad.rules.in b/udev/69-dm-lvm-metad.rules.in
+index 66c58b3..a0e48a1 100644
+--- a/udev/69-dm-lvm-metad.rules.in
++++ b/udev/69-dm-lvm-metad.rules.in
+@@ -21,6 +21,7 @@ SUBSYSTEM!="block", GOTO="lvm_end"
+ ENV{ID_FS_TYPE}!="LVM2_member|LVM1_member", GOTO="lvm_end"
+ 
+ ACTION=="remove", GOTO="lvm_scan"
++ACTION=="change", KERNEL=="md[0-9]*", GOTO="lvm_scan"
+ 
+ # If the PV is not a dm device, scan only after device addition (ADD event)
+ KERNEL!="dm-[0-9]*", ACTION!="add", GOTO="lvm_end"
diff --git a/lvm2.spec b/lvm2.spec
index 0a98d12..34f642b 100644
--- a/lvm2.spec
+++ b/lvm2.spec
@@ -37,7 +37,7 @@
 Summary: Userland logical volume management tools 
 Name: lvm2
 Version: 2.02.98
-Release: 7%{?dist}
+Release: 8%{?dist}
 License: GPLv2
 Group: System Environment/Base
 URL: http://sources.redhat.com/lvm2
@@ -57,6 +57,7 @@ Patch11: lvm2-2_02_99-skip-mlocking-verctors-on-arm-arch.patch
 Patch12: lvm2-2_02_99-fix-autoactivation-to-not-autoactivate-vg-lv-on-each-pv-change.patch
 Patch13: lvm2-2_02_99-synchronize-with-udev-in-pvscan-cache-and-fix-dangling-udev_sync-cookies.patch
 Patch14: lvm2-2_02_99-also-autoactivate-on-coldplug.patch
+Patch15: lvm2-2_02_99-fire-pvscan-cache-on-change-event-for-md-devs.patch
 
 BuildRequires: libselinux-devel >= %{libselinux_version}, libsepol-devel
 BuildRequires: ncurses-devel
@@ -106,6 +107,7 @@ or more physical volumes and creating one or more logical volumes
 %patch12 -p1 -b .autoactivation
 %patch13 -p1 -b .dangling_cookies
 %patch14 -p1 -b .coldplug
+%patch15 -p1 -b .autoactivation_on_md
 
 %build
 %define _default_pid_dir /run
@@ -602,6 +604,9 @@ the device-mapper event library.
 %{_libdir}/pkgconfig/devmapper-event.pc
 
 %changelog
+* Fri May 03 2013 Peter Rajnoha <prajnoha@redhat.com> - 2.02.98-8
+- Fix non-functional autoactivation of LVM volumes on top of MD devices.
+
 * Fri Apr 19 2013 Peter Rajnoha <prajnoha@redhat.com> - 2.02.98-7
 - Autoactivate VG/LV on coldplug of DM-based PVs at boot.