From owner-freebsd-arm@freebsd.org Wed May 3 01:53:35 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D679ED5B88D for ; Wed, 3 May 2017 01:53:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-62.reflexion.net [208.70.210.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 982861047 for ; Wed, 3 May 2017 01:53:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11863 invoked from network); 3 May 2017 01:53:33 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 3 May 2017 01:53:33 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 02 May 2017 21:53:33 -0400 (EDT) Received: (qmail 8830 invoked from network); 3 May 2017 01:53:33 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 May 2017 01:53:33 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 9E834EC7ED9; Tue, 2 May 2017 18:53:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: [My FreeBSD-12.0-CURRENT-arm64-aarch64.raw ] under qemu-system-aarch64 on odroid-c2 under UbuntuMate : [A combination that boots but gets some panics] From: Mark Millard In-Reply-To: Date: Tue, 2 May 2017 18:53:32 -0700 Cc: FreeBSD Current , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> <9D0414D3-7A48-4C37-8710-1AFAA5E2874E@dsl-only.net> <85D4E274-07FC-4E92-8A23-99712FB50707@dsl-only.net> <9E66D0B3-3682-49DD-A792-95E29F9DC55C@dsl-only.net> <934E8CA3-A100-47F8-B6F7-F49C83AA8EF0@dsl-only.net> To: Andrew Turner , Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 01:53:35 -0000 On 2017-May-2, at 2:59 PM, Mark Millard wrote: > The code around handle_el1h_sync+0x70 : >=20 > ffff000000607804 sub sp, sp, #0x80 > ffff000000607808 sub sp, sp, #0x120 > ffff00000060780c stp x29, x30, [sp,#272] > ffff000000607810 stp x28, x29, [sp,#256] > ffff000000607814 stp x26, x27, [sp,#240] > ffff000000607818 stp x24, x25, [sp,#224] > ffff00000060781c stp x22, x23, [sp,#208] > ffff000000607820 stp x20, x21, [sp,#192] > ffff000000607824 stp x18, x19, [sp,#176] > ffff000000607828 stp x16, x17, [sp,#160] > ffff00000060782c stp x14, x15, [sp,#144] > ffff000000607830 stp x12, x13, [sp,#128] > ffff000000607834 stp x10, x11, [sp,#112] > ffff000000607838 stp x8, x9, [sp,#96] > ffff00000060783c stp x6, x7, [sp,#80] > ffff000000607840 stp x4, x5, [sp,#64] > ffff000000607844 stp x2, x3, [sp,#48] > ffff000000607848 stp x0, x1, [sp,#32] > ffff00000060784c mrs x10, elr_el1 > ffff000000607850 mrs x11, spsr_el1 > ffff000000607854 mrs x12, esr_el1 > ffff000000607858 str x10, [sp,#16] > ffff00000060785c stp w11, w12, [sp,#24] > ffff000000607860 stp x18, x30, [sp] > ffff000000607864 mrs x18, tpidr_el1 > ffff000000607868 add x29, sp, #0x110 > ffff00000060786c mov x0, sp > ffff000000607870 bl ffff00000061aad8 = > ffff000000607874 msr daifset, #0x2 > ffff000000607878 ldp x18, x30, [sp] > ffff00000060787c ldp x10, x11, [sp,#16] > ffff000000607880 msr spsr_el1, x11 > ffff000000607884 msr elr_el1, x10 > ffff000000607888 ldp x0, x1, [sp,#32] > ffff00000060788c ldp x2, x3, [sp,#48] > ffff000000607890 ldp x4, x5, [sp,#64] > ffff000000607894 ldp x6, x7, [sp,#80] > ffff000000607898 ldp x8, x9, [sp,#96] > ffff00000060789c ldp x10, x11, [sp,#112] > ffff0000006078a0 ldp x12, x13, [sp,#128] > ffff0000006078a4 ldp x14, x15, [sp,#144] > ffff0000006078a8 ldp x16, x17, [sp,#160] > ffff0000006078ac ldr x29, [sp,#264] > ffff0000006078b0 mov sp, x18 > ffff0000006078b4 mrs x18, tpidr_el1 > ffff0000006078b8 eret >=20 > So the bl to do_el1h_sync apparently gets the data_abort. It turns out that in the first type of example there is also a: data_abort() at handle_el1h_sync+0x70 pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 sp =3D 0xffff000040238180 fp =3D 0xffff000040238290 handle_el1h_sync() at pmap_enter+0x678 pc =3D 0xffff000000607870 lr =3D 0xffff000000615684 sp =3D 0xffff0000402382a0 fp =3D 0xffff0000402383b0 in what I showed. And around pmap_enter+0x678 happens to be: ffff00000061566c b ffff000000615688 = ffff000000615670 and x8, x28, #0x1f ffff000000615674 cmp x8, #0xb ffff000000615678 b.ne ffff000000615688 = ffff00000061567c ldr x0, [sp,#32] ffff000000615680 orr w1, wzr, #0x1000 ffff000000615684 bl ffff000000605884 = ffff000000615688 ldrb w8, [x22,#93] ffff00000061568c tbnz w8, #2, ffff0000006157a4 = ffff000000615690 add x1, sp, #0x38 ffff000000615694 mov x0, x19 ffff000000615698 mov x24, x23 ffff00000061569c orr x23, x23, #0x100000000000000 ffff0000006156a0 bl ffff000000615f44 So again handle_el1h_sync happens at a bl to arm64_dcache_wb_range and ends up with a data_abort at handle_el1h_sync+0x70 . The context is pmap_enter instead of pmap_remove_pages. But an example of a pmap_remove_pages+0x2a8 context for handle_el1h_sync is also in the call chain for the first type of example that I originally showed. > The code around pmap_remove_pages+0x2a8 : >=20 > ffff000000617570 bl ffff0000005cf83c = > ffff000000617574 ldr x9, [sp,#80] > ffff000000617578 adrp x8, ffff000000bbd000 = > ffff00000061757c add x8, x8, #0x848 > ffff000000617580 str x0, [sp,#48] > ffff000000617584 cmp x9, x8 > ffff000000617588 b.eq ffff0000006175a4 = > ffff00000061758c ldr x8, [x18] > ffff000000617590 ldr x8, [x8,#8] > ffff000000617594 ldr x8, [x8,#512] > ffff000000617598 ldr x8, [x8,#224] > ffff00000061759c cmp x8, x9 > ffff0000006175a0 b.ne ffff0000006175d8 = > ffff0000006175a4 and x8, x22, #0x1f > ffff0000006175a8 cmp x28, #0x3 > ffff0000006175ac b.ne ffff0000006175c4 = > ffff0000006175b0 cmp x8, #0xb > ffff0000006175b4 b.ne ffff0000006175d8 = > ffff0000006175b8 ldr x0, [x24] > ffff0000006175bc orr w1, wzr, #0x1000 > ffff0000006175c0 b ffff0000006175d4 = > ffff0000006175c4 cmp x8, #0x9 > ffff0000006175c8 b.ne ffff0000006175d8 = > ffff0000006175cc ldr x0, [x24] > ffff0000006175d0 orr w1, wzr, #0x200000 > ffff0000006175d4 bl ffff000000605884 = > ffff0000006175d8 mov x8, xzr > ffff0000006175dc orr w1, wzr, #0x8 > ffff0000006175e0 mov x0, x26 > ffff0000006175e4 ldxr x9, [x26] > ffff0000006175e8 stxr w10, x8, [x26] > ffff0000006175ec cbnz w10, ffff0000006175e4 = > ffff0000006175f0 bl ffff000000605884 = >=20 > So this happens to involve arm64_dcache_wb_range (that has > not started yet). I still have not replicated the example that involved instruction-cache related code. I'm going to give up on directly attempting to get examples of that. But if I happen to see it again I'll try to remember to get a backtrace (bt) for it. =3D=3D=3D Mark Millard markmi at dsl-only.net