I've got a problem that I think may be with NFS.  If not, I have no
idea where it is, and I'd appreciate any pointers on how to track this
down.

First of all:

I'm running July 27 i386 current (though I had the same problems with
sources supped a week earlier).  My kernel is modified with the latest
and greatest of Stefan Grefan's PCMCIA code, and I have a 3com 3c589
ethernet adaptor in the slot.  I don't think this problem is related
to PCMCIA, though I can't discount the idea completely.

The problem is one of memory corruption.  I have the kernel compiled
with options DIAGNOSITIC, though if I run a kernel without that
option, it runs a little farther than usual, but eventually dies (as
expected).

The problem:

When running NFS, and copying a large file from the remote host, I
will eventually get a panic like the following (as expected with a
corrupt freelist problem, the details of the panic are different every
time, but it always indicates a problem with the freelist):

Data modified on freelist: word 0 of object 0xf8709e80 size 128
previous type free (0x0 != 0xdeadbeef)
Data modified on freelist: word 0 of object 0xf8709f00 size 128
previous type free (0x0 != 0xdeadbeef)
Data modified on freelist: word 0 of object 0xf8709f14 size 128
previous type ??? (invalid addr 0xc)
Data modified on freelist: word 0 of object 0xf8709f14 size 128
previous type ??? (0x400 != 0xdeadbeef)
panic: free: unaligned addr 0xf8709f14, size 128, type mbuf, mask 127
db> trace
_panic()
_free(f8709f14,1)
_m_freem(f8709f14)
_nfs_request()
_nfs_readrpc()
_nfs_doio()
_nfs_read()
_vn_read()
_read()

I can use ftp to transfer the same (50 MB) file back and forth all day
without causing a kernel panic (which is why I don't think this
problem is related to PCMCIA).

My biggest problem is that I don't have a clue as to how to go about
debugging this.  Obviously, somebody is tromping on memory on the
freelist, but how do I figure out who it is?  

All suggestions welcome.

-Todd.