diff --git a/testcases/kernel/hotplug/cpu_hotplug/doc/hotplug05.txt b/testcases/kernel/hotplug/cpu_hotplug/doc/hotplug05.txt
index 26fd5961245..67f8198d91a 100644
--- a/testcases/kernel/hotplug/cpu_hotplug/doc/hotplug05.txt
+++ b/testcases/kernel/hotplug/cpu_hotplug/doc/hotplug05.txt
@@ -1,35 +1,29 @@
-# Test Case 5 - Pseudocode
+Testcase 05
+-----------
 
-# This test looks for memory leaks or deadlocks
+It's been found that sometimes onlining and offlining CPUs confuse some
+of the various system tools.  We found that sar wouldn't register the change
+in newly available cpus that weren't there when it started. This
+test case seeks to exercise this known error cases and verify that
+they behave correctly now.
 
-# "mm_struct slab leak (affected only some architectures)"
+Algorithm - Sar
+===============
+Given a CPU to test that exists
 
-INTERVAL=30
-THRESHHOLD='xxx'
+Make sure the specified cpu is offline
 
-# TODO:  Start monitoring memory usage via vmstat and sar
+Loop until done:
+  Start up sar writing to a temp log and give it a little time to run
 
-# TODO:  Start dbt2, running for at least 4 hours
+  Verify that SAR has correctly displayed all fields of CPU statistics
+  as '0.00' for the offlined CPU or just not displayed it in its tmp log
 
-while [ 1 ]; do
-    last if workload has completed
+  Online the specified cpu
 
-    select a cpu at random
-    if cpu is online
-        offline it
-    else
-        online it
-    fi
+  Take another timestamp and another count of offlined CPUs
 
-    measure current throughput
-    # TODO:  Mary and Mark will better define how to detect
-    # the threshhold and what to do in response
-    if [ throughput falls below $THRESHHOLD ]; then
-        echo "Throughput has fallen below threshhold."
-    fi
+  Verify SAR registered the change in CPU online/offline states
 
-    sleep $INTERVAL
-done
-
-# Analyze system statistics to determine memory leaks
-# Analyze drops in activities
+When exiting:
+  Kill the sar process
diff --git a/testcases/kernel/hotplug/cpu_hotplug/doc/hotplug06.txt b/testcases/kernel/hotplug/cpu_hotplug/doc/hotplug06.txt
index 0cccc871c9b..d7d6c181426 100644
--- a/testcases/kernel/hotplug/cpu_hotplug/doc/hotplug06.txt
+++ b/testcases/kernel/hotplug/cpu_hotplug/doc/hotplug06.txt
@@ -2,11 +2,9 @@ Testcase 06
 -----------
 
 It's been found that sometimes onlining and offlining CPUs confuse some
-of the various system tools.  In particular, we found it caused top to
-crash, and found that sar wouldn't register newly available cpus that
-weren't there when it started.  This test case seeks to exercise these
-known error cases and verify that they behave correctly now.
-
+of the various system tools.  We found it caused top to
+crash.  This test case seeks to exercise this known error cases and
+verify that they behave correctly now.
 
 Algorithm - Top
 ===============
@@ -29,28 +27,3 @@ When exiting:
   Restore all CPUs to their initial state
 
 
-Algorithm - Sar
-===============
-Given a CPU to test that exists
-
-Make sure the specified cpu is offline
-
-Loop until done:
-  Start up sar writing to a temp log and give it a little time to run
-
-  Verify that SAR has correctly listed the missing CPU as 'nan' in its
-  tmp log
-
-  Take a timestamp and count how many CPUs sar is reporting to be
-  offline
-
-  Online the specified cpu
-
-  Take another timestamp and another count of offlined CPUs.
-
-  Verify that the number of CPUs offline has changed
-
-When exiting:
-  Kill the sar process
-
-