From owner-freebsd-alpha Wed Oct 4 7:44:47 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 8603137B66D for ; Wed, 4 Oct 2000 07:44:40 -0700 (PDT) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id KAA07028; Wed, 4 Oct 2000 10:44:34 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.0/8.9.1) id e94EiYd44357; Wed, 4 Oct 2000 10:44:34 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 4 Oct 2000 10:44:34 -0400 (EDT) To: Doug Rabson Cc: Kenjiro Cho , freebsd-alpha@FreeBSD.ORG, core@kame.net Subject: Re: size problems with INVARIANTS/DIAGNOSTIC -current kernels In-Reply-To: References: <20001003175912F.kjc@csl.sony.co.jp> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14811.11704.600307.685105@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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