Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Apr 2003 19:43:23 +0300
From:      Maxim Sobolev <sobomax@portaone.com>
To:        John Baldwin <jhb@FreeBSD.ORG>
Cc:        current@FreeBSD.ORG
Subject:   Re: i386/loader compiled with NOFORTH
Message-ID:  <20030425164323.GA66424@vega.vega.com>
In-Reply-To: <XFMail.20030425120735.jhb@FreeBSD.org>
References:  <20030425061745.GD32731@sunbay.com> <XFMail.20030425120735.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 25, 2003 at 12:07:35PM -0400, John Baldwin wrote:
> 
> On 25-Apr-2003 Ruslan Ermilov wrote:
> > On Thu, Apr 24, 2003 at 05:45:15PM -0400, John Baldwin wrote:
> >> 
> >> On 24-Apr-2003 Ruslan Ermilov wrote:
> >> > On Thu, Apr 24, 2003 at 02:21:17PM -0400, John Baldwin wrote:
> >> >> 
> >> >> On 24-Apr-2003 Ruslan Ermilov wrote:
> >> >> > On 5.x, loader(8) compiled with -DNOFORTH, results in
> >> >> > a system without a console.  This does not affect the
> >> >> > RELENG_4.
> >> >> > 
> >> >> > Can someone who knows this code please look into it?
> >> >> 
> >> >> No kernel console or no loader console?  The usual problem with
> >> >> no kernel console on 5.x is lack of device.hints.
> >> >> 
> >> > No kernel console.  The device.hints, it's there under /boot;
> >> > I only reinstalled loader(8) with -DNOFORTH, and this gave me
> >> > "no console" behavior.  Can you try it locally?
> >> 
> >> Since device.hints is read in by Forth code, I wouldn't be
> >> surprised if it didn't work.  When you break into the 10
> >> second countdown, do you have any hints set in the loader
> >> environment?
> >> 
> > Yes, figured this out by myself already.  I've ended up
> > uncommenting the "hints" line in GENERIC config, everything
> > is OK now, and bzip2(1) also works, modulo the memory
> > restrictions -- only level 1 bzipping works that requires
> > ~250K of memory.
> > 
> > John, is there a way to fix btx/loader/whatever so that
> > heap memory is not limited to 640K?
> 
> Not really.  At least, not easily.  We load the kernel up above 1mb,
> but we don't know how much memory lives up above 1mb and we assume
> that there is enough for the kernel and that's it.

Why we can't just test it - i.e. write some value into each page and
try to read it back? This will give at least rough estimate.

-Maxim



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030425164323.GA66424>