From owner-freebsd-arm@FreeBSD.ORG Sun May 17 02:41:09 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 43A2A174; Sun, 17 May 2015 02:41:09 +0000 (UTC) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.site.uottawa.ca", Issuer "PositiveSSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DE73813AA; Sun, 17 May 2015 02:41:08 +0000 (UTC) Received: from [10.0.2.15] (dsl-66-225-165-235.vianet.ca [66.225.165.235]) (authenticated bits=0) by courriel.site.uottawa.ca (8.14.5/8.14.5) with ESMTP id t4H2ewuw068222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 16 May 2015 22:40:59 -0400 (EDT) (envelope-from kwhite@site.uottawa.ca) Date: Sat, 16 May 2015 22:40:56 -0400 (EDT) From: Keith White X-X-Sender: kwhite@localhost.my.domain To: Daisuke Aoyama cc: Ian Lepore , Svatopluk Kraus , freebsd-arm@freebsd.org Subject: Re: Translation Fault panic when trying to use an mfs_root on BBB [solved?] [patch] In-Reply-To: Message-ID: References: <1431822588.91685.48.camel@freebsd.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed 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 02:41:09 -0000 On Sun, 17 May 2015, Daisuke Aoyama wrote: > -------------------------------------------------- > From: "Ian Lepore" > Sent: Sunday, May 17, 2015 9:29 AM > To: "Svatopluk Kraus" > Cc: "Keith White" ; > Subject: Re: Translation Fault panic when trying to use an mfs_root on BBB > [solved?] [patch] > >> 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: >> 1> >>> >>> on >>> >>> usbus1 >>> >>> ugen0.1: at usbus0 >>> >>> uhub1: >> 1> >>> >>> 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. > > I posted about ubldr/mfsroot last year. no one interest it... > http://lists.freebsd.org/pipermail/freebsd-arm/2014-December/009839.html > I think ubldr should be fixed. > -- > Daisuke Aoyama > > Thanks Ian for looking at this! Based upon the comments by Daisuke Aoyama, the patch above using KERNBASE becomes this using preload_addr_relocate: ----------------- --- 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(ptr - preload_addr_relocate, len, name); +#else md_preloaded(ptr, len, name); +#endif sx_xunlock(&md_sx); } } ----------------- ...keith