From owner-freebsd-arm@FreeBSD.ORG Sun May 17 07:54:54 2015 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 071A017F; Sun, 17 May 2015 07:54:54 +0000 (UTC) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C4E3D10AF; Sun, 17 May 2015 07:54:53 +0000 (UTC) Received: by igbpi8 with SMTP id pi8so65573286igb.0; Sun, 17 May 2015 00:54:53 -0700 (PDT) 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; bh=JZ1YR/VROstb6sNoYtCW+Pzv4IA+TGVAgptIJP+XIeo=; b=qGEfVZQkQ4oI2ALn/K5W2Rks5MVZY/6SZuNIbrm2Tw2gXoIkaFPF5/7TsJw3CNj6fm d3W3bmHMscjnm1QP6Mjx9bhilu178XfGylRFsN6AP09Pnr4ay8or78UpHjNqV7jJK4rG 81kIVN55rYdQcT3ztGO8WgPNc1SCPkZQgRzLbGMJRuj/sVktwRY171ySZkG/Il87duSu XvikegHBrv9sVL38+6DzUvz/rBR6/mz4VJboUUdYdVz4wbeS9oIGPl03BPJ9Bq1ouZpf PrPmkpMwRNYh4f3u0ETCl0ZBNBImTb2HW1huVf8QId5XfQ0DDXoRcdpoMP7RauVxpxgf dsxA== MIME-Version: 1.0 X-Received: by 10.42.76.146 with SMTP id e18mr30146365ick.42.1431849293190; Sun, 17 May 2015 00:54:53 -0700 (PDT) Received: by 10.64.228.199 with HTTP; Sun, 17 May 2015 00:54:53 -0700 (PDT) In-Reply-To: <1431822588.91685.48.camel@freebsd.org> References: <1431822588.91685.48.camel@freebsd.org> Date: Sun, 17 May 2015 09:54:53 +0200 Message-ID: Subject: Re: Translation Fault panic when trying to use an mfs_root on BBB [solved?] [patch] From: Svatopluk Kraus To: Ian Lepore Cc: Keith White , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 07:54:54 -0000 On Sun, May 17, 2015 at 2:29 AM, Ian Lepore wrote: > On Fri, 2015-05-15 at 10:18 +0200, Svatopluk Kraus wrote: >> On Fri, May 15, 2015 at 2:13 AM, Keith White wrote: >> > On Thu, 14 May 2015, Svatopluk Kraus wrote: >> > >> >> On Thu, May 14, 2015 at 2:03 AM, Keith White >> >> wrote: >> >>> >> >>> I get the following panic when trying to load an mfs_root on a >> >>> reasonably current BBB image: >> >>> >> >>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >> >>> trapframe: 0xdd43fd50 >> >>> FSR=00000005, FAR=01211ef0, spsr=20000113 >> >>> r0 =c35f4200, r1 =01211f00, r2 =000001e0, r3 =3dc1dd00 >> >>> r4 =c3638930, r5 =c362d838, r6 =c362d810, r7 =c06037b8 >> >>> r8 =0000002d, r9 =00000000, r10=c3638930, r11=dd43fdf0 >> >>> r12=00000000, ssp=dd43fde0, slr=c0249918, pc =c05c6a68 >> >>> >> >>> [ thread pid 4 tid 100054 ] >> >>> Stopped at memmove+0x29c: ldmdb r1!, {r3-r4, r12, r14} >> >>> db> >> >>> >> >>> Hints, suggestions? >> >>> >> >>> ...keith >> >>> >> >>> --------------------------------- >> >>> More (trimmed) details from boot: >> >>> >> >>> ... >> >>> U-Boot 2014.10 (Mar 19 2015 - 18:29:51) >> >>> ... >> >>> FreeBSD/armv6hf U-Boot loader, Revision 1.2 >> >>> (kwhite@freebsd11, Tue Mar 17 22:23:25 EDT 2015) >> >>> ... >> >>> Found U-Boot device: disk >> >>> Checking unit=1 slice= partition=... good. >> >>> /boot/kernel/kernel data=0x505c2c+0x923d4 syms=[0x4+0x606a0+0x4+0x65ed4] >> >>> /boot/kernel/snd_uaudio.ko text=0xed3c data=0x620+0x10 >> >>> syms=[0x4+0x1ec0+0x4+0x1a2f] >> >>> ... >> >>> Type '?' for a list of commands, 'help' for more detailed help. >> >>> loader> load -t mfs_root /rootfs >> >>> /rootfs size=0x858000 >> >>> loader> boot -asv >> >>> Booting... >> >>> /boot/dtb/beaglebone-black.dtb size=0x24b4 >> >>> Loaded DTB from file 'beaglebone-black.dtb'. >> >>> Kernel entry at 0x80200100... >> >>> Kernel args: -asv >> >>> KDB: debugger backends: ddb >> >>> KDB: current backend: ddb >> >>> Copyright (c) 1992-2015 The FreeBSD Project. >> >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> >>> The Regents of the University of California. All rights reserved. >> >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >> >>> FreeBSD 11.0-CURRENT #1 r282672M: Tue May 12 06:57:24 EDT 2015 >> >>> >> >>> kwhite@freebsd11:/usr/obj/arm.armv6hf/tank/RPI/head/sys/BEAGLEBONE-LOCAL >> >>> arm >> >>> FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225 >> >>> WARNING: WITNESS option enabled, expect reduced performance. >> >>> Preloaded elf kernel "/boot/kernel/kernel" at 0xc1219000. >> >>> ... >> >>> mmc0: Probing bus >> >>> usbus0: 480Mbps High Speed USB v2.0 >> >>> usbus1: 480Mbps High Speed USB v2.0 >> >>> md0: Preloaded image 8749056 bytes at 0x9b9f00 >> >>> ugen1.1: at usbus1 >> >>> uhub0: >> >>> on >> >>> usbus1 >> >>> ugen0.1: at usbus0 >> >>> uhub1: >> >>> on >> >>> usbus0 >> >>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >> >>> trapframe: 0xdd43fd50 >> >>> FSR=00000005, FAR=01211ef0, spsr=20000113 >> >>> r0 =c35f4200, r1 =01211f00, r2 =000001e0, r3 =3dc1dd00 >> >>> r4 =c3638930, r5 =c362d838, r6 =c362d810, r7 =c06037b8 >> >>> r8 =0000002d, r9 =00000000, r10=c3638930, r11=dd43fdf0 >> >>> r12=00000000, ssp=dd43fde0, slr=c0249918, pc =c05c6a68 >> >>> >> >>> [ thread pid 4 tid 100054 ] >> >>> Stopped at memmove+0x29c: ldmdb r1!, {r3-r4, r12, r14} >> >> >> >> >> >> >> >> Well, FAR (fault address) points to user address space. System is >> >> still in boot process and no user address should be used. The first >> >> thing is to find out if arguments pushed to bcopy() in >> >> mdstart_preload() are correct. Can you print them out? >> >> ... >> > >> > >> > Thanks for the hint! After a little digging with ddb, it appears >> > that the fault address is missing an offset of KERNBASE (0xc0000000). >> > The mfs_root being found at 0x9b9f00 ("md0: preloaded image at") + >> > KERNBASE (0xc0000000). The following patch fixes the symptom, and >> > allows a boot to successfully complete. The resulting md is also >> > usable as /. >> > >> > I'm sure there's a more correct patch? >> > >> > Index: sys/dev/md/md.c >> > =================================================================== >> > --- sys/dev/md/md.c (revision 282672) >> > +++ sys/dev/md/md.c (working copy) >> > @@ -1590,7 +1590,11 @@ >> > len = preload_fetch_size(mod); >> > if (ptr != NULL && len != 0) { >> > sx_xlock(&md_sx); >> > +#ifdef __arm__ >> > + md_preloaded(KERNBASE + ptr, len, name); >> > +#else >> > md_preloaded(ptr, len, name); >> > +#endif >> > sx_xunlock(&md_sx); >> > } >> > } >> >> >> Thanks for debugging it. The preload_fetch_addr() already uses >> preload_addr_relocate to adjust returned address. IMO, a patch should >> either deal with preload_addr_relocate and init it correctly or fix >> MODINFO_ADDR info in kernel modules. Now, preload_addr_relocate is set >> only when FREEBSD_BOOT_LOADER is defined. In this moment, I know >> nothing about how MODINFO_ADDR info is generated. >> >> BTW, physical address space starts at 0x80000000 on BBB and KERNBASE >> is 0xC0000000, so I would be expecting that preload_addr_relocate >> should be set to 0x40000000. The FAR is 0x01211ef0, so it's not >> physical address. And as your patch helps, it's an offset to either >> physical or virtual address space. So it looks more like MODINFO_ADDR >> info problem. >> > > I think the problem here is likely to be in ubldr. Today I tried to > recreate this and all I could get was complete system lockup right after > the kernel copyright displayed. Eventually I noticed that your root > image is less than 10MB, so I created a little image about the same size > as yours and put init(8) in it, and with that I get the same panic you > do (different physical address, I'm doing it on a wandboard). > > I think there are at least two separate problems here. ubldr isn't > setting the right metadata for the load address, and then separately > from that, trying to load really big files corrupts memory somehow in a > way that locks up the kernel. > > I'll keep poking at it. > Well, there is a way how to get 0x01211ef0 which looks like an offset on BBB. If MODINFO_ADDR is already relocated to VA (above 0xC0000000) and preload_addr_relocate is not zero (0x40000000), then preload_fetch_addr() will return an "offset" in BBB case.