Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Mar 2002 14:34:06 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Mike Silbersack <silby@silby.com>
Cc:        "Clark C . Evans" <cce@clarkevans.com>, freebsd-hackers@freebsd.org
Subject:   Re: panic: pmap_enter
Message-ID:  <3C8E825E.41E7DDFA@mindspring.com>
References:  <20020312160818.T14552-100000@patrocles.silby.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.
> 
> <etc, etc>
> 
> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C8E825E.41E7DDFA>