Commit the results of the typo hunt by Darren Pilgrim.

This change affects documentation and comments only,
no real code involved.

PR:		misc/101245
Submitted by:	Darren Pilgrim <darren pilgrim bitfreak org>
Tested by:	md5(1)
MFC after:	1 week

bin/sh/histedit.c

@@ -370,7 +370,7 @@ histcmd(int argc, char **argv)
 				fputs(s, efp);
 		}
 		/*
-		 * At end?  (if we were to loose last, we'd sure be
+		 * At end?  (if we were to lose last, we'd sure be
 		 * messed up).
 		 */
 		if (he.num == last)

games/fortune/datfiles/fortunes

@@ -5459,7 +5459,7 @@ never when standing.
 Most of us just sit back and marvel at such a story; how could that terminal
 know whether the poor guy was sitting or standing?  Good debuggers, though,
 know that there has to be a reason.  Electrical theories are the easiest to
-hypothesize: was there a loose with under the carpet, or problems with static
+hypothesize: was there a loose wire under the carpet, or problems with static
 electricity?  But electrical problems are rarely consistently reproducible.
 An alert IBMer finally noticed that the problem was in the terminal's keyboard:
 the tops of two keys were switched.  When the programmer was seated he was a

lib/libc/sys/kse.2

@@ -267,7 +267,7 @@ This system call does not return unless there is an error.
 .Pp
 As a special case, if the last remaining KSE in the last remaining KSE group
 invokes this system call, then the KSE is not destroyed;
-instead, the KSE just looses the association with its mailbox and
+instead, the KSE just loses the association with its mailbox and
 .Fn kse_exit
 returns normally.
 This returns the process to its original, unthreaded state.

release/doc/fr_FR.ISO8859-1/hardware/alpha/proc-alpha.sgml

@@ -1212,7 +1212,7 @@ cpu	EV4</programlisting>
       IDE interface is quite slow, a Promise card gives a 3-4 times 
       speed improvement.</para>
 
-      <para>On PC164 the SRM sometimes seems to loose its variable settings. 
+      <para>On PC164 the SRM sometimes seems to lose its variable settings. 
       <quote>For PC164, current superstition says that, to avoid losing settings,
       you want to first downgrade to SRM 4.x and then upgrade to 5.x.</quote>
       One sample error that was observed was:</para>

share/doc/papers/timecounter/timecounter.ms

@@ -72,7 +72,7 @@ Despite the fact that time is the physical quantity (or maybe entity
 ?) about which we know the least, it is at the same time [sic!] what we
 can measure with the highest precision of all physical quantities.
 .LP
-The current crop of atomic clocks will neither gain nor loose a
+The current crop of atomic clocks will neither gain nor lose a
 second in the next couple hundred million years, provided we
 stick to the preventative maintenance schedules.  This is a feat
 roughly in line with to knowing the circumference of the Earth

share/man/man4/devctl.4

@@ -69,7 +69,7 @@ or
 The read channel for this device is used to report changes to
 userland in realtime.
 We return one record at a time.
-If you try to read this device a character at a time, you will loose
+If you try to read this device a character at a time, you will lose
 the rest of the data.
 Listening programs are expected to cope.
 .Pp

sys/boot/i386/loader/main.c

@@ -226,7 +226,7 @@ extract_currdev(void)
 
 	/*
 	 * If we are booted by an old bootstrap, we have to guess at the BIOS
-	 * unit number.  We will loose if there is more than one disk type
+	 * unit number.  We will lose if there is more than one disk type
 	 * and we are not booting from the lowest-numbered disk type 
 	 * (ie. SCSI when IDE also exists).
 	 */

sys/boot/pc98/loader/main.c

@@ -218,7 +218,7 @@ extract_currdev(void)
 
 	/*
 	 * If we are booted by an old bootstrap, we have to guess at the BIOS
-	 * unit number.  We will loose if there is more than one disk type
+	 * unit number.  We will lose if there is more than one disk type
 	 * and we are not booting from the lowest-numbered disk type 
 	 * (ie. SCSI when IDE also exists).
 	 */

sys/dev/bktr/CHANGELOG.TXT

@@ -182,7 +182,7 @@
                            video_open() function select PAL rather than NTSC.
                            This fixed all the hangs on my Dual Crystal card
                            when using a PAL video signal. As a result, you
-                           can loose the tsleep (of 2 seconds - now 0.25!!)
+                           can lose the tsleep (of 2 seconds - now 0.25!!)
                            which I previously added. (Unless someone else
                            wanted the 0.25 second tsleep).
 

sys/dev/dpt/dpt_scsi.c

@@ -1811,7 +1811,7 @@ dpttimeout(void *arg)
 	s = splcam();
 
 	/*
-	 * Try to clear any pending jobs.  FreeBSD will loose interrupts,
+	 * Try to clear any pending jobs.  FreeBSD will lose interrupts,
 	 * leaving the controller suspended, and commands timed-out.
 	 * By calling the interrupt handler, any command thus stuck will be
 	 * completed.

sys/dev/em/if_em.c

@@ -1055,7 +1055,7 @@ em_init_locked(struct adapter *adapter)
 	}
 	em_initialize_receive_unit(adapter);
 
-	/* Don't loose promiscuous settings */
+	/* Don't lose promiscuous settings */
 	em_set_promisc(adapter);
 
 	ifp->if_drv_flags |= IFF_DRV_RUNNING;

sys/dev/fe/if_fe.c

@@ -1197,7 +1197,7 @@ fe_start (struct ifnet *ifp)
 		 * If txb_count is incorrect, leaving it as-is will cause
 		 * sending of garbage after next interrupt.  We have to
 		 * avoid it.  Hence, we reset the txb_count here.  If
-		 * txb_free was incorrect, resetting txb_count just loose
+		 * txb_free was incorrect, resetting txb_count just loses
 		 * some packets.  We can live with it.
 		 */
 		sc->txb_count = 0;

sys/dev/ixgb/if_ixgb.c

@@ -697,7 +697,7 @@ ixgb_init_locked(struct adapter *adapter)
 	}
 	ixgb_initialize_receive_unit(adapter);
 
-	/* Don't loose promiscuous settings */
+	/* Don't lose promiscuous settings */
 	ixgb_set_promisc(adapter);
 
 	ifp = adapter->ifp;

sys/dev/patm/if_patm_intr.c

@@ -226,7 +226,7 @@ patm_intr(void *p)
  * Feeding buffers is actually not so easy as it seems. We cannot use the
  * fraction fields in the status registers, because they round down, i.e.
  * if we have 34 buffers in the queue, it will show 1. If we now feed
- * 512 - 1 * 32 buffers, we loose two buffers. The only reliable way to know
+ * 512 - 1 * 32 buffers, we lose two buffers. The only reliable way to know
  * how many buffers are in the queue are the FBQP registers.
  */
 static u_int

sys/dev/pci/pcivar.h

@@ -317,10 +317,10 @@ pci_is_vga_memory_range(u_long start, u_long end)
  *	power from the system and delivering full functionality to the user.
  * D1	Class-specific low-power state in which device context may or may not
  *	be lost.  Buses in D1 cannot do anything to the bus that would force
- *	devices on that bus to loose context.
+ *	devices on that bus to lose context.
  * D2	Class-specific low-power state in which device context may or may
  *	not be lost.  Attains greater power savings than D1.  Buses in D2
- *	can cause devices on that bus to loose some context.  Devices in D2
+ *	can cause devices on that bus to lose some context.  Devices in D2
  *	must be prepared for the bus to be in D2 or higher.
  * D3	State in which the device is off and not running.  Device context is
  *	lost.  Power can be removed from the device.

sys/dev/sym/sym_fw1.h

@@ -317,7 +317,7 @@ static struct SYM_FWA_SCR SYM_FWA_SCR = {
 	/*
 	 *  Now there are 4 possibilities:
 	 *
-	 *  (1) The chip looses arbitration.
+	 *  (1) The chip loses arbitration.
 	 *  This is ok, because it will try again,
 	 *  when the bus becomes idle.
 	 *  (But beware of the timeout function!)

sys/dev/sym/sym_fw2.h

@@ -290,7 +290,7 @@ static struct SYM_FWA_SCR SYM_FWA_SCR = {
 	/*
 	 *  Now there are 4 possibilities:
 	 *
-	 *  (1) The chip looses arbitration.
+	 *  (1) The chip loses arbitration.
 	 *  This is ok, because it will try again,
 	 *  when the bus becomes idle.
 	 *  (But beware of the timeout function!)

sys/fs/hpfs/hpfs.h

@@ -311,7 +311,7 @@ struct hpfsmount {
 	struct sublock	hpm_su;
 	struct spblock	hpm_sp;
 	struct mount *	hpm_mp;
-	struct vnode *	hpm_devvp;	/* XXX: loose this, it's in hpfsmount */
+	struct vnode *	hpm_devvp;	/* XXX: lose this, it's in hpfsmount */
 	struct g_consumer *hpm_cp;
 	struct bufobj *hpm_bo;
 	struct cdev *hpm_dev;

sys/geom/bde/g_bde_work.c

@@ -646,7 +646,7 @@ g_bde_worker(void *arg)
 			    PRIBIO, "-", hz);
 			if (error == EWOULDBLOCK) {
 				/*
-				 * Loose our skey cache in an orderly fashion.
+				 * Lose our skey cache in an orderly fashion.
 				 * The exact rate can be tuned to be less
 				 * aggressive if this is desirable.  10% per
 				 * second means that the cache is gone in a

sys/geom/mirror/g_mirror.c

@@ -2079,7 +2079,7 @@ g_mirror_determine_state(struct g_mirror_disk *disk)
 		 * and more fresh disk just arrive.
 		 * If there were writes, mirror is broken, sorry.
 		 * I think the best choice here is don't touch
-		 * this disk and inform the user laudly.
+		 * this disk and inform the user loudly.
 		 */
 		G_MIRROR_DEBUG(0, "Device %s was started before the freshest "
 		    "disk (%s) arrives!! It will not be connected to the "

sys/geom/raid3/g_raid3.c

@@ -2353,7 +2353,7 @@ g_raid3_determine_state(struct g_raid3_disk *disk)
 		 * and more fresh disk just arrive.
 		 * If there were writes, device is broken, sorry.
 		 * I think the best choice here is don't touch
-		 * this disk and inform the user laudly.
+		 * this disk and inform the user loudly.
 		 */
 		G_RAID3_DEBUG(0, "Device %s was started before the freshest "
 		    "disk (%s) arrives!! It will not be connected to the "

sys/i386/i386/tsc.c

@@ -94,11 +94,11 @@ void
 init_TSC_tc(void)
 {
 	/*
-	 * We can not use the TSC if we support APM. Precise timekeeping
+	 * We can not use the TSC if we support APM.  Precise timekeeping
 	 * on an APM'ed machine is at best a fools pursuit, since 
 	 * any and all of the time spent in various SMM code can't 
 	 * be reliably accounted for.  Reading the RTC is your only
-	 * source of reliable time info.  The i8254 looses too of course
+	 * source of reliable time info.  The i8254 loses too, of course,
 	 * but we need to have some kind of time...
 	 * We don't know at this point whether APM is going to be used
 	 * or not, nor when it might be activated.  Play it safe.

sys/kern/kern_resource.c

@@ -1087,7 +1087,7 @@ uihold(uip)
  *   that we don't need to free, simply unlock and return.
  * Suboptimal case:
  *   If refcount lowering results in need to free, bump the count
- *   back up, loose the lock and aquire the locks in the proper
+ *   back up, lose the lock and aquire the locks in the proper
  *   order to try again.
  */
 void

sys/kern/kern_tc.c

@@ -961,7 +961,7 @@ cpu_tickrate(void)
  * years) and in 64 bits at 4 GHz (146 years), but if we do a multiply
  * before divide conversion (to retain precision) we find that the
  * margin shrinks to 1.5 hours (one millionth of 146y).
- * With a three prong approach we never loose significant bits, no
+ * With a three prong approach we never lose significant bits, no
  * matter what the cputick rate and length of timeinterval is.
  */
 

sys/kern/subr_bus.c

@@ -417,7 +417,7 @@ devclose(struct cdev *dev, int fflag, int devtype, d_thread_t *td)
  * userland in realtime.  We are required to free the data as well as
  * the n1 object because we allocate them separately.  Also note that
  * we return one record at a time.  If you try to read this device a
- * character at a time, you will loose the rest of the data.  Listening
+ * character at a time, you will lose the rest of the data.  Listening
  * programs are expected to cope.
  */
 static int

sys/pci/ncr.c

@@ -1532,7 +1532,7 @@ static	struct script script0 = {
 	/*
 	**	Now there are 4 possibilities:
 	**
-	**	(1) The ncr looses arbitration.
+	**	(1) The ncr loses arbitration.
 	**	This is ok, because it will try again,
 	**	when the bus becomes idle.
 	**	(But beware of the timeout function!)