Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 15 Sep 2013 15:31:50 +0200
From:      "Ronald Klop" <ronald-freebsd8@klop.yi.org>
To:        freebsd-arm@freebsd.org
Subject:   Re: Panic while building perl on sheevaplug/armv5 freebsd 10.
Message-ID:  <op.w3gfvcg88527sy@212-182-167-131.ip.telfort.nl>
In-Reply-To: <1379080987.1111.637.camel@revolution.hippie.lan>
References:  <op.w3cpl1ua8527sy@212-182-167-131.ip.telfort.nl> <1379080987.1111.637.camel@revolution.hippie.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 13 Sep 2013 16:03:07 +0200, Ian Lepore <ian@freebsd.org> wrote:

> 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
>

I had to bump KSTACK_PAGES up to 4, but now it is going on with building  
ports.

Ronald.



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