Date: Tue, 2 May 2017 14:30:05 -0700 From: Mark Millard <markmi@dsl-only.net> To: freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>, Andrew Turner <andrew@fubar.geek.nz>, Konstantin Belousov <kostikbel@gmail.com> Cc: "O. Hartmann" <o.hartmann@walstatt.org>, Tom Vijlbrief <tvijlbrief@gmail.com> 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] Message-ID: <934E8CA3-A100-47F8-B6F7-F49C83AA8EF0@dsl-only.net> In-Reply-To: <9E66D0B3-3682-49DD-A792-95E29F9DC55C@dsl-only.net> References: <FF5D8468-CE04-411A-9F3C-10EF5F21D9E5@dsl-only.net> <D2E876BD-A23F-4C33-A0B6-8F1A862C11D6@fubar.geek.nz> <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> <B16C20CC-EA3A-461D-8719-7418207572A4@dsl-only.net> <BA05FF2E-179C-46B2-B0B5-7FC4C1AE00E8@dsl-only.net> <9E66D0B3-3682-49DD-A792-95E29F9DC55C@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-May-2, at 2:22 PM, Mark Millard <markmi at dsl-only.net> wrote: > It turns out that the bt's from the example panics are > repeatable for the pc and lr sequence involved (but not > the specific sp's and fp's involved). I report this in > case it suggests anything. I'll note that the build had > a production style kernel for a build of -r317015 . >=20 > The first type of panic actually a back to back > sequence of two bt's, this is the sleeping-thread type > pf example. The second type is just one bt by itself. >=20 > There is one variable lr in the bt for the sleeping-thread > type of example (the first type of panic of the two shown > later, the one with back-to-back bt's): >=20 > 131,133c131,133 > < handle_el0_sync() at 0x40040070 > < pc =3D 0xffff0000006079e8 lr =3D 0x0000000040040070 > < sp =3D 0xffff000065dfdba0 fp =3D 0x0000ffffffffeb00 > --- >> handle_el0_sync() at 0x40044490 >> pc =3D 0xffff0000006079e8 lr =3D 0x0000000040044490 >> sp =3D 0xffff000040229ba0 fp =3D 0x0000ffffffffe3d0 >=20 > Otherwise the two bt's in the example match for the pc/lr > sequence. >=20 > I only have the two examples of this type to compare so > far (one diff). >=20 > I have 3 examples of the second type and they had no such > variation. >=20 > One thing in common to all 5 of these examples is the > sequence: >=20 > data_abort() at handle_el1h_sync+0x70 > lr =3D 0xffff000000607870 > handle_el1h_sync() at pmap_remove_pages+0x2a8 > pc =3D 0xffff000000607870 lr =3D 0xffff0000006175d4 > pmap_remove_pages() >=20 > being involved in each example. >=20 >=20 > I'm not saying that I can cause any panics at will, but > when either of the two types happen the bt is (mostly) > stable for the pc and lr sequence and that short > sequence above is involved. >=20 > I have seen one other type of panic but I did not manage > to record a bt for it yet. It involved the instruction > cache instead of arm64_dcache_wb_range . >=20 > I quote the prior reported example bt's below. >=20 > On 2017-May-2, at 5:24 AM, Mark Millard <markmi at dsl-only.net> = wrote: >=20 >> On 2017-May-2, at 3:37 AM, Mark Millard <markmi at dsl-only.net> = wrote: >>=20 >>> On 2017-May-2, at 2:53 AM, Mark Millard <markmi at dsl-only.net> = wrote: >>>=20 >>> . . . >>> FYI: >>>=20 >>> I do sometimes get things like: >>>=20 >>>=20 >>> System shutdown time has arrived >>> Apr 30 19:43:15 ODC2FBSD shutdown: power-down by root:=20 >>> Sleeping thread (tid 100093, pid 708) owns a non-sleepable lock >>> KDB: stack backtrace of thread 100093: >>> sched_switch() at mi_switch+0x100 >>> pc =3D 0xffff000000347d44 lr =3D 0xffff000000327358 >>> sp =3D 0xffff000040237e00 fp =3D 0xffff000040237e20 >>>=20 >>> mi_switch() at sleepq_wait+0x3c >>> pc =3D 0xffff000000327358 lr =3D 0xffff00000036c174 >>> sp =3D 0xffff000040237e30 fp =3D 0xffff000040237e50 >>>=20 >>> sleepq_wait() at _sleep+0x29c >>> pc =3D 0xffff00000036c174 lr =3D 0xffff000000326c7c >>> sp =3D 0xffff000040237e60 fp =3D 0xffff000040237ee0 >>>=20 >>> _sleep() at vm_page_sleep_if_busy+0xb0 >>> pc =3D 0xffff000000326c7c lr =3D 0xffff0000005cfcf4 >>> sp =3D 0xffff000040237ef0 fp =3D 0xffff000040237f10 >>>=20 >>> vm_page_sleep_if_busy() at vm_fault_hold+0xcc8 >>> pc =3D 0xffff0000005cfcf4 lr =3D 0xffff0000005ba17c >>> sp =3D 0xffff000040237f20 fp =3D 0xffff000040238070 >>>=20 >>> vm_fault_hold() at vm_fault+0x70 >>> pc =3D 0xffff0000005ba17c lr =3D 0xffff0000005b9464 >>> sp =3D 0xffff000040238080 fp =3D 0xffff0000402380b0 >>>=20 >>> vm_fault() at data_abort+0xe0 >>> pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 >>> sp =3D 0xffff0000402380c0 fp =3D 0xffff000040238170 >>>=20 >>> data_abort() at handle_el1h_sync+0x70 >>> pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 >>> sp =3D 0xffff000040238180 fp =3D 0xffff000040238290 >>>=20 >>> handle_el1h_sync() at pmap_enter+0x678 >>> pc =3D 0xffff000000607870 lr =3D 0xffff000000615684 >>> sp =3D 0xffff0000402382a0 fp =3D 0xffff0000402383b0 >>>=20 >>> pmap_enter() at vm_fault_hold+0x17c0 >>> pc =3D 0xffff000000615684 lr =3D 0xffff0000005bac74 >>> sp =3D 0xffff0000402383c0 fp =3D 0xffff000040238510 >>>=20 >>> vm_fault_hold() at vm_fault+0x70 >>> pc =3D 0xffff0000005bac74 lr =3D 0xffff0000005b9464 >>> sp =3D 0xffff000040238520 fp =3D 0xffff000040238550 >>>=20 >>> vm_fault() at data_abort+0xe0 >>> pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 >>> sp =3D 0xffff000040238560 fp =3D 0xffff000040238610 >>>=20 >>> data_abort() at handle_el1h_sync+0x70 >>> pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 >>> sp =3D 0xffff000040238620 fp =3D 0xffff000040238730 >>>=20 >>> handle_el1h_sync() at pmap_remove_pages+0x2a8 >>> pc =3D 0xffff000000607870 lr =3D 0xffff0000006175d4 >>> sp =3D 0xffff000040238740 fp =3D 0xffff000040238870 >>>=20 >>> pmap_remove_pages() at vmspace_exit+0xb0 >>> pc =3D 0xffff0000006175d4 lr =3D 0xffff0000005c020c >>> sp =3D 0xffff000040238880 fp =3D 0xffff0000402388b0 >>>=20 >>> vmspace_exit() at exit1+0x604 >>> pc =3D 0xffff0000005c020c lr =3D 0xffff0000002db5e0 >>> sp =3D 0xffff0000402388c0 fp =3D 0xffff000040238920 >>>=20 >>> exit1() at sys_sys_exit+0x10 >>> pc =3D 0xffff0000002db5e0 lr =3D 0xffff0000002dafd8 >>> sp =3D 0xffff000040238930 fp =3D 0xffff000040238930 >>>=20 >>> sys_sys_exit() at do_el0_sync+0xa48 >>> pc =3D 0xffff0000002dafd8 lr =3D 0xffff00000061b91c >>> sp =3D 0xffff000040238940 fp =3D 0xffff000040238a70 >>>=20 >>> do_el0_sync() at handle_el0_sync+0x6c >>> pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 >>> sp =3D 0xffff000040238a80 fp =3D 0xffff000040238b90 >>>=20 >>> handle_el0_sync() at 0x38cc0 >>> pc =3D 0xffff0000006079e8 lr =3D 0x0000000000038cc0 >>> sp =3D 0xffff000040238ba0 fp =3D 0x0000ffffffffed00 >>>=20 >>> panic: sleeping thread >>> cpuid =3D 2 >>> time =3D 1493581440 >>> KDB: stack backtrace: >>> db_trace_self() at db_trace_self_wrapper+0x28 >>> pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000869cc >>> sp =3D 0xffff000065dfd320 fp =3D 0xffff000065dfd530 >>>=20 >>> db_trace_self_wrapper() at vpanic+0x164 >>> pc =3D 0xffff0000000869cc lr =3D 0xffff00000031d464 >>> sp =3D 0xffff000065dfd540 fp =3D 0xffff000065dfd5b0 >>>=20 >>> vpanic() at panic+0x4c >>> pc =3D 0xffff00000031d464 lr =3D 0xffff00000031d2fc >>> sp =3D 0xffff000065dfd5c0 fp =3D 0xffff000065dfd640 >>>=20 >>> panic() at propagate_priority+0x2d0 >>> pc =3D 0xffff00000031d2fc lr =3D 0xffff000000374558 >>> sp =3D 0xffff000065dfd650 fp =3D 0xffff000065dfd690 >>>=20 >>> propagate_priority() at turnstile_wait+0x340 >>> pc =3D 0xffff000000374558 lr =3D 0xffff00000037503c >>> sp =3D 0xffff000065dfd6a0 fp =3D 0xffff000065dfd6e0 >>>=20 >>> turnstile_wait() at __rw_wlock_hard+0x208 >>> pc =3D 0xffff00000037503c lr =3D 0xffff000000319138 >>> sp =3D 0xffff000065dfd6f0 fp =3D 0xffff000065dfd770 >>>=20 >>> __rw_wlock_hard() at pmap_enter+0xe98 >>> pc =3D 0xffff000000319138 lr =3D 0xffff000000615ea4 >>> sp =3D 0xffff000065dfd780 fp =3D 0xffff000065dfd810 >>>=20 >>> pmap_enter() at vm_fault_hold+0x28c >>> pc =3D 0xffff000000615ea4 lr =3D 0xffff0000005b9740 >>> sp =3D 0xffff000065dfd820 fp =3D 0xffff000065dfd970 >>>=20 >>> vm_fault_hold() at vm_fault+0x70 >>> pc =3D 0xffff0000005b9740 lr =3D 0xffff0000005b9464 >>> sp =3D 0xffff000065dfd980 fp =3D 0xffff000065dfd9b0 >>>=20 >>> vm_fault() at data_abort+0xe0 >>> pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 >>> sp =3D 0xffff000065dfd9c0 fp =3D 0xffff000065dfda70 >>>=20 >>> data_abort() at handle_el0_sync+0x6c >>> pc =3D 0xffff00000061ad94 lr =3D 0xffff0000006079e8 >>> sp =3D 0xffff000065dfda80 fp =3D 0xffff000065dfdb90 >>>=20 >>> handle_el0_sync() at 0x40040070 >>> pc =3D 0xffff0000006079e8 lr =3D 0x0000000040040070 >>> sp =3D 0xffff000065dfdba0 fp =3D 0x0000ffffffffeb00 >>>=20 >>> KDB: enter: panic >>> [ thread pid 709 tid 100086 ] >>> Stopped at kdb_enter+0x44: undefined d4200000 >>> db> >>=20 >> Another example failure is: >>=20 >> Fatal data abort: >> x0: 400a9000 >> x1: 1000 >> x2: 0 >> x3: 40 >> x4: 3f >> x5: fffffd00304e5000 >> x6: 2b52 >> x7: c >> x8: b >> x9: fffffd000076d5d0 >> x10: 68 >> x11: 40000000 >> x12: 704c5000 >> x13: 42b42003 >> x14: 42b42003 >> x15: 40000000 >> x16: c >> x17: ffffffffffffffff >> x18: ffff000065dd5310 >> x19: 800000000000000 >> x20: 1 >> x21: fffffd0002b43000 >> x22: 12000004556478b >> x23: f000000000000000 >> x24: fffffd0002b41bc8 >> x25: 40 >> x26: fffffd0002b42548 >> x27: 7b >> x28: 3 >> x29: ffff000065dd53c0 >> sp: ffff000065dd5310 >> lr: ffff0000006175d8 >> elr: ffff00000060589c >> spsr: 60000345 >> far: 400a9000 >> esr: 96000147 >> [ thread pid 715 tid 100078 ] >> Stopped at arm64_dcache_wb_range+0x18: undefined = d50b7a20 >> db> bt >> Tracing pid 715 tid 100078 td 0xfffffd00007849c0 >> db_trace_self() at db_stack_trace+0xf0 >> pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000840e0 >> sp =3D 0xffff000065dd4cb0 fp =3D 0xffff000065dd4ce0 >>=20 >> db_stack_trace() at db_command+0x23c >> pc =3D 0xffff0000000840e0 lr =3D 0xffff000000083d58 >> sp =3D 0xffff000065dd4cf0 fp =3D 0xffff000065dd4dd0 >>=20 >> db_command() at db_command_loop+0x60 >> pc =3D 0xffff000000083d58 lr =3D 0xffff000000083b00 >> sp =3D 0xffff000065dd4de0 fp =3D 0xffff000065dd4e00 >>=20 >> db_command_loop() at db_trap+0xf4 >> pc =3D 0xffff000000083b00 lr =3D 0xffff000000086b34 >> sp =3D 0xffff000065dd4e10 fp =3D 0xffff000065dd5030 >>=20 >> db_trap() at kdb_trap+0x180 >> pc =3D 0xffff000000086b34 lr =3D 0xffff00000035f650 >> sp =3D 0xffff000065dd5040 fp =3D 0xffff000065dd50a0 >>=20 >> kdb_trap() at data_abort+0x1a0 >> pc =3D 0xffff00000035f650 lr =3D 0xffff00000061ae54 >> sp =3D 0xffff000065dd50b0 fp =3D 0xffff000065dd5160 >>=20 >> data_abort() at handle_el1h_sync+0x70 >> pc =3D 0xffff00000061ae54 lr =3D 0xffff000000607870 >> sp =3D 0xffff000065dd5170 fp =3D 0xffff000065dd5280 >>=20 >> handle_el1h_sync() at pmap_remove_pages+0x2a8 >> pc =3D 0xffff000000607870 lr =3D 0xffff0000006175d4 >> sp =3D 0xffff000065dd5290 fp =3D 0xffff000065dd53c0 >>=20 >> pmap_remove_pages() at exec_new_vmspace+0x1a4 >> pc =3D 0xffff0000006175d4 lr =3D 0xffff0000002d9da0 >> sp =3D 0xffff000065dd53d0 fp =3D 0xffff000065dd5430 >>=20 >> exec_new_vmspace() at exec_elf64_imgact+0xa70 >> pc =3D 0xffff0000002d9da0 lr =3D 0xffff0000002b7c14 >> sp =3D 0xffff000065dd5440 fp =3D 0xffff000065dd5550 >>=20 >> exec_elf64_imgact() at kern_execve+0x664 >> pc =3D 0xffff0000002b7c14 lr =3D 0xffff0000002d8730 >> sp =3D 0xffff000065dd5560 fp =3D 0xffff000065dd58b0 >>=20 >> kern_execve() at sys_execve+0x54 >> pc =3D 0xffff0000002d8730 lr =3D 0xffff0000002d7d90 >> sp =3D 0xffff000065dd58c0 fp =3D 0xffff000065dd5930 >>=20 >> sys_execve() at do_el0_sync+0xa48 >> pc =3D 0xffff0000002d7d90 lr =3D 0xffff00000061b91c >> sp =3D 0xffff000065dd5940 fp =3D 0xffff000065dd5a70 >>=20 >> do_el0_sync() at handle_el0_sync+0x6c >> pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 >> sp =3D 0xffff000065dd5a80 fp =3D 0xffff000065dd5b90 >>=20 >> handle_el0_sync() at 0x24a90 >> pc =3D 0xffff0000006079e8 lr =3D 0x0000000000024a90 >> sp =3D 0xffff000065dd5ba0 fp =3D 0x0000ffffffffe7d0 >>=20 >> db>=20 Because Konstanin B. was not Cc'd/To'd previously I should have included the following background information about how this was run on a Odroid-C2 under UbuntuMate: qemu-system-aarch64 -m 1024M -enable-kvm -cpu host -machine virt \ -bios QEMU_EFI.fd -nographic \ -drive = format=3Draw,if=3Dnone,file=3DFreeBSD-12.0-CURRENT-arm64-aarch64.raw,id=3D= hd0 \ -device virtio-blk-device,drive=3Dhd0 \ -device virtio-net-device,netdev=3Dnet0 \ -netdev user,id=3Dnet0 \ -smp cpus=3D4 based on: = https://releases.linaro.org/components/kernel/uefi-linaro/16.02/release/qe= mu64/QEMU_EFI.fd and my build of head -r317015 turned into a .raw file. =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?934E8CA3-A100-47F8-B6F7-F49C83AA8EF0>