--- zzzz-none-000/linux-2.6.28.10/mm/vmalloc.c	2009-05-02 18:54:43.000000000 +0000
+++ puma5-6360-529/linux-2.6.28.10/mm/vmalloc.c	2012-08-27 08:19:35.000000000 +0000
@@ -467,6 +467,8 @@
 
 static atomic_t vmap_lazy_nr = ATOMIC_INIT(0);
 
+static DEFINE_SPINLOCK(purge_lock);
+
 /*
  * Purges all lazily-freed vmap areas.
  *
@@ -480,7 +482,6 @@
 static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
 					int sync, int force_flush)
 {
-	static DEFINE_SPINLOCK(purge_lock);
 	LIST_HEAD(valist);
 	struct vmap_area *va;
 	struct vmap_area *n_va;
@@ -513,10 +514,8 @@
 	}
 	rcu_read_unlock();
 
-	if (nr) {
-		BUG_ON(nr > atomic_read(&vmap_lazy_nr));
+	if (nr)
 		atomic_sub(nr, &vmap_lazy_nr);
-	}
 
 	if (nr || force_flush)
 		flush_tlb_kernel_range(*start, *end);
@@ -557,10 +556,31 @@
  */
 static void free_unmap_vmap_area_noflush(struct vmap_area *va)
 {
+	spin_lock(&purge_lock);
 	va->flags |= VM_LAZY_FREE;
 	atomic_add((va->va_end - va->va_start) >> PAGE_SHIFT, &vmap_lazy_nr);
+	spin_unlock(&purge_lock);
+    //----------
+    //--BEGIN--HBL
+    // Auf Puma-Plattformen wird die if-Abfrage rausgenommen und
+    // 'try_purge_vmap_area_lazy' jedesmal ausgeführt.
+    // D.h IMMER wenn virt Speicher freigegeben wird, geschieht dies jetzt
+    // sofort (früher wurde die erst auf eine lazy-Liste geschrieben).
+    //
+    // Warum?
+    //   .bei den Puma-Plattformen gibt es einen Fehler der die 
+    //    Verwaltungsstrukturen des virtuellen Speichers überschreibt
+    //    -> resultiert in einem ungültigem Speicherzugriff in 'try_purge_vmap_area_lazy'
+    //
+    // Zweck?
+    //   .Übeltäter finden
+    //   .diese Maßnahme hier scheint den Fehler zu umgehen
+#ifndef CONFIG_ARCH_PUMA5
 	if (unlikely(atomic_read(&vmap_lazy_nr) > lazy_max_pages()))
+#endif /*--- #ifndef(CONFIG_PUMA5) ---*/
 		try_purge_vmap_area_lazy();
+    //--END--HBL
+    //----------
 }
 
 /*