diff --git a/en_US.ISO8859-1/books/arch-handbook/pccard/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/pccard/chapter.sgml
index 4416a729c8..645d78ddfc 100644
--- a/en_US.ISO8859-1/books/arch-handbook/pccard/chapter.sgml
+++ b/en_US.ISO8859-1/books/arch-handbook/pccard/chapter.sgml
@@ -27,7 +27,7 @@
 
       <para>PC Cards are identified in one of two ways, both based on
       information in the CIS of the card.  The first method is to use
-      numberic manufacturer and product numbers.  The second method is
+      numeric manufacturer and product numbers.  The second method is
       to use the human readable strings that are also contained in the
       CIS as well.  The PC Card bus uses a centralized database and
       some macros to facilitate a design pattern to help the driver
@@ -52,7 +52,7 @@
       card, especially when it appears that the vendor who made the
       card from might already have a different manufacturer id listed
       in the central database.  Linksys, D-Link and NetGear are a
-      number of US Manufactuers of LAN hardware that often sell the
+      number of US Manufacturers of LAN hardware that often sell the
       same design.  These same designs can be sold in Japan under the
       names such as Buffalo and Corega.  Yet often, these devices will
       all have the same manufacturer and product id.</para>
@@ -63,7 +63,7 @@
       that allow one to easily construct simple entries in the table
       the driver uses to claim devices.</para>
 
-      <para>Finally, some really low end divices do not contain
+      <para>Finally, some really low end devices do not contain
       manufacturer identification at all.  These devices require that
       one matches them using the human readable CIS strings.  While it
       would be nice if we didn't need this method as a fallback, it is
@@ -71,7 +71,7 @@
       popular.  This method should generally be avoided, but a number
       of devices are listed in this section because they were added
       prior to the recognition of the OEM nature of the PC Card
-      buisiness.  When adding new devices, prefer using the numberic
+      business.  When adding new devices, prefer using the numeric
       method.</para>
 
     </sect2>
@@ -107,7 +107,7 @@ vendor SANDISK			0x0045	Sandisk Corporation
       the time that Netgear was using someone else's id.  These
       entries are fairly straight forward.  There's the vendor keyword
       used to denote the kind of line that this is.  There's the name
-      of the vendor.  This name will be repated later in the
+      of the vendor.  This name will be repeated later in the
       pccarddevs file, as well as used in the driver's match tables,
       so keep it short and a valid C identifier.  There's a numeric
       ID, in hex, for the manufacturer.  Do not add IDs of the form
@@ -150,6 +150,7 @@ product	ARCHOS ARC_ATAPI	0x0043 MiniCD
       <para>The final section contains the entries for those cards
       that we must match with string entries.  This sections' format
       is a little different than the neric section:
+
 <programlisting>product ADDTRON AWP100		{ "Addtron", "AWP-100 Wireless PCMCIA", "Version 01.02", NULL }
 product ALLIEDTELESIS WR211PCM	{ "Allied Telesis K.K.", "WR211PCM", NULL, NULL } Allied Telesis WR211PCM
 </programlisting>
@@ -163,7 +164,7 @@ product ALLIEDTELESIS WR211PCM	{ "Allied Telesis K.K.", "WR211PCM", NULL, NULL }
       real space.  NULL entries mean that that part of the entry
       should be ignored.  In the example I've picked, there's a bad
       entry.  It shouldn't contain the version number in it unless
-      that's critical for the operatin of the card.  Sometimes vendors
+      that's critical for the operation of the card.  Sometimes vendors
       will have many different versions of the card in the field that
       all work, in which case that information only makes it harder
       for someone with a similar card to use it with FreeBSD.
@@ -179,12 +180,12 @@ product ALLIEDTELESIS WR211PCM	{ "Allied Telesis K.K.", "WR211PCM", NULL, NULL }
     <sect2 id="pccard-probe">
       <title>Sample probe routine</title>
 
-      <para>To understand how to add a device to list of supported
+      <para>To understand how to add a device to the list of supported
       devices, one must understand the probe and/or match routines
       that many drivers have.  It is complicated a little in FreeBSD
       5.x because there is a compatibility layer for OLDCARD present
       as well.  Since only the window-dressing is different, I'll be
-      presenting an lidealized version.</para>
+      presenting an idealized version.</para>
 
 <programlisting>static const struct pccard_product wi_pccard_products[] = {
 	PCMCIA_CARD(3COM, 3CRWE737A, 0),
@@ -217,7 +218,7 @@ wi_pccard_probe(dev)
 	<function>pccard_product_lookup()</function> is a generalized
         function that walks the table and returns a pointer to the
         first entry that it matches.  Some drivers may use this
-        mechanism to convey addtional information about some cards to
+        mechanism to convey additional information about some cards to
         the rest of the driver, so there may be some variance in the
         table.  The only requirement is that if you have a
         different table, the first element of the structure you have a
@@ -233,7 +234,7 @@ wi_pccard_probe(dev)
         description from the pccarddevs file.  You may also see
         PCMCIA_CARD2 and PCMCIA_CARD2_D which are used when you need
         to match CIS both CIS strings and manufacturer numbers, in the
-        'use the default descrition' and 'take the descrition from
+        'use the default description' and 'take the description from
         pccarddevs' flavors.</para>
 
     </sect2>
@@ -296,11 +297,11 @@ product BUFFALO WLI_CF_S11G	0x030b	BUFFALO AirStation 11Mbps CF WLAN
 </programlisting>
       Note that I've included a '<literal>+</literal>' in the line before the line that I
       added, but that is simply to highlight the line.  Do not add it
-      to the eactual driver.   Once you've added the line, you can
+      to the actual driver.   Once you've added the line, you can
       recompile your kernel or module and try to see if it recognizes
       the device.  If it does and works, please submit a patch.  If it
       doesn't work, please figure out what is needed to make it work
-      and submit a patch.  If it didn't recgonize it at all, you have
+      and submit a patch.  If it didn't recognize it at all, you have
       done something wrong and should recheck each step.</para>
 
       <para>If you are a FreeBSD src committer, and everything appears
@@ -324,7 +325,7 @@ product BUFFALO WLI_CF_S11G	0x030b	BUFFALO AirStation 11Mbps CF WLAN
       sure that entries aren't lost.  When submitting a PR, it is
       unnecessary to include the <filename>pccardevs.h</filename> diffs in the patch, since
       those will be regenerated.  It is necessary to include a
-      descrition of the device, as well as the patches to the client
+      description of the device, as well as the patches to the client
       driver.  If you don't know the name, use OEM99 as the name, and
       the author will adjust OEM99 accordingly after investigation.
       Committers should not commit OEM99, but instead find the highest