From owner-freebsd-hackers Tue Mar 12 14:35:20 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 2F63537B4A7 for ; Tue, 12 Mar 2002 14:34:31 -0800 (PST) Received: from pool0291.cvx40-bradley.dialup.earthlink.net ([216.244.43.36] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16kuqe-00071g-00; Tue, 12 Mar 2002 14:34:24 -0800 Message-ID: <3C8E825E.41E7DDFA@mindspring.com> Date: Tue, 12 Mar 2002 14:34:06 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack Cc: "Clark C . Evans" , freebsd-hackers@freebsd.org Subject: Re: panic: pmap_enter References: <20020312160818.T14552-100000@patrocles.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Silbersack wrote: > On Tue, 12 Mar 2002, Terry Lambert wrote: > > No, I mean allocate kernel memory pages. As I said, 4M pages > > are not permitted to be swapped, so they should never go through > > the swap code. > > > > Because of this, a fault indicating that there is not a page > > present behind some of the memory is fatal. > > > > Whoa, slow down Terry! > > He pasted the entire traceback in his second message, and it looks like > the ffs code is where the fault is occuring. His trap was in the pmap_enter on a 4M page that wasn't "swapped in", when it's ``impossible'' to create one that needs to be demand paged in the first place. My gut feeling was(is) that it's a problem with the MFS backing in the overcommit case, because of the pmap_enter message in the panic he posted. > Clark confirmed that he was not using a 8:1 frag:block ratio > on the MFS partition, so that was probably the problem. He's > trying out different MFS settings, and I assume we'll hear back > from him once he can determine whether that fixed the problem > or not. > > In the meantime, stop hypothesizing about 4MB pages, and go figure out why > the FFS code can't handle other frag:block ratios. :) Are you sure this is an FFS problem, and not an MFS problem? I have never had problems using odd frag sizes. On the other hand, my branch point for my common work is pretty old. It seems to me that in fs.h, the following: #define blkmap(fs, map, loc) \ (((map)[(loc) / NBBY] >> ((loc) % NBBY)) & (0xff >> (NBBY - (fs)->fs_frag))) looks a little suspect, doesn't it? "& 0" for 8 is probably correct, but "& 1" for 4 and "& 2" for 2 and "& 4" for 1 is probably not right... maybe: #define blkmap(fs, map, loc) \ (((map)[(loc) / NBBY] >> ((loc) % NBBY)) & 0xff & ((0xff >> (NBBY - (fs)->fs_frag))^0xff)) Would be more right? After all, it's the high bits of the low bits you want to save, not the low bits of the low bits... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message