Date: Fri, 13 Sep 2013 13:21:36 -0600 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-arm@FreeBSD.org, Ronald Klop <ronald-freebsd8@klop.yi.org> Subject: Re: Panic while building perl on sheevaplug/armv5 freebsd 10. Message-ID: <0D9A93F9-E4F1-4D78-BA8B-809169AE450D@bsdimp.com> 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 Sep 13, 2013, at 8:03 AM, Ian Lepore wrote: > On Fri, 2013-09-13 at 15:11 +0200, Ronald Klop wrote: >> Hello, >>=20 >> I have a repeatable panic while building perl on my Sheevaplug ARMv5 =20= >> 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. >>=20 >> ---- 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 =3D 0xc0bba3fc lr =3D 0xc0a60c88 (tc_setclock+0x458) >> sp =3D 0xddf9d008 fp =3D 0xddf9e038 >> r0 =3D 0xc0bba324 r1 =3D 0xc0d00000 >> r2 =3D 0xddf9d00c r3 =3D 0x20000093 >> r4 =3D 0x00000000 r5 =3D 0xc0ccd630 >> r6 =3D 0x00000000 r7 =3D 0x00000000 >> r8 =3D 0xc0caece0 r9 =3D 0x00000001 >> r10 =3D 0xc0caec88 r12 =3D 0x00000000 >> data_abort_entry() at data_abort_entry+0x30 >> pc =3D 0xc0bba324 lr =3D 0xc0a60c88 (tc_setclock+0x458) >> sp =3D 0xddf9d008 fp =3D 0xddf9e038 >> Unwind failure (no registers changed) >=20 > 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=3D3" = 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0D9A93F9-E4F1-4D78-BA8B-809169AE450D>