Date: Wed, 4 Oct 2000 10:44:34 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Doug Rabson <dfr@nlsystems.com> Cc: Kenjiro Cho <kjc@csl.sony.co.jp>, freebsd-alpha@FreeBSD.ORG, core@kame.net Subject: Re: size problems with INVARIANTS/DIAGNOSTIC -current kernels Message-ID: <14811.11704.600307.685105@grasshopper.cs.duke.edu> In-Reply-To: <Pine.BSF.4.21.0010040926550.94692-100000@salmon.nlsystems.com> References: <20001003175912F.kjc@csl.sony.co.jp> <Pine.BSF.4.21.0010040926550.94692-100000@salmon.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Rabson writes:
> On Tue, 3 Oct 2000, Kenjiro Cho wrote:
>
> >
> > Doug Rabson wrote:
> > > Could you compile a kernel with DEBUG_CLUSTER defined in machdep.c so that
> > > I can see what the system memory map looks like.
> >
> > OK. I got the following output for the KAME kernel:
> > text data bss dec hex filename
> > 3776913 338432 226922 4342267 4241fb kernel
> >
> > FreeBSD/alpha SRM disk boot, Revision 0.3
> > (root@beta.osd.bsdi.com, Thu Jul 27 08:00:34 GMT 2000)
> > Memory: 262144 k
> > Loading /boot/defaults/loader.conf
> > /kernel data=0x3eccf0+0x3766a syms=[0x8+0x4bae0+0x8+0x35d55]
> >
> > Hit [Enter] to boot immediately, or any other key for command prompt.
> > Booting [kernel]...
> > Entering kernel at 0xfffffc0000330840...
> > Memory cluster count: 3
> > MEMC 0: pfn 0x0 cnt 0x100 usage 0x1
> > MEMC 1: pfn 0x100 cnt 0x7ea3 usage 0x0
> > Cluster 1 contains kernel
> > Loading chunk after kernel: 0x3d5 / 0x7fa3
> > MEMC 2: pfn 0x7fa3 cnt 0x5d usage 0x1
>
From my AS500:
MEMC 0: pfn 0x0 cnt 0xa5 usage 0x1
MEMC 1: pfn 0xa5 cnt 0x3ee6 usage 0x0
Cluster 1 contains kernel
Loading chunk after kernel: 0x3d3 / 0x3f8b
MEMC 2: pfn 0x3f8b cnt 0x75 usage 0x1
Unrecognized boot flag '"'.
Unrecognized boot flag '"'.
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
> This all looks reasonable. I'll have to think about this some more -
> possibly something is wrong in the loader?
>
If so, the breakage has not happened recently. I'm seeing this with a
'loader' from late august, a netboot from late august & a netboot
that's over 1 year old.
Bear in mind that we seem to run just fine until the first time we
attempt to call a function from a stack created for us by the
palcode. However, that same function is callable when not running
in an interrupt/trap/etc palcode-created context.
I've "proved" this to myself by making sure that trap() is actually
callable from the mainline kernel code (eg, not running out XentMM).
I put a call to trap() in kern_malloc() & I put a call to printtrap()
at the top of trap. I see trap being called from kern_malloc, but
when its called by XentMM, random stuff happens.
Drew
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14811.11704.600307.685105>