Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 26 May 2001 16:39:32 -0700
From:      Peter Wemm <peter@wemm.org>
To:        obrien@FreeBSD.ORG
Cc:        Matthew Jacob <mjacob@feral.com>, dcs@FreeBSD.ORG, alpha@FreeBSD.ORG
Subject:   Re: broken loader? 
Message-ID:  <20010526233932.9C78B380E@overcee.netplex.com.au>
In-Reply-To: <20010526145104.C11876@dragon.nuxi.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
"David O'Brien" wrote:
> On Fri, May 25, 2001 at 07:54:05PM -0700, Matthew Jacob wrote:
> > At some point after May 3, but probably much more frequently, the alpha boo
    t
> > stuff has gotten broken.
> 
> VERY broken.  I am trying to back out loader commits to find the
> problem.. but thanks to some very poorly tested commits I've wasted 10
> hours trying to get either of a -current PWS or DS20 usable.

I would like to remind folks that we have remote power and serial console
available on the freebsd.org cluster.  beast.freebsd.org is available for
this sort of testing by freebsd committers.  Using the on-disk boot1 code,
you can press space at the right time and select an alternative loader.  If
somebody needs to get access to the alpha box for testing something like
this, I'm sure something can be worked out.

Did we ever resolve the memory issue in boot1/loader?  ie: the one where we
only have 256k for the boot1+stack+loader workspace to live in?  I wonder if
the last FICL update is simply using more memory and simply wont fit in
the space available...  There were also some ctype changes that may have
changed things..

Makefile.inc:PRIMARY_LOAD_ADDRESS=   0x20000000 # "Region 1 start"
Makefile.inc:SECONDARY_LOAD_ADDRESS= 0x2000c000 # "Region 1 start" + 48k

where region 1 is 256k.

   text    data     bss     dec     hex filename
 181873   21864   17364  221101   35fad loader.sym

That puts the end of BSS at 0x20041FAD..  ie: at the 264K mark.

We are dangerously close to overflowing the 256 region 1 initial size.  The
bss section already overflows it, but it looks like we are saved by the
fact that we call extend_heap() before doing a bzero on the bss, then we
switch from the prom stack to the stack that is embedded in BSS.  We must
be very very close to the wire here.  Where is the prom stack anyway?  Is
it possible that it is at the end of region 1 and we're clobbering it with
some of the data segment contents?

Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5


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?20010526233932.9C78B380E>