Subject: Re: netbsd-1-6 GENERIC + "options DDB" won't boot (on my dual-CPU SS20)
To: Julian Coleman <jdc@coris.org.uk>
From: Greg A. Woods <woods@weird.com>
List: port-sparc
Date: 07/29/2003 16:30:28
[ On Tuesday, July 29, 2003 at 10:46:23 (+0100), Julian Coleman wrote: ]
> Subject: Re: netbsd-1-6 GENERIC + "options DDB" won't boot (on my dual-CPU SS20)
>
> Hmm, this sounds like the problem where the kernel load overwrites the memory
> that the bootloader is running in.  At a guess, your DDB-enabled kernel is
> just large enough to cause this.  Can you try changing the bootloader address
> or using the current boot code?

Hmmm.... if that's the case then building a custom kernel with all the
unnecessary drivers I don't need will actually shrink it below the size
of the GENERIC kernel, even when the custom kernel has DDB, and indeed
it does:

    # size netb*
    text    data    bss     dec     hex     filename
    2254028 86644   447524  2788196 2a8b64  netbsd
    2845304 100076  258940  3204320 30e4e0  netbsd-GENERIC-1.6.1_STABLE.0
    2866600 100060  257700  3224360 313328  netbsd-GENERIC-1.6.1_STABLE.0-self
    2842948 100076  258940  3201964 30dbac  netbsd-GENERIC-1.6.1_STABLE.4
    2843016 100076  258940  3202032 30dbf0  netbsd-GENERIC-1.6.1_STABLE.5
    2925248 106924  263076  3295248 324810  netbsd-GENERIC.DDB-1.6.1_STABLE.0
    2921580 106908  262972  3291460 323944  netbsd-GENERIC.DDB-1.6.1_STABLE.1
    2920652 106908  262972  3290532 3235a4  netbsd-GENERIC.DDB-1.6.1_STABLE.2
    2254028 86644   447524  2788196 2a8b64  netbsd-MOST2-20030729.0

And this new custom kernel almost boots (well at least it gets well past
the loader problem, showing that DDB itself is not the cause and
suggesting your guess about the size is correct):

NetBSD 1.6.1_STABLE (MOST2) #0: Tue Jul 29 16:07:48 EDT 2003
    woods@almost:/home/woods/kern/MOST2
total memory = 319 MB
nbuf at 8170 is too large for VM_MAX_KERNEL_BUF... adjusted to 896
panic: uvm_km_suballoc: unable to allocate space in parent map
Stopped in pid 0 () at  cpu_Debugger+0x4:       jmpl            [%o7 + 0x8], %g0

db> trace
uvm_km_suballoc(0xf0261928, 0xf0242378, 0xf0242374, 0x4000000, 0x2, 0x0) at uvm_
km_suballoc+0x60
cpu_startup(0xf0242378, 0xf0247000, 0xf0247000, 0xf0248c00, 0xf0242380, 0xf02fd2
f0) at cpu_startup+0x2a0
main(0x0, 0xfffffff8, 0x0, 0x0, 0x38bbf8, 0xf0002208) at main+0x44
startmap_done(0x388130, 0x395ea8, 0x387eac, 0x0, 0x190, 0x398000) at startmap_do
ne+0x12c
db> 


It seems I made KMEMPAGES_MAX too large at 24576 (96MB worth).  I have a
note in my config file suggesting:

    ## On Sparc KMEMPAGES_MAX (and NKMEMPAGES) must be less than 57344.

but I guess that's not true (any more? never was?)....

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>