Date: Sun, 28 Apr 2002 15:13:52 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: current@FreeBSD.ORG Subject: Re: Page fault in swp_pager_meta_build() Message-ID: <Pine.NEB.3.96L.1020428150401.64976L-100000@fledge.watson.org> In-Reply-To: <200204281711.g3SHBbY53495@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 28 Apr 2002, Matthew Dillon wrote: > > :(Matt gets CC'd because he's just unlucky :-) > : > :This system is (as always) a pxeboot'd nfsroot'd dual processor box. This > :time, however, it's running straight GENERIC from the main tree instead of > :the MAC branch. The box network boots, does a buildkernel -j 8, and then > :reboots. It currently has no configured swap, suggesting that things > :broke down when it tried to think about using some swap. Not sure how > :many loops it took to get to this, but I've seen a couple of different > :panics that I'll be posting about as they recur. I'm actually trying to > :track an odd mbuf/nfs interaction... > > No idea, but the last time someone had a weird swap issue it > turned out that they had swapon'd the same swap partition twice. > The system's checks are not sufficient if you swapon the same device > from different mounts. So check that first. It currently has no swap started at all, which is one reason I was rather puzzled to see this panic: 192.168.50.1:/cboss/devel/nfsroot/crash2.cboss.tislabs.com / nfs ro 0 0 proc /proc procfs rw 0 0 /dev/ad0s1e /mnt ufs rw 0 0 > The swap code preallocates its bitmap space, the hash table array is > malloc'd once at boot time, and the swblock is zalloc()'d. From the > looks of it the hash chain either got corrupted somehow or part of > the kernel's KVM space containing either the hash table or > the swblock's got corrupted. Unless someone worked on the swap > code recently I would focus on either the memory subsystem or > on unrelated kernel subsystems blowing up KVK. Should it even be hitting this code if swap hasn't been enabled? I've run into a couple of other weird bugs and wouldn't be surprised if there is a memory allocation problem. The problem I was actually trying to reproduce with these two crash boxes was one where the socket used by NFS get zero'd, resulting in a null pointer dereference. The other one is in odd panic in the mutex code during an early VFS operation. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services 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?Pine.NEB.3.96L.1020428150401.64976L-100000>