Date: Tue, 30 Dec 2014 13:27:00 +0100 From: Svatopluk Kraus <onwahe@gmail.com> To: Ian Lepore <ian@freebsd.org> Cc: freebsd-arm@freebsd.org Subject: Re: vm_fault during BBB-boot Message-ID: <CAFHCsPVbXR6gNp4jadjvuTYiB6dTUJ52WWBZUJtfouBcRfnGDw@mail.gmail.com> In-Reply-To: <1419795385.1018.213.camel@freebsd.org> References: <54A0376A.8080908@freenet.de> <1419789437.1018.207.camel@freebsd.org> <54A04FEB.2080809@freenet.de> <1419795385.1018.213.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Ulrich Grey reported the same fault to me before Christmas. He supported me with ktr log and it was even more confusing. His reported fault was a little different but on same place. It happened in sx_assert() and register values saved before the fault do not match with register values expected for PC where the fault happened. I had no time to hunt it and I will not have it till January 5. However, it looks that it's related to geom_label.ko module loaded by ubldr. (1) When Ulrich disabled loading of this module, the fault did not happen. (2) The fault happened when this module was used firstly. (3) I've never see any preloaded module in ARM before. Svata On Sun, Dec 28, 2014 at 8:36 PM, Ian Lepore <ian@freebsd.org> wrote: > On Sun, 2014-12-28 at 19:46 +0100, Manuel St=C3=BChn wrote: >> Am 28.12.2014 um 18:57 schrieb Ian Lepore: >> > I can't reproduce this on my BBB. I sync'd to the exact rev you used >> > and rebuilt, installed it all on an sdcard and booted, and I boot all >> > the way to the login prompt. I even diff'd my boot messages against t= he >> > ones you posted and there are no significant differences other than >> > pathnames and compile times. >> > >> > Maybe a stack backtrace would help... enter 'bt' at that db> prompt an= d >> > post the output (everything from the vm_fault(...)-> 1 to the end of t= he >> > backtrace). >> >> [...] >> mmcsd0: 8GB <SDHC SD08G 3.8 SN C240108F MFG 06/2009 by 2 TM> at mmc0 >> 48.0MHz/4bit/65535-block >> >> vm_fault(0xc0788e48, 0, 1, 0) -> 1 >> Fatal kernel mode data abort: 'Translation Fault (S)' >> trapframe: 0xdd0cbc60 >> FSR=3D00000005, FAR=3D00000010, spsr=3D00000113 >> r0 =3D00000000, r1 =3D00000004, r2 =3D00003d2e, r3 =3D00000137 >> r4 =3Dc2be4180, r5 =3Dc2be4180, r6 =3Dc078876c, r7 =3Dc0869a24 >> r8 =3D028f5c28, r9 =3Dc0713d48, r10=3D00000000, r11=3Ddd0cbcb0 >> r12=3D00000001, ssp=3Ddd0cbcb0, slr=3D00101010, pc =3Dc0377d64 >> >> [ thread pid 12 tid 100006 ] >> Stopped at _sx_assert+0x48: ldr r14, [r0, #0x010] >> db> bt >> Tracing pid 12 tid 100006 td 0xc2a7d660 >> db_trace_self() at db_trace_self >> pc =3D 0xc05c43d4 lr =3D 0xc02324d0 (db_stack_trace+0x108) >> sp =3D 0xdd0cb960 fp =3D 0xdd0cb978 >> r10 =3D 0xc0787b70 >> db_stack_trace() at db_stack_trace+0x108 >> pc =3D 0xc02324d0 lr =3D 0xc0231e28 (db_command+0x294) >> sp =3D 0xdd0cb980 fp =3D 0xdd0cba20 >> r4 =3D 0x00000000 r5 =3D 0x00000000 >> r6 =3D 0x00000000 >> db_command() at db_command+0x294 >> pc =3D 0xc0231e28 lr =3D 0xc0231b80 (db_command_loop+0x78) >> sp =3D 0xdd0cba28 fp =3D 0xdd0cba38 >> r4 =3D 0xc060cef5 r5 =3D 0xc062832d >> r6 =3D 0xc0787b5c r7 =3D 0xc06cfce8 >> r8 =3D 0xc07235e4 r9 =3D 0xc07235e0 >> r10 =3D 0x00000001 >> db_command_loop() at db_command_loop+0x78 >> pc =3D 0xc0231b80 lr =3D 0xc0234698 (db_trap+0x108) >> sp =3D 0xdd0cba40 fp =3D 0xdd0cbb60 >> r4 =3D 0x00000000 r5 =3D 0xc0787b68 >> r6 =3D 0xc0723608 >> db_trap() at db_trap+0x108 >> pc =3D 0xc0234698 lr =3D 0xc03a8c38 (kdb_trap+0xd4) >> sp =3D 0xdd0cbb68 fp =3D 0xdd0cbb88 >> r4 =3D 0x00000000 r5 =3D 0x00000005 >> r6 =3D 0xc0723608 r7 =3D 0xc06cfce8 >> kdb_trap() at kdb_trap+0xd4 >> pc =3D 0xc03a8c38 lr =3D 0xc05d9464 (dab_fatal+0x1c0) >> sp =3D 0xdd0cbb90 fp =3D 0xdd0cbba8 >> r4 =3D 0xdd0cbc60 r5 =3D 0x00000005 >> r6 =3D 0x600001d3 r7 =3D 0x00000010 >> r8 =3D 0xc2a7d660 r9 =3D 0xdd0cbc60 >> r10 =3D 0x00000001 >> dab_fatal() at dab_fatal+0x1c0 >> pc =3D 0xc05d9464 lr =3D 0xc05d91a4 (abort_handler+0x66c) >> sp =3D 0xdd0cbbb0 fp =3D 0xdd0cbc58 >> r4 =3D 0x00000005 r5 =3D 0x00000001 >> r6 =3D 0xc0788e48 r7 =3D 0xdd0cbea0 >> abort_handler() at abort_handler+0x66c >> pc =3D 0xc05d91a4 lr =3D 0xc05c61e0 (exception_exit) >> sp =3D 0xdd0cbc60 fp =3D 0xdd0cbcb0 >> r4 =3D 0xc2be4180 r5 =3D 0xc2be4180 >> r6 =3D 0xc078876c r7 =3D 0xc0869a24 >> r8 =3D 0x028f5c28 r9 =3D 0xc0713d48 >> r10 =3D 0x00000000 >> exception_exit() at exception_exit >> pc =3D 0xc05c61e0 lr =3D 0x00101010 (0x101010) >> sp =3D 0xdd0cbcb0 fp =3D 0xdd0cbcb0 >> r0 =3D 0x00000000 r1 =3D 0x00000004 >> r2 =3D 0x00003d2e r3 =3D 0x00000137 >> r4 =3D 0xc2be4180 r5 =3D 0xc2be4180 >> r6 =3D 0xc078876c r7 =3D 0xc0869a24 >> r8 =3D 0x028f5c28 r9 =3D 0xc0713d48 >> r10 =3D 0x00000000 r12 =3D 0x00000001 >> _sx_assert() at _sx_assert+0x48 >> pc =3D 0xc0377d64 lr =3D 0xc085e4d0 ($a+0x54) >> sp =3D 0xdd0cbcb8 fp =3D 0xdd0cbdb8 >> Unknown entry: 0 >> $a() at $a+0x54 >> pc =3D 0xc085e4d0 lr =3D 0xc085e4d0 ($a+0x54) >> sp =3D 0xdd0cbcb8 fp =3D 0xdd0cbdb8 >> Unable to unwind into user mode >> db> > > Well that didn't really help at all, because that output is crazy. It > says it can't unwind into user mode, but the PC in the last frame isn't > from usermode, it's an address beyond the end of the kernel code. I > have a feeling that "unknown entry" is why the backtrace is broken. > > So all in all, I'm out of ideas. We should have nearly identical > setups, except I didn't build with crochet, and thus I'm probably using > a slightly different u-boot (a bit newer probably). I don't see how > that could lead to working vs. failing at this point. > > -- Ian > > > _______________________________________________ > 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPVbXR6gNp4jadjvuTYiB6dTUJ52WWBZUJtfouBcRfnGDw>