From owner-freebsd-arm@FreeBSD.ORG Sun Dec 28 19:36:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50272EE for ; Sun, 28 Dec 2014 19:36:29 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 11FFD64710 for ; Sun, 28 Dec 2014 19:36:28 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Y5Jdb-000Gze-8l; Sun, 28 Dec 2014 19:36:27 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sBSJaPGa005489; Sun, 28 Dec 2014 12:36:25 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18qAEwcJ7VtNeUgbjSVkJCW Message-ID: <1419795385.1018.213.camel@freebsd.org> Subject: Re: vm_fault during BBB-boot From: Ian Lepore To: Manuel =?ISO-8859-1?Q?St=FChn?= Date: Sun, 28 Dec 2014 12:36:25 -0700 In-Reply-To: <54A04FEB.2080809@freenet.de> References: <54A0376A.8080908@freenet.de> <1419789437.1018.207.camel@freebsd.org> <54A04FEB.2080809@freenet.de> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sBSJaPGa005489 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Dec 2014 19:36:29 -0000 On Sun, 2014-12-28 at 19:46 +0100, Manuel St=FChn 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 = the > > 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 a= nd > > post the output (everything from the vm_fault(...)-> 1 to the end of = the > > backtrace). >=20 > [...] > mmcsd0: 8GB at mmc0=20 > 48.0MHz/4bit/65535-block >=20 > 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 >=20 > [ 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