o Merge with Linux 2.1.116.

 o New Newport console code.
 o New G364 console code.

1 files changed, 9 insertions, 9 deletions

diff --git a/Documentation/exception.txt b/Documentation/exception.txt
index 0102bb615..ec8727e1b 100644
--- a/Documentation/exception.txt
+++ b/Documentation/exception.txt
@@ -14,12 +14,12 @@ addr and of size size was accessible for the operation specified
 in type (read or write). To do this, verify_read had to look up the 
 virtual memory area (vma) that contained the address addr. In the 
 normal case (correctly working program), this test was successful. 
-It only failed for the (hopefully) rare, buggy program. In some kernel 
-profiling tests, this normally unneeded verification used up a 
-considerable amount of time.
+It only failed for a few buggy programs. In some kernel profiling
+tests, this normally unneeded verification used up a considerable
+amount of time.
 
 To overcome this situation, Linus decided to let the virtual memory 
-hardware present in every Linux capable CPU handle this test.
+hardware present in every Linux-capable CPU handle this test.
 
 How does this work?
 
@@ -36,23 +36,23 @@ contains a reason code for the exception.
 
 do_page_fault first obtains the unaccessible address from the CPU 
 control register CR2. If the address is within the virtual address 
-space of the process, the fault probably occured, because the page 
-was not swapped in, write protected or something similiar. However, 
+space of the process, the fault probably occurred, because the page 
+was not swapped in, write protected or something similar. However, 
 we are interested in the other case: the address is not valid, there 
 is no vma that contains this address. In this case, the kernel jumps 
 to the bad_area label. 
 
 There it uses the address of the instruction that caused the exception 
-(i.e. regs->eip) to find an address where the excecution can continue 
+(i.e. regs->eip) to find an address where the execution can continue 
 (fixup). If this search is successful, the fault handler modifies the 
 return address (again regs->eip) and returns. The execution will 
 continue at the address in fixup.
 
 Where does fixup point to?
 
-Since we jump to the the contents of fixup, fixup obviously points 
+Since we jump to the contents of fixup, fixup obviously points 
 to executable code. This code is hidden inside the user access macros. 
-I have picked the get_user macro defined in include/asm/uacess.h as an
+I have picked the get_user macro defined in include/asm/uaccess.h as an
 example. The definition is somewhat hard to follow, so let's peek at 
 the code generated by the preprocessor and the compiler. I selected
 the get_user call in drivers/char/console.c for a detailed examination.