Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 Sep 2013 08:03:07 -0600
From:      Ian Lepore <ian@FreeBSD.org>
To:        Ronald Klop <ronald-freebsd8@klop.yi.org>
Cc:        freebsd-arm@FreeBSD.org
Subject:   Re: Panic while building perl on sheevaplug/armv5 freebsd 10.
Message-ID:  <1379080987.1111.637.camel@revolution.hippie.lan>
In-Reply-To: <op.w3cpl1ua8527sy@212-182-167-131.ip.telfort.nl>
References:  <op.w3cpl1ua8527sy@212-182-167-131.ip.telfort.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2013-09-13 at 15:11 +0200, Ronald Klop wrote:
> Hello,
> 
> I have a repeatable panic while building perl on my Sheevaplug ARMv5  
> running FreeBSD 10-CURRENT.
> Kernel is loaded from NAND.
> / is mounted from USB /dev/da0s2 (UFS2)
> /usr/ports is mounted over NFS from a 9-STABLE/amd64 box.
> Swap from 512MB file in /data/swap.
> 
> ---- console output
> login: panic: vm_fault: fault on nofault entry, addr: ddf9d000
> KDB: enter: panic
> [ thread pid 659 tid 100057 ]
> Stopped at      kdb_enter+0x4c: ldrb    r15, [r15, r15, ror r15]!
> db> bt
> Tracing pid 659 tid 100057 td 0xc3f86000
[...]
> exception_exit() at exception_exit
>           pc = 0xc0bba3fc  lr = 0xc0a60c88 (tc_setclock+0x458)
>           sp = 0xddf9d008  fp = 0xddf9e038
>           r0 = 0xc0bba324  r1 = 0xc0d00000
>           r2 = 0xddf9d00c  r3 = 0x20000093
>           r4 = 0x00000000  r5 = 0xc0ccd630
>           r6 = 0x00000000  r7 = 0x00000000
>           r8 = 0xc0caece0  r9 = 0x00000001
>          r10 = 0xc0caec88 r12 = 0x00000000
> data_abort_entry() at data_abort_entry+0x30
>           pc = 0xc0bba324  lr = 0xc0a60c88 (tc_setclock+0x458)
>           sp = 0xddf9d008  fp = 0xddf9e038
> Unwind failure (no registers changed)

That's the second time in the past few months I've seen a backtrace that
makes it look like we ran out of kernel stack, but the default is 8k
which should be plenty.  Still, try adding "option KSTACK_PAGES=3" to
your kernel config and see if the problem goes away.  If it does, we may
need to figure out why we're using so much stack.  If it doesn't, we've
probably got a bad recursion loop happening somewhere.

-- Ian





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