Panic while building perl on sheevaplug/armv5 freebsd 10.

[Adrian Chadd]

.. don't we have a guard page on ARM/MIPS so we can trap out whenever that
occurs?

That way we can at least try to identify where people have made some "huh
we're running on amd64, stack space is cheap huh" assumptions?


-adrian



On 13 September 2013 12:21, Warner Losh <imp at bsdimp.com> wrote:

>
> On Sep 13, 2013, at 8:03 AM, Ian Lepore 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.
>
> FreeBSD/mips runs out of kernel stack on ports builds as well, but there's
> a number of special conditions that seem to be needed before that happens...
>
> Warner
>
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>