[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: PR 9725 and the m68k pmap
At 9:16 Uhr -0600 12.5.2009, Michael L. Hitch wrote:
> A quick and dirty workaround is to reduce the user address space by
>lowering the USERSTACK in vmparam.h (I can't remember for sure what value
>it would need to be, but it might be 0x0e000000 or 0x0c000000).
At 20:54 Uhr +0900 14.5.2009, Izumi Tsutsui wrote:
>I guess Michael's hack for current pmap requires less efforts
>to fix (or workaround) the PR.
I am not sure what it is supposed to achieve... I built and ran a few test
kernels on a Quadra 650 with 136 MB RAM with
RCS file: /cvsroot/src/sys/arch/mac68k/include/vmparam.h,v
retrieving revision 1.36
diff -u -r1.36 vmparam.h
--- vmparam.h 11 Dec 2005 12:18:03 -0000 1.36
+++ vmparam.h 20 May 2009 07:35:45 -0000
@@ -127,7 +127,9 @@
* NOTE: HP300 uses HIGHPAGES == (0x100000/PAGE_SIZE) for HP/UX compatibility.
* Do we care? Obviously not at the moment.
#define USRSTACK (-HIGHPAGES*PAGE_SIZE) /* Start of user
#define BTOPUSRSTACK (0x100000-HIGHPAGES) /* btop(USRSTACK) */
#define P1PAGES 0x100000
#define HIGHPAGES 3 /* UPAGES */
and config options
# see mac68k/include/vmparam.h
options MAXDSIZ="(192*1024*1024)" # Bump max data size
options USRSTACK=0x0c000000 # PR 9725
varying USRSTACK between 0x0c000000 and 0x0f00000 (can anybody point me to
a memory map?), and MAXDSIZ between 96 MB and 192 MB. Running the PR 9715
test app, what I got was either an 'out of memory' core dump for small
values of MAXDSIZ (< phys memory), or the usual kernel panic, or - for low
values of USRSTACK - /sbin/init being not executable.
"It's never straight up and down" (DEVO)
Main Index |
Thread Index |