Date: Sat, 23 Jan 1999 17:25:03 +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: <199901230925.RAA00489@spinner.netplex.com.au> In-Reply-To: Your message of "Sat, 23 Jan 1999 00:47:03 PST." <199901230847.AAA44590@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > :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. I've since disabled MFS, compiled out a couple of other things I'm not using very often and generally cleaned things up. I've had three more panics since turning off MFS, so that wasn't it. :-( Anyway, I've just recompiled without SMP. There were some very strange things happening on the serial console again that I really do not like the look of. Console output has been disappearing and getting duplicated. > Try changing the panic in vm/vm_page.c to a printf() ( I'll do that. FWIW, this has happened while the system has been nearly quiescent all the way through to being thrashed with parallel cvs updates etc running. Most times it waits till exmh is running. Last time (when recompiling without SMP) it crashed when it came to linking the kernel (and no exmh running). I'll see if it still crashes in uniprocessor mode, if so, I'll put some debugging in and see if I can find anything out. The kernel was last built on Jan 16, and that one works fine still, so I'm pretty sure it isn't hardware. 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?199901230925.RAA00489>