From owner-freebsd-arm@FreeBSD.ORG Tue Dec 30 12:27:01 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E720EDEF; Tue, 30 Dec 2014 12:27:01 +0000 (UTC) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FF512DCA; Tue, 30 Dec 2014 12:27:01 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id k15so7838776qaq.35; Tue, 30 Dec 2014 04:27:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=t6I3uGh2Rqt8Gc/m/G/q3IZG1/a2IMeJmBTQx+W9Z1c=; b=tIf5qBYD6M/Eb5Nk4nVnXzMYJKSTRIg96PUTs1VFstFOKtrk6gVxGHe0U/H00o8sKh NTXz/Ta5fL98ORVggnq2Qtqq7FyTD1t7eA01V/M6o9BSCfYvk6bECwIXEFsgzMF4Zmja NWM6zCy1AEukkZbfuQTds8Xt/t/2zz4k6HpPrgWsJKb9d7YspiNTy6OJJSWlQsqqyvtU GcjK9L4JC36mtP5Y1vIjCwiJ++iBGdjJpYYHLHnSDECkioGwO2XdGDtSnBaJEcMh0z6g lo7swSul323LQj2V7TLPaF50eyZ3bY6dY2OQJye3Yob7BxE+XwlNrBvYifk+p906KFzS KFcQ== MIME-Version: 1.0 X-Received: by 10.140.49.5 with SMTP id p5mr72454487qga.15.1419942420809; Tue, 30 Dec 2014 04:27:00 -0800 (PST) Received: by 10.140.82.180 with HTTP; Tue, 30 Dec 2014 04:27:00 -0800 (PST) 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> Date: Tue, 30 Dec 2014 13:27:00 +0100 Message-ID: Subject: Re: vm_fault during BBB-boot From: Svatopluk Kraus To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Tue, 30 Dec 2014 12:27:02 -0000 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 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 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"