From owner-freebsd-alpha Sun Jun 27 6:58:13 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 9078614CE1 for ; Sun, 27 Jun 1999 06:58:10 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id PAA25188; Sun, 27 Jun 1999 15:00:50 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 27 Jun 1999 15:00:49 +0100 (BST) From: Doug Rabson To: Peter Wemm Cc: alpha@freebsd.org Subject: Re: Hmm!! In-Reply-To: <19990627132357.BAB6281@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 27 Jun 1999, Peter Wemm wrote: > Peter Wemm wrote: > [..] > > ashburton# csh > > ashburton# sysctl -n kern.bootfile > > /kernel > > > > ashburton# sh > > # sysctl -n kern.bootfile > > Segmentation fault - core dumped > [..] > > Some VM, pmap or fork/exec interaction perhaps? > > > > This is the same problem that showed up when I compiled in softupdates and > > went away when it was compiled out. With some other drivers present now > > it has come back again so perhaps it's a kernel size issue somehow? (I've > > had them before - see rev 1.21 in kern_fork.c back in 1996 that was kernel > > size related) > > It gets stranger.. If I give the kernel config a major diet, it works with > SOFTUPDATES, compiled in and running on /home... > > ashburton# ls -l /kernel* > -r-xr-xr-x 1 root wheel 2759622 Jun 27 21:03 /kernel > -rwxr-xr-x 1 root wheel 3810116 Mar 27 10:23 /kernel.GENERIC > -r-xr-xr-x 1 root wheel 3690516 Jun 27 20:19 /kernel.old > -r-xr-xr-x 1 root wheel 3583502 Jun 26 16:21 /kernel.sane > ashburton# size /kernel* > text data bss dec hex filename > 1568138 177520 161256 1906914 1d18e2 /kernel > 2218779 184776 170040 2573595 27451b /kernel.GENERIC > 2259744 213600 175176 2648520 2869c8 /kernel.old > 2014113 189088 173512 2376713 244409 /kernel.sane > ashburton# size -x /kernel* > text data bss dec hex filename > 0x17ed8a 0x2b570 0x275e8 1906914 1d18e2 /kernel > 0x21db1b 0x2d1c8 0x29838 2573595 27451b /kernel.GENERIC > 0x227b20 0x34260 0x2ac48 2648520 2869c8 /kernel.old > 0x1ebba1 0x2e2a0 0x2a5c8 2376713 244409 /kernel.sane > > kernel.old was showing the segfaults for sysctl, kernel is fine - both are > exactly the same code but with a handful of PCI drivers, platform drivers, > EV4 compiled out, no NFS or CD9660, but with softupdates added. > kernel.sane was my last known good kernel prior to the buffer changes, and > it works reliably but fails if I add softupdates. > > Just a datapoint... > > Anybody got any bright ideas about this? (apart from run the memory tester > in SRM that is..) Maybe the kernel doesn't fit in its memory region? You could try enabling the debug printfs in alpha_init() where it reads the memory cluster information. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message