Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 03 Oct 2000 16:55:14 +0900
From:      Kenjiro Cho <kjc@csl.sony.co.jp>
To:        gallatin@cs.duke.edu
Cc:        freebsd-alpha@freebsd.org, dfr@nlsystems.com, core@kame.net
Subject:   Re: size problems with INVARIANTS/DIAGNOSTIC -current kernels
Message-ID:  <20001003165514K.kjc@csl.sony.co.jp>
In-Reply-To: <14806.26688.509296.391897@grasshopper.cs.duke.edu>
References:  <14806.26688.509296.391897@grasshopper.cs.duke.edu>

next in thread | previous in thread | raw e-mail | index | archive | help

I encountered a similar problem with a KAME snap for FreeBSD-4.1R
(without INVARIANTS/DIAGNOSTIC).
Apparently, my XP900 freezes at the first malloc called from the
syscons sysinit.
	malloc
	sc_vtb_init
	sc_alloc_scr_buffer
	scmeminit (syscons.c)
	mi_startup

If the kernel size is reduced by disabling IPSEC, the system boots fine.
The magic number for the kernel size seems to be around 4MB. 

4.1R GENERIC kernel: (OK)
	   text    data     bss     dec     hex filename
	3472108  300196  174306 3946610  3c3872 kernel
KAME kernel: (NG)
	   text    data     bss     dec     hex filename
	3776569  338384  226922 4341875  424073 kernel
KAME -IPSEC: (OK)
	   text    data     bss     dec     hex filename
	3502027  301172  181338 3984537  3ccc99 kernel

-Kenjiro

Andrew Gallatin wrote:
> With an INVARIANTS/DIAGNOSTIC kernel, my -current machines are locking 
> up (or halting) at boot with a stack that looks like the following:
> 
> malloc
> resource_create
> resource_set_string
> hints_load
> mi_startup
> (discovered with printfs)
> 
> At the point it hangs, there should be a trap the first time malloc
> touches kmemusage (kup->ku_indx = indx;, line 203 of kern_malloc.c).
> I assume this is happening the first time the kernel touches mapped
> (not kseg) memory.
> 
> Rather than taking a trap & doing the normal vm magic, the machine
> just sits there.  It sometimes will eventually halt.  When it does, I
> see
> 
> >>>e pc
> PC psr:                0 (    PC) FFFFFC00006960F8 
> >>>e ra
> gpr:               1A (   R26) FFFFFC00005E1F4C 
> 
> 
> The RA maps to XentMM:
> 
> (gdb) l *0xFFFFFC00005E1F4C
> 0xfffffc00005e1f4c is in XentMM (../../alpha/alpha/exception.s:94).
> 89              PALVECT(XentMM)                 /* setup frame, save registers */
> 90
> 91              /* a0, a1, & a2 already set up */
> 92              ldiq    a3, ALPHA_KENTRY_MM
> 93              mov     sp, a4                  ; .loc 1 __LINE__
> 94              CALL(trap)
> 95
> 96              jmp     zero, exception_return
> 97              END(XentMM)
> 
> 
> The PC is off in the data segment (doesn't map to anything in the
> kernel text). trap is 0xfffffc00005f4460
> 
> Hmmm....  After more debugging, I'm fairly sure this is a size issue.
> A much smaller kernel (all unneeded devs, IPv6, etc, stripped out but
> with INVARIANTS/DIAGNOSTIC options), boots just fine.
> 
> I need some help here..
> 
> Thanks,
> 
> Drew
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-alpha" in the body of the message
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001003165514K.kjc>