Date: Sat, 23 Jan 1999 14:19:52 +0800 From: Peter Wemm <peter@netplex.com.au> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: current@FreeBSD.ORG Subject: Re: panic: found dirty cache page 0xf046f1c0 Message-ID: <199901230619.OAA06346@spinner.netplex.com.au> In-Reply-To: Your message of "Fri, 22 Jan 1999 20:30:28 PST." <199901230430.UAA58243@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > :Peter Wemm wrote: > :> Dual p5-90 w/ 48M ram, doing a major cvs update/merge (which mostly got > :> lost): > :> > :> panic: found dirty cache page 0xf046f1c0 > :... > : > :This is possibly a false alarm.. Something wierd was happening. I cleaned > :out the kernel and reconfigured with NFS static (it was being loaded) and > :it seems to boot OK. At least, I'm not getting console corruption (random > :baud rate changes) and the SMP mutex being broken and both cpu's entering > :the kernel at once..... I think I'll blame it on the 15 hour electrical > :storm. :-] > : > :Cheers, > :-Peter > > An old nfs module would almost certainly not work with the new > kernel without at least a recompile. I'd definitely recommend > keeping the major modules compiled in rather then dynamically > loaded, just on principle. In fact, in all my time at BEST and > all my time playing with FreeBSD, I have *never* used any > dynamic module except for the linux compatibility thingy, and > even that was only a fluke. If you can compile it in, compile > it in. 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). > But, keep a watch on it. I didn't have an SMP box to test > the new VM stuff on so it's possible there's something going > on there. 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901230619.OAA06346>