3 files changed, 23 insertions, 23 deletions
diff --git a/tests/checkfs/README b/tests/checkfs/README
index d9966a5..6b72487 100644
--- a/tests/checkfs/README
+++ b/tests/checkfs/README
@@ -11,11 +11,11 @@ This is the README file for the "checkfs" power fail test program.
 By: Vipin Malik
 
 NOTE: This program requires an external "power cycling box"
-connected to one of the com ports of the system under test. 
-This power cycling box should wait for a random amount of time 
-after it receives a "ok to power me down" message over the 
+connected to one of the com ports of the system under test.
+This power cycling box should wait for a random amount of time
+after it receives a "ok to power me down" message over the
 serial port, and then yank power to the system under test.
-(The box that I rigged up tested with waits anywhere from 
+(The box that I rigged up tested with waits anywhere from
 0 to ~40 seconds).
 
 
@@ -75,7 +75,7 @@ some "sister" files on the root fs even though "checkfs" would
 run fine through all its own check files.
 
 (I found this out when one of the clobbered sister file happened
-to be /bin/bash. The system refused to run rc.local thus 
+to be /bin/bash. The system refused to run rc.local thus
 preventing my "checkfs" program from being launched :)
 
 "checkfs":
@@ -98,8 +98,8 @@ Each file has a random number of bytes in it (set by using the
 first "int" in it (note: 0 length files are not allowed). Each file
 is then filled with random data and a 16 bit CRC appended at the end.
 
-When "checkfs" is run, it runs through all files (with predetermined 
-file names)- one at a time- and checks for the number of "int's" 
+When "checkfs" is run, it runs through all files (with predetermined
+file names)- one at a time- and checks for the number of "int's"
 in it as well as the ending CRC.
 
 The program exits if the numbers of files that are corrupt are greater
@@ -116,10 +116,10 @@ the data reliability of "other" files present of the fs, use -e 1.
 "other" files are defined as sister files on the fs, not being written to
 by the "checkfs" test program.
 
-As mentioned, in this case you would set -e 1, or allow at most 1 file 
-to be corrupt each time after a power fail. This would be the file 
-that was probably being written to when power failed (and CRC was not 
-updated to reflect the  new data being written). You would check file 
+As mentioned, in this case you would set -e 1, or allow at most 1 file
+to be corrupt each time after a power fail. This would be the file
+that was probably being written to when power failed (and CRC was not
+updated to reflect the  new data being written). You would check file
 systems like ext2 etc. with such a configuration.
 (As you have no hope that these file systems provide for either your
 new data or old data to be present in the file if power failed during
@@ -137,13 +137,13 @@ In other words, JFFS2 will partially update a file on FLASH even before
 the write() command has completed, thus leaving part old data part new
 data in your file if power failed in the middle of a write().
 
-This is bad functionality if you are updating a binary structure or a 
+This is bad functionality if you are updating a binary structure or a
 CRC protected file (as in our case).
 
 
 If All Files Check Out OK:
 
-On the startup scan, if there are less errors than specified by the "-e flag" 
+On the startup scan, if there are less errors than specified by the "-e flag"
 a "ok to power me down message" is sent via the specified com port.
 
 The actual format of this message will depend on the format expected
diff --git a/tests/jittertest/README b/tests/jittertest/README
index f411a2c..b97a8b7 100644
--- a/tests/jittertest/README
+++ b/tests/jittertest/README
@@ -11,7 +11,7 @@ a real time task under Linux with background
 JFFS file system activity.
 
 The jitter is measured in milli seconds (ms) from
-the expected time of arrival of a signal from a 
+the expected time of arrival of a signal from a
 periodic timer (set by the task) to when the
 task actually gets the signal.
 
@@ -20,7 +20,7 @@ This jitter is then stored in a file specified
 
 The data  may also be sent out to the console by
 writing to /dev/console (See help options. This is
-highly desirable specially if you have redirected 
+highly desirable specially if you have redirected
 your console to the serial port and are storing it
 as a minicom log on another computer for later analysis
 using some tools provided here).
@@ -82,7 +82,7 @@ supports it).
   In this test you would generate some background
 write/erase type activity that would generate
 chip erases. Since this program is reading from
-the same file system, you contrast the latencies 
+the same file system, you contrast the latencies
 with those obtained with writes going to the same
 fs.
 
@@ -90,7 +90,7 @@ fs.
 file system:
 
   Here you would test for latencies experienced by
-a program if it were writing (and optionally also 
+a program if it were writing (and optionally also
 reading) from a JFFS fs.
 
 
@@ -99,7 +99,7 @@ reading) from a JFFS fs.
 Grabing a kernel profile:
 
 This program can also conditionally grab a kernel profile.
-Specify --grab_kprofile on the cmd line as well as 
+Specify --grab_kprofile on the cmd line as well as
 a "threshold" parameter (see help options by -?).
 
 Any jitter greater than this "threshold" will cause the
@@ -119,10 +119,10 @@ when you boot the kernel if you want to use this functionality.
 
 Signalling the JFFS[2] GC task:
 
-You can also force this program to send a SIGSTOP/SIGCONT to the 
+You can also force this program to send a SIGSTOP/SIGCONT to the
 JFFS (or JFFS2) gc task by specifing --siggc <pid> on the cmd line.
 
-This will let you investigate the effect of forcing the gc task to 
+This will let you investigate the effect of forcing the gc task to
 wake up and do its thing when you are not writing to the fs and to
 force it to sleep when you want to write to the fs.
 
@@ -130,7 +130,7 @@ These are just various tools to investigate the possibility of
 achieving minimal read/write latency when using JFFS[2].
 
 You need to manually do a "ps aux" and look up the PID of the gc
-thread and provide it to the program. 
+thread and provide it to the program.
 
 
 
@@ -156,7 +156,7 @@ console log or printk data).
 
 You can then run this saved console log through this program and it
 will output a very nice text file with the %fill in one col and
-corrosponding jitter values in the second. gnuplot then does a 
+corrosponding jitter values in the second. gnuplot then does a
 beautifull plot of this resulting file showing you graphically the
 jitters encountered at different fill % of your JFFS[2] fs.
 
diff --git a/tests/jittertest/filljffs2.sh b/tests/jittertest/filljffs2.sh
index 10651f4..d8c2a83 100644
--- a/tests/jittertest/filljffs2.sh
+++ b/tests/jittertest/filljffs2.sh
@@ -8,7 +8,7 @@
 while [ $(( 1 )) -gt $(( 0 )) ]
 do
    cp $1 $2
-   rm $2 
+   rm $2
    df |grep mtd > /dev/console
    echo "sleeping $3"
    sleep $3