Date: Thu, 1 Jul 1999 16:50:09 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: Peter Wemm <peter@netplex.com.au>, hackers@FreeBSD.ORG Subject: Re: npx0 to set maxmem broken in -current? Message-ID: <Pine.BSF.3.95.990701164935.13958O-100000@current1.whistle.com> In-Reply-To: <14203.64207.225157.109702@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
a bit late....
you should check teh cvs rep for these files..
peter's already checked it in... :-)
On Thu, 1 Jul 1999, Andrew Gallatin wrote:
>
> Peter Wemm writes:
>
> Peter,
>
> Thanks for the details. I wasn't sure if it was something that was
> supposed to work... I assume it still works when built in by config &
> should be left in place for that reason though, right? (haven't tried
> it here..)
>
> > Personally, I think we should use a kernel environment variable passed in
> > from loader, since kern_envp is available *real early*, from the very
> > beginning of init386(), which is called form locore just after going
> > virtual. It needs a couple of tweaks to get this to work, and in
> > particular, the environment variable will have to override the VM86
> > calls.
>
> Great idea! I'd thought about adding a boot flag, but didn't realize
> the kernel environment variable route was so easy.
>
> The following hack seems to work here. At least it should have the
> same effect as building with MAXMEM. The only bit that concerns me is
> the movement of the movement of the kern_envp initialzation. I don't
> know diddly about the early stages of the boot & I don't know if
> moving it so that environment variables are available in getmemsize()
> is safe. Can you take a peek at this patch please?
>
> Index: machdep.c
> ===================================================================
> RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
> retrieving revision 1.342
> diff -u -b -B -c -r1.342 machdep.c
> cvs diff: conflicting specifications of output style
> *** machdep.c 1999/06/18 14:32:14 1.342
> --- machdep.c 1999/07/01 23:28:50
> ***************
> *** 153,158 ****
> --- 153,164 ----
> CTLFLAG_RD, &tlb_flush_count, 0, "");
> #endif
>
> + int i386_maxmem=0;
> +
> + SYSCTL_INT(_machdep, OID_AUTO, maxmem, CTLFLAG_RD,
> + &i386_maxmem, 0, "override memory auto-size at boottime");
> +
> +
> #ifdef PC98
> static int ispc98 = 1;
> #else
> ***************
> *** 1331,1337 ****
>
> /*
> * If a specific amount of memory is indicated via the MAXMEM
> ! * option or the npx0 "msize", then don't do the speculative
> * memory probe.
> */
> #ifdef MAXMEM
> --- 1337,1344 ----
>
> /*
> * If a specific amount of memory is indicated via the MAXMEM
> ! * option or the npx0 "msize", or the machdep.maxmem kernel
> ! * environment variable, then don't do the speculative
> * memory probe.
> */
> #ifdef MAXMEM
> ***************
> *** 1347,1352 ****
> --- 1354,1365 ----
> }
> }
> #endif
> + if (getenv_int("machdep.maxmem", &i386_maxmem) != 0) {
> + if(i386_maxmem != 0) {
> + Maxmem = i386_maxmem / 4;
> + speculative_mprobe = FALSE;
> + }
> + }
>
> #ifdef SMP
> /* look for the MP hardware - needed for apic addresses */
> ***************
> *** 1656,1661 ****
> --- 1669,1680 ----
> dblfault_tss.tss_ldt = GSEL(GLDT_SEL, SEL_KPL);
>
> vm86_initialize();
> + /*
> + * XXXX moved here to make machdep.maxmem available in
> + * getmemsize. Not sure if this is safe
> + */
> + if (bootinfo.bi_envp)
> + kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE;
> getmemsize(first);
>
> /* now running on new page tables, configured,and u/iom is accessible */
> ***************
> *** 1700,1707 ****
> preload_metadata = (caddr_t)bootinfo.bi_modulep + KERNBASE;
> preload_bootstrap_relocate(KERNBASE);
> }
> - if (bootinfo.bi_envp)
> - kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE;
> }
>
> #if defined(I586_CPU) && !defined(NO_F00F_HACK)
> --- 1719,1724 ----
>
>
>
>
> Thanks,
>
> Drew
>
> ------------------------------------------------------------------------------
> Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin
> Duke University Email: gallatin@cs.duke.edu
> Department of Computer Science Phone: (919) 660-6590
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.990701164935.13958O-100000>