Date: Fri, 13 Sep 2013 13:50:41 -0600 From: Warner Losh <imp@bsdimp.com> To: Adrian Chadd <adrian@freebsd.org> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, Ian Lepore <ian@freebsd.org>, Ronald Klop <ronald-freebsd8@klop.yi.org> Subject: Re: Panic while building perl on sheevaplug/armv5 freebsd 10. Message-ID: <0E7C0397-7D47-4725-B996-C5FB28BCF453@bsdimp.com> In-Reply-To: <CAJ-Vmo=tP0N5iQwO%2BNbxgyT=VDtAJm6oKSWyYR_r-BA65XHJ0Q@mail.gmail.com> References: <op.w3cpl1ua8527sy@212-182-167-131.ip.telfort.nl> <1379080987.1111.637.camel@revolution.hippie.lan> <0D9A93F9-E4F1-4D78-BA8B-809169AE450D@bsdimp.com> <CAJ-Vmo=tP0N5iQwO%2BNbxgyT=VDtAJm6oKSWyYR_r-BA65XHJ0Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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...=20 Warner >=20 > -adrian >=20 >=20 >=20 > On 13 September 2013 12:21, Warner Losh <imp@bsdimp.com> wrote: >=20 > On Sep 13, 2013, at 8:03 AM, Ian Lepore wrote: >=20 > > 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 =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) > > > > 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. >=20 > 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... >=20 > Warner >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0E7C0397-7D47-4725-B996-C5FB28BCF453>