Date: Thu, 1 Jul 1999 19:44:02 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Peter Wemm <peter@netplex.com.au> Cc: hackers@freebsd.org Subject: Re: npx0 to set maxmem broken in -current? Message-ID: <14203.64207.225157.109702@grasshopper.cs.duke.edu> In-Reply-To: <19990701181449.846AA8A@overcee.netplex.com.au> References: <14203.43667.496647.806250@grasshopper.cs.duke.edu> <19990701181449.846AA8A@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14203.64207.225157.109702>