Subject: port-i386/5102: i386 kernels larger than about 3.1MB won't load correctly
To: None <gnats-bugs@gnats.netbsd.org>
From: None <cgd@NetBSD.ORG>
List: netbsd-bugs
Date: 03/02/1998 17:36:57
>Number:         5102
>Category:       port-i386
>Synopsis:       i386 kernels larger than about 3.1MB won't load correctly
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Mar  2 17:50:01 1998
>Last-Modified:
>Originator:     Chris G. Demetriou
>Organization:
Kernel Hackers 'r' Us
>Release:        NetBSD-current as of March 2, 1998
>Environment:
System: NetBSD brick.demetriou.com 1.3D NetBSD 1.3D (BRICK) #36: Wed Feb 18 21:00:25 PST 1998 cgd@brick.demetriou.com:/usr/src/sys/arch/i386/compile/BRICK i386
(that's my current 'stable' kernel.)  System has 48MB of memory.

>Description:
	It seems that i386 kernels larger than about 3.1MB won't load
	correctly, causing the system to hang while the kernel startup code
	in locore is running.

	I originally noticed this problem a while ago (> a year), when
	putting large arrays into the kernel to debug problems by logging
	various system activity (e.g. the code that eventually became
	MALLOCLOG).

	It would appear that the problem is caused by locore wanting to
	be able to map the kernel's text + data + bss + symbols + various
	"other stuff" (e.g. the I/O hole, and I dunno what else) into a
	single i386 page table descriptor(? i'm not sure of the terminology).
	Anyway, i'm not _sure_ that that's the problem, but looking at locore
	it looks like it might be, and there _is_ a problem.

>How-To-Repeat:
	Build a big kernel, that's got a large array (either data or bss)
	in it, so that the kernel size (text + data + bss + symbols) is over
	about 3.1MB.  The (gzipped, uuencoded) kernel config file below is
	one that does that for me, on my laptop.  As noted in that kernel
	config file, using a MALLOCLOG with a MALLOCLOGSIZE of 88151 works,
	but with a MALLOGLOGSIZE of 88152 fails.  The sizes reported by
	the boot blocks for that kernel are:

		856064+49152+2236428+[55656+63863]

	Obviously, for other kernel configs/sets of kernel sources, that
	exact number might not be the trigger point.

	Another way to do it that should work pretty well is add MALLOCLOG
	to an existing i386 kernel.  The default configuration of MALLOCLOG
	(i.e. unless you set MALLOCLOGSIZE as well) will allocate a 2.4MB
	array for the log data, which should trigger the problem with most
	kernel configurations.  (This is actually how I started out, and
	I only tracked it down to a specific number for my amusement.)

begin 644 BRICK_MALLOCLOG.gz
M'XL("%)>^S0"`T)224-+7TU!3$Q/0TQ/1P"E5]MRVD@0?9:^HLND:I,LCI&X
M&">UY<(@O"HC8!$XSKZX=!F,"DFC:"1?\O7;/>(B$,[+NER"Z3FGIV>Z^VBH
M*1],_RO<S,S^7?T9M"\::%=7EQ<-_&]#H_6UW?RJ=\%[\L%X3>"#6E/5(/;"
MW&=PYJ3>ZB)H=CL7'H^7%R+SO]#H3%5KD;-F/,D"'@ME8-PL;O\Z.W\Z4VK@
M\2@)0@;+/`Q!O$4N#R%SW)"IZA:OF.UNY[$_790LK6/+O=7M*.CO/DBSW`FA
MV^AV@$5YZ!"@Y&RPL*P?C^/)U$:T2!CS8>5XZV^0,HPE<F*?^7OT@VW,[HU9
M?=&?C.W)R"B%,+:-_F)FJ&KDO.:"I4)IZA0!$UD0.1GZC?/(92GP)<CY4A!W
M\UFO;Q!:O(F,1>`YN/TL=;P@?JJ#`Z$#:QJRC]HGM;;A@3(P>[?CB3TW^V4C
MG6?)MV58]KPWM\N0P4UI=?N'?6_9M[2\72Q_?QX&:P81$\)Y8O`S9SD3AP3;
ML*H$P2(G6?&T`O[;.N4]XND;B)63XBY+\?0GUK0W?]1TI(Q9=F,/L/#T>A70
M+`.:54"+`)A!:'UI(DC=[7\SC\6(YD?K9C;MS>90DSE_BH-?#'CH0^*D64`,
M,`?5\$;F>/&`_MT@=G`;5+A86VX0!MD;O`39"D9!G+]6>,.98>"JOV4.4\8H
MX#W9>##ZC\9HV*1#:>KG;I`!#H&],B^7#2+@HWT_:]6+93^5N`LLVL?18(Y,
M*KQSP3+)`+1](Y,/[AM\-\?&KD24T9W,6,@=7T+7+(U9"!'W<UQ*59?8I.>;
M8E6&0YO`BZ%]:+<*^R;1-+6I[T/8N(!A)E]XNH8AX3:EXH4!B[,CK_9@8A<4
MRS['[P>>]]M&MT6WON,;C^*9I7O\T!Q.R"E]BF\P,S!AEC$>&)B'W;DHO:F%
M:O%H#D:ETU*F?:MO]AZ+UJN837L[M2O!:=_$R&XFME$6MK$QIPC,*?P)9M^B
MCWF?GHO!5%5)18,G18E9Y@I?23G/`(OS&K*WA,$U*4\0N[EH@),!S:J!<!H*
M#K83:N(%!P;`!TCS9S(GB8MN<.060T3C:%4>);L!(N/D5;K#=:XAX6D&C==E
M`X+T)\CF1-U;87TG*?=02GA*OBN$SH9`&XPJL\UE5TZW2!PS;&8G]?'T*'L!
MZCJA!!&U8Z*^(39I5J^X9<5L&W,+F!]J=M1<+/$$U2A#F9;/)4JN4&L/#P\0
M)EDUN,O"R^51<'MG,KPMOQKC97<W60W1]=3:_UGUW17?6TU-(M$HLKMV_>LB
M+?(E-K4O='#R5]0HDBS)B3A*!RJ![YU(6I'3#OCXU(_B7(8\24CWXBSE&#"^
M"I>^]$&^D!(\,RQ*]>6$9VU;7E0/]KS=Z-3!L`=F7>J\.3`.W+X4;E\.W(ID
MG99WN2U#3762J-P=6.`UX59"T/4BA+;<G$9Q\#SV;T('9255:T[N!UPVB:!N
MPL.3*E`.K`Z">VN6B2)LGST'6&=?0/8>Q@I0*5=<DZ.0XG>_@7\X$L$O'+5H
M(&G:*9J^I[6.:;1:Y`6.U(MBX7V,T-C$*.6!8-KO8=B_+*'0H<`5GI=Y[,E7
M*,U0)S8/`%H)0/R-MM#4]7[JFHCO3>$)8P?/_@']X@I\SD3\!YX\PSUG'*3H
M+WE*]9>AU'DK)\8+C>SM-$\RF0EZ!:*0,G*$E[-LQ6`5/*WHJA9C5M0:;3J2
MV:U6NH$'0!<&O8!M"FN'+XI5.YF%5N.J4["TDZQ2[MJG6`58JR3=T`]"T@^=
M:Y60.J><-T^R2B%='K.(1]G!SOF\+95KM58I"NJL7:R-S?%A9V]VC8807VS(
MK%1+F:FC@$MF5Y$JOV6IB6"YS\^+GE)"SA-%(PF+-U<`LKAXPS\"N@G>(DCW
M-?F[(7%D41>V(VB2)$JABM/I\53VIG1:TD%A1W:$U[Q0'`%%6+BP1^:QC^?8
M5XH@GF..OZ/\0*P+]4KW]X?2S7]KLGJCT:0_FMQ6+;;YK_%7MZNU28J'/7-4
5^C%0!9&D?9_,[FSU/XC#1?/_#0``
`
end

>Fix:
	Unknown.
>Audit-Trail:
>Unformatted: