From owner-freebsd-arm@FreeBSD.ORG Sun May 17 04:01:07 2015 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 250EF9ED for ; Sun, 17 May 2015 04:01:07 +0000 (UTC) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (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 DE6E51B8F for ; Sun, 17 May 2015 04:01:06 +0000 (UTC) Received: by igbpi8 with SMTP id pi8so64210641igb.0 for ; Sat, 16 May 2015 21:01:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=7zJLhyCZO1ylQzUdIkyoRFKq17+mtGEyvKOCB29myNA=; b=T/NA/cFphvf50ZnG+zize4AW7L4bXXJgrpHPTrRUQFzc/UP0NknhVNFrKTEBPB0Cco o+wRJaHWFmeWYYvCeVO7oXVCsdFoRWuYEobG11Ku/XcDsxSMB3HIMUrXLhSZDCxKfvZS UH0SH38oUwYLYY+ySJonaCBjhvYfuS2ddw9d6Ep+0uOYgcX/pO6LKD7fxY0dbRsgKeVG Bd1CwT5FNvIPGMHVNAPhPQQnHaeWJsPJejZ8B0uG9AXkd18MUKyz9Qqe66f95VNzxbqF uKCgTtn9yhZuIfkUa10Bq2LRkFJZbaYmF1ymFZoYgjxnJxuV8Zhl17Rw4Ldd8MNPHg8z 2w+Q== X-Gm-Message-State: ALoCoQmIR7r67YPE1jgv17Vh7HXmRHDWDQy1QR/DdpaHC2/canrEnEsB5LcfP3nBgkSys1xWwnlL X-Received: by 10.107.5.210 with SMTP id 201mr22376414iof.57.1431834886763; Sat, 16 May 2015 20:54:46 -0700 (PDT) Received: from netflix-mac-wired.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id v102sm2753555iov.8.2015.05.16.20.54.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 May 2015 20:54:45 -0700 (PDT) Sender: Warner Losh Subject: Re: Translation Fault panic when trying to use an mfs_root on BBB [solved?] [patch] Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D09AAF2F-C7F9-44FF-86A3-6F7CF1FB98C7"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Warner Losh In-Reply-To: Date: Sat, 16 May 2015 21:54:43 -0600 Cc: Daisuke Aoyama , freebsd-arm@freebsd.org, Ian Lepore Message-Id: References: <1431822588.91685.48.camel@freebsd.org> To: Keith White X-Mailer: Apple Mail (2.2098) 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 04:01:07 -0000 --Apple-Mail=_D09AAF2F-C7F9-44FF-86A3-6F7CF1FB98C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 16, 2015, at 8:40 PM, Keith White = wrote: >=20 > On Sun, 17 May 2015, Daisuke Aoyama wrote: >=20 >> -------------------------------------------------- >> 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] >>=20 >>> 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=3D00000005, FAR=3D01211ef0, spsr=3D20000113 >>>> >>> r0 =3Dc35f4200, r1 =3D01211f00, r2 =3D000001e0, r3 =3D3dc1dd00 >>>> >>> r4 =3Dc3638930, r5 =3Dc362d838, r6 =3Dc362d810, r7 =3Dc06037b8 >>>> >>> r8 =3D0000002d, r9 =3D00000000, r10=3Dc3638930, r11=3Ddd43fdf0 >>>> >>> r12=3D00000000, ssp=3Ddd43fde0, slr=3Dc0249918, pc =3Dc05c6a68 >>>> >>> >>>> >>> [ 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=3D1 slice=3D partition=3D... good. >>>> >>> /boot/kernel/kernel data=3D0x505c2c+0x923d4 = syms=3D[0x4+0x606a0+0x4+0x65ed4] >>>> >>> /boot/kernel/snd_uaudio.ko text=3D0xed3c data=3D0x620+0x10 >>>> >>> syms=3D[0x4+0x1ec0+0x4+0x1a2f] >>>> >>> ... >>>> >>> Type '?' for a list of commands, 'help' for more detailed help. >>>> >>> loader> load -t mfs_root /rootfs >>>> >>> /rootfs size=3D0x858000 >>>> >>> loader> boot -asv >>>> >>> Booting... >>>> >>> /boot/dtb/beaglebone-black.dtb size=3D0x24b4 >>>> >>> 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=3D00000005, FAR=3D01211ef0, spsr=3D20000113 >>>> >>> r0 =3Dc35f4200, r1 =3D01211f00, r2 =3D000001e0, r3 =3D3dc1dd00 >>>> >>> r4 =3Dc3638930, r5 =3Dc362d838, r6 =3Dc362d810, r7 =3Dc06037b8 >>>> >>> r8 =3D0000002d, r9 =3D00000000, r10=3Dc3638930, r11=3Ddd43fdf0 >>>> >>> r12=3D00000000, ssp=3Ddd43fde0, slr=3Dc0249918, pc =3Dc05c6a68 >>>> >>> >>>> >>> [ 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 >>>> > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> > --- sys/dev/md/md.c (revision 282672) >>>> > +++ sys/dev/md/md.c (working copy) >>>> > @@ -1590,7 +1590,11 @@ >>>> > len =3D preload_fetch_size(mod); >>>> > if (ptr !=3D NULL && len !=3D 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. >>=20 >> 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 >>=20 >>=20 >=20 > Thanks Ian for looking at this! >=20 > Based upon the comments by Daisuke Aoyama, the patch above using > KERNBASE becomes this using preload_addr_relocate: >=20 > ----------------- > --- sys/dev/md/md.c (revision 282672) > +++ sys/dev/md/md.c (working copy) > @@ -1590,7 +1590,11 @@ > len =3D preload_fetch_size(mod); > if (ptr !=3D NULL && len !=3D 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); > } > } This is almost certainly the wrong place to fix this. The right place to = fix it is in ubldr. It says that all the ptrs are AFU only on arm, and = this one is likely the first of many. Warner --Apple-Mail=_D09AAF2F-C7F9-44FF-86A3-6F7CF1FB98C7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVWBEDAAoJEGwc0Sh9sBEAMXoQAIwhN8B+QhgxHZU/DrFAHM9w PLD6gSs5uiKB+3Ib4wYT7SF9Psk6wXTwL6968VDfdh4AnsMvm9nnxCfNQSgftzRA L3wPEDUDgkd8Dv4Kw0yMFQT87hD4L0NCCX5TLEgGAB5z8brT08NneVyDhfM+PEbi VltxC08xcllOA7oa6oqTpi5YxZAz+DlRPG7M3HtZHOObLZQhOxpLlFYQ47zgfawm flXAG1r7iXU7zR0QQP7BOAUy0Gy+jVICAc89VSdgmNQFF5oNmRwW3OUQeycBwcIf V74GwLuGIU8jVMG+8fY2RArMIxaQwnVEtTUj/cSIhOqyUfqIE3Mw3nJzEnVpEckc oQoYx3tuPUNdiM41uj6okbIBdmG6P++QCZ/7TJ27LLwIHCyHAcUg/S7JhqEejbdf V9Umgn6byBPOu4dK89mMrvxq096OPL+/698ah684Jp6pP4TWr5rcUCU0XHOAQJqQ ra1mi1Kl1M4I6MNYKlnrQj/dQlk8xKMuuTuLUBLcUozIXExPU5q/dROtaWd16Zmr 4od6Q8MdSYITkoeqZkamDvhgrhXRpKEYItVJ4FpVidwa7zrPcpd6QKZIDvwuluGp 4eOoQKFQb8Y3hPDbmIBZT2fmDGmUYd/L0eQSZ+HSeQajTxKq/Vtj9OaiL/1MbLTr hy7HRUdMsRAUHAOJEt1I =PUKV -----END PGP SIGNATURE----- --Apple-Mail=_D09AAF2F-C7F9-44FF-86A3-6F7CF1FB98C7--