:It's definately happening still, sorry. :-( I recompiled a 100% static
:kernel and have had three more explosions, usually after starting exmh.
:(exmh takes 10 to 15MB of ram on this system due to my mailbox folder
:sizes).
:
:However, a clue.. The SMP box that is doing fine is a P6, an NFS client
:and server (loading nfs.ko, it fsck's fast, so I use that box for making
:sure the modules work). The one that is crashing, is a P5, an NFS client
:and server (static kernel), and with a MFS /tmp. Both run softupdates (up
:to date src/contrib/sys).
:
:I suspect MFS is the key. There's the new VOP_FREEBLKS() stuff you added,
:and the corresponding calls to madvise to free the pages.
:
:Given madvise()'s murky history, I can't help but feel suspicious about it.
:
:I've unmounted /tmp and am about to thrash the machine. At the
:moment, it's sitting on: Swap: 120M Total, 376K Used, 120M Free
:
:Cheers,
:-Peter
Hmmm. It's possible. A quick look at the exmh source indicates that
it uses /tmp a lot. I've been doing make buildworld's with a 300MB
MFS /usr/obj, but those are typically nothing more then simple file
creates, reads, and writes. Presumably exmh is doing something more
sophisticated.
Try changing the panic in vm/vm_page.c to a printf() (
if (m->dirty)
panic("found dirty cache page %p", m);
if (m->dirty)
printf(
"found dirty cache page %p (%p,%d,%x) obtype %d
obflags %x",
m,
m->object,
(int)m->pindex,
(int)m->flags,
(int)m->object->type,
(int)m->object->flags
);
Lets see what we get. This should tell me what kind
of object the page is attached to and the flags of the
page and object.
-Matt
Matthew Dillon
<dil...@backplane.com>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
