Panic while building perl on sheevaplug/armv5 freebsd 10.

[Adrian Chadd]

.. look at the zfs IO backtraces sometime. It got a bit ridiculous..



-a


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

>
> On Sep 13, 2013, at 1:44 PM, Adrian Chadd wrote:
> > .. don't we have a guard page on ARM/MIPS so we can trap out whenever
> that occurs?
>
> We know on the MIPS when that happens.
>
> > 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?
>
> Well, I'm not sure that's even real. I think that there are more registers
> on mips, so certain traps eat a lot more space than on i386... 32 * 8 bytes
> adds up fast...
>
> Warner
>
>
> >
> > -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"
> >
>
>