From owner-freebsd-current  Thu May 16 23:05:40 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id XAA17521
          for current-outgoing; Thu, 16 May 1996 23:05:40 -0700 (PDT)
Received: from bunyip.cc.uq.oz.au (pp@bunyip.cc.uq.oz.au [130.102.2.1])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA17507
          for <freebsd-current@freebsd.org>; Thu, 16 May 1996 23:05:26 -0700 (PDT)
Received: from bunyip.cc.uq.oz.au by bunyip.cc.uq.oz.au 
          id <15977-0@bunyip.cc.uq.oz.au>; Fri, 17 May 1996 16:04:57 +1000
Received: from orion.devetir.qld.gov.au 
          by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP 
          id QAA02938; Fri, 17 May 1996 16:05:32 +1000
Received: by orion.devetir.qld.gov.au (8.6.10/DEVETIR-0.3) id QAA07165;
          Fri, 17 May 1996 16:04:42 +1000
Date: Fri, 17 May 1996 16:04:42 +1000
From: Stephen McKay <syssgm@devetir.qld.gov.au>
Message-Id: <199605170604.QAA07165@orion.devetir.qld.gov.au>
To: Michael Smith <msmith@atrad.adelaide.edu.au>
cc: freebsd-current@freebsd.org, sysgsm@devetir.qld.gov.au
Subject: Re: Debugging NFS bustedness in -current...
X-Newsreader: NN version 6.5.0 #1 (NOV)
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Michael Smith <msmith@atrad.adelaide.edu.au> wrote:

>I've been building test kernels using a -current from around 15/5.
>(Awfully slow on a 386 8( ).
>
>So far, things which _haven't_ affected bustedness : 
> -  the presence or abscene of any of the Ix86_CPU defines (which might have
>    changed the behaviour of the kernel bcopy).
>
>(I'm building a fresh GENERIC kernel, and one of the above to see if 
>NFS_NOSERVER is a problem).

>Suggestions anyone?

I had lots of NFS problems until I switched to TCP from UDP on my 386.  UDP
used to work before mid January, or so.  I mount mine "rw,intr,tcp" now, and
everything is fine.  Of course, not all servers support NFS over TCP, so the
UDP problem should be worked on.

Also, have you noticed any "spinning" processes on your 386, that is,
processes that get a lot of CPU time, but never complete?  If so, this is
triggered by some interactions between 386's, swapping (not just paging),
and the VM system.  The following patch works for me.  By the way, John
Dyson tells me this will be irrelevant when his updated VM code is
installed (Real Soon Now).

Apply to pmap.c version 1.89:
--- pmap.c.dist	Tue May 14 14:09:52 1996
+++ pmap.c	Tue May 14 14:45:51 1996
@@ -380,6 +380,7 @@
 		pmap_page_protect(VM_PAGE_TO_PHYS(mpte), VM_PROT_NONE);
 		vm_page_free(mpte);
 #else
+		pmap_changebit(VM_PAGE_TO_PHYS(mpte), PG_A|PG_M, FALSE);
 		mpte->dirty = 0;
 		vm_page_deactivate(mpte);
 #endif

Stephen.