From owner-freebsd-arm@freebsd.org Sun Sep 10 08:34:39 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 EED33E04554 for ; Sun, 10 Sep 2017 08:34:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 ABE2B6B28C for ; Sun, 10 Sep 2017 08:34:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31289 invoked from network); 10 Sep 2017 08:39:56 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 10 Sep 2017 08:39:56 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Sun, 10 Sep 2017 04:34:32 -0400 (EDT) Received: (qmail 20269 invoked from network); 10 Sep 2017 08:34:32 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Sep 2017 08:34:32 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 67B17EC86EF; Sun, 10 Sep 2017 01:34:31 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r323246 Pine64+ 2GB context: boot1.efi (as bootaa64.efi), I had to revert to an older one that I had around; more Message-Id: <8419C238-702D-4BF7-89DB-EC649CD405A5@dsl-only.net> Date: Sun, 10 Sep 2017 01:34:30 -0700 To: FreeBSD Toolchain , freebsd-arm 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: Sun, 10 Sep 2017 08:34:40 -0000 When I attempted to use the result of: # cp -aRx /usr/obj/DESTDIRs/clang-cortexA53-installworld/boot/boot1.efi = /mnt/EFI/BOOT/ the pine64+ boot sequence got over and over a sequence like: U-Boot 2017.07 (Sep 06 2017 - 07:49:12 +0000) Allwinner Technology CPU: Allwinner A64 (SUN50I) Model: Pine64+ DRAM: 2 GiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment In: serial Out: serial . . . >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Load Path:=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80= "Synchronous Abort" handler, esr 0x96000004 ELR: bdf90b30 LR: bdf8fb6c x0 : 0000000000000000 x1 : 0000000000000000 x2 : 00000000bdffc000 x3 : 0000000040000000 x4 : 00000000b9f34d40 x5 : 0000000000000000 x6 : 0000000000000015 x7 : 0000000000000000 x8 : 00000000bdfa59b8 x9 : 000000000000001c x10: 0000000000000002 x11: 0000000000000000 x12: 0000000000000000 x13: 0000000000000000 x14: 0000000000000000 x15: 0000000000000000 x16: 0000000000000000 x17: 0000000000000000 x18: 00000000b9f39df8 x19: 0000000000000000 x20: 0000000000000000 x21: 0000000000000002 x22: 00000000b8f34c98 x23: 00000000b8f34c88 x24: 00000000b8f34ca0 x25: 00000000000007d0 x26: 00000000b8f34c90 x27: 00000000b8f2f198 x28: 0000000000000000 x29: 00000000b9f34de0 Resetting CPU ... resetting ... I found an old boot1.efi to copy over instead (from back in -r308??? time frames as I remember) and doing the replacement got past this point. Booting with the non-debug kernel appears to hang for a bit and then gets to a db> prompt and a bt showed (for example): (The console output for the register dump seems to always be incomplete and there is a wait to end up at the db> prompt. Note the data_abort closest to the fork_exit .) . . . Release APs APs not started CPU 0: ARM Cortex-A53 r0p4 affinity: 0 Instruction Set Attributes 0 =3D Instruction Set Attributes 1 =3D <0> Processor Features 0 =3D Processor Features 1 =3D <0> Memory Model Features 0 =3D <4k Granule,64k = Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> Memory Model Features 1 =3D <> Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 = Breakpoints,PMUv3,Debug v8> Debug Features 1 =3D <0> Auxiliary Features 0 =3D <0> Auxiliary Features 1 =3D <0> CPU 1: (null) (null) r0p0 affinity: 0 CPU 2: (null) (null) r0p0 affinity: 0 CPU 3: (null) (null) r0p0 affinity: 0 x0: ffff000000a1c000 x1: fffffd000103a[ thread pid 0 tid 100057 ] Stopped at thread_lock_flags_+0x298: ldr w4, [x3, #156] db> bt Tracing pid 0 tid 100057 td 0xfffffd000103a000 db_trace_self() at db_stack_trace+0xec pc =3D 0xffff000000613688 lr =3D 0xffff000000084db4 sp =3D 0xffff0000698f4260 fp =3D 0xffff0000698f4290 db_stack_trace() at db_command+0x224 pc =3D 0xffff000000084db4 lr =3D 0xffff000000084a3c sp =3D 0xffff0000698f42a0 fp =3D 0xffff0000698f4380 db_command() at db_command_loop+0x60 pc =3D 0xffff000000084a3c lr =3D 0xffff0000000847fc sp =3D 0xffff0000698f4390 fp =3D 0xffff0000698f43b0 db_command_loop() at db_trap+0xf4 pc =3D 0xffff0000000847fc lr =3D 0xffff000000087964 sp =3D 0xffff0000698f43c0 fp =3D 0xffff0000698f45e0 db_trap() at kdb_trap+0x180 pc =3D 0xffff000000087964 lr =3D 0xffff0000003693e0 sp =3D 0xffff0000698f45f0 fp =3D 0xffff0000698f4650 =20 kdb_trap() at do_el1h_sync+0x90 pc =3D 0xffff0000003693e0 lr =3D 0xffff00000062956c sp =3D 0xffff0000698f4660 fp =3D 0xffff0000698f4690 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff00000062956c lr =3D 0xffff000000615074 sp =3D 0xffff0000698f46a0 fp =3D 0xffff0000698f47b0 handle_el1h_sync() at kdb_enter+0x38 pc =3D 0xffff000000615074 lr =3D 0xffff000000368ac8 sp =3D 0xffff0000698f47c0 fp =3D 0xffff0000698f4850 kdb_enter() at vpanic+0x180 pc =3D 0xffff000000368ac8 lr =3D 0xffff000000326dd8 sp =3D 0xffff0000698f4860 fp =3D 0xffff0000698f48d0 vpanic() at panic+0x48 pc =3D 0xffff000000326dd8 lr =3D 0xffff000000326c54 sp =3D 0xffff0000698f48e0 fp =3D 0xffff0000698f4960 =20 panic() at data_abort+0x21c pc =3D 0xffff000000326c54 lr =3D 0xffff0000006298e8 sp =3D 0xffff0000698f4970 fp =3D 0xffff0000698f4a20 data_abort() at do_el1h_sync+0xfc pc =3D 0xffff0000006298e8 lr =3D 0xffff0000006295d8 sp =3D 0xffff0000698f4a30 fp =3D 0xffff0000698f4a60 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff0000006295d8 lr =3D 0xffff000000615074 sp =3D 0xffff0000698f4a70 fp =3D 0xffff0000698f4b80 handle_el1h_sync() at thread_lock_flags_+0x1a8 pc =3D 0xffff000000615074 lr =3D 0xffff000000309060 sp =3D 0xffff0000698f4b90 fp =3D 0xffff0000698f4c80 thread_lock_flags_() at statclock_cnt+0x11c pc =3D 0xffff000000309060 lr =3D 0xffff0000002c5b90 sp =3D 0xffff0000698f4c90 fp =3D 0xffff0000698f4cb0 =20 statclock_cnt() at handleevents+0x108 pc =3D 0xffff0000002c5b90 lr =3D 0xffff00000064ad84 sp =3D 0xffff0000698f4cc0 fp =3D 0xffff0000698f4d00 handleevents() at timercb+0xe0 pc =3D 0xffff00000064ad84 lr =3D 0xffff00000064b51c sp =3D 0xffff0000698f4d10 fp =3D 0xffff0000698f4d80 timercb() at arm_tmr_intr+0x58 pc =3D 0xffff00000064b51c lr =3D 0xffff000000600e5c sp =3D 0xffff0000698f4d90 fp =3D 0xffff0000698f4d90 arm_tmr_intr() at intr_event_handle+0x64 pc =3D 0xffff000000600e5c lr =3D 0xffff0000002edd50 sp =3D 0xffff0000698f4da0 fp =3D 0xffff0000698f4dd0 intr_event_handle() at intr_isrc_dispatch+0x30 pc =3D 0xffff0000002edd50 lr =3D 0xffff00000064d8ec sp =3D 0xffff0000698f4de0 fp =3D 0xffff0000698f4df0 =20 intr_isrc_dispatch() at arm_gic_intr+0xf0 pc =3D 0xffff00000064d8ec lr =3D 0xffff000000601848 sp =3D 0xffff0000698f4e00 fp =3D 0xffff0000698f4e50 arm_gic_intr() at intr_irq_handler+0x60 pc =3D 0xffff000000601848 lr =3D 0xffff00000064d6e0 sp =3D 0xffff0000698f4e60 fp =3D 0xffff0000698f4e80 intr_irq_handler() at handle_el1h_irq+0x70 pc =3D 0xffff00000064d6e0 lr =3D 0xffff000000615130 sp =3D 0xffff0000698f4e90 fp =3D 0xffff0000698f4fa0 handle_el1h_irq() at ns8250_putc+0x2c pc =3D 0xffff000000615130 lr =3D 0xffff00000019a570 sp =3D 0xffff0000698f4fb0 fp =3D 0xffff0000698f5050 ns8250_putc() at ns8250_putc+0x2c pc =3D 0xffff00000019a570 lr =3D 0xffff00000019a570 sp =3D 0xffff0000698f5060 fp =3D 0xffff0000698f5080 =20 ns8250_putc() at uart_cnputc+0x94 pc =3D 0xffff00000019a570 lr =3D 0xffff0000001a0860 sp =3D 0xffff0000698f5090 fp =3D 0xffff0000698f50c0 uart_cnputc() at cnputc+0x90 pc =3D 0xffff0000001a0860 lr =3D 0xffff0000002cb3a8 sp =3D 0xffff0000698f50d0 fp =3D 0xffff0000698f5120 cnputc() at cnputs+0xb4 pc =3D 0xffff0000002cb3a8 lr =3D 0xffff0000002cb7c8 sp =3D 0xffff0000698f5130 fp =3D 0xffff0000698f5150 cnputs() at putchar+0x158 pc =3D 0xffff0000002cb7c8 lr =3D 0xffff00000036f04c sp =3D 0xffff0000698f5160 fp =3D 0xffff0000698f51e0 putchar() at kvprintf+0xda8 pc =3D 0xffff00000036f04c lr =3D 0xffff00000036ec70 sp =3D 0xffff0000698f51f0 fp =3D 0xffff0000698f5300 =20 kvprintf() at vprintf+0x7c pc =3D 0xffff00000036ec70 lr =3D 0xffff00000036f838 sp =3D 0xffff0000698f5310 fp =3D 0xffff0000698f5420 vprintf() at printf+0x48 pc =3D 0xffff00000036f838 lr =3D 0xffff00000036f7ac sp =3D 0xffff0000698f5430 fp =3D 0xffff0000698f54b0 printf() at print_registers+0x4c pc =3D 0xffff00000036f7ac lr =3D 0xffff00000062966c sp =3D 0xffff0000698f54c0 fp =3D 0xffff0000698f54f0 print_registers() at data_abort+0x1f0 pc =3D 0xffff00000062966c lr =3D 0xffff0000006298bc sp =3D 0xffff0000698f5500 fp =3D 0xffff0000698f55b0 data_abort() at do_el1h_sync+0xfc pc =3D 0xffff0000006298bc lr =3D 0xffff0000006295d8 sp =3D 0xffff0000698f55c0 fp =3D 0xffff0000698f55f0 =20 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff0000006295d8 lr =3D 0xffff000000615074 sp =3D 0xffff0000698f5600 fp =3D 0xffff0000698f5710 handle_el1h_sync() at sched_switch+0x54c pc =3D 0xffff000000615074 lr =3D 0xffff000000351dd4 sp =3D 0xffff0000698f5720 fp =3D 0xffff0000698f5800 sched_switch() at mi_switch+0x118 pc =3D 0xffff000000351dd4 lr =3D 0xffff000000330c14 sp =3D 0xffff0000698f5810 fp =3D 0xffff0000698f5830 mi_switch() at taskqgroup_binder+0x74 pc =3D 0xffff000000330c14 lr =3D 0xffff000000367864 sp =3D 0xffff0000698f5840 fp =3D 0xffff0000698f5860 taskqgroup_binder() at gtaskqueue_run_locked+0x160 pc =3D 0xffff000000367864 lr =3D 0xffff000000367710 sp =3D 0xffff0000698f5870 fp =3D 0xffff0000698f58e0 =20 gtaskqueue_run_locked() at gtaskqueue_thread_loop+0xcc pc =3D 0xffff000000367710 lr =3D 0xffff0000003672c8 sp =3D 0xffff0000698f58f0 fp =3D 0xffff0000698f5910 gtaskqueue_thread_loop() at fork_exit+0x94 pc =3D 0xffff0000003672c8 lr =3D 0xffff0000002eab20 sp =3D 0xffff0000698f5920 fp =3D 0xffff0000698f5950 fork_exit() at fork_trampoline+0x10 pc =3D 0xffff0000002eab20 lr =3D 0xffff00000062934c sp =3D 0xffff0000698f5960 fp =3D 0x0000000000000000 Booting with a debug kernel worked fine. (This matches up with past reports about "recent" pine64+ handling.) But trying to have the root file system on a USB SSD drive failed to see the USB drive at all. (This matches up with past reports about "recent" pine64+ handling.) =46rom a separate non-debug kernel boot attempt: (remember the "thread_lock_flags_+0x298: ldr w4, [x3, #156]" but also note x8 in addition to x3) db> show reg spsr 0x96000004000003c5 x0 0xffff00000069b000 $d.2+0x1ac x1 0x2 x2 0xffff00000069ba48 $d.5+0x1d x3 0xdeadc0d8 <<<<<<<<< Note the "0xdeadc0d8" x4 0x3 x5 0xffff000000610cf0 generic_bs_barrier x6 0 x7 0x40 $d.14 x8 0xdeadc0de <<<<<<<<< Note the "0xdeadc0de" x9 0 x10 0x975c860b x11 0x975c860b x12 0x51eb850 x13 0x4 x14 0x66 $d.9+0x26 x15 0xffff0000007004ce hex2ascii_data x16 0 x17 0 x18 0xffff00006990ec10 x19 0xfffffd000103a000 x20 0xffff000000bcee70 blocked_lock+0x18 x21 0xffff00000080e5a8 sdt_lockstat___spin__release x22 0x3938700 x23 0xfffffd000103a000 x24 0xffff000000bcee58 blocked_lock x25 0x4 x26 0x98967f x27 0xffff0000009ef000 next_to_notify x28 0xffff000000bb9000 proc0+0x4f8 x29 0xffff00006990ec80 lr 0xffff000000309064 thread_lock_flags_+0x1ac elr 0xffff000000309154 thread_lock_flags_+0x29c sp 0xffff00006990ec10 thread_lock_flags_+0x298: ldr w4, [x3, #156] db> bt Tracing pid 0 tid 100057 td 0xfffffd000103a000 db_trace_self() at db_stack_trace+0xec pc =3D 0xffff000000613688 lr =3D 0xffff000000084db4 sp =3D 0xffff00006990e260 fp =3D 0xffff00006990e290 db_stack_trace() at db_command+0x224 pc =3D 0xffff000000084db4 lr =3D 0xffff000000084a3c sp =3D 0xffff00006990e2a0 fp =3D 0xffff00006990e380 db_command() at db_command_loop+0x60 pc =3D 0xffff000000084a3c lr =3D 0xffff0000000847fc sp =3D 0xffff00006990e390 fp =3D 0xffff00006990e3b0 db_command_loop() at db_trap+0xf4 pc =3D 0xffff0000000847fc lr =3D 0xffff000000087964 sp =3D 0xffff00006990e3c0 fp =3D 0xffff00006990e5e0 db_trap() at kdb_trap+0x180 pc =3D 0xffff000000087964 lr =3D 0xffff0000003693e0 sp =3D 0xffff00006990e5f0 fp =3D 0xffff00006990e650 =20 kdb_trap() at do_el1h_sync+0x90 pc =3D 0xffff0000003693e0 lr =3D 0xffff00000062956c sp =3D 0xffff00006990e660 fp =3D 0xffff00006990e690 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff00000062956c lr =3D 0xffff000000615074 sp =3D 0xffff00006990e6a0 fp =3D 0xffff00006990e7b0 handle_el1h_sync() at kdb_enter+0x38 pc =3D 0xffff000000615074 lr =3D 0xffff000000368ac8 sp =3D 0xffff00006990e7c0 fp =3D 0xffff00006990e850 kdb_enter() at vpanic+0x180 pc =3D 0xffff000000368ac8 lr =3D 0xffff000000326dd8 sp =3D 0xffff00006990e860 fp =3D 0xffff00006990e8d0 vpanic() at panic+0x48 pc =3D 0xffff000000326dd8 lr =3D 0xffff000000326c54 sp =3D 0xffff00006990e8e0 fp =3D 0xffff00006990e960 =20 panic() at data_abort+0x21c pc =3D 0xffff000000326c54 lr =3D 0xffff0000006298e8 sp =3D 0xffff00006990e970 fp =3D 0xffff00006990ea20 data_abort() at do_el1h_sync+0xfc pc =3D 0xffff0000006298e8 lr =3D 0xffff0000006295d8 sp =3D 0xffff00006990ea30 fp =3D 0xffff00006990ea60 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff0000006295d8 lr =3D 0xffff000000615074 sp =3D 0xffff00006990ea70 fp =3D 0xffff00006990eb80 handle_el1h_sync() at thread_lock_flags_+0x1a8 pc =3D 0xffff000000615074 lr =3D 0xffff000000309060 sp =3D 0xffff00006990eb90 fp =3D 0xffff00006990ec80 thread_lock_flags_() at statclock_cnt+0x11c pc =3D 0xffff000000309060 lr =3D 0xffff0000002c5b90 sp =3D 0xffff00006990ec90 fp =3D 0xffff00006990ecb0 =20 statclock_cnt() at handleevents+0x108 pc =3D 0xffff0000002c5b90 lr =3D 0xffff00000064ad84 sp =3D 0xffff00006990ecc0 fp =3D 0xffff00006990ed00 handleevents() at timercb+0xe0 pc =3D 0xffff00000064ad84 lr =3D 0xffff00000064b51c sp =3D 0xffff00006990ed10 fp =3D 0xffff00006990ed80 timercb() at arm_tmr_intr+0x58 pc =3D 0xffff00000064b51c lr =3D 0xffff000000600e5c sp =3D 0xffff00006990ed90 fp =3D 0xffff00006990ed90 arm_tmr_intr() at intr_event_handle+0x64 pc =3D 0xffff000000600e5c lr =3D 0xffff0000002edd50 sp =3D 0xffff00006990eda0 fp =3D 0xffff00006990edd0 intr_event_handle() at intr_isrc_dispatch+0x30 pc =3D 0xffff0000002edd50 lr =3D 0xffff00000064d8ec sp =3D 0xffff00006990ede0 fp =3D 0xffff00006990edf0 =20 intr_isrc_dispatch() at arm_gic_intr+0xf0 pc =3D 0xffff00000064d8ec lr =3D 0xffff000000601848 sp =3D 0xffff00006990ee00 fp =3D 0xffff00006990ee50 arm_gic_intr() at intr_irq_handler+0x60 pc =3D 0xffff000000601848 lr =3D 0xffff00000064d6e0 sp =3D 0xffff00006990ee60 fp =3D 0xffff00006990ee80 intr_irq_handler() at handle_el1h_irq+0x70 pc =3D 0xffff00000064d6e0 lr =3D 0xffff000000615130 sp =3D 0xffff00006990ee90 fp =3D 0xffff00006990efa0 handle_el1h_irq() at ns8250_putc+0x2c pc =3D 0xffff000000615130 lr =3D 0xffff00000019a570 sp =3D 0xffff00006990efb0 fp =3D 0xffff00006990f050 ns8250_putc() at ns8250_putc+0x2c pc =3D 0xffff00000019a570 lr =3D 0xffff00000019a570 sp =3D 0xffff00006990f060 fp =3D 0xffff00006990f080 =20 ns8250_putc() at uart_cnputc+0x94 pc =3D 0xffff00000019a570 lr =3D 0xffff0000001a0860 sp =3D 0xffff00006990f090 fp =3D 0xffff00006990f0c0 uart_cnputc() at cnputc+0x90 pc =3D 0xffff0000001a0860 lr =3D 0xffff0000002cb3a8 sp =3D 0xffff00006990f0d0 fp =3D 0xffff00006990f120 cnputc() at cnputs+0xb4 pc =3D 0xffff0000002cb3a8 lr =3D 0xffff0000002cb7c8 sp =3D 0xffff00006990f130 fp =3D 0xffff00006990f150 cnputs() at putchar+0x158 pc =3D 0xffff0000002cb7c8 lr =3D 0xffff00000036f04c sp =3D 0xffff00006990f160 fp =3D 0xffff00006990f1e0 putchar() at kvprintf+0xda8 pc =3D 0xffff00000036f04c lr =3D 0xffff00000036ec70 sp =3D 0xffff00006990f1f0 fp =3D 0xffff00006990f300 =20 kvprintf() at vprintf+0x7c pc =3D 0xffff00000036ec70 lr =3D 0xffff00000036f838 sp =3D 0xffff00006990f310 fp =3D 0xffff00006990f420 vprintf() at printf+0x48 pc =3D 0xffff00000036f838 lr =3D 0xffff00000036f7ac sp =3D 0xffff00006990f430 fp =3D 0xffff00006990f4b0 printf() at print_registers+0x4c pc =3D 0xffff00000036f7ac lr =3D 0xffff00000062966c sp =3D 0xffff00006990f4c0 fp =3D 0xffff00006990f4f0 print_registers() at data_abort+0x1f0 pc =3D 0xffff00000062966c lr =3D 0xffff0000006298bc sp =3D 0xffff00006990f500 fp =3D 0xffff00006990f5b0 data_abort() at do_el1h_sync+0xfc pc =3D 0xffff0000006298bc lr =3D 0xffff0000006295d8 sp =3D 0xffff00006990f5c0 fp =3D 0xffff00006990f5f0 =20 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff0000006295d8 lr =3D 0xffff000000615074 sp =3D 0xffff00006990f600 fp =3D 0xffff00006990f710 handle_el1h_sync() at sched_switch+0x54c pc =3D 0xffff000000615074 lr =3D 0xffff000000351dd4 sp =3D 0xffff00006990f720 fp =3D 0xffff00006990f800 sched_switch() at mi_switch+0x118 pc =3D 0xffff000000351dd4 lr =3D 0xffff000000330c14 sp =3D 0xffff00006990f810 fp =3D 0xffff00006990f830 mi_switch() at taskqgroup_binder+0x74 pc =3D 0xffff000000330c14 lr =3D 0xffff000000367864 sp =3D 0xffff00006990f840 fp =3D 0xffff00006990f860 taskqgroup_binder() at gtaskqueue_run_locked+0x160 pc =3D 0xffff000000367864 lr =3D 0xffff000000367710 sp =3D 0xffff00006990f870 fp =3D 0xffff00006990f8e0 =20 gtaskqueue_run_locked() at gtaskqueue_thread_loop+0xcc pc =3D 0xffff000000367710 lr =3D 0xffff0000003672c8 sp =3D 0xffff00006990f8f0 fp =3D 0xffff00006990f910 gtaskqueue_thread_loop() at fork_exit+0x94 pc =3D 0xffff0000003672c8 lr =3D 0xffff0000002eab20 sp =3D 0xffff00006990f920 fp =3D 0xffff00006990f950 fork_exit() at fork_trampoline+0x10 pc =3D 0xffff0000002eab20 lr =3D 0xffff00000062934c sp =3D 0xffff00006990f960 fp =3D 0x0000000000000000 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Sep 10 16:57:36 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 BA679E1B25F for ; Sun, 10 Sep 2017 16:57:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 A93CD7E95A for ; Sun, 10 Sep 2017 16:57:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v8AGvaQd015598 for ; Sun, 10 Sep 2017 16:57:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 222200] aarch64 FreeBSD 11 image not available for RPI 3 Date: Sun, 10 Sep 2017 16:57:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tarjei@online.no X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sun, 10 Sep 2017 16:57:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222200 Bug ID: 222200 Summary: aarch64 FreeBSD 11 image not available for RPI 3 Product: Base System Version: 11.1-RELEASE Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: tarjei@online.no There seems to be a lack of 64bit aarch64 images for FreeBSD 11 in general.= The images posted at=20 https://download.freebsd.org/ftp/releases/arm64/aarch64/ISO-IMAGES/11.1/ https://download.freebsd.org/ftp/releases/arm64/aarch64/ISO-IMAGES/11.0/ seems to not be suitable for any of the popular aarch64 devices. I notice that there is a lot of images for devices like the Raspberry PI 3 = in the FreeBSD 12.0-CURRENT snapshot section. https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/12.0/ The corresponding 11.0 section do not have images for these devices. I find it weird that there is a lot of support in FreeBSD 12, but none for FreeBSD 11. And it is also annoying since I happen to need aarch64 FreeBSD = 11 in order to test the gcc6-aux port which have an Ada compiler which does not work on FreeBSD 12. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sun Sep 10 17:43:44 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 A8B51E1D7AF; Sun, 10 Sep 2017 17:43:44 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (kientzle.com [142.254.26.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E7547FE45; Sun, 10 Sep 2017 17:43:43 +0000 (UTC) (envelope-from tim@kientzle.com) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id v8AHPl60094185; Sun, 10 Sep 2017 17:25:47 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.101] (192.168.1.101 [192.168.1.101]) by kientzle.com with SMTP id xfpvih96bs4hkrksnbzxwwmqr6; Sun, 10 Sep 2017 17:25:47 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Missing in action during arm64/aarch64 builds: no pine64_plus.dtb to be found from buildkernel, installkernel, or u-boot-pine64 From: Tim Kientzle In-Reply-To: Date: Sun, 10 Sep 2017 10:26:22 -0700 Cc: FreeBSD Toolchain , freebsd-arm , FreeBSD current Content-Transfer-Encoding: 7bit Message-Id: <5D56FE2E-DB64-4038-BD5B-8C1AD6B1A69D@kientzle.com> References: To: Mark Millard 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: Sun, 10 Sep 2017 17:43:44 -0000 > On Sep 9, 2017, at 4:35 PM, Mark Millard wrote: > > crochet goes to the trouble to have logic to > build and install pine64_plus.dtb (based on > arm64/pine64_plus.dts ). > I'm not sure about Pine64 in particular, but generally only the DTS file is actually required. Crochet tries to provide a dtb file (converting the dts if necessary) partly for documentation and partly to make it easier to edit the device tree file. This is especially convenient in cases where the original DTB file depends heavily on other include files; converting DTS to DTB gives you a fully standalone DTB file that can be edited (for example, to enable additional serial ports) and recompiled without having the full source tree available. This is probably less important now that overlay DTBs are more commonly supported. Tim From owner-freebsd-arm@freebsd.org Sun Sep 10 19:51:15 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 55A3EE24196 for ; Sun, 10 Sep 2017 19:51:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 1450E8425A for ; Sun, 10 Sep 2017 19:51:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2601 invoked from network); 10 Sep 2017 19:56:37 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 10 Sep 2017 19:56:37 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Sun, 10 Sep 2017 15:51:13 -0400 (EDT) Received: (qmail 7880 invoked from network); 10 Sep 2017 19:51:12 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Sep 2017 19:51:12 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id E6878EC7888; Sun, 10 Sep 2017 12:51:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Missing in action during arm64/aarch64 builds: no pine64_plus.dtb to be found from buildkernel, installkernel, or u-boot-pine64 From: Mark Millard In-Reply-To: <5D56FE2E-DB64-4038-BD5B-8C1AD6B1A69D@kientzle.com> Date: Sun, 10 Sep 2017 12:51:11 -0700 Cc: FreeBSD Toolchain , freebsd-arm , FreeBSD current Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D56FE2E-DB64-4038-BD5B-8C1AD6B1A69D@kientzle.com> To: Tim Kientzle 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: Sun, 10 Sep 2017 19:51:15 -0000 On 2017-Sep-10, at 10:26 AM, Tim Kientzle wrote: >> On Sep 9, 2017, at 4:35 PM, Mark Millard = wrote: >>=20 >> crochet goes to the trouble to have logic to >> build and install pine64_plus.dtb (based on >> arm64/pine64_plus.dts ). >>=20 >=20 > I'm not sure about Pine64 in particular, but generally > only the DTS file is actually required. [Note: I used crochet source code to figure out a set of manual steps sufficient to produce a pine64_plus.dtb to copy to the boot msdosfs file system.] Some of the #include structure that the existing pine64_plus.dts.dts depends on: # grep "#include" /usr/src/sys = /usr/src/sys/boot/fdt/dts/arm64/pine64_plus.dts /usr/src/sys/boot/fdt/dts/arm64/pine64_plus.dts:#include = "sun50i-a64-pine64-plus.dts" /usr/src/sys/boot/fdt/dts/arm64/pine64_plus.dts:#include "a64.dtsi" /usr/src/sys/boot/fdt/dts/arm64/pine64_plus.dts:#include = # grep "#include" /usr/src/sys = /usr/src/sys/boot/fdt/dts/arm64/sun50i-a64-pine64-plus.dts /usr/src/sys/boot/fdt/dts/arm64/sun50i-a64-pine64-plus.dts:#include = "sun50i-a64-pine64-common.dtsi" # grep "#include" /usr/src/sys = /usr/src/sys/boot/fdt/dts/arm64/pine64_plus.dts /usr/src/sys/boot/fdt/dts/arm64/pine64_plus.dts:#include = "sun50i-a64-pine64-plus.dts" /usr/src/sys/boot/fdt/dts/arm64/pine64_plus.dts:#include "a64.dtsi" /usr/src/sys/boot/fdt/dts/arm64/pine64_plus.dts:#include = # grep "#include" /usr/src/sys = /usr/src/sys/boot/fdt/dts/arm64/sun50i-a64-pine64-plus.dts /usr/src/sys/boot/fdt/dts/arm64/sun50i-a64-pine64-plus.dts:#include = "sun50i-a64-pine64-common.dtsi" # grep "#include" /usr/src/sys = /usr/src/sys/boot/fdt/dts/arm64/sun50i-a64-pine64-common.dtsi /usr/src/sys/boot/fdt/dts/arm64/sun50i-a64-pine64-common.dtsi:#include = "sun50i-a64.dtsi" # grep "#include" /usr/src/sys = /usr/src/sys/boot/fdt/dts/arm64/sun50i-a64.dtsi=20 /usr/src/sys/boot/fdt/dts/arm64/sun50i-a64.dtsi:#include = /usr/src/sys/boot/fdt/dts/arm64/sun50i-a64.dtsi:#include = # grep "#include" /usr/src/sys /usr/src/sys/boot/fdt/dts/arm64/a64.dtsi=20= (Yep: nothing for that last one.) I would not guess that the full structure is a appropriate as a substitute for the dtb/pine64_plus.dtb part of the msdosfs partition for booting the Pine64+ 2GB : # find /mnt -print /mnt /mnt/startup.nsh /mnt/EFI /mnt/EFI/BOOT /mnt/EFI/BOOT/bootaa64.efi /mnt/dtb /mnt/dtb/pine64_plus.dtb /mnt/System Volume Information /mnt/System Volume Information/WPSettings.dat # ls -lt /usr/local/share/u-boot/u-boot-pine64/u-boot-sunxi-with-spl.bin=20= -rw-r--r-- 1 root wheel 505940 Sep 6 00:49 = /usr/local/share/u-boot/u-boot-pine64/u-boot-sunxi-with-spl.bin (*.bin dd'd appropriately.) So there still seems to be a lack of appropriate .dt* material for direct use/placement on the boot media. Instead manual extra steps are required relative to *.dt* files. > Crochet tries to provide a dtb file (converting the dts if necessary) > partly for documentation and partly to make it easier to edit the > device tree file. >=20 > This is especially convenient in cases where the > original DTB file depends heavily on other include files; > converting DTS to DTB gives you a fully standalone DTB > file that can be edited (for example, to enable additional > serial ports) and recompiled without having the full source > tree available. The above is the kind of context that the Pine64+'s have. It does not appear to me that the existing pine64_plus.dts is set up for more direct use (even with other supporting files). > This is probably less important now that overlay DTBs are > more commonly supported. Whatever this is, it seems to not be in use for much (any?) of the Pine64+ structuring of such things in head -r323246 . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Sep 10 20:14:22 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 DB509E002C0 for ; Sun, 10 Sep 2017 20:14:22 +0000 (UTC) (envelope-from che@bein.link) Received: from mail.bein.link (bein.link [37.252.124.82]) (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 A24FA84FA5 for ; Sun, 10 Sep 2017 20:14:22 +0000 (UTC) (envelope-from che@bein.link) Received: from mail.bein.link (unknown [172.16.32.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.bein.link (Postfix) with ESMTPSA id 19B8524C196 for ; Sun, 10 Sep 2017 20:05:50 +0000 (UTC) Mime-Version: 1.0 Date: Sun, 10 Sep 2017 20:05:49 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: RainLoop/1.11.1 From: "Maxim Filimonov" Message-ID: <96b2c29572af7ef10b5127720bf85724@bein.link> Subject: Raspberry Pi 2 i2c doesn't seem to work To: freebsd-arm@freebsd.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=bein.link; s=mail; t=1505073950; bh=TDjZhHN0+m+L5mmBP1Fh1hUYX3A=; h=Mime-Version:Date:Content-Type:Content-Transfer-Encoding:From:Message-ID:Subject:To; b=oMT4SHfuzVnn8DEESnMnb+/Kv9QVSOl/2RQjgyKxNKz6Swj6JvbfoVPoxLU3a3qtTxbQWZgooNO4nhVuZaXlJ/FPyRl49xxkn+Kfb7CueorBwbq0Gscsa4Tg0dGfUdwK6yOARSk1edS7vW0t6T0ZLdZ0sybxw9QmvNmWFP4NeY0= 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: Sun, 10 Sep 2017 20:14:23 -0000 Hello everyone,=0A=0AI understand something has been discussed on this ma= tter, however Google doesn't say anything.=0AI have a Raspberry Pi 2, and= currently I installed FreeBSD 11.1-STABLE on it.=0AWorks fine, but when = I try to detect i2c devices (using `i2c -s -f /dev/iic1`), it shows nothi= ng.=0Aktrace/kdump show it has "Device not configured" on every address.= =0AOn Linux, the device (address 0x77) detects just fine.=0AWhat am I mis= sing? Do I have to configure GPIO pins separately?=0AThanks in advance.= =0A=0A=0A=0A=0A-----=0Awbr, Maxim V Filimonov From owner-freebsd-arm@freebsd.org Sun Sep 10 20:18:01 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 18AABE005F1 for ; Sun, 10 Sep 2017 20:18:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 D9F2879D for ; Sun, 10 Sep 2017 20:18:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22e.google.com with SMTP id c195so13189469itb.1 for ; Sun, 10 Sep 2017 13:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=A3idJGx4ceZlOmUpu1XJ4ydF0ZukLG2YE3nvrHGCkkU=; b=cx+l1MtCXyfUNqHOeITwlA0w2IV2O0qdGrnqxCWoVUbJZr7zwbcr0pylku2IrPX6DX MUSDLEK/alMwnsRalnDh7e6cLcGxkmTz+DFZvz/J8p2XB1Ye9+BMxPhe03HrtCdm6rEI /fUx6vpf67ROY7veGY3gOl1YZ/ulGRwPqKKjzTZGaQbbGi1o4Fqxe7Fd5znE3XwEMAfw gCsWHsI7I5R9awPL68j6b7/RUvxNhryTP744kQb8u/1nSTSXL411frX2cCPep9F0d7xb 2NWNcJM9D64Dsp1yx/wHmTsjWMfUH706Mm3Rx3lDfg8RxyhAIx7L46DaPzZbxbeiEE6X tkXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=A3idJGx4ceZlOmUpu1XJ4ydF0ZukLG2YE3nvrHGCkkU=; b=eBrQe9wJEBqHrHdrAETO0UfdYi5zXo+F7ifDEbECkuXX+awHML1sql3VEHUH1S8NIH T/LcNpO5RRe/1zZjyMHZTYV68/FGQG99Y24PZjnp9YOUH45WV0k7bGZz2iBuTWQHkPDz hNrt0wYVusJcP+p1AtHCtInSD+Zomrl4JgyWcib1ryEMNsu0wzBey9p1Yzvpfkv+bR1F vDyoy2x4VSc/vRJTAiTVkIiyEE0W3beb9VvLT5HwD1AcwhgmaI5v/qd577Mz50eYYRwb urJxsksPoE1lqLD+XwMZr+i0X6mCr9zqPGnv0xMJRp2YxCmvbSvfOjH67fl2aAXwb58p 88Lg== X-Gm-Message-State: AHPjjUgGhOt3yOC5tIVKPJkd0XVic4aS6qYdWgYdukQQ8QY1+/ZoCc4q dCYd659UjzhZOHakb0LFCClvF2IShKTW X-Google-Smtp-Source: ADKCNb6XTy2Xw937ItKxemiJlPxSiSuZMfP7cEZ4dihdbaHI71e+jT4WfCtvh21giyJbaV/CnY4Em+h4uwEijFCxjjM= X-Received: by 10.36.179.79 with SMTP id z15mr10580297iti.26.1505074679975; Sun, 10 Sep 2017 13:17:59 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Sun, 10 Sep 2017 13:17:59 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:146f:d629:d0:a2f2] In-Reply-To: <8419C238-702D-4BF7-89DB-EC649CD405A5@dsl-only.net> References: <8419C238-702D-4BF7-89DB-EC649CD405A5@dsl-only.net> From: Warner Losh Date: Sun, 10 Sep 2017 14:17:59 -0600 X-Google-Sender-Auth: 8d09KCwlbPebyo10JJsgvQRLfjU Message-ID: Subject: Re: head -r323246 Pine64+ 2GB context: boot1.efi (as bootaa64.efi), I had to revert to an older one that I had around; more To: Mark Millard Cc: FreeBSD Toolchain , freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Sun, 10 Sep 2017 20:18:01 -0000 On Sun, Sep 10, 2017 at 2:34 AM, Mark Millard wrote: > When I attempted to use the result of: > > # cp -aRx /usr/obj/DESTDIRs/clang-cortexA53-installworld/boot/boot1.efi > /mnt/EFI/BOOT/ > > the pine64+ boot sequence got over and over > a sequence like: > > U-Boot 2017.07 (Sep 06 2017 - 07:49:12 +0000) Allwinner Technology > > CPU: Allwinner A64 (SUN50I) > Model: Pine64+ > DRAM: 2 GiB > MMC: SUNXI SD/MMC: 0 > *** Warning - bad CRC, using default environment > > In: serial > Out: serial > . . . > >> FreeBSD EFI boot block > Loader path: /boot/loader.efi > > Initializing modules: ZFS UFS > Load Path:=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8= =80 > "Synchronous Abort" handler, esr 0x96000004 > ELR: bdf90b30 > LR: bdf8fb6c > x0 : 0000000000000000 x1 : 0000000000000000 > x2 : 00000000bdffc000 x3 : 0000000040000000 > x4 : 00000000b9f34d40 x5 : 0000000000000000 > x6 : 0000000000000015 x7 : 0000000000000000 > x8 : 00000000bdfa59b8 x9 : 000000000000001c > x10: 0000000000000002 x11: 0000000000000000 > x12: 0000000000000000 x13: 0000000000000000 > x14: 0000000000000000 x15: 0000000000000000 > x16: 0000000000000000 x17: 0000000000000000 > x18: 00000000b9f39df8 x19: 0000000000000000 > x20: 0000000000000000 x21: 0000000000000002 > x22: 00000000b8f34c98 x23: 00000000b8f34c88 > x24: 00000000b8f34ca0 x25: 00000000000007d0 > x26: 00000000b8f34c90 x27: 00000000b8f2f198 > x28: 0000000000000000 x29: 00000000b9f34de0 > > Resetting CPU ... > > resetting ... > It would be super helpful if you could bisect the change that caused this. Warner From owner-freebsd-arm@freebsd.org Sun Sep 10 21:18:31 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 E8394E034A0 for ; Sun, 10 Sep 2017 21:18:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 9916D2439 for ; Sun, 10 Sep 2017 21:18:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1426 invoked from network); 10 Sep 2017 21:18:29 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 10 Sep 2017 21:18:29 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Sun, 10 Sep 2017 17:18:29 -0400 (EDT) Received: (qmail 418 invoked from network); 10 Sep 2017 21:18:28 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Sep 2017 21:18:28 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 42AB0EC8A8A; Sun, 10 Sep 2017 14:18:28 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r323246 Pine64+ 2GB context: boot1.efi (as bootaa64.efi), I had to revert to an older one that I had around; more From: Mark Millard In-Reply-To: Date: Sun, 10 Sep 2017 14:18:27 -0700 Cc: FreeBSD Toolchain , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <06E8015B-89F8-4789-B876-59B8624D1207@dsl-only.net> References: <8419C238-702D-4BF7-89DB-EC649CD405A5@dsl-only.net> To: Warner Losh 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: Sun, 10 Sep 2017 21:18:32 -0000 On 2017-Sep-10, at 1:17 PM, Warner Losh wrote: > On Sun, Sep 10, 2017 at 2:34 AM, Mark Millard = wrote: > When I attempted to use the result of: >=20 > # cp -aRx = /usr/obj/DESTDIRs/clang-cortexA53-installworld/boot/boot1.efi = /mnt/EFI/BOOT/ >=20 > the pine64+ boot sequence got over and over > a sequence like: >=20 > U-Boot 2017.07 (Sep 06 2017 - 07:49:12 +0000) Allwinner Technology >=20 > CPU: Allwinner A64 (SUN50I) > Model: Pine64+ > DRAM: 2 GiB > MMC: SUNXI SD/MMC: 0 > *** Warning - bad CRC, using default environment >=20 > In: serial > Out: serial > . . . > >> FreeBSD EFI boot block > Loader path: /boot/loader.efi >=20 > Initializing modules: ZFS UFS > Load Path:=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8= =80 > "Synchronous Abort" handler, esr 0x96000004 > ELR: bdf90b30 > LR: bdf8fb6c > x0 : 0000000000000000 x1 : 0000000000000000 > x2 : 00000000bdffc000 x3 : 0000000040000000 > x4 : 00000000b9f34d40 x5 : 0000000000000000 > x6 : 0000000000000015 x7 : 0000000000000000 > x8 : 00000000bdfa59b8 x9 : 000000000000001c > x10: 0000000000000002 x11: 0000000000000000 > x12: 0000000000000000 x13: 0000000000000000 > x14: 0000000000000000 x15: 0000000000000000 > x16: 0000000000000000 x17: 0000000000000000 > x18: 00000000b9f39df8 x19: 0000000000000000 > x20: 0000000000000000 x21: 0000000000000002 > x22: 00000000b8f34c98 x23: 00000000b8f34c88 > x24: 00000000b8f34ca0 x25: 00000000000007d0 > x26: 00000000b8f34c90 x27: 00000000b8f2f198 > x28: 0000000000000000 x29: 00000000b9f34de0 >=20 > Resetting CPU ... >=20 > resetting ... >=20 > It would be super helpful if you could bisect the change that caused = this. I'm doing some other experiments first but I'll probably take a stab at it if things seem stable enough. Pine64+ has multiple problems currently. (It regressed some time back.) Unfortunately I do not have a known way to reproduce the older boot1.efi file fully. I'll have to explore that part to have a known-good low bound. If I'm lucky the first try from the general time frame will happen to work. Do to other issues I'm jumping from pre-INO64 to modern without having tracked in the middle. I will note that the older boot1.efi (as bootaa64.efi) output is different (no "Load Path:")=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80=EE= =A8=80=EE=A8=80=EE=A8=80: >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Probing 3 block devices.....* done ZFS found no pools UFS found 1 partition Consoles: EFI console =20 Command line arguments: loader.efi Image base: 0xb6dbb008 EFI version: 2.05 EFI Firmware: Das U-boot (rev 0.00) The failing one has garbage (invisible) text after "Load Path:". =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Sep 10 22:17:41 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 1F38CE06260 for ; Sun, 10 Sep 2017 22:17:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 D200B3FE3 for ; Sun, 10 Sep 2017 22:17:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x236.google.com with SMTP id c195so13508927itb.1 for ; Sun, 10 Sep 2017 15:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=iNWcRYy+QM50go1pLAJv1rYfdG+U4L3ts4s6rD+t42g=; b=oRkTFuL28kSa4K1PVCrr5ZQL3rY5YJ2Kxoz24u9YaO+2z1NibOq6ymDY5UdLYMegXP Jdhe3vTMVKvBQUS5+EqrUgdZ6VQGCOihXr2glIGlezluG4AoJHDyif7UbPGpHtZ0qkPH xHHC4YBvwG0AijLCbUYe9Qj3MGDYqw7lAC9ZFpf+RYEkO527DNNVgxVHX097MTzc+fF/ fRSWBuG4xJsJqB/m7KtUB4XfCauOBVcPKhVPlGseJsi2Oc9745PNwcatkf9JYEapkAni g8UNAX3Q9ItBmWneblb4yBU0qmzLQnP2Chk5Qu4hGL57mlV3EqZNos6nG0lPeMZF05c2 3PBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=iNWcRYy+QM50go1pLAJv1rYfdG+U4L3ts4s6rD+t42g=; b=FV8RHMrixTpI+Yeb1wWQ5ySArt3+TSjhL3T5YIy1tQR92n5gth/4loltsQqm5Jj2zs 8mI8mDbGgT3tO0jISwntyEfZ5wLBVxzwOM8WBjLrWLra1moEN2cBd3Mev65RghpXI1Ec OyuHqu1HQgfAr9Jtyjl+EfRiPixoqamdcwWPu13Hc+hAQxBBkb4pjg85IzP3ZyzqFAdB fhmL92eGvEz4qm9zTRtWyaT/ztdFkRgI28Xgo7uSYBBu/IF1eh9UpqReqTYcHzbvyeGR V6x7l280+MrUyGXd9lGAEpL6gHPsxxvPrR++Fcz/S2d9fats72MPwDuHG56Ou2G9nfhc 8qPg== X-Gm-Message-State: AHPjjUiA/1RvrBieNrCQRsU+MKJIFMDXE/OHuiSW6rerBZH95GSZjCkw KrpXY6vIk/hfikjcpm625qbtT6jbExkdXl0ntQI1Lg== X-Google-Smtp-Source: ADKCNb5vS641zXdnQXlU8b/k78PdLifHasV0xGUWrZfR8RONU3w09UK0AbpSTqs/Gw0x3s7v7WUd7KOlC0vNtrz6T3I= X-Received: by 10.36.73.23 with SMTP id z23mr9633260ita.136.1505081859808; Sun, 10 Sep 2017 15:17:39 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Sun, 10 Sep 2017 15:17:39 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:146f:d629:d0:a2f2] In-Reply-To: <06E8015B-89F8-4789-B876-59B8624D1207@dsl-only.net> References: <8419C238-702D-4BF7-89DB-EC649CD405A5@dsl-only.net> <06E8015B-89F8-4789-B876-59B8624D1207@dsl-only.net> From: Warner Losh Date: Sun, 10 Sep 2017 16:17:39 -0600 X-Google-Sender-Auth: lvuUg3HNapCwiEV4K-P7XtpaF7E Message-ID: Subject: Re: head -r323246 Pine64+ 2GB context: boot1.efi (as bootaa64.efi), I had to revert to an older one that I had around; more To: Mark Millard Cc: FreeBSD Toolchain , freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Sun, 10 Sep 2017 22:17:41 -0000 On Sun, Sep 10, 2017 at 3:18 PM, Mark Millard wrote: > On 2017-Sep-10, at 1:17 PM, Warner Losh wrote: > > > On Sun, Sep 10, 2017 at 2:34 AM, Mark Millard > wrote: > > When I attempted to use the result of: > > > > # cp -aRx /usr/obj/DESTDIRs/clang-cortexA53-installworld/boot/boot1.efi > /mnt/EFI/BOOT/ > > > > the pine64+ boot sequence got over and over > > a sequence like: > > > > U-Boot 2017.07 (Sep 06 2017 - 07:49:12 +0000) Allwinner Technology > > > > CPU: Allwinner A64 (SUN50I) > > Model: Pine64+ > > DRAM: 2 GiB > > MMC: SUNXI SD/MMC: 0 > > *** Warning - bad CRC, using default environment > > > > In: serial > > Out: serial > > . . . > > >> FreeBSD EFI boot block > > Loader path: /boot/loader.efi > > > > Initializing modules: ZFS UFS > > Load Path:=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80=EE= =A8=80 > > "Synchronous Abort" handler, esr 0x96000004 > > ELR: bdf90b30 > > LR: bdf8fb6c > > x0 : 0000000000000000 x1 : 0000000000000000 > > x2 : 00000000bdffc000 x3 : 0000000040000000 > > x4 : 00000000b9f34d40 x5 : 0000000000000000 > > x6 : 0000000000000015 x7 : 0000000000000000 > > x8 : 00000000bdfa59b8 x9 : 000000000000001c > > x10: 0000000000000002 x11: 0000000000000000 > > x12: 0000000000000000 x13: 0000000000000000 > > x14: 0000000000000000 x15: 0000000000000000 > > x16: 0000000000000000 x17: 0000000000000000 > > x18: 00000000b9f39df8 x19: 0000000000000000 > > x20: 0000000000000000 x21: 0000000000000002 > > x22: 00000000b8f34c98 x23: 00000000b8f34c88 > > x24: 00000000b8f34ca0 x25: 00000000000007d0 > > x26: 00000000b8f34c90 x27: 00000000b8f2f198 > > x28: 0000000000000000 x29: 00000000b9f34de0 > > > > Resetting CPU ... > > > > resetting ... > > > > It would be super helpful if you could bisect the change that caused > this. > > I'm doing some other experiments first but I'll > probably take a stab at it if things seem stable > enough. Pine64+ has multiple problems currently. > (It regressed some time back.) > > Unfortunately I do not have a known way to reproduce > the older boot1.efi file fully. I'll have to explore > that part to have a known-good low bound. If I'm > lucky the first try from the general time frame will > happen to work. > > Do to other issues I'm jumping from pre-INO64 to modern > without having tracked in the middle. > > > I will note that the older boot1.efi (as bootaa64.efi) > output is different (no "Load Path:")=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80= =EE=A8=80=EE=A8=80=EE=A8=80: > > >> FreeBSD EFI boot block > Loader path: /boot/loader.efi > > Initializing modules: ZFS UFS > Probing 3 block devices.....* done > ZFS found no pools > UFS found 1 partition > Consoles: EFI console > Command line arguments: loader.efi > Image base: 0xb6dbb008 > EFI version: 2.05 > EFI Firmware: Das U-boot (rev 0.00) > > The failing one has garbage (invisible) > text after "Load Path:". My first guess, and it's just a shot in the dark, is that the UEFI subset that u-boot implements doesn't implement the device path to text protocols, so we're jumping into the middle of cloud cuckoo land and/or printing stack trash. This is new functionality designed to help track WTF we booted from. Warner From owner-freebsd-arm@freebsd.org Sun Sep 10 22:25:29 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 6AD0CE06A12 for ; Sun, 10 Sep 2017 22:25:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 29C98636A2 for ; Sun, 10 Sep 2017 22:25:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16869 invoked from network); 10 Sep 2017 22:27:23 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 10 Sep 2017 22:27:23 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Sun, 10 Sep 2017 18:25:27 -0400 (EDT) Received: (qmail 2931 invoked from network); 10 Sep 2017 22:25:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Sep 2017 22:25:27 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 77CE8EC8AAE; Sun, 10 Sep 2017 15:25:26 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r323246 Pine64+ 2GB boot time context: acquiring blockable sleep lock with spinlock or critical section held for data_abort calling pmap_fault calling __mtx_lock_flags Date: Sun, 10 Sep 2017 15:25:25 -0700 References: <8419C238-702D-4BF7-89DB-EC649CD405A5@dsl-only.net> To: FreeBSD Toolchain , freebsd-arm , freebsd-hackers In-Reply-To: <8419C238-702D-4BF7-89DB-EC649CD405A5@dsl-only.net> Message-Id: <9DB26517-E4E0-4B2A-9855-9F7381AD4C66@dsl-only.net> 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: Sun, 10 Sep 2017 22:25:29 -0000 [I got a boot-time panic with a debug kernel that reported a "acquiring blockable sleep lock with spinlock or critical section held (sleep mutex)". This was for data_abort calling pmap_fault calling __mtx_lock_flags . I first include prior non-debug kernel reports in case they are related.] On 2017-Sep-10, at 1:34 AM, Mark Millard wrote: > . . . >=20 > Booting with the non-debug kernel appears to hang for > a bit and then gets to a db> prompt and a bt showed > (for example): > (The console output for the register dump seems > to always be incomplete and there is a wait to > end up at the db> prompt. Note the data_abort > closest to the fork_exit .) >=20 > . . . > Release APs > APs not started > CPU 0: ARM Cortex-A53 r0p4 affinity: 0 > Instruction Set Attributes 0 =3D > Instruction Set Attributes 1 =3D <0> > Processor Features 0 =3D > Processor Features 1 =3D <0> > Memory Model Features 0 =3D <4k Granule,64k = Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> > Memory Model Features 1 =3D <> > Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 = Breakpoints,PMUv3,Debug v8> > Debug Features 1 =3D <0> > Auxiliary Features 0 =3D <0> > Auxiliary Features 1 =3D <0> > CPU 1: (null) (null) r0p0 affinity: 0 > CPU 2: (null) (null) r0p0 affinity: 0 > CPU 3: (null) (null) r0p0 affinity: 0 > x0: ffff000000a1c000 > x1: fffffd000103a[ thread pid 0 tid 100057 ] > Stopped at thread_lock_flags_+0x298: ldr w4, [x3, #156] > db> bt > Tracing pid 0 tid 100057 td 0xfffffd000103a000 > db_trace_self() at db_stack_trace+0xec > pc =3D 0xffff000000613688 lr =3D 0xffff000000084db4 > sp =3D 0xffff0000698f4260 fp =3D 0xffff0000698f4290 >=20 > db_stack_trace() at db_command+0x224 > pc =3D 0xffff000000084db4 lr =3D 0xffff000000084a3c > sp =3D 0xffff0000698f42a0 fp =3D 0xffff0000698f4380 >=20 > db_command() at db_command_loop+0x60 > pc =3D 0xffff000000084a3c lr =3D 0xffff0000000847fc > sp =3D 0xffff0000698f4390 fp =3D 0xffff0000698f43b0 >=20 > db_command_loop() at db_trap+0xf4 > pc =3D 0xffff0000000847fc lr =3D 0xffff000000087964 > sp =3D 0xffff0000698f43c0 fp =3D 0xffff0000698f45e0 >=20 > db_trap() at kdb_trap+0x180 > pc =3D 0xffff000000087964 lr =3D 0xffff0000003693e0 > sp =3D 0xffff0000698f45f0 fp =3D 0xffff0000698f4650 >=20 > kdb_trap() at do_el1h_sync+0x90 > pc =3D 0xffff0000003693e0 lr =3D 0xffff00000062956c > sp =3D 0xffff0000698f4660 fp =3D 0xffff0000698f4690 >=20 > do_el1h_sync() at handle_el1h_sync+0x74 > pc =3D 0xffff00000062956c lr =3D 0xffff000000615074 > sp =3D 0xffff0000698f46a0 fp =3D 0xffff0000698f47b0 >=20 > handle_el1h_sync() at kdb_enter+0x38 > pc =3D 0xffff000000615074 lr =3D 0xffff000000368ac8 > sp =3D 0xffff0000698f47c0 fp =3D 0xffff0000698f4850 >=20 > kdb_enter() at vpanic+0x180 > pc =3D 0xffff000000368ac8 lr =3D 0xffff000000326dd8 > sp =3D 0xffff0000698f4860 fp =3D 0xffff0000698f48d0 >=20 > vpanic() at panic+0x48 > pc =3D 0xffff000000326dd8 lr =3D 0xffff000000326c54 > sp =3D 0xffff0000698f48e0 fp =3D 0xffff0000698f4960 >=20 > panic() at data_abort+0x21c > pc =3D 0xffff000000326c54 lr =3D 0xffff0000006298e8 > sp =3D 0xffff0000698f4970 fp =3D 0xffff0000698f4a20 >=20 > data_abort() at do_el1h_sync+0xfc > pc =3D 0xffff0000006298e8 lr =3D 0xffff0000006295d8 > sp =3D 0xffff0000698f4a30 fp =3D 0xffff0000698f4a60 >=20 > do_el1h_sync() at handle_el1h_sync+0x74 > pc =3D 0xffff0000006295d8 lr =3D 0xffff000000615074 > sp =3D 0xffff0000698f4a70 fp =3D 0xffff0000698f4b80 >=20 > handle_el1h_sync() at thread_lock_flags_+0x1a8 > pc =3D 0xffff000000615074 lr =3D 0xffff000000309060 > sp =3D 0xffff0000698f4b90 fp =3D 0xffff0000698f4c80 >=20 > thread_lock_flags_() at statclock_cnt+0x11c > pc =3D 0xffff000000309060 lr =3D 0xffff0000002c5b90 > sp =3D 0xffff0000698f4c90 fp =3D 0xffff0000698f4cb0 >=20 > statclock_cnt() at handleevents+0x108 > pc =3D 0xffff0000002c5b90 lr =3D 0xffff00000064ad84 > sp =3D 0xffff0000698f4cc0 fp =3D 0xffff0000698f4d00 >=20 > handleevents() at timercb+0xe0 > pc =3D 0xffff00000064ad84 lr =3D 0xffff00000064b51c > sp =3D 0xffff0000698f4d10 fp =3D 0xffff0000698f4d80 >=20 > timercb() at arm_tmr_intr+0x58 > pc =3D 0xffff00000064b51c lr =3D 0xffff000000600e5c > sp =3D 0xffff0000698f4d90 fp =3D 0xffff0000698f4d90 >=20 > arm_tmr_intr() at intr_event_handle+0x64 > pc =3D 0xffff000000600e5c lr =3D 0xffff0000002edd50 > sp =3D 0xffff0000698f4da0 fp =3D 0xffff0000698f4dd0 >=20 > intr_event_handle() at intr_isrc_dispatch+0x30 > pc =3D 0xffff0000002edd50 lr =3D 0xffff00000064d8ec > sp =3D 0xffff0000698f4de0 fp =3D 0xffff0000698f4df0 >=20 > intr_isrc_dispatch() at arm_gic_intr+0xf0 > pc =3D 0xffff00000064d8ec lr =3D 0xffff000000601848 > sp =3D 0xffff0000698f4e00 fp =3D 0xffff0000698f4e50 >=20 > arm_gic_intr() at intr_irq_handler+0x60 > pc =3D 0xffff000000601848 lr =3D 0xffff00000064d6e0 > sp =3D 0xffff0000698f4e60 fp =3D 0xffff0000698f4e80 >=20 > intr_irq_handler() at handle_el1h_irq+0x70 > pc =3D 0xffff00000064d6e0 lr =3D 0xffff000000615130 > sp =3D 0xffff0000698f4e90 fp =3D 0xffff0000698f4fa0 >=20 > handle_el1h_irq() at ns8250_putc+0x2c > pc =3D 0xffff000000615130 lr =3D 0xffff00000019a570 > sp =3D 0xffff0000698f4fb0 fp =3D 0xffff0000698f5050 >=20 > ns8250_putc() at ns8250_putc+0x2c > pc =3D 0xffff00000019a570 lr =3D 0xffff00000019a570 > sp =3D 0xffff0000698f5060 fp =3D 0xffff0000698f5080 >=20 > ns8250_putc() at uart_cnputc+0x94 > pc =3D 0xffff00000019a570 lr =3D 0xffff0000001a0860 > sp =3D 0xffff0000698f5090 fp =3D 0xffff0000698f50c0 >=20 > uart_cnputc() at cnputc+0x90 > pc =3D 0xffff0000001a0860 lr =3D 0xffff0000002cb3a8 > sp =3D 0xffff0000698f50d0 fp =3D 0xffff0000698f5120 >=20 > cnputc() at cnputs+0xb4 > pc =3D 0xffff0000002cb3a8 lr =3D 0xffff0000002cb7c8 > sp =3D 0xffff0000698f5130 fp =3D 0xffff0000698f5150 >=20 > cnputs() at putchar+0x158 > pc =3D 0xffff0000002cb7c8 lr =3D 0xffff00000036f04c > sp =3D 0xffff0000698f5160 fp =3D 0xffff0000698f51e0 >=20 > putchar() at kvprintf+0xda8 > pc =3D 0xffff00000036f04c lr =3D 0xffff00000036ec70 > sp =3D 0xffff0000698f51f0 fp =3D 0xffff0000698f5300 >=20 > kvprintf() at vprintf+0x7c > pc =3D 0xffff00000036ec70 lr =3D 0xffff00000036f838 > sp =3D 0xffff0000698f5310 fp =3D 0xffff0000698f5420 >=20 > vprintf() at printf+0x48 > pc =3D 0xffff00000036f838 lr =3D 0xffff00000036f7ac > sp =3D 0xffff0000698f5430 fp =3D 0xffff0000698f54b0 >=20 > printf() at print_registers+0x4c > pc =3D 0xffff00000036f7ac lr =3D 0xffff00000062966c > sp =3D 0xffff0000698f54c0 fp =3D 0xffff0000698f54f0 >=20 > print_registers() at data_abort+0x1f0 > pc =3D 0xffff00000062966c lr =3D 0xffff0000006298bc > sp =3D 0xffff0000698f5500 fp =3D 0xffff0000698f55b0 >=20 > data_abort() at do_el1h_sync+0xfc > pc =3D 0xffff0000006298bc lr =3D 0xffff0000006295d8 > sp =3D 0xffff0000698f55c0 fp =3D 0xffff0000698f55f0 >=20 > do_el1h_sync() at handle_el1h_sync+0x74 > pc =3D 0xffff0000006295d8 lr =3D 0xffff000000615074 > sp =3D 0xffff0000698f5600 fp =3D 0xffff0000698f5710 >=20 > handle_el1h_sync() at sched_switch+0x54c > pc =3D 0xffff000000615074 lr =3D 0xffff000000351dd4 > sp =3D 0xffff0000698f5720 fp =3D 0xffff0000698f5800 >=20 > sched_switch() at mi_switch+0x118 > pc =3D 0xffff000000351dd4 lr =3D 0xffff000000330c14 > sp =3D 0xffff0000698f5810 fp =3D 0xffff0000698f5830 >=20 > mi_switch() at taskqgroup_binder+0x74 > pc =3D 0xffff000000330c14 lr =3D 0xffff000000367864 > sp =3D 0xffff0000698f5840 fp =3D 0xffff0000698f5860 >=20 > taskqgroup_binder() at gtaskqueue_run_locked+0x160 > pc =3D 0xffff000000367864 lr =3D 0xffff000000367710 > sp =3D 0xffff0000698f5870 fp =3D 0xffff0000698f58e0 >=20 > gtaskqueue_run_locked() at gtaskqueue_thread_loop+0xcc > pc =3D 0xffff000000367710 lr =3D 0xffff0000003672c8 > sp =3D 0xffff0000698f58f0 fp =3D 0xffff0000698f5910 >=20 > gtaskqueue_thread_loop() at fork_exit+0x94 > pc =3D 0xffff0000003672c8 lr =3D 0xffff0000002eab20 > sp =3D 0xffff0000698f5920 fp =3D 0xffff0000698f5950 >=20 > fork_exit() at fork_trampoline+0x10 > pc =3D 0xffff0000002eab20 lr =3D 0xffff00000062934c > sp =3D 0xffff0000698f5960 fp =3D 0x0000000000000000 >=20 >=20 > Booting with a debug kernel worked fine. (This matches up > with past reports about "recent" pine64+ handling.) >=20 > But trying to have the root file system on a USB SSD > drive failed to see the USB drive at all. (This matches > up with past reports about "recent" pine64+ handling.) >=20 >=20 > =46rom a separate non-debug kernel boot attempt: > (remember the "thread_lock_flags_+0x298: ldr w4, [x3, #156]" > but also note x8 in addition to x3) >=20 > db> show reg > spsr 0x96000004000003c5 > x0 0xffff00000069b000 $d.2+0x1ac > x1 0x2 > x2 0xffff00000069ba48 $d.5+0x1d > x3 0xdeadc0d8 <<<<<<<<< Note the "0xdeadc0d8" > x4 0x3 > x5 0xffff000000610cf0 generic_bs_barrier > x6 0 > x7 0x40 $d.14 > x8 0xdeadc0de <<<<<<<<< Note the "0xdeadc0de" > x9 0 > x10 0x975c860b > x11 0x975c860b > x12 0x51eb850 > x13 0x4 > x14 0x66 $d.9+0x26 > x15 0xffff0000007004ce hex2ascii_data > x16 0 > x17 0 > x18 0xffff00006990ec10 > x19 0xfffffd000103a000 > x20 0xffff000000bcee70 blocked_lock+0x18 > x21 0xffff00000080e5a8 sdt_lockstat___spin__release > x22 0x3938700 > x23 0xfffffd000103a000 > x24 0xffff000000bcee58 blocked_lock > x25 0x4 > x26 0x98967f > x27 0xffff0000009ef000 next_to_notify > x28 0xffff000000bb9000 proc0+0x4f8 > x29 0xffff00006990ec80 > lr 0xffff000000309064 thread_lock_flags_+0x1ac > elr 0xffff000000309154 thread_lock_flags_+0x29c > sp 0xffff00006990ec10 > thread_lock_flags_+0x298: ldr w4, [x3, #156] > db> bt > Tracing pid 0 tid 100057 td 0xfffffd000103a000 > db_trace_self() at db_stack_trace+0xec > pc =3D 0xffff000000613688 lr =3D 0xffff000000084db4 > sp =3D 0xffff00006990e260 fp =3D 0xffff00006990e290 >=20 > db_stack_trace() at db_command+0x224 > pc =3D 0xffff000000084db4 lr =3D 0xffff000000084a3c > sp =3D 0xffff00006990e2a0 fp =3D 0xffff00006990e380 >=20 > db_command() at db_command_loop+0x60 > pc =3D 0xffff000000084a3c lr =3D 0xffff0000000847fc > sp =3D 0xffff00006990e390 fp =3D 0xffff00006990e3b0 >=20 > db_command_loop() at db_trap+0xf4 > pc =3D 0xffff0000000847fc lr =3D 0xffff000000087964 > sp =3D 0xffff00006990e3c0 fp =3D 0xffff00006990e5e0 >=20 > db_trap() at kdb_trap+0x180 > pc =3D 0xffff000000087964 lr =3D 0xffff0000003693e0 > sp =3D 0xffff00006990e5f0 fp =3D 0xffff00006990e650 >=20 > kdb_trap() at do_el1h_sync+0x90 > pc =3D 0xffff0000003693e0 lr =3D 0xffff00000062956c > sp =3D 0xffff00006990e660 fp =3D 0xffff00006990e690 >=20 > do_el1h_sync() at handle_el1h_sync+0x74 > pc =3D 0xffff00000062956c lr =3D 0xffff000000615074 > sp =3D 0xffff00006990e6a0 fp =3D 0xffff00006990e7b0 >=20 > handle_el1h_sync() at kdb_enter+0x38 > pc =3D 0xffff000000615074 lr =3D 0xffff000000368ac8 > sp =3D 0xffff00006990e7c0 fp =3D 0xffff00006990e850 >=20 > kdb_enter() at vpanic+0x180 > pc =3D 0xffff000000368ac8 lr =3D 0xffff000000326dd8 > sp =3D 0xffff00006990e860 fp =3D 0xffff00006990e8d0 >=20 > vpanic() at panic+0x48 > pc =3D 0xffff000000326dd8 lr =3D 0xffff000000326c54 > sp =3D 0xffff00006990e8e0 fp =3D 0xffff00006990e960 >=20 > panic() at data_abort+0x21c > pc =3D 0xffff000000326c54 lr =3D 0xffff0000006298e8 > sp =3D 0xffff00006990e970 fp =3D 0xffff00006990ea20 >=20 > data_abort() at do_el1h_sync+0xfc > pc =3D 0xffff0000006298e8 lr =3D 0xffff0000006295d8 > sp =3D 0xffff00006990ea30 fp =3D 0xffff00006990ea60 >=20 > do_el1h_sync() at handle_el1h_sync+0x74 > pc =3D 0xffff0000006295d8 lr =3D 0xffff000000615074 > sp =3D 0xffff00006990ea70 fp =3D 0xffff00006990eb80 >=20 > handle_el1h_sync() at thread_lock_flags_+0x1a8 > pc =3D 0xffff000000615074 lr =3D 0xffff000000309060 > sp =3D 0xffff00006990eb90 fp =3D 0xffff00006990ec80 >=20 > thread_lock_flags_() at statclock_cnt+0x11c > pc =3D 0xffff000000309060 lr =3D 0xffff0000002c5b90 > sp =3D 0xffff00006990ec90 fp =3D 0xffff00006990ecb0 >=20 > statclock_cnt() at handleevents+0x108 > pc =3D 0xffff0000002c5b90 lr =3D 0xffff00000064ad84 > sp =3D 0xffff00006990ecc0 fp =3D 0xffff00006990ed00 >=20 > handleevents() at timercb+0xe0 > pc =3D 0xffff00000064ad84 lr =3D 0xffff00000064b51c > sp =3D 0xffff00006990ed10 fp =3D 0xffff00006990ed80 >=20 > timercb() at arm_tmr_intr+0x58 > pc =3D 0xffff00000064b51c lr =3D 0xffff000000600e5c > sp =3D 0xffff00006990ed90 fp =3D 0xffff00006990ed90 >=20 > arm_tmr_intr() at intr_event_handle+0x64 > pc =3D 0xffff000000600e5c lr =3D 0xffff0000002edd50 > sp =3D 0xffff00006990eda0 fp =3D 0xffff00006990edd0 >=20 > intr_event_handle() at intr_isrc_dispatch+0x30 > pc =3D 0xffff0000002edd50 lr =3D 0xffff00000064d8ec > sp =3D 0xffff00006990ede0 fp =3D 0xffff00006990edf0 >=20 > intr_isrc_dispatch() at arm_gic_intr+0xf0 > pc =3D 0xffff00000064d8ec lr =3D 0xffff000000601848 > sp =3D 0xffff00006990ee00 fp =3D 0xffff00006990ee50 >=20 > arm_gic_intr() at intr_irq_handler+0x60 > pc =3D 0xffff000000601848 lr =3D 0xffff00000064d6e0 > sp =3D 0xffff00006990ee60 fp =3D 0xffff00006990ee80 >=20 > intr_irq_handler() at handle_el1h_irq+0x70 > pc =3D 0xffff00000064d6e0 lr =3D 0xffff000000615130 > sp =3D 0xffff00006990ee90 fp =3D 0xffff00006990efa0 >=20 > handle_el1h_irq() at ns8250_putc+0x2c > pc =3D 0xffff000000615130 lr =3D 0xffff00000019a570 > sp =3D 0xffff00006990efb0 fp =3D 0xffff00006990f050 >=20 > ns8250_putc() at ns8250_putc+0x2c > pc =3D 0xffff00000019a570 lr =3D 0xffff00000019a570 > sp =3D 0xffff00006990f060 fp =3D 0xffff00006990f080 >=20 > ns8250_putc() at uart_cnputc+0x94 > pc =3D 0xffff00000019a570 lr =3D 0xffff0000001a0860 > sp =3D 0xffff00006990f090 fp =3D 0xffff00006990f0c0 >=20 > uart_cnputc() at cnputc+0x90 > pc =3D 0xffff0000001a0860 lr =3D 0xffff0000002cb3a8 > sp =3D 0xffff00006990f0d0 fp =3D 0xffff00006990f120 >=20 > cnputc() at cnputs+0xb4 > pc =3D 0xffff0000002cb3a8 lr =3D 0xffff0000002cb7c8 > sp =3D 0xffff00006990f130 fp =3D 0xffff00006990f150 >=20 > cnputs() at putchar+0x158 > pc =3D 0xffff0000002cb7c8 lr =3D 0xffff00000036f04c > sp =3D 0xffff00006990f160 fp =3D 0xffff00006990f1e0 >=20 > putchar() at kvprintf+0xda8 > pc =3D 0xffff00000036f04c lr =3D 0xffff00000036ec70 > sp =3D 0xffff00006990f1f0 fp =3D 0xffff00006990f300 >=20 > kvprintf() at vprintf+0x7c > pc =3D 0xffff00000036ec70 lr =3D 0xffff00000036f838 > sp =3D 0xffff00006990f310 fp =3D 0xffff00006990f420 >=20 > vprintf() at printf+0x48 > pc =3D 0xffff00000036f838 lr =3D 0xffff00000036f7ac > sp =3D 0xffff00006990f430 fp =3D 0xffff00006990f4b0 >=20 > printf() at print_registers+0x4c > pc =3D 0xffff00000036f7ac lr =3D 0xffff00000062966c > sp =3D 0xffff00006990f4c0 fp =3D 0xffff00006990f4f0 >=20 > print_registers() at data_abort+0x1f0 > pc =3D 0xffff00000062966c lr =3D 0xffff0000006298bc > sp =3D 0xffff00006990f500 fp =3D 0xffff00006990f5b0 >=20 > data_abort() at do_el1h_sync+0xfc > pc =3D 0xffff0000006298bc lr =3D 0xffff0000006295d8 > sp =3D 0xffff00006990f5c0 fp =3D 0xffff00006990f5f0 >=20 > do_el1h_sync() at handle_el1h_sync+0x74 > pc =3D 0xffff0000006295d8 lr =3D 0xffff000000615074 > sp =3D 0xffff00006990f600 fp =3D 0xffff00006990f710 >=20 > handle_el1h_sync() at sched_switch+0x54c > pc =3D 0xffff000000615074 lr =3D 0xffff000000351dd4 > sp =3D 0xffff00006990f720 fp =3D 0xffff00006990f800 >=20 > sched_switch() at mi_switch+0x118 > pc =3D 0xffff000000351dd4 lr =3D 0xffff000000330c14 > sp =3D 0xffff00006990f810 fp =3D 0xffff00006990f830 >=20 > mi_switch() at taskqgroup_binder+0x74 > pc =3D 0xffff000000330c14 lr =3D 0xffff000000367864 > sp =3D 0xffff00006990f840 fp =3D 0xffff00006990f860 >=20 > taskqgroup_binder() at gtaskqueue_run_locked+0x160 > pc =3D 0xffff000000367864 lr =3D 0xffff000000367710 > sp =3D 0xffff00006990f870 fp =3D 0xffff00006990f8e0 >=20 > gtaskqueue_run_locked() at gtaskqueue_thread_loop+0xcc > pc =3D 0xffff000000367710 lr =3D 0xffff0000003672c8 > sp =3D 0xffff00006990f8f0 fp =3D 0xffff00006990f910 >=20 > gtaskqueue_thread_loop() at fork_exit+0x94 > pc =3D 0xffff0000003672c8 lr =3D 0xffff0000002eab20 > sp =3D 0xffff00006990f920 fp =3D 0xffff00006990f950 >=20 > fork_exit() at fork_trampoline+0x10 > pc =3D 0xffff0000002eab20 lr =3D 0xffff00000062934c > sp =3D 0xffff00006990f960 fp =3D 0x0000000000000000 [Another issue was modern boot1.efi (as bootaa64.efi) not working and so I'm using an old one (2016-Nov-7) that I found that allows getting this far.] A boot attempt with a older boot1.efi that works and a debug kernel got: . . . Release APs APs not started CPU 0: ARM Cortex-A53 r0p4 affinity: 0 Instruction Set Attributes 0 =3D Instruction Set Attributes 1 =3D <0> Processor Features 0 =3D Processor Features 1 =3D <0> Memory Model Features 0 =3D <4k Granule,64k = Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> Memory Model Features 1 =3D <> Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 = Breakpoints,PMUv3,Debug v8> Debug Features 1 =3D <0> Auxiliary Features 0 =3D <0> Auxiliary Features 1 =3D <0> CPU 1: (null) (null) r0p0 affinity: 0 CPU 2: (null) (null) r0p0 affinity: 0 CPU 3: (null) (null) r0p0 affinity: 0 panic: acquiring blockable sleep lock with spinlock or critical section = held (sleep mutex) pmap @ /usr/src/sys/arm64/arm64/pmap.c:4710 cpuid =3D 0 time =3D 13 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffff0000005efc78 lr =3D 0xffff000000088094 sp =3D 0xffff000069850080 fp =3D 0xffff000069850290 db_trace_self_wrapper() at vpanic+0x164 pc =3D 0xffff000000088094 lr =3D 0xffff00000031764c sp =3D 0xffff0000698502a0 fp =3D 0xffff000069850310 vpanic() at kassert_panic+0x15c pc =3D 0xffff00000031764c lr =3D 0xffff0000003174e4 sp =3D 0xffff000069850320 fp =3D 0xffff0000698503e0 kassert_panic() at witness_checkorder+0x160 pc =3D 0xffff0000003174e4 lr =3D 0xffff000000374990 sp =3D 0xffff0000698503f0 fp =3D 0xffff000069850470 witness_checkorder() at __mtx_lock_flags+0xa8 pc =3D 0xffff000000374990 lr =3D 0xffff0000002f8b7c sp =3D 0xffff000069850480 fp =3D 0xffff0000698504b0 __mtx_lock_flags() at pmap_fault+0x40 pc =3D 0xffff0000002f8b7c lr =3D 0xffff000000606994 sp =3D 0xffff0000698504c0 fp =3D 0xffff0000698504e0 pmap_fault() at data_abort+0xb8 pc =3D 0xffff000000606994 lr =3D 0xffff000000608a9c sp =3D 0xffff0000698504f0 fp =3D 0xffff0000698505a0 data_abort() at do_el1h_sync+0xfc pc =3D 0xffff000000608a9c lr =3D 0xffff0000006088f0 sp =3D 0xffff0000698505b0 fp =3D 0xffff0000698505e0 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff0000006088f0 lr =3D 0xffff0000005f1874 sp =3D 0xffff0000698505f0 fp =3D 0xffff000069850700 handle_el1h_sync() at sched_switch+0x2a8 pc =3D 0xffff0000005f1874 lr =3D 0xffff00000033f0c8 sp =3D 0xffff000069850710 fp =3D 0xffff0000698507f0 sched_switch() at mi_switch+0x1b8 pc =3D 0xffff00000033f0c8 lr =3D 0xffff00000032161c sp =3D 0xffff000069850800 fp =3D 0xffff000069850820 mi_switch() at taskqgroup_binder+0x7c pc =3D 0xffff00000032161c lr =3D 0xffff00000035510c sp =3D 0xffff000069850830 fp =3D 0xffff000069850860 taskqgroup_binder() at gtaskqueue_run_locked+0x104 pc =3D 0xffff00000035510c lr =3D 0xffff000000354f74 sp =3D 0xffff000069850870 fp =3D 0xffff0000698508e0 gtaskqueue_run_locked() at gtaskqueue_thread_loop+0x9c pc =3D 0xffff000000354f74 lr =3D 0xffff000000354d10 sp =3D 0xffff0000698508f0 fp =3D 0xffff000069850910 gtaskqueue_thread_loop() at fork_exit+0x7c pc =3D 0xffff000000354d10 lr =3D 0xffff0000002dbd3c sp =3D 0xffff000069850920 fp =3D 0xffff000069850950 fork_exit() at fork_trampoline+0x10 pc =3D 0xffff0000002dbd3c lr =3D 0xffff000000608664 sp =3D 0xffff000069850960 fp =3D 0x0000000000000000 KDB: enter: panic [ thread pid 0 tid 100058 ] Stopped at sched_switch+0x2b8: ldrb w9, [x8, #894] db>=20 Unfortunately it was not taking console input so that is all I got. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Sep 11 07:01:55 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 513C7E1FE59 for ; Mon, 11 Sep 2017 07:01:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 0D52973682 for ; Mon, 11 Sep 2017 07:01:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17623 invoked from network); 11 Sep 2017 07:01:53 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 11 Sep 2017 07:01:53 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Mon, 11 Sep 2017 03:01:53 -0400 (EDT) Received: (qmail 4201 invoked from network); 11 Sep 2017 07:01:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Sep 2017 07:01:52 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 37572EC7888; Mon, 11 Sep 2017 00:01:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r323246 Pine64+ 2GB context: boot1.efi (as bootaa64.efi), I had to revert to an older one that I had around; more From: Mark Millard In-Reply-To: Date: Mon, 11 Sep 2017 00:01:51 -0700 Cc: FreeBSD Toolchain , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <36A0023C-0DD7-4903-A9C7-C641CC759B47@dsl-only.net> References: <8419C238-702D-4BF7-89DB-EC649CD405A5@dsl-only.net> <06E8015B-89F8-4789-B876-59B8624D1207@dsl-only.net> To: Warner Losh 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: Mon, 11 Sep 2017 07:01:55 -0000 [Warner: looks like you were thinking in the correct general direction. Details below.] On 2017-Sep-10, at 3:17 PM, Warner Losh wrote: > On Sun, Sep 10, 2017 at 3:18 PM, Mark Millard = wrote: > On 2017-Sep-10, at 1:17 PM, Warner Losh wrote: >=20 > > On Sun, Sep 10, 2017 at 2:34 AM, Mark Millard = wrote: > > When I attempted to use the result of: > > > > # cp -aRx = /usr/obj/DESTDIRs/clang-cortexA53-installworld/boot/boot1.efi = /mnt/EFI/BOOT/ > > > > the pine64+ boot sequence got over and over > > a sequence like: > > > > U-Boot 2017.07 (Sep 06 2017 - 07:49:12 +0000) Allwinner Technology > > > > CPU: Allwinner A64 (SUN50I) > > Model: Pine64+ > > DRAM: 2 GiB > > MMC: SUNXI SD/MMC: 0 > > *** Warning - bad CRC, using default environment > > > > In: serial > > Out: serial > > . . . > > >> FreeBSD EFI boot block > > Loader path: /boot/loader.efi > > > > Initializing modules: ZFS UFS > > Load Path:=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80=EE= =A8=80 > > "Synchronous Abort" handler, esr 0x96000004 > > ELR: bdf90b30 > > LR: bdf8fb6c > > x0 : 0000000000000000 x1 : 0000000000000000 > > x2 : 00000000bdffc000 x3 : 0000000040000000 > > x4 : 00000000b9f34d40 x5 : 0000000000000000 > > x6 : 0000000000000015 x7 : 0000000000000000 > > x8 : 00000000bdfa59b8 x9 : 000000000000001c > > x10: 0000000000000002 x11: 0000000000000000 > > x12: 0000000000000000 x13: 0000000000000000 > > x14: 0000000000000000 x15: 0000000000000000 > > x16: 0000000000000000 x17: 0000000000000000 > > x18: 00000000b9f39df8 x19: 0000000000000000 > > x20: 0000000000000000 x21: 0000000000000002 > > x22: 00000000b8f34c98 x23: 00000000b8f34c88 > > x24: 00000000b8f34ca0 x25: 00000000000007d0 > > x26: 00000000b8f34c90 x27: 00000000b8f2f198 > > x28: 0000000000000000 x29: 00000000b9f34de0 > > > > Resetting CPU ... > > > > resetting ... > > > > It would be super helpful if you could bisect the change that caused = this. >=20 > I'm doing some other experiments first but I'll > probably take a stab at it if things seem stable > enough. Pine64+ has multiple problems currently. > (It regressed some time back.) >=20 > Unfortunately I do not have a known way to reproduce > the older boot1.efi file fully. I'll have to explore > that part to have a known-good low bound. If I'm > lucky the first try from the general time frame will > happen to work. >=20 > Do to other issues I'm jumping from pre-INO64 to modern > without having tracked in the middle. >=20 >=20 > I will note that the older boot1.efi (as bootaa64.efi) > output is different (no "Load Path:")=EE=A8=80=EE=A8=80=EE=A8=80=EE=A8=80= =EE=A8=80=EE=A8=80=EE=A8=80: >=20 > >> FreeBSD EFI boot block > Loader path: /boot/loader.efi >=20 > Initializing modules: ZFS UFS > Probing 3 block devices.....* done > ZFS found no pools > UFS found 1 partition > Consoles: EFI console > Command line arguments: loader.efi > Image base: 0xb6dbb008 > EFI version: 2.05 > EFI Firmware: Das U-boot (rev 0.00) >=20 > The failing one has garbage (invisible) > text after "Load Path:". >=20 > My first guess, and it's just a shot in the dark, is that the UEFI = subset that u-boot implements doesn't implement the device path to text = protocols, so we're jumping into the middle of cloud cuckoo land and/or = printing stack trash. >=20 > This is new functionality designed to help track WTF we booted from. Based on your guess I explored just recent changes that looked to be tied to your guesses. The following back-off of 2 file revisions was enough to build a working boot1.efi (as bootaa64.efi) for the Pine64+ 2GB : # svnlite update -r322941 /usr/src/sys/boot/efi/boot1/boot1.c = /usr/src/sys/boot/efi/include/efiapi.h -r323064 was not far enough back for these 2 soruces: failed just like -r323246 did. I did not directly try -r323063 . I can if you want. Revision 323064 - Directory Listing=20 Modified Thu Aug 31 17:32:19 2017 UTC (10 days, 12 hours ago) by imp Exit rather than panic for most errors. In the FreeBSD UEFI boot protocol, boot1.efi exits back to UEFI if it can't boot the image for most reasons (so that further items in the EFI boot manger list can be tried). Rename panic to efi_panic, make it static and give it an extra status argument. Exit back to UEFI with that status argument so the next loader can be tried. Use malloc/free exclusively instead of mixing malloc/free and AllocatePool/FreePool. The code is smaller. Sponsored by: Netflix Revision 323063 - Directory Listing=20 Modified Thu Aug 31 17:32:14 2017 UTC (10 days, 12 hours ago) by imp boot1.efi: print more info about where boot1.efi is loaded from Print the device that boot1.efi was loaded from. Print the path as well (since it isn't included in DeviceHandle). Move block where we do this earlier so all the block handle code is now together. Sponsored by: Netflix Revision 322941 - Directory Listing=20 Modified Sun Aug 27 03:10:16 2017 UTC (2 weeks, 1 day ago) by imp Eliminate redunant device path matching. Use efi_devpath_match instead of device_paths_match. They are functionally the same. Remove device_paths_match from boot1.c and call efi_devpath_match instead. Sponsored by: Netflix =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Sep 11 08:48:59 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 A6A18E23864 for ; Mon, 11 Sep 2017 08:48:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 5605D77B1D for ; Mon, 11 Sep 2017 08:48:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32012 invoked from network); 11 Sep 2017 08:48:51 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 11 Sep 2017 08:48:51 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Mon, 11 Sep 2017 04:48:51 -0400 (EDT) Received: (qmail 16635 invoked from network); 11 Sep 2017 08:48:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Sep 2017 08:48:51 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id E4374EC86EF; Mon, 11 Sep 2017 01:48:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Missing in action during arm64/aarch64 builds: no pine64_plus.dtb to be found from buildkernel, installkernel, or u-boot-pine64 From: Mark Millard In-Reply-To: <20170911095641.616658985e7148a88f6c03a7@bidouilliste.com> Date: Mon, 11 Sep 2017 01:48:49 -0700 Cc: FreeBSD Toolchain , freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170911095641.616658985e7148a88f6c03a7@bidouilliste.com> To: Emmanuel Vadot , Tim Kientzle 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: Mon, 11 Sep 2017 08:48:59 -0000 On 2017-Sep-11, at 12:56 AM, Emmanuel Vadot = wrote: > On Sat, 9 Sep 2017 16:35:11 -0700 > Mark Millard wrote: >=20 >> The context here is head -r323246 amd64 -> arm64/aarch64 >> cross build activity. >>=20 >> =46rom installkernel : >>=20 >> # find /usr/obj/DESTDIRs/clang-cortexA53-installkernel/ -name "*.dtb" = -print >> #=20 >>=20 >> =46rom buildkernel : >>=20 >> # find /usr/obj/cortexA53_clang/arm64.aarch64/ -name "*.dtb" -print >> #=20 >>=20 >> =46rom installing u-boot-pine64 : >>=20 >> # ls -lTd /usr/local/share/u-boot/u-boot-pine64/* >> -rw-r--r-- 1 root wheel 125 Sep 6 00:49:44 2017 = /usr/local/share/u-boot/u-boot-pine64/README >> -rw-r--r-- 1 root wheel 505940 Sep 6 00:49:43 2017 = /usr/local/share/u-boot/u-boot-pine64/u-boot-sunxi-with-spl.bin >>=20 >>=20 >> As stands the file must be manually produced. >=20 > Since the latest update of u-boot-pine64 the dtb is included in = u-boot. > U-Boot loads it and pass it to boot1.efi. Cool . . . Trying: # mv /boot/efi/dtb/pine64_plus.dtb /boot/efi/dtb/no_pine64_plus.dtb # shutdown -r now does reboot just fine. As does: # rm -fr /boot/efi/dtb # shutdown -r now A cold boot also boots into the kernel. So no .dts or .dtb is needed for the Pine64+ 2GB . For reference after this: # mount /dev/label/PINE642GAroot on / (ufs, NFS exported, local, noatime, = soft-updates, nfsv4acls) devfs on /dev (devfs, local, multilabel) /dev/label/PINE642GAboot on /boot/efi (msdosfs, local, noatime) # find /boot/efi /boot/efi /boot/efi/startup.nsh /boot/efi/EFI /boot/efi/EFI/BOOT /boot/efi/EFI/BOOT/bootaa64.efi /boot/efi/System Volume Information /boot/efi/System Volume Information/WPSettings.dat I have no clue if this hidden dtb contributes to the USB problem(s) or not: . . . cryptosoft0: NULL mp in getnewvnode(9), tag crossmp Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on = usbus0 uhub_attach: getting USB 2.0 HUB descriptor = failed,error=3DUSB_ERR_SHORT_XFER device_attach: uhub0 attach returned 6 usbus0: Root HUB problem, error=3DUSB_ERR_NO_ROOT_HUB mmcsd0: 32GB at mmc0 = 50.0MHz/4bit/65535-block . . . My old -r308??? context not only could use usb devices but had the root file system on a USB SSD. But modernizing made plugged in USB devices not show up. >> crochet goes to the trouble to have logic to >> build and install pine64_plus.dtb (based on >> arm64/pine64_plus.dts ). Looks like crochet does not need to produce the .dtb . It is not even clear that if a dtb/pine64_plus.dtb exists that it is used for anything. >> Is pine64_plus.dtb required for the likes of >> Pine64+ 2GB's? Now answered as: no. >> If yes: should it be automatically >> built and installed someplace for arm64/aarch64 >> builds (even if more manual steps are required to >> have the final placement on the Pine64 media)? =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Sep 11 08:56:47 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 1C016E23EC1; Mon, 11 Sep 2017 08:56:47 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E7F97C30F; Mon, 11 Sep 2017 08:56:45 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id cd6620fd; Mon, 11 Sep 2017 09:56:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=4Fr3a953iWNfh0GR/89NN1bULJA=; b=IcENBs2xiaUxX6H6/A31lehvmE07 WB7Q+gz5dnBxHTfsbFEaKDNrFgukVN5jcP5NVzCDXGo2A68HTffTlBBUDahZ4WP0 PF0AOLm14T5m+W2JPZuYieNkpIYHkqcSiO0Lsi5VLiTVXTWi9Eahey0ovFutS0Ng dbl8XwFw9lOyYuw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=HUIaSYrceLEtfm6QWa22fDzgxde1+Vcj3T03geJ3AkcGLxxwW2AmSzzX P/rTk9/nZnCmsV31Fvf1U+r8XQCoPYqMM8e+F1yV8DynCCqyC4RfxpCSt4RVoM3u DROQb5EPPdDlD7Yks6ec0ZibtY9MbhOu9tkIKLmvzrjkkcz7mf8= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 672b6df3 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 11 Sep 2017 09:56:43 +0200 (CEST) Date: Mon, 11 Sep 2017 09:56:41 +0200 From: Emmanuel Vadot To: Mark Millard Cc: FreeBSD Toolchain , freebsd-arm , FreeBSD Current Subject: Re: Missing in action during arm64/aarch64 builds: no pine64_plus.dtb to be found from buildkernel, installkernel, or u-boot-pine64 Message-Id: <20170911095641.616658985e7148a88f6c03a7@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Mon, 11 Sep 2017 08:56:47 -0000 On Sat, 9 Sep 2017 16:35:11 -0700 Mark Millard wrote: > The context here is head -r323246 amd64 -> arm64/aarch64 > cross build activity. > > From installkernel : > > # find /usr/obj/DESTDIRs/clang-cortexA53-installkernel/ -name "*.dtb" -print > # > > From buildkernel : > > # find /usr/obj/cortexA53_clang/arm64.aarch64/ -name "*.dtb" -print > # > > From installing u-boot-pine64 : > > # ls -lTd /usr/local/share/u-boot/u-boot-pine64/* > -rw-r--r-- 1 root wheel 125 Sep 6 00:49:44 2017 /usr/local/share/u-boot/u-boot-pine64/README > -rw-r--r-- 1 root wheel 505940 Sep 6 00:49:43 2017 /usr/local/share/u-boot/u-boot-pine64/u-boot-sunxi-with-spl.bin > > > As stands the file must be manually produced. Since the latest update of u-boot-pine64 the dtb is included in u-boot. U-Boot loads it and pass it to boot1.efi. > crochet goes to the trouble to have logic to > build and install pine64_plus.dtb (based on > arm64/pine64_plus.dts ). > > Is pine64_plus.dtb required for the likes of > Pine64+ 2GB's? If yes: should it be automatically > built and installed someplace for arm64/aarch64 > builds (even if more manual steps are required to > have the final placement on the Pine64 media)? > > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Sep 11 09:21:38 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 CCCE5E00041 for ; Mon, 11 Sep 2017 09:21:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 906397D482 for ; Mon, 11 Sep 2017 09:21:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5488 invoked from network); 11 Sep 2017 09:27:02 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 11 Sep 2017 09:27:02 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Mon, 11 Sep 2017 05:21:37 -0400 (EDT) Received: (qmail 11245 invoked from network); 11 Sep 2017 09:21:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Sep 2017 09:21:36 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 163F0EC86EF; Mon, 11 Sep 2017 02:21:36 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r323246 Pine64+ 2GB boot time context: acquiring blockable sleep lock with spinlock or critical section held for data_abort calling pmap_fault calling __mtx_lock_flags Date: Mon, 11 Sep 2017 02:21:35 -0700 References: <8419C238-702D-4BF7-89DB-EC649CD405A5@dsl-only.net> <9DB26517-E4E0-4B2A-9855-9F7381AD4C66@dsl-only.net> To: FreeBSD Toolchain , freebsd-arm , freebsd-hackers In-Reply-To: <9DB26517-E4E0-4B2A-9855-9F7381AD4C66@dsl-only.net> Message-Id: 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: Mon, 11 Sep 2017 09:21:38 -0000 [I got another blockable sleep lock panic during the Pine64+ 2GB boot, this time with ddb> input working. I show both the older example and the new one.] On 2017-Sep-10, at 3:25 PM, Mark Millard wrote: > [I got a boot-time panic with a debug kernel that > reported a "acquiring blockable sleep lock with > spinlock or critical section held (sleep mutex)". > This was for data_abort calling pmap_fault calling > __mtx_lock_flags . I first include prior non-debug > kernel reports in case they are related.] >=20 > . . . >=20 > . . . > Release APs > APs not started > CPU 0: ARM Cortex-A53 r0p4 affinity: 0 > Instruction Set Attributes 0 =3D > Instruction Set Attributes 1 =3D <0> > Processor Features 0 =3D > Processor Features 1 =3D <0> > Memory Model Features 0 =3D <4k Granule,64k = Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> > Memory Model Features 1 =3D <> > Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 = Breakpoints,PMUv3,Debug v8> > Debug Features 1 =3D <0> > Auxiliary Features 0 =3D <0> > Auxiliary Features 1 =3D <0> > CPU 1: (null) (null) r0p0 affinity: 0 > CPU 2: (null) (null) r0p0 affinity: 0 > CPU 3: (null) (null) r0p0 affinity: 0 > panic: acquiring blockable sleep lock with spinlock or critical = section held (sleep mutex) pmap @ /usr/src/sys/arm64/arm64/pmap.c:4710 > cpuid =3D 0 > time =3D 13 > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x28 > pc =3D 0xffff0000005efc78 lr =3D 0xffff000000088094 > sp =3D 0xffff000069850080 fp =3D 0xffff000069850290 >=20 > db_trace_self_wrapper() at vpanic+0x164 > pc =3D 0xffff000000088094 lr =3D 0xffff00000031764c > sp =3D 0xffff0000698502a0 fp =3D 0xffff000069850310 >=20 > vpanic() at kassert_panic+0x15c > pc =3D 0xffff00000031764c lr =3D 0xffff0000003174e4 > sp =3D 0xffff000069850320 fp =3D 0xffff0000698503e0 >=20 > kassert_panic() at witness_checkorder+0x160 > pc =3D 0xffff0000003174e4 lr =3D 0xffff000000374990 > sp =3D 0xffff0000698503f0 fp =3D 0xffff000069850470 >=20 > witness_checkorder() at __mtx_lock_flags+0xa8 > pc =3D 0xffff000000374990 lr =3D 0xffff0000002f8b7c > sp =3D 0xffff000069850480 fp =3D 0xffff0000698504b0 >=20 > __mtx_lock_flags() at pmap_fault+0x40 > pc =3D 0xffff0000002f8b7c lr =3D 0xffff000000606994 > sp =3D 0xffff0000698504c0 fp =3D 0xffff0000698504e0 >=20 > pmap_fault() at data_abort+0xb8 > pc =3D 0xffff000000606994 lr =3D 0xffff000000608a9c > sp =3D 0xffff0000698504f0 fp =3D 0xffff0000698505a0 >=20 > data_abort() at do_el1h_sync+0xfc > pc =3D 0xffff000000608a9c lr =3D 0xffff0000006088f0 > sp =3D 0xffff0000698505b0 fp =3D 0xffff0000698505e0 >=20 > do_el1h_sync() at handle_el1h_sync+0x74 > pc =3D 0xffff0000006088f0 lr =3D 0xffff0000005f1874 > sp =3D 0xffff0000698505f0 fp =3D 0xffff000069850700 >=20 > handle_el1h_sync() at sched_switch+0x2a8 > pc =3D 0xffff0000005f1874 lr =3D 0xffff00000033f0c8 > sp =3D 0xffff000069850710 fp =3D 0xffff0000698507f0 >=20 > sched_switch() at mi_switch+0x1b8 > pc =3D 0xffff00000033f0c8 lr =3D 0xffff00000032161c > sp =3D 0xffff000069850800 fp =3D 0xffff000069850820 >=20 > mi_switch() at taskqgroup_binder+0x7c > pc =3D 0xffff00000032161c lr =3D 0xffff00000035510c > sp =3D 0xffff000069850830 fp =3D 0xffff000069850860 >=20 > taskqgroup_binder() at gtaskqueue_run_locked+0x104 > pc =3D 0xffff00000035510c lr =3D 0xffff000000354f74 > sp =3D 0xffff000069850870 fp =3D 0xffff0000698508e0 >=20 > gtaskqueue_run_locked() at gtaskqueue_thread_loop+0x9c > pc =3D 0xffff000000354f74 lr =3D 0xffff000000354d10 > sp =3D 0xffff0000698508f0 fp =3D 0xffff000069850910 >=20 > gtaskqueue_thread_loop() at fork_exit+0x7c > pc =3D 0xffff000000354d10 lr =3D 0xffff0000002dbd3c > sp =3D 0xffff000069850920 fp =3D 0xffff000069850950 >=20 > fork_exit() at fork_trampoline+0x10 > pc =3D 0xffff0000002dbd3c lr =3D 0xffff000000608664 > sp =3D 0xffff000069850960 fp =3D 0x0000000000000000 >=20 > KDB: enter: panic > [ thread pid 0 tid 100058 ] > Stopped at sched_switch+0x2b8: ldrb w9, [x8, #894] > db>=20 >=20 > Unfortunately it was not taking console input so that is > all I got. =46rom the new example: CPU 1: (null) (null) r0p0 affinity: 0 CPU 2: (null) (null) r0p0 affinity: 0 CPU 3: (null) (null) r0p0 affinity: 0 panic: acquiring blockable sleep lock with spinlock or critical section = held (sleep mutex) pmap @ /usr/src/sys/arm64/arm64/pmap.c:4710 cpuid =3D 0 time =3D 13 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffff0000005efc78 lr =3D 0xffff000000088094 sp =3D 0xffff000069850080 fp =3D 0xffff000069850290 db_trace_self_wrapper() at vpanic+0x164 pc =3D 0xffff000000088094 lr =3D 0xffff00000031764c sp =3D 0xffff0000698502a0 fp =3D 0xffff000069850310 vpanic() at kassert_panic+0x15c pc =3D 0xffff00000031764c lr =3D 0xffff0000003174e4 sp =3D 0xffff000069850320 fp =3D 0xffff0000698503e0 kassert_panic() at witness_checkorder+0x160 pc =3D 0xffff0000003174e4 lr =3D 0xffff000000374990 sp =3D 0xffff0000698503f0 fp =3D 0xffff000069850470 witness_checkorder() at __mtx_lock_flags+0xa8 pc =3D 0xffff000000374990 lr =3D 0xffff0000002f8b7c sp =3D 0xffff000069850480 fp =3D 0xffff0000698504b0 __mtx_lock_flags() at pmap_fault+0x40 pc =3D 0xffff0000002f8b7c lr =3D 0xffff000000606994 sp =3D 0xffff0000698504c0 fp =3D 0xffff0000698504e0 pmap_fault() at data_abort+0xb8 pc =3D 0xffff000000606994 lr =3D 0xffff000000608a9c sp =3D 0xffff0000698504f0 fp =3D 0xffff0000698505a0 data_abort() at do_el1h_sync+0xfc pc =3D 0xffff000000608a9c lr =3D 0xffff0000006088f0 sp =3D 0xffff0000698505b0 fp =3D 0xffff0000698505e0 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff0000006088f0 lr =3D 0xffff0000005f1874 sp =3D 0xffff0000698505f0 fp =3D 0xffff000069850700 handle_el1h_sync() at sched_switch+0x2a8 pc =3D 0xffff0000005f1874 lr =3D 0xffff00000033f0c8 sp =3D 0xffff000069850710 fp =3D 0xffff0000698507f0 sched_switch() at mi_switch+0x1b8 pc =3D 0xffff00000033f0c8 lr =3D 0xffff00000032161c sp =3D 0xffff000069850800 fp =3D 0xffff000069850820 mi_switch() at taskqgroup_binder+0x7c pc =3D 0xffff00000032161c lr =3D 0xffff00000035510c sp =3D 0xffff000069850830 fp =3D 0xffff000069850860 taskqgroup_binder() at gtaskqueue_run_locked+0x104 pc =3D 0xffff00000035510c lr =3D 0xffff000000354f74 sp =3D 0xffff000069850870 fp =3D 0xffff0000698508e0 gtaskqueue_run_locked() at gtaskqueue_thread_loop+0x9c pc =3D 0xffff000000354f74 lr =3D 0xffff000000354d10 sp =3D 0xffff0000698508f0 fp =3D 0xffff000069850910 gtaskqueue_thread_loop() at fork_exit+0x7c pc =3D 0xffff000000354d10 lr =3D 0xffff0000002dbd3c sp =3D 0xffff000069850920 fp =3D 0xffff000069850950 fork_exit() at fork_trampoline+0x10 pc =3D 0xffff0000002dbd3c lr =3D 0xffff000000608664 sp =3D 0xffff000069850960 fp =3D 0x0000000000000000 KDB: enter: panic [ thread pid 0 tid 100058 ] Stopped at sched_switch+0x2b8: ldrb w9, [x8, #894] It turns our that x8 is reported as holding the value zero: db> show regs No such command; use "help" to list available commands db> show reg spsr 0x9600000440000085 x0 0xffff000000ac1000 __pcpu+0x200 x1 0x4 x2 0xffff00000068a5cb $d.4+0x15c x3 0x218 $d.9+0x1d8 x4 0 x5 0x11 x6 0xffff000000a45f20 x7 0x40 $d.14 x8 0 x9 0x5 x10 0xffff0000009a7d88 tdq_cpu+0xe08 x11 0x18 x12 0x1ddc88 x13 0x7ff707d0 x14 0 x15 0x7ff6e010 x16 0x2af8 $d.1+0x122e x17 0x27c0 $d.1+0xef6 x18 0xffff000069850790 x19 0xfffffd0001415a80 x20 0xffff0000009a7c80 tdq_cpu+0xd00 x21 0xffff0000009a6f80 tdq_cpu x22 0xffff0000009a7d1d tdq_cpu+0xd9d x23 0x1 x24 0 x25 0xffff0000009a6f80 tdq_cpu x26 0xffff000000c85000 dpcpu+0x158 x27 0xffff000000c85000 dpcpu+0x158 x28 0 x29 0xffff0000698507f0 lr 0xffff00000033f0cc sched_switch+0x2ac elr 0xffff00000033f0dc sched_switch+0x2bc sp 0xffff000069850790 sched_switch+0x2b8: ldrb w9, [x8, #894] db> show lockchain thread 100058 (pid 0, softirq_1) is on a run queue db> show locks db> show lock db> show locktree db> show sleepqueue db> show sleepq ddb> show sleepchain thread 100058 (pid 0, softirq_1) is on a run queue db> show alllocks Process 0 (kernel) thread 0xffff000000acd500 (100000) exclusive sleep mutex Giant (Giant) r =3D 0 (0xffff000000c5d860) locked = @ /usr/src/sys/kern/kern_module.c:116 db> show allchains chain 1: thread 100049 (pid 18, vmdaemon) sleeping on 0xffff000000aa811c = "psleep" chain 2: thread 100054 (pid 17, laundry: dom0) sleeping on 0xffff000000aa80c4 = "launds" chain 3: thread 100055 (pid 17, uma) sleeping on 0xffff000000aa7b68 "umarcl" chain 4: thread 100047 (pid 16, mmcsd0: mmc/sd card) sleeping on = 0xfffffd0000638800 "mmcsd disk jobqueue" chain 5: thread 100046 (pid 15, soaiod4) sleeping on 0xffff000000a9dbe4 "-" chain 6: thread 100045 (pid 9, soaiod3) sleeping on 0xffff000000a9dbe4 "-" chain 7: thread 100044 (pid 8, soaiod2) sleeping on 0xffff000000a9dbe4 "-" chain 8: thread 100043 (pid 7, soaiod1) sleeping on 0xffff000000a9dbe4 "-" chain 9: thread 100036 (pid 5, sctp_iterator) sleeping on 0xffff000000c7bf20 = "waiting_for_work" chain 10: thread 100028 (pid 14, usbus0) sleeping on 0xffff000040925358 "-" chain 11: thread 100029 (pid 14, usbus0) sleeping on 0xffff0000409253b0 "-" chain 12: thread 100030 (pid 14, usbus0) sleeping on 0xffff000040925408 "-" chain 13: thread 100031 (pid 14, usbus0) sleeping on 0xffff000040925460 "-" chain 14: thread 100032 (pid 14, usbus0) sleeping on 0xffff0000409254b8 "-" chain 15: thread 100025 (pid 4, doneq0) sleeping on 0xffff000000878280 "-" chain 16: thread 100042 (pid 4, scanner) sleeping on 0xffff0000008780c8 "-" chain 17: thread 100024 (pid 3, crypto returns) sleeping on 0xffff000000aa6008 = "crypto_ret_wait" chain 18: thread 100023 (pid 2, crypto) sleeping on 0xffff000000aa5ec0 = "crypto_wait" chain 19: thread 100019 (pid 13, g_event) sleeping on 0xffff000000c6a450 "-" chain 20: thread 100020 (pid 13, g_up) sleeping on 0xffff000000c6a460 "-" chain 21: thread 100021 (pid 13, g_down) sleeping on 0xffff000000c6a458 "-" chain 22: thread 100014 (pid 12, swi4: clock (0)) blocked on lock = 0xffff000000c5d860 (sleep mutex) "Giant" thread 100000 (pid 0, swapper) is on a run queue chain 23: thread 100002 (pid 1, kernel) blocked on lock 0xffff000000c5d860 (sleep = mutex) "Giant" thread 100000 (pid 0, swapper) is on a run queue chain 24: thread 100001 (pid 10, audit) sleeping on 0xffff000000c808e0 = "audit_worker_cv" chain 25: thread 100009 (pid 0, thread taskq) sleeping on 0xfffffd00005f2b00 "-" chain 26: thread 100010 (pid 0, aiod_kick taskq) sleeping on 0xfffffd00005f2a00 = "-" chain 27: thread 100012 (pid 0, kqueue_ctx taskq) sleeping on 0xfffffd00005f2700 = "-" chain 28: thread 100022 (pid 0, firmware taskq) sleeping on 0xfffffd00005f2000 = "-" chain 29: thread 100037 (pid 0, acpi_task_0) sleeping on 0xfffffd00005f1400 "-" chain 30: thread 100038 (pid 0, acpi_task_1) sleeping on 0xfffffd00005f1400 "-" chain 31: thread 100039 (pid 0, acpi_task_2) sleeping on 0xfffffd00005f1400 "-" chain 32: thread 100041 (pid 0, CAM taskq) sleeping on 0xfffffd00005f1e00 "-" chain 33: thread 100056 (pid 0, if_config_tqg_0) sleeping on 0xfffffd00005f1300 = "-" chain 34: thread 100057 (pid 0, softirq_0) sleeping on 0xfffffd00005f1200 "-" chain 35: thread 100059 (pid 0, softirq_2) sleeping on 0xfffffd00005f1000 "-" chain 36: thread 100060 (pid 0, softirq_3) sleeping on 0xfffffd00005f0e00 "-" The code for: panic: acquiring blockable sleep lock with spinlock or critical section = held (sleep mutex) pmap @ /usr/src/sys/arm64/arm64/pmap.c:4710 is the PMAP_LOCK in: int pmap_fault(pmap_t pmap, uint64_t esr, uint64_t far) { #ifdef SMP uint64_t par; #endif =20 switch (ESR_ELx_EXCEPTION(esr)) { case EXCP_DATA_ABORT_L: case EXCP_DATA_ABORT: break; default: return (KERN_FAILURE); } =20 #ifdef SMP PMAP_LOCK(pmap); switch (esr & ISS_DATA_DFSC_MASK) { case ISS_DATA_DFSC_TF_L0: case ISS_DATA_DFSC_TF_L1: case ISS_DATA_DFSC_TF_L2: case ISS_DATA_DFSC_TF_L3: /* Ask the MMU to check the address */ if (pmap =3D=3D kernel_pmap) par =3D arm64_address_translate_s1e1r(far); else par =3D arm64_address_translate_s1e0r(far); =20 /* * If the translation was successful the address was = invalid * due to a break-before-make sequence. We can unlock = and * return success to the trap handler. */ if (PAR_SUCCESS(par)) { PMAP_UNLOCK(pmap); return (KERN_SUCCESS); } break; default: break; } PMAP_UNLOCK(pmap); #endif =20 return (KERN_FAILURE); } =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Sep 11 18:56:58 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 87E02E1D5C2 for ; Mon, 11 Sep 2017 18:56:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (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 4AF7B6DD29 for ; Mon, 11 Sep 2017 18:56:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8405 invoked from network); 11 Sep 2017 18:56:57 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 11 Sep 2017 18:56:57 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Mon, 11 Sep 2017 14:56:57 -0400 (EDT) Received: (qmail 19537 invoked from network); 11 Sep 2017 18:56:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Sep 2017 18:56:57 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 4786CEC94BF; Mon, 11 Sep 2017 11:56:56 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: FYI: I have submitted an intermittent -r323246 debug-kernel panic problem for the Pine64+ 2GB context (so A64): bugzilla 222234 Message-Id: <99F9944A-E03C-45F5-8F6C-C3DD1E76D328@dsl-only.net> Date: Mon, 11 Sep 2017 11:56:55 -0700 To: Emmanuel Vadot , freebsd-arm , FreeBSD Current , freebsd-hackers 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: Mon, 11 Sep 2017 18:56:58 -0000 [Note: I've jumped from way back around -r308??? to -r323246 finally. The -r323246 is an example but I've no clue what range of revisions of head also show the issue. But before this jump I'd never seen such a boot-panic.] The content of the description is: Based on a head -r323246 debug kernel build: Occasionally when I boot the Pine64+ 2GB I get: panic: acquiring blockable sleep lock with spinlock or critical section = held (sleep mutex) pmap @ /usr/src/sys/arm64/arm64/pmap.c:4710 This is the PMAP_LOCK in: int pmap_fault(pmap_t pmap, uint64_t esr, uint64_t far) . . . It reports: [ thread pid 0 tid 100058 ] Stopped at sched_switch+0x2b8: ldrb w9, [x8, #894] It turns our that x8 is reported as holding the value zero: db> show reg . . . x8 0 . . . The back trace is: . . . (a little text given a clue about where in the boot sequence) . . = . CPU 1: (null) (null) r0p0 affinity: 0 CPU 2: (null) (null) r0p0 affinity: 0 CPU 3: (null) (null) r0p0 affinity: 0 panic: acquiring blockable sleep lock with spinlock or critical section = held (sleep mutex) pmap @ /usr/src/sys/arm64/arm64/pmap.c:4710 cpuid =3D 0 time =3D 13 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffff0000005efc78 lr =3D 0xffff000000088094 sp =3D 0xffff000069850080 fp =3D 0xffff000069850290 db_trace_self_wrapper() at vpanic+0x164 pc =3D 0xffff000000088094 lr =3D 0xffff00000031764c sp =3D 0xffff0000698502a0 fp =3D 0xffff000069850310 vpanic() at kassert_panic+0x15c pc =3D 0xffff00000031764c lr =3D 0xffff0000003174e4 sp =3D 0xffff000069850320 fp =3D 0xffff0000698503e0 kassert_panic() at witness_checkorder+0x160 pc =3D 0xffff0000003174e4 lr =3D 0xffff000000374990 sp =3D 0xffff0000698503f0 fp =3D 0xffff000069850470 witness_checkorder() at __mtx_lock_flags+0xa8 pc =3D 0xffff000000374990 lr =3D 0xffff0000002f8b7c sp =3D 0xffff000069850480 fp =3D 0xffff0000698504b0 __mtx_lock_flags() at pmap_fault+0x40 pc =3D 0xffff0000002f8b7c lr =3D 0xffff000000606994 sp =3D 0xffff0000698504c0 fp =3D 0xffff0000698504e0 pmap_fault() at data_abort+0xb8 pc =3D 0xffff000000606994 lr =3D 0xffff000000608a9c sp =3D 0xffff0000698504f0 fp =3D 0xffff0000698505a0 data_abort() at do_el1h_sync+0xfc pc =3D 0xffff000000608a9c lr =3D 0xffff0000006088f0 sp =3D 0xffff0000698505b0 fp =3D 0xffff0000698505e0 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff0000006088f0 lr =3D 0xffff0000005f1874 sp =3D 0xffff0000698505f0 fp =3D 0xffff000069850700 handle_el1h_sync() at sched_switch+0x2a8 pc =3D 0xffff0000005f1874 lr =3D 0xffff00000033f0c8 sp =3D 0xffff000069850710 fp =3D 0xffff0000698507f0 sched_switch() at mi_switch+0x1b8 pc =3D 0xffff00000033f0c8 lr =3D 0xffff00000032161c sp =3D 0xffff000069850800 fp =3D 0xffff000069850820 mi_switch() at taskqgroup_binder+0x7c pc =3D 0xffff00000032161c lr =3D 0xffff00000035510c sp =3D 0xffff000069850830 fp =3D 0xffff000069850860 taskqgroup_binder() at gtaskqueue_run_locked+0x104 pc =3D 0xffff00000035510c lr =3D 0xffff000000354f74 sp =3D 0xffff000069850870 fp =3D 0xffff0000698508e0 gtaskqueue_run_locked() at gtaskqueue_thread_loop+0x9c pc =3D 0xffff000000354f74 lr =3D 0xffff000000354d10 sp =3D 0xffff0000698508f0 fp =3D 0xffff000069850910 gtaskqueue_thread_loop() at fork_exit+0x7c pc =3D 0xffff000000354d10 lr =3D 0xffff0000002dbd3c sp =3D 0xffff000069850920 fp =3D 0xffff000069850950 fork_exit() at fork_trampoline+0x10 pc =3D 0xffff0000002dbd3c lr =3D 0xffff000000608664 sp =3D 0xffff000069850960 fp =3D 0x0000000000000000 See: = https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-September/00330= 0.html for more details. In the console output this seem to be about the same place that the non-debug kernel (typically?) fails. =3D=3D=3D Mark Millard markmi@dsl-only.net From owner-freebsd-arm@freebsd.org Mon Sep 11 19:40:51 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 C6456E2009C; Mon, 11 Sep 2017 19:40:51 +0000 (UTC) (envelope-from hackagadget@gmail.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 88A636FAC2; Mon, 11 Sep 2017 19:40:51 +0000 (UTC) (envelope-from hackagadget@gmail.com) Received: by mail-io0-x22c.google.com with SMTP id d16so33491012ioj.3; Mon, 11 Sep 2017 12:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I3eRjKM0vpcBfVVX7MpTlkFLr9gxIKL6C04n971MtQA=; b=otMJqSXmMeTOrbFVinFfItx/S06q2cnNOKUBKL7hVCPsFCBHcfD9VoXmC8bcnzUvCT 2oUXn+MvPrV6X68pEAX6fMmdCuOg+PLV4nSQA3ZgyRCt9bpmXjauSvztPpeFDq2OwDvr UffUByuTmcE5vf/yr8VKcy0c36azJu8DGyunpDmXkm4xyfVUlWJd4MgqQQOwSrRYvjka gIuuYBTE7ax8VQT4r+OWCf1V/p7jxVOIlaBzo+Hcf+bMsMipty/mLXxobUci76mA+Bef Jxm/4DjTX3fV9wRRf0/QtsC9FUSLQr5XoTZVGfl39EhzZzXIg03zqMdtkupIF8DTlpjj 1TVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I3eRjKM0vpcBfVVX7MpTlkFLr9gxIKL6C04n971MtQA=; b=iJvJyyntTVuREHwKwI8u1Sj7HT9iDJDNMAY2i3Aai8BKHE9RZiuaL68VDndPoOJvNo c8U1jY7a7omGo0ix5NQvejh3+3MDjUzpLadTMT26yKjyX+iKpUzuz9+aGmc+32ImoEmc 34/gamBnSlN8vQE3E3rBgcncOPCKYTKkdq9D5z8bR9/85xS7/1uTSxVxfdOGRaSeFm9j dycq7au40NPTPuaL1abmiq50nFaA0Ubq75f14Rl8mi6LwjZsXuDKdsAeEDtYJTRcQZ7B AxWiWsC7kNjnpF6GsRh+6Ox7MGOKqti+oMmanaO3OkHpubO+Omd6N+NUzC8tLYcE000l xKJQ== X-Gm-Message-State: AHPjjUjzV+7XGzrd+c/3SjCNfsLeVfLxLNs6mjI+Pv2OxBiwmEgadoer vtRcoOaqNzdmNjZ8bjDIqAhqvutYVSFuc4U= X-Google-Smtp-Source: AOwi7QBgnBLG4MUaPiJzsQ51a7rouFGkBHhI+IntCAdWM5x2DkRW3yeMzg2bbnPK2F22fz6EfwsWh0Vgbq2YJl4S9aw= X-Received: by 10.202.171.142 with SMTP id u136mr11744594oie.0.1505158850958; Mon, 11 Sep 2017 12:40:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.33.5 with HTTP; Mon, 11 Sep 2017 12:40:50 -0700 (PDT) In-Reply-To: References: From: Stephen Kiernan Date: Mon, 11 Sep 2017 15:40:50 -0400 Message-ID: Subject: Re: FCP-100: armv7 plan To: Warner Losh Cc: Jan Beich , "freebsd-arm@freebsd.org" , "freebsd-toolchain@FreeBSD.org" , Jan Beich Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Mon, 11 Sep 2017 19:40:51 -0000 (replying to all this time) There are ARMv7 systems that do not have hardware floating point. This is identified by being able to enable CP10 and/or CP11 in the ACR. If one tries to enable them and, upon reading the ACR back, the values get reset, then the hardware is not there. I know this because the BCM56160 SoC from Broadcom does not have hardware floating point and it is a Cortex-A9-based SoC. On Sat, Sep 9, 2017 at 3:37 PM, Warner Losh wrote: > On Sat, Sep 9, 2017 at 1:25 PM, Jan Beich wrote: > > > Warner Losh writes: > > > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: > > > > > >> Warner Losh writes: > > >> > > >> > Greetings, > > >> > > > >> > This will serve as 'Last Call' for any objections to the plan to > > create > > >> an > > >> > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. > > >> [...] > > >> > > >> Some ports want NEON support but FCP-0100 is vague about > > FreeBSD-specific > > >> differences between armv6 and armv7. Clang appears to enable NEON for > > all > > >> *-gnueabi* targets but I have no clue about GCC. Apparently, Android > and > > >> Debian don't assume NEON on armv7. > > >> > > >> related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221898 > > >> > > > > > > Yes. We are vague about it on purpose. Just like we're vague about MMX, > > > MMX2, etc on x86 because different processors can/want use different > > > things. > > > > Do you mean similar to how FreeBSD i386 is vague about not supporting > > real i386, only i486 or later? > > > I mean we don't enumerate the list of all the processor supported things. > We default to compiling for a fairly middle of the road processor, but you > can strip that back all the way to i486, or hyper optimize for the latest > core-2 duo. > > However, armv6 vs armv7 can affect the ABI in subtle ways that's it's best > to avoid by declaring the two different. One may be able to run armv6 > binaries on an armv7 CPUs still, but we're not specifically guaranteeing > it. > > > The goal, if it doesn't work already, is for NEON to work if used, > > > but not be required, just like all the other optional features of a > CPU. > > > > FreeBSD doesn't support detecting NEON at runtime unlike Linux. > > > No, I don't mean that at all. I mean we don't care if it is enabled or > not. It doesn't affect the ABI. The kernel knows about the extensions and > saves the context when it's in use, just like the x86 kernel saves MMX, etc > context when it's in use. > > Do you > > mean at compile time? If so then the following probably needs to change > > > > $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E - > fgrep -i neon > > #define __ARM_NEON 1 > > #define __ARM_NEON_FP 0x4 > > #define __ARM_NEON__ 1 > > > > Right. that's based on the default target. gcc/clang can enable or disable > it (and a dozen other things) depending on what options you give. We don't > care. We'll run all binaries. It's up to the system integrator to mix/match > the options so they get optimal performance for their platform. > > Just like on x86. If you compile for MMX and run it on 486 w/o run-time > detection, you'll get a reserved instruction fault. Same philosophy here. > We don't dictate policy for the binaries, just like on x86. However, most > of them have run-time detection to be nicer to the users than a core dump, > and most do the best thing for that CPU if they really care about > performance, but those applications that don't can just do whatever and be > fine. > > Warner > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Mon Sep 11 21:58:48 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 DDA85E01FDE for ; Mon, 11 Sep 2017 21:58:48 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 C30E074AEE for ; Mon, 11 Sep 2017 21:58:48 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 684a0790-973c-11e7-950d-03a3531dacf2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 684a0790-973c-11e7-950d-03a3531dacf2; Mon, 11 Sep 2017 21:58:56 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v8BLweMW013463; Mon, 11 Sep 2017 15:58:40 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1505167119.32063.84.camel@freebsd.org> Subject: Re: Raspberry Pi 2 i2c doesn't seem to work From: Ian Lepore To: Maxim Filimonov , freebsd-arm@freebsd.org Date: Mon, 11 Sep 2017 15:58:39 -0600 In-Reply-To: <96b2c29572af7ef10b5127720bf85724@bein.link> References: <96b2c29572af7ef10b5127720bf85724@bein.link> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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: Mon, 11 Sep 2017 21:58:49 -0000 On Sun, 2017-09-10 at 20:05 +0000, Maxim Filimonov wrote: > Hello everyone, > > I understand something has been discussed on this matter, however > Google doesn't say anything. > I have a Raspberry Pi 2, and currently I installed FreeBSD 11.1- > STABLE on it. > Works fine, but when I try to detect i2c devices (using `i2c -s -f > /dev/iic1`), it shows nothing. > ktrace/kdump show it has "Device not configured" on every address. > On Linux, the device (address 0x77) detects just fine. > What am I missing? Do I have to configure GPIO pins separately? > Thanks in advance. > As a followup for future searches... the discussion on this moved to irc, and what eventually shook out was that the device was on the i2c bus and working fine.  The problem was in the i2c(8) program: "i2c -s" didn't work on some types of i2c controllers.  There was no indication that maybe i2c(8) was the problem... when used with a "complete transfers only" i2c controller it just silently claimed no devices were on the bus. So I fixed all that, as best I could. In r323465 I added some code to i2c(8) to use a fallback scan method with controllers that can't do a START/STOP scan.  Instead it tries to read a single byte from each device address.  This isn't quite as reliable, some devices don't respond to a read that wasn't preceeded by a write of the register address, but writing isn't safe for probing.  At least now it tells you it's using a less-reliable fallback scan, so you've got some clue that the problem may be i2c(8) if it doesn't find your device.  And most i2c devices do respond to a bare read, so it makes scanning work for most common devices. -- Ian From owner-freebsd-arm@freebsd.org Tue Sep 12 22:43:23 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 D65C7E22C2B for ; Tue, 12 Sep 2017 22:43:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (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 8439466879 for ; Tue, 12 Sep 2017 22:43:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8176 invoked from network); 12 Sep 2017 22:43:16 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 12 Sep 2017 22:43:16 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Tue, 12 Sep 2017 18:43:16 -0400 (EDT) Received: (qmail 9637 invoked from network); 12 Sep 2017 22:43:16 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Sep 2017 22:43:16 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 30AA8EC7925 for ; Tue, 12 Sep 2017 15:43:15 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Another Pine64+ 2GB oddity with head -r323246 (so A64 in use): the occasional "Expensive timeout(9) function . . ." Message-Id: Date: Tue, 12 Sep 2017 15:43:14 -0700 To: freebsd-arm 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: Tue, 12 Sep 2017 22:43:23 -0000 Another thing that is different from my prior -r308??? and before Pine64+ use is that -r323246 gets occasional notices like the following, even when sitting idle. I've added a line identifying what the address just after "function: " is (looked up via objdump on the kernel file). Expensive timeout(9) function: 0xffff0000005dd044(0xffff00004091c000) = 0.002561100 s ffff0000005dd044 str x21, [sp, #-48]! Expensive timeout(9) function: 0xffff0000003978c8(0) 0.963402488 s ffff0000003978c8 stp x20, x19, [sp, #-32]! Expensive timeout(9) function: 0xffff00000059f33c(0) 0.002390250 s ffff00000059f33c stp x22, x21, [sp, #-48]! Expensive timeout(9) function: 0xffff00000021716c(0) 0.963501285 s ffff00000021716c adrp x8, ffff000000983000 = Expensive timeout(9) function: 0xffff0000003581b0(0) 0.963506661 s ffff0000003581b0 adrp x8, ffff000000c85000 = I do not see each of these every boot (and its later operation). For example my most recent boot has only gotten 0xffff00000021716c so far (somewhat after my logging in as it turns out). 0xffff00000059f33c has happened during the "add net" messaging during boot. Some context notes follow. This is with boot1.efs (as bootaa64.efi) based on having done: # svnlite update -r322941 /usr/src/sys/boot/efi/boot1/boot1.c = /usr/src/sys/boot/efi/include/efiapi.h so that what is built works on the Pine64+ 2GB. This is with a debug kernel build (because a non-debug kernel normally does not finish booting). (The debug kernel sometimes fails to boot but usually does.) This is with the kernel and world on mmcsd0 (because USB is not working). No swap. (Historically I've had world and swap on a USB SSD for the Pine64+ 2GB .) This is with having dd'd: # ls -lT /usr/local/share/u-boot/u-boot-pine64/*.bin -rw-r--r-- 1 root wheel 505940 Sep 6 00:49:43 2017 = /usr/local/share/u-boot/u-boot-pine64/u-boot-sunxi-with-spl.bin that was built from: # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 449313 Last Changed Rev: 449313 (The port had been updated after I'd last done such a thing so I updated. It turns out that with u-boot-sunxi-with-spl.bin no pine64_plus.dtb is needed on mmcsd0s1 .) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Sep 13 02:00:42 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 ACABCE05156 for ; Wed, 13 Sep 2017 02:00:42 +0000 (UTC) (envelope-from freebsd@theory14.net) Received: from bacon.theory14.net (bacon.theory14.net [45.55.200.27]) by mx1.freebsd.org (Postfix) with ESMTP id 68EB16DB0B for ; Wed, 13 Sep 2017 02:00:42 +0000 (UTC) (envelope-from freebsd@theory14.net) Received: from remote.theory14.net (remote.theory14.net [173.79.116.36]) by bacon.theory14.net (Postfix) with ESMTPSA id 201B2125ECD; Tue, 12 Sep 2017 22:00:41 -0400 (EDT) Received: from anubis.int.theory14.net (anubis.int.theory14.net [192.168.10.50]) by remote.theory14.net (Postfix) with ESMTPS id D68F36079; Tue, 12 Sep 2017 22:00:40 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Beaglebone Black + FreeBSD + USB WiFi = WAP? From: Chris Gordon In-Reply-To: Date: Tue, 12 Sep 2017 22:00:40 -0400 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <40EA308E-489D-4A0B-B75A-2CA5A4EC474E@theory14.net> <685d0eed3532a34f239e7ff893f817db@bakulin.de> <20170905141711.6545490.14963.31294@gmail.com> <656A5193-7389-476C-AF58-EB013E9155F3@theory14.net> To: Russell Haley X-Mailer: Apple Mail (2.3124) 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, 13 Sep 2017 02:00:42 -0000 > On Sep 6, 2017, at 8:13 PM, Russell Haley = wrote: >=20 > Argh! I was just in Maryland and we flew home from Dulles!!! I made > the client push the date forward to last week so I could be home for > Labour Day. >=20 > Have fun! (sob, sob, sob). ;) Sorry you missed it. I agree that timing wasn=E2=80=99t great with a = holiday weekend (for the US at least) on one side and EuroBSDcon very = soon afterward, but constraints on the availability of the hotel drove = the exact date. Maybe we can see you in 2019 (we do the conference = every other year, opposite MeetBSD). >>> I used nuttcp for testing the wired connection, so I would plan to = use that for the Wifi. >=20 > nuttcp. Got it, I'll start playing with it. For the testing described in my original email and the data below, I = used the most basic options from = https://fasterdata.es.net/performance-testing/network-troubleshooting-tool= s/nuttcp/. Specifically: Server: =20 nuttcp -S Client: nuttcp -i1 server_hostname and nuttcp -i1 -r server_hostname >>> - Can you run the bbb as a standard device (not an access point) and >>> test the performance of the wlan0 interface using the method of >>> measurement pointed above? I will do the same at some point with my >>> wi-fi dongle. >>=20 >> Yes, that should be easy to do, but will be next week before I have a = chance. I did the above -- setup the BBB as a simple WiFi client to my existing = (ancient) access point. I ran nuttcp between the BBB and my desktop = (wired network, access point connected to same wired network). Both the = BBBB and desktop were run as server and client for nuttcp. Many runs of = the various combinations were run. I saw the following: - In general between 10 and 20 Mbps, typically on the lower side. This = is consistent for what I see for other devices going to my access point = (again, it=E2=80=99s an old access point, circa 2008, so I don=E2=80=99t = expect too much from it) - I did have one period of slow traffic, 1 Mbps and lower. After a few = runs of this, I did a =E2=80=9Cservice netif restart=E2=80=9D, dealt = with pets for a couple of minutes and when I returned performance was = back. - I just hit another period of slow traffic, but this is around 2.5 Mbps = instead of the really bad < 1 Mbps. Instead of resetting the network, = I=E2=80=99m going to let the BBB sit until morning and test again then. = I did test my iPad with a speed test app and it=E2=80=99s getting a = little more than 10 Mbps to the internet through the same access point = that the BBB is using. I=E2=80=99ll follow up with what I see in the morning. My theories at = this time (neither very good) are: - There is a lot of wifi congestion around me and when others are = heavily using their wifi, I suffer. This is exacerbated by something = about the usb wifi NIC I have in the BBB. This doesn=E2=80=99t impact = the iPad or other devices due to differences in antennae or some other = aspect of their devices. This idea doesn=E2=80=99t quite fit with = everything, but a guess. - There is something in kernel or wireless stack that degrades over = time/amount of traffic passed that ends up limiting performance. Thanks, Chris From owner-freebsd-arm@freebsd.org Wed Sep 13 02:19:59 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 9E3FFE05EE4 for ; Wed, 13 Sep 2017 02:19:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (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 50A266E247 for ; Wed, 13 Sep 2017 02:19:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25239 invoked from network); 13 Sep 2017 02:19:57 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 13 Sep 2017 02:19:57 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Tue, 12 Sep 2017 22:19:57 -0400 (EDT) Received: (qmail 31843 invoked from network); 13 Sep 2017 02:19:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Sep 2017 02:19:57 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 5AE55EC92AD; Tue, 12 Sep 2017 19:19:56 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: FYI: Pine64+ 2GB (so A64) booting and non-debug vs. debug kernel: nondebug+INVARIANTS+INVARIANT_SUPPORT sufficient to boot Message-Id: <1C18FF04-6772-4E9C-88C5-B8D5478C5809@dsl-only.net> Date: Tue, 12 Sep 2017 19:19:55 -0700 To: Emmanuel Vadot , freebsd-arm 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, 13 Sep 2017 02:19:59 -0000 I took my normal GENERIC-NODBG (that includes GENERIC) and changed INVARIANTS and INVARIANT_SUPPORT to have "options" status instead of "nooptions" status. The result boots (so far no counterexamples). (This is head -r323246 .) So it appears that one or more INVARIANT tests are "fixing" the Pine64+ 2GB boot problem. I've no clue which. But other debug options are not required. FYI. . . # more /usr/src/sys/arm64/conf/GENERIC-NODBG = = =20 # # GENERIC -- Custom configuration for the arm64/aarch64 # include "GENERIC" ident GENERIC-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: #options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity = checking options INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones nooptions BUF_TRACKING nooptions FULL_BUF_TRACKING =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Sep 13 06:16: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 09C59E0EE68 for ; Wed, 13 Sep 2017 06:16:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (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 BC47E74FBC for ; Wed, 13 Sep 2017 06:16:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19832 invoked from network); 13 Sep 2017 06:21:59 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 13 Sep 2017 06:21:59 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Wed, 13 Sep 2017 02:16:32 -0400 (EDT) Received: (qmail 6587 invoked from network); 13 Sep 2017 06:16:32 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Sep 2017 06:16:32 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id AC413EC7925; Tue, 12 Sep 2017 23:16:31 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: Pine64+ 2GB (so A64) booting and non-debug vs. debug kernel: nondebug+INVARIANTS+INVARIANT_SUPPORT sufficient to boot Date: Tue, 12 Sep 2017 23:16:31 -0700 References: <1C18FF04-6772-4E9C-88C5-B8D5478C5809@dsl-only.net> To: Emmanuel Vadot , freebsd-arm In-Reply-To: <1C18FF04-6772-4E9C-88C5-B8D5478C5809@dsl-only.net> Message-Id: 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, 13 Sep 2017 06:16:35 -0000 [Back to nooptions for INVARIANTS and INVARIANT_SUPPORT but now verbose booting. taskqgroup_adjust_softirq(0)... is the one to not get a "done." before failure.] On 2017-Sep-12, at 7:19 PM, Mark Millard wrote: > I took my normal GENERIC-NODBG (that includes GENERIC) > and changed INVARIANTS and INVARIANT_SUPPORT to have > "options" status instead of "nooptions" status. The > result boots (so far no counterexamples). (This is > head -r323246 .) >=20 > So it appears that one or more INVARIANT tests are > "fixing" the Pine64+ 2GB boot problem. I've no clue > which. But other debug options are not required. >=20 > FYI. . . >=20 > # more /usr/src/sys/arm64/conf/GENERIC-NODBG = = =20 > # > # GENERIC -- Custom configuration for the arm64/aarch64 > # >=20 > include "GENERIC" >=20 > ident GENERIC-NODBG >=20 > makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols >=20 > options ALT_BREAK_TO_DEBUGGER >=20 > options KDB # Enable kernel debugger = support >=20 > # For minimum debugger support (stable branch) use: > #options KDB_TRACE # Print a stack trace for a = panic > options DDB # Enable the kernel debugger >=20 > # Extra stuff: > #options VERBOSE_SYSINIT # Enable verbose sysinit = messages > #options BOOTVERBOSE=3D1 > #options BOOTHOWTO=3DRB_VERBOSE > #options KTR > #options KTR_MASK=3DKTR_TRAP > ##options KTR_CPUMASK=3D0xF > #options KTR_VERBOSE >=20 > # Disable any extra checking for. . . > nooptions DEADLKRES # Enable the deadlock resolver > options INVARIANTS # Enable calls of extra sanity = checking > options INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS > nooptions WITNESS # Enable checks to detect = deadlocks and cycles > nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed > nooptions DIAGNOSTIC > nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones > nooptions BUF_TRACKING > nooptions FULL_BUF_TRACKING I've changed to have: options VERBOSE_SYSINIT # Enable verbose sysinit messages options BOOTVERBOSE=3D1 options BOOTHOWTO=3DRB_VERBOSE and: nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS The tail of the verbose failing boot looks like: . . . vt_upgrade(&vt_consdev)... done. subsystem b000000 nfs_rootconf(0)... done. fhanew_init(0)... done. subsystem d000000 proc0_post(0)... done. subsystem d800000 sctp_syscalls_init(0)... done. selectinit(0)... done. subsystem dffff9c linker_preload_finish(0)... done. subsystem e000000 kick_init(0)... done. kstack_cache_init(0)... done. subsystem e400000 vm_pageout_init(0)... done. $x.1(&page_kp)... done. subsystem e800000 $x.1(&vm_kp)... done. subsystem ea00000 $x.1(&bufspace_kp)... done. $x.1(&buf_kp)... done. subsystem ec00000 $x.1(&vnlru_kp)... done. $x.1(&up_kp)... done. subsystem ee00000 acpi_acad_ac_only(0)... done. nfsiod_setup(0)... done. subsystem f000000 release_aps(0)... Release APs APs not started done. tmr_setup_user_access(0)... done. intr_irq_shuffle(0)... done. tqg_record_smp_started(0)... done. netisr_start(0)... done. cpuset_init(0)... done. taskqgroup_adjust_if_config_tqg(0)... done. identify_cpu_sysinit(0)... CPU 0: ARM Cortex-A53 r0p4 affinity: 0 Instruction Set Attributes 0 =3D Instruction Set Attributes 1 =3D <0> Processor Features 0 =3D Processor Features 1 =3D <0> Memory Model Features 0 =3D <4k Granule,64k = Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> Memory Model Features 1 =3D <> Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 = Breakpoints,PMUv3,Debug v8> Debug Features 1 =3D <0> Auxiliary Features 0 =3D <0> Auxiliary Features 1 =3D <0> CPU 1: (null) (null) r0p0 affinity: 0 CPU 2: (null) (null) r0p0 affinity: 0 CPU 3: (null) (null) r0p0 affinity: 0 done. taskqgroup_adjust_softirq(0)... x0: ffff000000a1c080 x1: fffffd0001031a80 x2: 3 [ thread pid 0 tid 100055 ] Stopped at thread_lock_flags_+0x298: ldr w4, [x3, #156] db>=20 taskqgroup_adjust_softirq seems to be from: /usr/src/sys/kern/subr_gtaskqueue.c : TASKQGROUP_DEFINE(softirq, mp_ncpus, 1); =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Sep 13 07:08:09 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 D2F98E10E28 for ; Wed, 13 Sep 2017 07:08:09 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 9E6A376594 for ; Wed, 13 Sep 2017 07:08:09 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-io0-x22a.google.com with SMTP id n69so56921874ioi.5 for ; Wed, 13 Sep 2017 00:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references:to:cc; bh=TNAXK9YVAmFO8/7SwUls/RHU5QyxdyV0zSrPerheygA=; b=nP0sC53/yrd/Q50GcBhYTBkr/mQAolN9sjQ814KYOlCTxWKxaDXp5tabksxff+WbMn 8M8BsUDSNgjUSFTVnjDe21IjqSsy22XSIkHbiUdu7c6oIA8o7NIMsGVXB7NZQErBVgnw MD0UP8MIgUDxUEy4DYocQjdy4yKALR0ZooZ9KUSnA2G0XESEVylskW0ZPFmHljagqaVK S7DZXLWZqdGm/8940rPqqy2z45mf1uNewSGQO+kFeBPwyFNgSb3XSnTGnCtrBvMipjxu VRUZIK+W4xM5kwBvLapUlLhtU++G9s3I3BuqDqQ4QCUhHVFaDqMA1nwWfyVSfdgodQpL RGLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references:to:cc; bh=TNAXK9YVAmFO8/7SwUls/RHU5QyxdyV0zSrPerheygA=; b=cPy+I2irbShR0WQAvnm1IF3zSlw6eyididYqEY2Fv3dN+EhagBDQtkpBJjsBlP2lcb wC5N2y/aAmMUMVYe0K/20kqahT/Vn4AZ/dh/w3wZSp/aBWBmAsiAlunfUzSlLi5Qdi7F bL3xW9IYOjDzhihGZ4hkUAxhQaOyM546DKsikqUqirz3PzejNwnpa3WGa0BYtOGD305T cyNgKlndWxunsKHi0M930kY8l6C19cSgRx7LV4ygXZY6nVciC0BCGwq1AejBjywdXo8Q HLVRHXRQChslzPMhKlaUf/VVpK8506gqR4/6csiP67c3uTBlMit4B5rQ5kRZF5XoKe41 wnsQ== X-Gm-Message-State: AHPjjUhyEUs7L+PWeQulWIfkncpEK7LJoQ+SLikr9NhiJeicCSVis68d z62kILSrdaneB5QbGYw= X-Google-Smtp-Source: AOwi7QBZcQDXz2jogjxr7TZLGk1kIZAHvfAcOPRAGrgaSVhU0QwI1knja20RV7P1hMCAr8nThqGr5Q== X-Received: by 10.107.189.194 with SMTP id n185mr12794203iof.48.1505286488843; Wed, 13 Sep 2017 00:08:08 -0700 (PDT) Received: from [127.0.0.1] ([204.174.94.196]) by smtp.gmail.com with ESMTPSA id c198sm7056755ioc.67.2017.09.13.00.08.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 13 Sep 2017 00:08:06 -0700 (PDT) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.3.2163) Message-ID: <20170913070805.6545490.83195.31798@gmail.com> Date: Wed, 13 Sep 2017 00:08:05 -0700 Subject: Re: Beaglebone Black + FreeBSD + USB WiFi = WAP? From: Russell Haley In-Reply-To: References: <40EA308E-489D-4A0B-B75A-2CA5A4EC474E@theory14.net> <20170905141711.6545490.14963.31294@gmail.com> <656A5193-7389-476C-AF58-EB013E9155F3@theory14.net> To: Chris Gordon Cc: freebsd-arm 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, 13 Sep 2017 07:08:09 -0000 Need some sort of script to monitor performance of various things.=C2=A0 Netstat Load average Dtrace would be good for looking into locks,mem consumption at specific cal= ls. Start looking at how long each syscall is taking? Once you have some idea of what system calls are stalling, a dev could put = it on a debugger? Have you compared against a linux image on the same unit? Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A010=C2=A0smartphone=C2=A0on=C2= =A0the=C2=A0Virgin=C2=A0Mobile=C2=A0network. =C2=A0 Original Message =C2=A0 From: Chris Gordon Sent: Tuesday, September 12, 2017 7:00 PM To: Russell Haley Cc: freebsd-arm Subject: Re: Beaglebone Black + FreeBSD + USB WiFi =3D WAP? > On Sep 6, 2017, at 8:13 PM, Russell Haley wrote: >=20 > Argh! I was just in Maryland and we flew home from Dulles!!! I made > the client push the date forward to last week so I could be home for > Labour Day. >=20 > Have fun! (sob, sob, sob). ;) Sorry you missed it. I agree that timing wasn=E2=80=99t great with a holida= y weekend (for the US at least) on one side and EuroBSDcon very soon afterw= ard, but constraints on the availability of the hotel drove the exact date.= Maybe we can see you in 2019 (we do the conference every other year, oppos= ite MeetBSD). >>> I used nuttcp for testing the wired connection, so I would plan to use = that for the Wifi. >=20 > nuttcp. Got it, I'll start playing with it. For the testing described in my original email and the data below, I used t= he most basic options from https://fasterdata.es.net/performance-testing/ne= twork-troubleshooting-tools/nuttcp/. Specifically: Server:=20 nuttcp -S Client: nuttcp -i1 server_hostname and nuttcp -i1 -r server_hostname >>> - Can you run the bbb as a standard device (not an access point) and >>> test the performance of the wlan0 interface using the method of >>> measurement pointed above? I will do the same at some point with my >>> wi-fi dongle. >>=20 >> Yes, that should be easy to do, but will be next week before I have a ch= ance. I did the above -- setup the BBB as a simple WiFi client to my existing (an= cient) access point. I ran nuttcp between the BBB and my desktop (wired net= work, access point connected to same wired network). Both the BBBB and desk= top were run as server and client for nuttcp. Many runs of the various comb= inations were run. I saw the following: - In general between 10 and 20 Mbps, typically on the lower side. This is c= onsistent for what I see for other devices going to my access point (again,= it=E2=80=99s an old access point, circa 2008, so I don=E2=80=99t expect to= o much from it) - I did have one period of slow traffic, 1 Mbps and lower. After a few runs= of this, I did a =E2=80=9Cservice netif restart=E2=80=9D, dealt with pets = for a couple of minutes and when I returned performance was back. - I just hit another period of slow traffic, but this is around 2.5 Mbps in= stead of the really bad < 1 Mbps. Instead of resetting the network, I=E2=80= =99m going to let the BBB sit until morning and test again then. I did test= my iPad with a speed test app and it=E2=80=99s getting a little more than = 10 Mbps to the internet through the same access point that the BBB is using. I=E2=80=99ll follow up with what I see in the morning. My theories at this = time (neither very good) are: - There is a lot of wifi congestion around me and when others are heavily u= sing their wifi, I suffer. This is exacerbated by something about the usb w= ifi NIC I have in the BBB. This doesn=E2=80=99t impact the iPad or other de= vices due to differences in antennae or some other aspect of their devices.= This idea doesn=E2=80=99t quite fit with everything, but a guess. - There is something in kernel or wireless stack that degrades over time/am= ount of traffic passed that ends up limiting performance. Thanks, Chris From owner-freebsd-arm@freebsd.org Wed Sep 13 10:52:12 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 57229E1A0BD for ; Wed, 13 Sep 2017 10:52:12 +0000 (UTC) (envelope-from freebsd@theory14.net) Received: from bacon.theory14.net (bacon.theory14.net [45.55.200.27]) by mx1.freebsd.org (Postfix) with ESMTP id 302C9826BA for ; Wed, 13 Sep 2017 10:52:12 +0000 (UTC) (envelope-from freebsd@theory14.net) Received: from remote.theory14.net (remote.theory14.net [173.79.116.36]) by bacon.theory14.net (Postfix) with ESMTPSA id 1627D126011; Wed, 13 Sep 2017 06:52:11 -0400 (EDT) Received: from anubis.int.theory14.net (anubis.int.theory14.net [192.168.10.50]) by remote.theory14.net (Postfix) with ESMTPS id D136260D5; Wed, 13 Sep 2017 06:52:10 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Beaglebone Black + FreeBSD + USB WiFi = WAP? From: Chris Gordon In-Reply-To: <20170913070805.6545490.83195.31798@gmail.com> Date: Wed, 13 Sep 2017 06:52:10 -0400 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <40EA308E-489D-4A0B-B75A-2CA5A4EC474E@theory14.net> <20170905141711.6545490.14963.31294@gmail.com> <656A5193-7389-476C-AF58-EB013E9155F3@theory14.net> <20170913070805.6545490.83195.31798@gmail.com> To: Russell Haley X-Mailer: Apple Mail (2.3124) 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, 13 Sep 2017 10:52:12 -0000 Poor performance was still present this morning, but as soon as I = restarted the network interfaces, everything returned to =E2=80=9Cfull = speed=E2=80=9D. This seems to confirm the idea of something happening = over time in the kernel as opposed to some congestion or other = environmental factor. This evening, I=E2=80=99ll look at either = updating your bug report or opening a new one. > On Sep 13, 2017, at 3:08 AM, Russell Haley = wrote: >=20 > Need some sort of script to monitor performance of various things.=20 > Netstat > Load average >=20 > Dtrace would be good for looking into locks,mem consumption at = specific calls. Start looking at how long each syscall is taking? Agree. At least in my case, it=E2=80=99s something that isn=E2=80=99t a = problem initially and then builds up/falls over and becomes a problem. > Have you compared against a linux image on the same unit? I started to setup the full access point config with Linux for testing, = but just didn=E2=80=99t have the patience to deal with it. I=E2=80=99m = not sure that will reveal much given what I=E2=80=99ve found so far. Thoughts? Thanks, Chris= From owner-freebsd-arm@freebsd.org Wed Sep 13 15:22:47 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 9093FE01156 for ; Wed, 13 Sep 2017 15:22:47 +0000 (UTC) (envelope-from mail@sezi.eu) Received: from mail.fizon.de (mail.fizon.de [195.149.99.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3627169CDB for ; Wed, 13 Sep 2017 15:22:46 +0000 (UTC) (envelope-from mail@sezi.eu) Received: from sz-mbp.level1.hanse.fizon.de (p5DEDC051.dip0.t-ipconnect.de [93.237.192.81]) (authenticated bits=0) by mail.fizon.de (8.14.5/8.14.5) with ESMTP id v8DF3vBs035588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Sep 2017 17:03:57 +0200 (CEST) (envelope-from mail@sezi.eu) From: Sebastian Zietz Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: NanoPi Neo missing awg0 Message-Id: <065FD014-DA60-43D6-87E2-3B53BCDC0650@sezi.eu> Date: Wed, 13 Sep 2017 17:03:56 +0200 To: freebsd-arm@freebsd.org 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, 13 Sep 2017 15:22:47 -0000 Hi everyone, currently I am playing with my NanoPi NEO and build an image for it = using crochet. The image was able to boot but the network interface = could't be attached: # dmesg | grep awg awg0: mem = 0x1c30000-0x1c30103,0x1c00030-0x1c00033 irq 35 on simplebus0 awg0: soft reset timed out device_attach: awg0 attach returned 60 Since awg0 is running fine with the FreeBSD image linked in the = FriendlyARM wiki [1], I tried to swap its U-Boot (2016.07) against mine = from the ports (2017.07). With the following patch and the older U-Boot = I managed to get awg working: Index: sys/boot/fdt/dts/arm/h3.dtsi =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/boot/fdt/dts/arm/h3.dtsi (revision 322966) +++ sys/boot/fdt/dts/arm/h3.dtsi (working copy) @@ -36,6 +36,7 @@ =20 soc { emac: ethernet@1c30000 { + #reset-cells =3D <1>; compatible =3D "allwinner,sun8i-h3-emac"; reg =3D <0x01c30000 0x104>, <0x01c00030 0x4>; reg-names =3D "emac", "syscon"; # dmesg | grep awg awg0: mem = 0x1c30000-0x1c30103,0x1c00030-0x1c00033 irq 38 on simplebus0 miibus0: on awg0 Sadly my USB network card is not working with older U-Boot: U-Boot 2017.07 # usbconfig=20 ugen0.1: at usbus0, cfg=3D0 md=3DHOST spd=3DHIGH= (480Mbps) pwr=3DSAVE (0mA) ugen1.1: at usbus1, cfg=3D0 md=3DHOST spd=3DFULL = (12Mbps) pwr=3DSAVE (0mA) ugen1.2: at usbus1, = cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON (120mA) U-Boot 2016.07 # usbconfig=20 ugen0.1: at usbus0, cfg=3D0 md=3DHOST spd=3DHIGH= (480Mbps) pwr=3DON (0mA) ugen1.1: at usbus1, cfg=3D0 md=3DHOST spd=3DFULL = (12Mbps) pwr=3DON (0mA) For building I used GENERIC kernel and revision 322966. Does anyone know how to fix the "soft reset timed out" error? I am = thankful for every Idea, I will try it out. [1] http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO#FreeBSD= From owner-freebsd-arm@freebsd.org Thu Sep 14 00:47:51 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 7C495E18876 for ; Thu, 14 Sep 2017 00:47:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (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 3FA3681AF5 for ; Thu, 14 Sep 2017 00:47:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31956 invoked from network); 14 Sep 2017 00:47:43 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 14 Sep 2017 00:47:43 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Wed, 13 Sep 2017 20:47:43 -0400 (EDT) Received: (qmail 13704 invoked from network); 14 Sep 2017 00:47:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Sep 2017 00:47:43 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 8E8B7EC7C39; Wed, 13 Sep 2017 17:47:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: Pine64+ 2GB (so A64) booting and non-debug vs. debug kernel: nondebug+INVARIANTS+INVARIANT_SUPPORT sufficient to boot From: Mark Millard In-Reply-To: Date: Wed, 13 Sep 2017 17:47:41 -0700 Cc: freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: <6D63486A-E933-4CC2-9A24-0688BE01A0DA@dsl-only.net> References: <1C18FF04-6772-4E9C-88C5-B8D5478C5809@dsl-only.net> To: Emmanuel Vadot , freebsd-arm 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: Thu, 14 Sep 2017 00:47:51 -0000 [This time a debug kernel (including witness) and verbose booting. Also showing what has spin locks active (none) and what has critical sections mentioned on the back traces (critical_exit).] On 2017-Sep-12, at 11:16 PM, Mark Millard = wrote: > [Back to nooptions for INVARIANTS and INVARIANT_SUPPORT > but now verbose booting. taskqgroup_adjust_softirq(0)... > is the one to not get a "done." before failure.] >=20 > On 2017-Sep-12, at 7:19 PM, Mark Millard = wrote: >=20 >> I took my normal GENERIC-NODBG (that includes GENERIC) >> and changed INVARIANTS and INVARIANT_SUPPORT to have >> "options" status instead of "nooptions" status. The >> result boots (so far no counterexamples). (This is >> head -r323246 .) >>=20 >> So it appears that one or more INVARIANT tests are >> "fixing" the Pine64+ 2GB boot problem. I've no clue >> which. But other debug options are not required. >>=20 >> FYI. . . >>=20 >> # more /usr/src/sys/arm64/conf/GENERIC-NODBG = = =20 >> # >> # GENERIC -- Custom configuration for the arm64/aarch64 >> # >>=20 >> include "GENERIC" >>=20 >> ident GENERIC-NODBG >>=20 >> makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols >>=20 >> options ALT_BREAK_TO_DEBUGGER >>=20 >> options KDB # Enable kernel debugger = support >>=20 >> # For minimum debugger support (stable branch) use: >> #options KDB_TRACE # Print a stack trace for a = panic >> options DDB # Enable the kernel debugger >>=20 >> # Extra stuff: >> #options VERBOSE_SYSINIT # Enable verbose sysinit = messages >> #options BOOTVERBOSE=3D1 >> #options BOOTHOWTO=3DRB_VERBOSE >> #options KTR >> #options KTR_MASK=3DKTR_TRAP >> ##options KTR_CPUMASK=3D0xF >> #options KTR_VERBOSE >>=20 >> # Disable any extra checking for. . . >> nooptions DEADLKRES # Enable the deadlock = resolver >> options INVARIANTS # Enable calls of extra = sanity checking >> options INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS >> nooptions WITNESS # Enable checks to detect = deadlocks and cycles >> nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed >> nooptions DIAGNOSTIC >> nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones >> nooptions BUF_TRACKING >> nooptions FULL_BUF_TRACKING >=20 > I've changed to have: >=20 > options VERBOSE_SYSINIT # Enable verbose sysinit = messages > options BOOTVERBOSE=3D1 > options BOOTHOWTO=3DRB_VERBOSE >=20 > and: >=20 > nooptions INVARIANTS # Enable calls of extra = sanity checking > nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS >=20 > The tail of the verbose failing boot looks like: >=20 > . . . > vt_upgrade(&vt_consdev)... done. > subsystem b000000 > nfs_rootconf(0)... done. > fhanew_init(0)... done. > subsystem d000000 > proc0_post(0)... done. > subsystem d800000 > sctp_syscalls_init(0)... done. > selectinit(0)... done. > subsystem dffff9c > linker_preload_finish(0)... done. > subsystem e000000 > kick_init(0)... done. > kstack_cache_init(0)... done. > subsystem e400000 > vm_pageout_init(0)... done. > $x.1(&page_kp)... done. > subsystem e800000 > $x.1(&vm_kp)... done. > subsystem ea00000 > $x.1(&bufspace_kp)... done. > $x.1(&buf_kp)... done. > subsystem ec00000 > $x.1(&vnlru_kp)... done. > $x.1(&up_kp)... done. > subsystem ee00000 > acpi_acad_ac_only(0)... done. > nfsiod_setup(0)... done. > subsystem f000000 > release_aps(0)... Release APs > APs not started > done. > tmr_setup_user_access(0)... done. > intr_irq_shuffle(0)... done. > tqg_record_smp_started(0)... done. > netisr_start(0)... done. > cpuset_init(0)... done. > taskqgroup_adjust_if_config_tqg(0)... done. > identify_cpu_sysinit(0)... CPU 0: ARM Cortex-A53 r0p4 affinity: 0 > Instruction Set Attributes 0 =3D > Instruction Set Attributes 1 =3D <0> > Processor Features 0 =3D > Processor Features 1 =3D <0> > Memory Model Features 0 =3D <4k Granule,64k = Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> > Memory Model Features 1 =3D <> > Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 = Breakpoints,PMUv3,Debug v8> > Debug Features 1 =3D <0> > Auxiliary Features 0 =3D <0> > Auxiliary Features 1 =3D <0> > CPU 1: (null) (null) r0p0 affinity: 0 > CPU 2: (null) (null) r0p0 affinity: 0 > CPU 3: (null) (null) r0p0 affinity: 0 > done. > taskqgroup_adjust_softirq(0)... x0: ffff000000a1c080 > x1: fffffd0001031a80 > x2: 3 > [ thread pid 0 tid 100055 ] > Stopped at thread_lock_flags_+0x298: ldr w4, [x3, #156] > db>=20 >=20 > taskqgroup_adjust_softirq seems to be from: >=20 > /usr/src/sys/kern/subr_gtaskqueue.c : >=20 > TASKQGROUP_DEFINE(softirq, mp_ncpus, 1); [The above was a non-debug kernel with verbose messages.] So a debug kernel with verbose boot messages: CPU 1: (null) (null) r0p0 affinity: 0 CPU 2: (null) (null) r0p0 affinity: 0 CPU 3: (null) (null) r0p0 affinity: 0 done. taskqgroup_adjust_softirq(0)... panic: acquiring blockable sleep lock = with spinlock or critical section held (sleep mutex) pmap @ = /usr/src/sys/arm64/arm64/pmap.c:4710 cpuid =3D 0 time =3D 13 Thus the non-debug kernel boot-failures stop during "taskqgroup_adjust_softirq(0)..." and that is also what the debug kernel reports via witness (or invariant testing if witness is disabled). Witness does catch the problem somewhat earlier than invariant in the code sequence (when the race happens). Without invariants (and without witness) the failure seems to happen reliably. For this witness context. . . db> show allpcpu Current CPU: 0 cpuid =3D 0 dynamic pcpu =3D 0x84af00 curthread =3D 0xfffffd0001415a80: pid 0 tid 100058 "softirq_1" curpcb =3D 0xffff000069850cb0 fpcurthread =3D none idlethread =3D 0xfffffd00005de000: tid 100003 "idle: cpu0" spin locks held: cpuid =3D 1 dynamic pcpu =3D 0x81324f00 curthread =3D none curpcb =3D 0 fpcurthread =3D none idlethread =3D 0xfffffd00005dda80: tid 100004 "idle: cpu1" spin locks held: cpuid =3D 2 dynamic pcpu =3D 0x81325f00 curthread =3D none curpcb =3D 0 fpcurthread =3D none idlethread =3D 0xfffffd00005dd540: tid 100005 "idle: cpu2" spin locks held: cpuid =3D 3 dynamic pcpu =3D 0x81326f00 curthread =3D none curpcb =3D 0 fpcurthread =3D none idlethread =3D 0xfffffd00005dd000: tid 100006 "idle: cpu3" spin locks held: So no spin locks held. As for critical sections. . . db> show allchains . . . (just ones mentioning "on a run queue"). . . chain 20: thread 100014 (pid 12, swi4: clock (0)) blocked on lock = 0xffff000000c5d8e0 (sleep mutex) "Giant" thread 100000 (pid 0, swapper) is on a run queue chain 21: thread 100002 (pid 1, kernel) blocked on lock 0xffff000000c5d8e0 (sleep = mutex) "Giant" thread 100000 (pid 0, swapper) is on a run queue . . . db> thread 100000 [ thread pid 0 tid 100000 ] 0 db> bt Tracing pid 0 tid 100000 td 0xffff000000acd580 sched_switch() at mi_switch+0x1b8 pc =3D 0xffff00000033f494 lr =3D 0xffff000000321754 sp =3D 0xffff0000000109f0 fp =3D 0xffff000000010a10 mi_switch() at critical_exit+0x84 pc =3D 0xffff000000321754 lr =3D 0xffff00000031e72c sp =3D 0xffff000000010a20 fp =3D 0xffff000000010a30 critical_exit() at spinlock_exit+0x10 pc =3D 0xffff00000031e72c lr =3D 0xffff0000005f83b4 sp =3D 0xffff000000010a40 fp =3D 0xffff000000010a50 spinlock_exit() at wakeup_one+0x30 pc =3D 0xffff0000005f83b4 lr =3D 0xffff00000032157c sp =3D 0xffff000000010a60 fp =3D 0xffff000000010a70 wakeup_one() at grouptaskqueue_enqueue+0xcc pc =3D 0xffff00000032157c lr =3D 0xffff0000003533ec sp =3D 0xffff000000010a80 fp =3D 0xffff000000010aa0 =20 grouptaskqueue_enqueue() at taskqgroup_adjust+0x83c pc =3D 0xffff0000003533ec lr =3D 0xffff00000035483c sp =3D 0xffff000000010ab0 fp =3D 0xffff000000010b40 taskqgroup_adjust() at mi_startup+0x254 pc =3D 0xffff00000035483c lr =3D 0xffff0000002b5704 sp =3D 0xffff000000010b50 fp =3D 0xffff000000010bb0 mi_startup() at virtdone+0x54 pc =3D 0xffff0000002b5704 lr =3D 0xffff000000001084 sp =3D 0xffff000000010bc0 fp =3D 0x0000000000000000 From: db> show threads . . . (just ones mentioning critical_exit). . . 100027 (0xfffffd000062e000) (stack 0xffff00006a58a000) 100033 = (0xfffffd0000796000) (stack 0xffff00006a5a9000) 100034 = (0xfffffd0000795a80) (stack 0xffff00006a5b6000) 100003 = (0xfffffd00005de000) (stack 0xffff000081baa000) sched_switch() at = mi_switch+0x1b8 pc =3D 0xffff00000033f494 lr =3D 0xffff000000321754 sp =3D 0xffff000081bada20 fp =3D 0xffff000081bada40 mi_switch() at critical_exit+0x84 pc =3D 0xffff000000321754 lr =3D 0xffff00000031e72c sp =3D 0xffff000081bada50 fp =3D 0xffff000081bada60 critical_exit() at cpu_idle+0x3c pc =3D 0xffff00000031e72c lr =3D 0xffff0000005f8308 sp =3D 0xffff000081bada70 fp =3D 0xffff000081bada80 cpu_idle() at sched_idletd+0xf4 pc =3D 0xffff0000005f8308 lr =3D 0xffff000000341b84 sp =3D 0xffff000081bada90 fp =3D 0xffff000081badb50 sched_idletd() at fork_exit+0x7c pc =3D 0xffff000000341b84 lr =3D 0xffff0000002dbe74 sp =3D 0xffff000081badb60 fp =3D 0xffff000081badb90 fork_exit() at fork_trampoline+0x10 pc =3D 0xffff0000002dbe74 lr =3D 0xffff000000608664 sp =3D 0xffff000081badba0 fp =3D 0x0000000000000000 . . . I did not find any other references to "critical". Only swapper listed on the run queue as far as critical_exit goes. The other critical_exit's were from cpu_idle. It appears to me as fairly likely that what witness and invariant reports sometimes is the same thing that is involved for the non-debug kernels run into (more) reliably: non-debug is likely hanging on the lock attempt while (it appears that) a critical section is still active. As near as I can tell some invariant logic makes the critical section vs. blockable lock conflict far less likely to happen: some form of race. Thus the invariant-only and full-debug kernels usually booting, but not always booting. (But I make no claim to be expert in these areas.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Sep 14 03:45:39 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 CD6DAE22ECF for ; Thu, 14 Sep 2017 03:45:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (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 8C1AA381C for ; Thu, 14 Sep 2017 03:45:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4268 invoked from network); 14 Sep 2017 03:45:37 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 14 Sep 2017 03:45:37 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Wed, 13 Sep 2017 23:45:37 -0400 (EDT) Received: (qmail 29784 invoked from network); 14 Sep 2017 03:45:37 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Sep 2017 03:45:37 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id D8CF2EC91CC; Wed, 13 Sep 2017 20:45:36 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: A question on possible A64 (Pine64+ 2GB) aarch64 blocked_lock misuse. . . Message-Id: <91EBBD4A-DC93-44E0-A3DD-0DCECD5BB93C@dsl-only.net> Date: Wed, 13 Sep 2017 20:45:36 -0700 To: freebsd-arm , freebsd-hackers 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: Thu, 14 Sep 2017 03:45:39 -0000 I've been trying to gather evidence for why for some times head hangs up or panics on Pine64+ 2GB's (and other A64's?) during: taskqgroup_adjust_softirq(0)... in the following contexts: A) non-debug kernel build (no witness, no invariants): hang, possibly always (I've never seen a boot get past that point). B) debug kernel build (witness and invariants): sometimes gets: panic: acquiring blockable sleep lock with spinlock or critical section held (sleep mutex) pmap @ = /usr/src/sys/arm64/arm64/pmap.c:4710 C) debug kernel build (invariants but no witness): sometimes gets a kassert failure Exploring this is appears that in all cases of explicitly reported failure there is something like (witness example): . . . kassert_panic() at witness_checkorder+0x160 pc =3D 0xffff0000003174e4 lr =3D 0xffff000000374990 sp =3D 0xffff0000698503f0 fp =3D 0xffff000069850470 witness_checkorder() at __mtx_lock_flags+0xa8 pc =3D 0xffff000000374990 lr =3D 0xffff0000002f8b7c sp =3D 0xffff000069850480 fp =3D 0xffff0000698504b0 __mtx_lock_flags() at pmap_fault+0x40 pc =3D 0xffff0000002f8b7c lr =3D 0xffff000000606994 sp =3D 0xffff0000698504c0 fp =3D 0xffff0000698504e0 pmap_fault() at data_abort+0xb8 pc =3D 0xffff000000606994 lr =3D 0xffff000000608a9c sp =3D 0xffff0000698504f0 fp =3D 0xffff0000698505a0 data_abort() at do_el1h_sync+0xfc pc =3D 0xffff000000608a9c lr =3D 0xffff0000006088f0 sp =3D 0xffff0000698505b0 fp =3D 0xffff0000698505e0 . . . with the thread in question having the status of "blocked lock" (so blocked_lock in use): db> show thread 100058 Thread 100058 at 0xfffffd0001415a80: proc (pid 0): 0xffff000000c5db88 name: softirq_1 stack: 0xffff00006984d000-0xffff000069850fff flags: 0x4010004 pflags: 0x200000 state: RUNQ priority: 24 container lock: blocked lock (0xffff000000c73e30) last voluntary switch: 245 ms ago The Question: Should pmap_fault's lock activity be possible while blocked_lock is in use for the thread's container lock? FYI: The call chain leading to that status shows: do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff0000006088f0 lr =3D 0xffff0000005f1874 sp =3D 0xffff0000698505f0 fp =3D 0xffff000069850700 handle_el1h_sync() at sched_switch+0x2a8 pc =3D 0xffff0000005f1874 lr =3D 0xffff00000033f0c8 sp =3D 0xffff000069850710 fp =3D 0xffff0000698507f0 sched_switch() at mi_switch+0x1b8 pc =3D 0xffff00000033f0c8 lr =3D 0xffff00000032161c sp =3D 0xffff000069850800 fp =3D 0xffff000069850820 mi_switch() at taskqgroup_binder+0x7c pc =3D 0xffff00000032161c lr =3D 0xffff00000035510c sp =3D 0xffff000069850830 fp =3D 0xffff000069850860 taskqgroup_binder() at gtaskqueue_run_locked+0x104 pc =3D 0xffff00000035510c lr =3D 0xffff000000354f74 sp =3D 0xffff000069850870 fp =3D 0xffff0000698508e0 gtaskqueue_run_locked() at gtaskqueue_thread_loop+0x9c pc =3D 0xffff000000354f74 lr =3D 0xffff000000354d10 sp =3D 0xffff0000698508f0 fp =3D 0xffff000069850910 gtaskqueue_thread_loop() at fork_exit+0x7c pc =3D 0xffff000000354d10 lr =3D 0xffff0000002dbd3c sp =3D 0xffff000069850920 fp =3D 0xffff000069850950 fork_exit() at fork_trampoline+0x10 pc =3D 0xffff0000002dbd3c lr =3D 0xffff000000608664 sp =3D 0xffff000069850960 fp =3D 0x0000000000000000 Apparently sched_switch did one of the last 2 cases of: if (TD_IS_IDLETHREAD(td)) { . . . } else if (TD_IS_RUNNING(td)) { MPASS(td->td_lock =3D=3D TDQ_LOCKPTR(tdq)); srqflag =3D preempted ? SRQ_OURSELF|SRQ_YIELDING|SRQ_PREEMPTED : SRQ_OURSELF|SRQ_YIELDING; #ifdef SMP if (THREAD_CAN_MIGRATE(td) && !THREAD_CAN_SCHED(td, = ts->ts_cpu)) ts->ts_cpu =3D sched_pickcpu(td, 0); #endif if (ts->ts_cpu =3D=3D cpuid) tdq_runq_add(tdq, td, srqflag); else { KASSERT(THREAD_CAN_MIGRATE(td) || (ts->ts_flags & TSF_BOUND) !=3D 0, ("Thread %p shouldn't migrate", td)); mtx =3D sched_switch_migrate(tdq, td, srqflag); } } else { /* This thread must be going to sleep. */ TDQ_LOCK(tdq); mtx =3D thread_lock_block(td); tdq_load_rem(tdq, td); } where sched_switch_migrate also also does thread_lock_block : static struct mtx * sched_switch_migrate(struct tdq *tdq, struct thread *td, int flags) { struct tdq *tdn; =20 tdn =3D TDQ_CPU(td_get_sched(td)->ts_cpu); #ifdef SMP tdq_load_rem(tdq, td); /* * Do the lock dance required to avoid LOR. We grab an extra * spinlock nesting to prevent preemption while we're * not holding either run-queue lock. */ spinlock_enter(); thread_lock_block(td); /* This releases the lock on tdq. */ =20 /* * Acquire both run-queue locks before placing the thread on the = new * run-queue to avoid deadlocks created by placing a thread with = a * blocked lock on the run-queue of a remote processor. The = deadlock * occurs when a third processor attempts to lock the two queues = in * question while the target processor is spinning with its own * run-queue lock held while waiting for the blocked lock to = clear. */ tdq_lock_pair(tdn, tdq); tdq_add(tdn, td, flags); tdq_notify(tdn, td); TDQ_UNLOCK(tdn); spinlock_exit(); #endif return (TDQ_LOCKPTR(tdn)); } (I have not checked for inlining so I allow for it above.) There have been past discussions such as: https://lists.freebsd.org/pipermail/freebsd-arm/2016-January/013120.html that have notes like (from before a fix to an inappropriate indirection for blocked_lock that was later changed): > > cpu_switch() already does what you describe though in a slightly > different > > way. The thread_lock() of a thread being switched out is set to > blocked_lock. > > cpu_switch() on the new CPU will always spin until cpu_switch = updates > > thread_lock of the old thread to point to the proper runq lock after > saving > > its state in the pcb. arm64 does this here: > > > > /* > > * Release the old thread. This doesn't need to be a > store-release > > * as the above dsb instruction will provide release = semantics. > > */ > > str x2, [x0, #TD_LOCK] > > #if defined(SCHED_ULE) && defined(SMP) > > /* Read the value in blocked_lock */ > > ldr x0, =3D_C_LABEL(blocked_lock) > > ldr x2, [x0] > > 1: > > ldar x3, [x1, #TD_LOCK] > > cmp x3, x2 > > b.eq 1b > > #endif > > > > Note the thread_lock_block() call just above the block you noted = from > > sched_switch_migrate() to see where td_lock is set to &blocked_lock. > > > > If the comment about 'dsb' above is wrong that might explain why you = see > > stale state in the PCB after seeing the new value of td_lock. > > > > -- > > John Baldwin Unfortunately I've no hint what causes the race condition debug kernel builds (invariants and possibly witness) get that leads to the variable behavior. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Sep 14 05:33:19 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 7979CE00BAC for ; Thu, 14 Sep 2017 05:33:19 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 66427654CF for ; Thu, 14 Sep 2017 05:33:19 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id 65777E00BAB; Thu, 14 Sep 2017 05:33:19 +0000 (UTC) Delivered-To: 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 64E27E00BAA for ; Thu, 14 Sep 2017 05:33:19 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1FD7F654CE for ; Thu, 14 Sep 2017 05:33:18 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bs.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1dsMYT-000Afb-GP; Thu, 14 Sep 2017 08:19:13 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: spi on allwinner? From: Daniel Braniss In-Reply-To: <20170303101341.ed3438ff193d36f0ed80d363@bidouilliste.com> Date: Thu, 14 Sep 2017 08:19:12 +0300 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1935694E-B319-494C-A189-5A1E91019B45@cs.huji.ac.il> References: <012A1974-4411-4C67-AB00-43961D64E4A1@cs.huji.ac.il> <20170303101341.ed3438ff193d36f0ed80d363@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3124) 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: Thu, 14 Sep 2017 05:33:19 -0000 Hi Emmanuel, summer is almost over and was wondering if there is any progress, I have a whole bunch of allwinners just waiting =E2=80=A6 cheers, danny > On 3 Mar 2017, at 11:13 AM, Emmanuel Vadot = wrote: >=20 >=20 > Hi Daniel, >=20 > As soon as I have debug why my driver doesn't work with SPI flash but > does with some RFID chip I'll commit it. > In the meantime you can test : > https://github.com/evadot/freebsd/tree/a10_spi >=20 > Thanks, >=20 > On Fri, 3 Mar 2017 10:37:16 +0200 > Daniel Braniss wrote: >=20 >> Hi All, >> any chance that we can have kernel support for SPI on the Allwinner = like we have on Raspberry? >>=20 >> I am more than willing to help debugging, >>=20 >> danny >>=20 >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >=20 >=20 > --=20 > Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Sep 14 06:54:13 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 7DD7DE03EE4 for ; Thu, 14 Sep 2017 06:54:13 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 0649167645 for ; Thu, 14 Sep 2017 06:54:13 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id m199so5905016lfe.3 for ; Wed, 13 Sep 2017 23:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=oLS+Lzp50m+y5mdPqPg+ETXqwjWaox1UPD0KELo+M3s=; b=XQMjEzEQZ+ZuVGj1+MeYBWp+CNFGuhuf7V+v8csgUo0VEESO+q7/ffqm3iF+Mla+CW +u93czehGX1NODpiUX3WV7h2C3ByioE8kppRL64v2D1X0HZghVozMCosaMBTAqlwhb+Y HVTA5R75YWYF07nbReUBbjKC4VrEkb8Usb+AvlL/K15tZXYWGenipyGfnnGIrI827e/4 9YDBtzWt9ZDxnyR3BcuNYlBO2zfp0h4ZWIO95Pn3EJaU2jRTI4fV+O3Numdgg/ODyR/Q KBbtvJ2wa22OrD1MxAzlB8rjMz4FzbBWeU9IBTrq1D4kWcN3xZsF3HjLGrKIZEXmLg60 dIGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=oLS+Lzp50m+y5mdPqPg+ETXqwjWaox1UPD0KELo+M3s=; b=IlEeouqIprIl2fnquh6ArTOGbvESHbXkLtSCHSVndit/CxhdjSwVmeadzTJi9NU0fm NMh6vMSBGQD52CT77PMeW+x4riYIHKVyBB/kZx3ice1fa60I8TA9Xn44w1aCX/QTQVI9 gmlxiQ9Rb3c6ZN4jHIxgqtclHzGPHba2YqrMwt2eJgxaToOQ2XXrEKy8CyBj3rgnlqWv WzASSs7y/UyezRXWNCbvxl2ByI+NNjueV+wTI2BYztKvTXHnjFUQ7IMfPF0sEgjdxXsS ebDMjvG00Ro0kIz9L7SrQ1iQd9Lh10AJbwtpW5rnQhbxwwe+2OIP3FUph0TV0LsanIrt C1qQ== X-Gm-Message-State: AHPjjUhRnhRtVBv3GRIHVksb1M/CHqUzrRhyujZ08ZwpTKFfUUy//+yT 8324V8+q5OVbEM9wXaWSMePP23urSjkzRjaWU+5XRQ== X-Google-Smtp-Source: AOwi7QCdJNoWCkpeErEkaEGiHHp2RrV00llHbGyt5GLf2bHOvLtMsf3zGjjKJIcbRqqBIyZJ6hB5hUHjx1IFoSmyb5k= X-Received: by 10.25.81.85 with SMTP id f82mr7738505lfb.70.1505372050925; Wed, 13 Sep 2017 23:54:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.18 with HTTP; Wed, 13 Sep 2017 23:54:10 -0700 (PDT) From: Russell Haley Date: Wed, 13 Sep 2017 23:54:10 -0700 Message-ID: Subject: HDMI not working on Imx6 Hummingboard To: freebsd-arm Content-Type: text/plain; charset="UTF-8" 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: Thu, 14 Sep 2017 06:54:13 -0000 Hi, The HDMI on my hummingboard/Imx6 (dula pro) doesn't work. I'm not sure when it broke or if I did it. usbus1: 480Mbps High Speed USB v2.0 hdmi0: i2c transfer failed: 2 fb0: failed to get EDID info from HDMI framer fbd0 on fb0 VT: initialize with new VT driver "fb". ugen1.1: at usbus1 Complete verbose kernel output here: http://termbin.com/i3rp Any help would be great. Does anyone use HDMI on imx6? Does anyone know where I should start poking? Russ From owner-freebsd-arm@freebsd.org Thu Sep 14 11:43:57 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 83F2FE11F35 for ; Thu, 14 Sep 2017 11:43:57 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 66BBB70C6F for ; Thu, 14 Sep 2017 11:43:57 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.ysv.freebsd.org (Postfix) id 62BB8E11F34; Thu, 14 Sep 2017 11:43:57 +0000 (UTC) Delivered-To: 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 62484E11F33 for ; Thu, 14 Sep 2017 11:43:57 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B31FE70C6E for ; Thu, 14 Sep 2017 11:43:56 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 82a7f75d; Thu, 14 Sep 2017 13:43:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=lP1yrC8WL3stolLoB41uMO4smms=; b=UoeKZwm7fpR/Nn/AoCZcHLBBWrSu JkizVqAQyIbUcZgS5x5n/gIICcSDJtbMTQ39AJonHDS6Gumo8mcmmSwSsp4/RBbi 6cs0b6Hblu9VJm3FmEB5njr6OHYSOCoZXdVpn/UPZacncTwsB8n4CK1cxjnnv//v zbifhiD0FYMq8+c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=iebPhMFParQ6c+Qx0vX5YiI3wR4VX3Se0knFZ/N17opOwq/p0gYINQrZ 3Q7B9MDbaPS3KCxdHzDh2Ub4ZIJmOJqBxM6y62szcgp59mBsrgjCMwuEDhUdAf7o 7FKQ7751yQMBKiyt3IbfCk8zq9DuGcdCgxyO8cFpCj71RS+wDmE= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 1859265c TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Thu, 14 Sep 2017 13:43:54 +0200 (CEST) Date: Thu, 14 Sep 2017 13:43:53 +0200 From: Emmanuel Vadot To: Daniel Braniss Cc: "freebsd-arm@freebsd.org" Subject: Re: spi on allwinner? Message-Id: <20170914134353.c410c28e6a3102a651ca28c5@bidouilliste.com> In-Reply-To: <1935694E-B319-494C-A189-5A1E91019B45@cs.huji.ac.il> References: <012A1974-4411-4C67-AB00-43961D64E4A1@cs.huji.ac.il> <20170303101341.ed3438ff193d36f0ed80d363@bidouilliste.com> <1935694E-B319-494C-A189-5A1E91019B45@cs.huji.ac.il> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Thu, 14 Sep 2017 11:43:57 -0000 On Thu, 14 Sep 2017 08:19:12 +0300 Daniel Braniss wrote: > Hi Emmanuel, > summer is almost over and was wondering if there is any progress, > I have a whole bunch of allwinners just waiting ? > cheers, > danny Hi, No I didn't take time to debug my driver yet. Cheers, > > On 3 Mar 2017, at 11:13 AM, Emmanuel Vadot wrot= e: > >=20 > >=20 > > Hi Daniel, > >=20 > > As soon as I have debug why my driver doesn't work with SPI flash but > > does with some RFID chip I'll commit it. > > In the meantime you can test : > > https://github.com/evadot/freebsd/tree/a10_spi > >=20 > > Thanks, > >=20 > > On Fri, 3 Mar 2017 10:37:16 +0200 > > Daniel Braniss wrote: > >=20 > >> Hi All, > >> any chance that we can have kernel support for SPI on the Allwinner li= ke we have on Raspberry? > >>=20 > >> I am more than willing to help debugging, > >>=20 > >> danny > >>=20 > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > >=20 > >=20 > > --=20 > > Emmanuel Vadot --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Sep 14 15:01:32 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 D7AE1E1DCB8 for ; Thu, 14 Sep 2017 15:01:32 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 BA6F577A46 for ; Thu, 14 Sep 2017 15:01:32 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 9de6cd2d-995d-11e7-950d-03a3531dacf2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 9de6cd2d-995d-11e7-950d-03a3531dacf2; Thu, 14 Sep 2017 15:01:42 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v8EF1OYL019967; Thu, 14 Sep 2017 09:01:24 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1505401284.32063.145.camel@freebsd.org> Subject: Re: HDMI not working on Imx6 Hummingboard From: Ian Lepore To: Russell Haley , freebsd-arm Date: Thu, 14 Sep 2017 09:01:24 -0600 In-Reply-To: References: Content-Type: multipart/mixed; boundary="=-Y7pkKQqo9gnshUliju2L" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 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: Thu, 14 Sep 2017 15:01:33 -0000 --=-Y7pkKQqo9gnshUliju2L Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit On Wed, 2017-09-13 at 23:54 -0700, Russell Haley wrote: > Hi, > > The HDMI on my hummingboard/Imx6 (dula pro) doesn't work.  I'm not > sure when it broke or if I did it. > > usbus1: 480Mbps High Speed USB v2.0 > hdmi0: i2c transfer failed: 2 > fb0: failed to get EDID info from HDMI framer > fbd0 on fb0 > VT: initialize with new VT driver "fb". > ugen1.1: at usbus1 > > > Complete verbose kernel output here: http://termbin.com/i3rp > > Any help would be great. Does anyone use HDMI on imx6? Does anyone > know where I should start poking? > > Russ Let me know if hitting it with this hammer helps... -- Ian --=-Y7pkKQqo9gnshUliju2L Content-Disposition: inline; filename="temp.diff" Content-Type: text/x-patch; name="temp.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/dev/iicbus/iiconf.c =================================================================== --- sys/dev/iicbus/iiconf.c (revision 323390) +++ sys/dev/iicbus/iiconf.c (working copy) @@ -423,7 +423,7 @@ iicbus_transfer_gen(device_t dev, struct iic_msg * bus = children[0]; rpstart = 0; free(children, M_TEMP); - nostop = iicbus_get_nostop(dev); + //nostop = iicbus_get_nostop(dev); started = false; for (i = 0, error = 0; i < nmsgs && error == 0; i++) { addr = msgs[i].slave; --=-Y7pkKQqo9gnshUliju2L-- From owner-freebsd-arm@freebsd.org Thu Sep 14 15:03:51 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 847FDE1DE96 for ; Thu, 14 Sep 2017 15:03:51 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from anteater.dogwood.relay.mailchannels.net (anteater.dogwood.relay.mailchannels.net [23.83.211.3]) (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 14BB177BC2 for ; Thu, 14 Sep 2017 15:03:50 +0000 (UTC) (envelope-from ian@freebsd.org) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 15A565C91DB for ; Thu, 14 Sep 2017 15:03:44 +0000 (UTC) Received: from outbound1a.eu.mailhop.org (unknown [100.96.139.214]) (Authenticated sender: duocircle) by relay.mailchannels.net (Postfix) with ESMTPA id 6DDBC5C8A03 for ; Thu, 14 Sep 2017 15:03:43 +0000 (UTC) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [172.20.55.158]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.9.14); Thu, 14 Sep 2017 15:03:44 +0000 X-MC-Relay: Junk X-MailChannels-SenderId: _forwarded-from|73.78.92.27 X-MailChannels-Auth-Id: duocircle X-Dime-Descriptive: 5d5e30a16552ff0b_1505401423885_721659608 X-MC-Loop-Signature: 1505401423885:2201227157 X-MC-Ingress-Time: 1505401423885 X-MHO-User: e2d2da82-995d-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id e2d2da82-995d-11e7-a893-25625093991c; Thu, 14 Sep 2017 15:03:38 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v8EF3b9a019973; Thu, 14 Sep 2017 09:03:37 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1505401417.32063.146.camel@freebsd.org> Subject: Re: HDMI not working on Imx6 Hummingboard From: Ian Lepore To: Russell Haley , freebsd-arm Date: Thu, 14 Sep 2017 09:03:37 -0600 In-Reply-To: <1505401284.32063.145.camel@freebsd.org> References: <1505401284.32063.145.camel@freebsd.org> Content-Type: multipart/mixed; boundary="=-+9s7BOdCjHp8G5smiCHP" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 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: Thu, 14 Sep 2017 15:03:51 -0000 --=-+9s7BOdCjHp8G5smiCHP Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable On Thu, 2017-09-14 at 09:01 -0600, Ian Lepore wrote: > On Wed, 2017-09-13 at 23:54 -0700, Russell Haley wrote: > >=20 > > Hi, > >=20 > > The HDMI on my hummingboard/Imx6 (dula pro) doesn't work.=A0=A0I'm no= t > > sure when it broke or if I did it. > >=20 > > usbus1: 480Mbps High Speed USB v2.0 > > hdmi0: i2c transfer failed: 2 > > fb0: failed to get EDID info from HDMI framer > > fbd0 on fb0 > > VT: initialize with new VT driver "fb". > > ugen1.1: at usbus1 > >=20 > >=20 > > Complete verbose kernel output here: http://termbin.com/i3rp > >=20 > > Any help would be great. Does anyone use HDMI on imx6? Does anyone > > know where I should start poking? > >=20 > > Russ > Let me know if hitting it with this hammer helps... >=20 Umm, actually, that's just a compile error, try it this way... -- Ian --=-+9s7BOdCjHp8G5smiCHP Content-Disposition: inline; filename="temp.diff" Content-Type: text/x-patch; name="temp.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/dev/iicbus/iiconf.c =================================================================== --- sys/dev/iicbus/iiconf.c (revision 323390) +++ sys/dev/iicbus/iiconf.c (working copy) @@ -423,7 +423,7 @@ iicbus_transfer_gen(device_t dev, struct iic_msg * bus = children[0]; rpstart = 0; free(children, M_TEMP); - nostop = iicbus_get_nostop(dev); + nostop = 0; // iicbus_get_nostop(dev); started = false; for (i = 0, error = 0; i < nmsgs && error == 0; i++) { addr = msgs[i].slave; --=-+9s7BOdCjHp8G5smiCHP-- From owner-freebsd-arm@freebsd.org Fri Sep 15 04:14:59 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 B6F53E23522 for ; Fri, 15 Sep 2017 04:14:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (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 74F3076C70 for ; Fri, 15 Sep 2017 04:14:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17477 invoked from network); 15 Sep 2017 04:14:52 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 15 Sep 2017 04:14:52 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Fri, 15 Sep 2017 00:14:52 -0400 (EDT) Received: (qmail 19639 invoked from network); 15 Sep 2017 04:14:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Sep 2017 04:14:52 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 90F37EC91CC; Thu, 14 Sep 2017 21:14:51 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: Pine64+ 2GB (so A64) booting and non-debug vs. debug kernel: nondebug+INVARIANTS+INVARIANT_SUPPORT sufficient to boot Date: Thu, 14 Sep 2017 21:14:50 -0700 References: <1C18FF04-6772-4E9C-88C5-B8D5478C5809@dsl-only.net> <6D63486A-E933-4CC2-9A24-0688BE01A0DA@dsl-only.net> To: Emmanuel Vadot , freebsd-arm , freebsd-hackers In-Reply-To: <6D63486A-E933-4CC2-9A24-0688BE01A0DA@dsl-only.net> Message-Id: <8E15A747-3413-4537-9ECA-5EDAD1285351@dsl-only.net> 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: Fri, 15 Sep 2017 04:14:59 -0000 [I've traced the failure back to the bad pointer value that is in place when it was put to use. I omit the prior details of earlier explorations that got me into this area.] Summary of the following investigations: When the witness or invariant failure during: taskqgroup_adjust_softirq(0)... happens it traces back to the condition: pcpu_find(cpu)->pc_curthread =3D=3D NULL in the code: ctd =3D pcpu_find(cpu)->pc_curthread; for cpu =3D=3D 1 in tdq_notify (but inlined). It then attempts to evaluate: ctd->td_priority which gets a data_abort but it is during when blocked_lock is the container lock for the thread. In the witness included case this leads to: panic: acquiring blockable sleep lock with spinlock or critical section = held (sleep mutex) pmap @ /usr/src/sys/arm64/arm64/pmap.c:4710 cpuid =3D 0 time =3D 13 but that is a later consequence of the earlier problem. I'm not sure why pcpu_find(cpu)->pc_curthread is still NULL but since the behavior is intermittent for debug kernel builds it suggests a race for an update that was initiated but not always finished in time. (I've had occasions of hours of reboots to try to get a failure but mostly only needing a few. I've not run into a long sequence of failures to boot for a debug kernel but have had some back-to-back ones.) Supporting detail that lead to the above: int pmap_fault(pmap_t pmap, uint64_t esr, uint64_t far) The far (fault address register) argument to pmap_fault is the=20 rd one (x2 below): ffff000000606954 stp x22, x21, [sp, #-48]! ffff000000606958 stp x20, x19, [sp, #16] ffff00000060695c stp x29, x30, [sp, #32] ffff000000606960 add x29, sp, #0x20 ffff000000606964 mov x20, x2 ffff000000606968 mov x22, x1 ffff00000060696c mov x21, x0 For the failing call sequence far ends up stored on the stack via the x20 save-to-stack in: ffff0000002f8c0c <__mtx_lock_flags> stp x24, x23, [sp, #-64]! ffff0000002f8c10 <__mtx_lock_flags+0x4> stp x22, x21, [sp, #16] ffff0000002f8c14 <__mtx_lock_flags+0x8> stp x20, x19, [sp, #32] ffff0000002f8c18 <__mtx_lock_flags+0xc> stp x29, x30, [sp, #48] ffff0000002f8c1c <__mtx_lock_flags+0x10> add x29, sp, #0x30 Stack segment with a little context: 0xffff000069850470: ffff0000698504b0 ffff0000002f8b80 0xffff000069850480: ffff000000c6a528 0 0xffff000069850490: 96000004 ffff000000c6a658 0xffff0000698504a0: 37e ffff000000c6a670 0xffff0000698504b0: ffff0000698504e0 ffff000000606998 So it appears: pmap_fault`esr =3D=3D 0x96000004 pmap_fault`pmap =3D=3D 0xffff000000c6a658 (vmspace0+0x130) pmap_fault`far =3D=3D 0x37e I'll note that 0x37e =3D 894 so it matches up with x8 =3D=3D 0x0 for the likes of: elr 0xffff00000033f0dc sched_switch+0x2bc . . . ssched_switch+0x2b8: ldrb w9, [x8, #894] matching: db> show reg . . . x8 0 . . . So apparently sched_switch tried to access 0x37e db> x/gx 0xffff000000606998 =20 pmap_fault+0x44: f100111f927e0ec8 Part of the back trace is (for the example debug kernel): kassert_panic() at witness_checkorder+0x160 pc =3D 0xffff0000003174e4 lr =3D 0xffff000000374990 sp =3D 0xffff0000698503f0 fp =3D 0xffff000069850470 witness_checkorder() at __mtx_lock_flags+0xa8 pc =3D 0xffff000000374990 lr =3D 0xffff0000002f8b7c sp =3D 0xffff000069850480 fp =3D 0xffff0000698504b0 __mtx_lock_flags() at pmap_fault+0x40 pc =3D 0xffff0000002f8b7c lr =3D 0xffff000000606994 sp =3D 0xffff0000698504c0 fp =3D 0xffff0000698504e0 =20 pmap_fault() at data_abort+0xb8 pc =3D 0xffff000000606994 lr =3D 0xffff000000608a9c sp =3D 0xffff0000698504f0 fp =3D 0xffff0000698505a0 data_abort() at do_el1h_sync+0xfc pc =3D 0xffff000000608a9c lr =3D 0xffff0000006088f0 sp =3D 0xffff0000698505b0 fp =3D 0xffff0000698505e0 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff0000006088f0 lr =3D 0xffff0000005f1874 sp =3D 0xffff0000698505f0 fp =3D 0xffff000069850700 handle_el1h_sync() at sched_switch+0x2a8 pc =3D 0xffff0000005f1874 lr =3D 0xffff00000033f0c8 sp =3D 0xffff000069850710 fp =3D 0xffff0000698507f0 sched_switch() at mi_switch+0x1b8 pc =3D 0xffff00000033f0c8 lr =3D 0xffff00000032161c sp =3D 0xffff000069850800 fp =3D 0xffff000069850820 mi_switch() at taskqgroup_binder+0x7c pc =3D 0xffff00000032161c lr =3D 0xffff00000035510c sp =3D 0xffff000069850830 fp =3D 0xffff000069850860 taskqgroup_binder() at gtaskqueue_run_locked+0x104 pc =3D 0xffff00000035510c lr =3D 0xffff000000354f74 sp =3D 0xffff000069850870 fp =3D 0xffff0000698508e0 =20 gtaskqueue_run_locked() at gtaskqueue_thread_loop+0x9c pc =3D 0xffff000000354f74 lr =3D 0xffff000000354d10 sp =3D 0xffff0000698508f0 fp =3D 0xffff000069850910 gtaskqueue_thread_loop() at fork_exit+0x7c pc =3D 0xffff000000354d10 lr =3D 0xffff0000002dbd3c sp =3D 0xffff000069850920 fp =3D 0xffff000069850950 fork_exit() at fork_trampoline+0x10 pc =3D 0xffff0000002dbd3c lr =3D 0xffff000000608664 sp =3D 0xffff000069850960 fp =3D 0x0000000000000000 Note: ffff00000033f0bc ldr w0, [x19, #1292] ffff00000033f0c0 ldrb w27, [x19, #894] ffff00000033f0c4 str w0, [sp, #12] ffff00000033f0c8 bl ffff000000359708 = ffff00000033f0cc ldr x8, [x0] ffff00000033f0d0 mov w11, w27 ffff00000033f0d4 adrp x27, ffff000000c85000 = ffff00000033f0d8 ldrb w9, [x8, #894] ffff00000033f0dc cmp w11, w9 ffff00000033f0e0 b.cs ffff00000033f150 = // b.hs, b.nlast This is code for the later part of what is shown below: static void tdq_notify(struct tdq *tdq, struct thread *td) { struct thread *ctd; int pri; int cpu; if (tdq->tdq_ipipending) return; cpu =3D td_get_sched(td)->ts_cpu; pri =3D td->td_priority; ctd =3D pcpu_find(cpu)->pc_curthread; if (!sched_shouldpreempt(pri, ctd->td_priority, 1)) return; . . . } (Where: sched_shouldpreempt has been inlined and some of it is interlaced.) The failing [x8, #894] is the attempt to access: ctd->td_priority In other words: ctd =3D=3D NULL resulted from the pcpu_find (i.e., x8 =3D=3D 0 ). As for how it got to be zero: db> show reg spsr 0x9600000440000085 x0 0xffff000000ac1000 __pcpu+0x200 . . . db> x/gx cpuid_to_pcpu,32 cpuid_to_pcpu: ffff000000ac0e00 ffff000000ac1000 cpuid_to_pcpu+0x10: ffff000000ac1200 ffff000000ac1400 cpuid_to_pcpu+0x20: 0 0 . . . (So cpu =3D=3D 1 .) db> x/gx 0xffff000000ac1000,8 __pcpu+0x200: 0 fffffd00005dda80 __pcpu+0x210: 0 0 __pcpu+0x220: 0 0 __pcpu+0x230: 100000000 ffff000000ac1200 Thus it seems that at the time for cpu=3D=3D1 : pcpu_find(cpu)->pc_curthread =3D=3D NULL (at __pcpu+0x200). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sat Sep 16 13:41:08 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 22E91E17309 for ; Sat, 16 Sep 2017 13:41:08 +0000 (UTC) (envelope-from shigeru@os-hackers.jp) Received: from mailssl04.asahi-net.or.jp (mailssl04.asahi-net.or.jp [202.224.55.63]) by mx1.freebsd.org (Postfix) with ESMTP id EB9E97671E for ; Sat, 16 Sep 2017 13:41:07 +0000 (UTC) (envelope-from shigeru@os-hackers.jp) Received: from localhost (w142149.ppp.asahi-net.or.jp [121.1.142.149]) (Authenticated sender: WJ8S-YMMT) by mailssl04.asahi-net.or.jp (Postfix) with ESMTPSA id 2E3094007B for ; Sat, 16 Sep 2017 22:35:21 +0900 (JST) Date: Sun, 17 Sep 2017 07:35:22 +0900 (JST) Message-Id: <20170917.073522.1609759952573324323.shigeru@os-hackers.jp> To: freebsd-arm@freebsd.org Subject: release.sh configuration file for PINE64 From: YAMAMOTO Shigeru X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Sat, 16 Sep 2017 13:41:08 -0000 Hi, all, I create a release.sh configuration file for PINE64. https://github.com/bsd-hacker/freebsd/blob/issue/1/add_release_conf_for_pine64/release/arm64/PINE64.conf I test to build a SD image using this configuration file. Thanks, --- YAMAMOTO Shigeru From owner-freebsd-arm@freebsd.org Sat Sep 16 22:17: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 3DB28E0C360 for ; Sat, 16 Sep 2017 22:17:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (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 F3AF765948 for ; Sat, 16 Sep 2017 22:17:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15956 invoked from network); 16 Sep 2017 22:17:27 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 16 Sep 2017 22:17:27 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 16 Sep 2017 18:17:27 -0400 (EDT) Received: (qmail 6091 invoked from network); 16 Sep 2017 22:17:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Sep 2017 22:17:27 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 78A6DEC770C; Sat, 16 Sep 2017 15:17:26 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: Pine64+ 2GB (so A64) booting and non-debug vs. debug kernel: "APs not started" for failure cases only, possible missing atomic_load_acq_int's? Date: Sat, 16 Sep 2017 15:17:25 -0700 References: <1C18FF04-6772-4E9C-88C5-B8D5478C5809@dsl-only.net> <6D63486A-E933-4CC2-9A24-0688BE01A0DA@dsl-only.net> <8E15A747-3413-4537-9ECA-5EDAD1285351@dsl-only.net> To: Emmanuel Vadot , freebsd-arm , freebsd-hackers In-Reply-To: <8E15A747-3413-4537-9ECA-5EDAD1285351@dsl-only.net> Message-Id: <256CF612-1D52-4BCC-981B-E476F6EEC9AB@dsl-only.net> 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: Sat, 16 Sep 2017 22:17:35 -0000 A new finding: When verbose boot messages are enabled there is an earlier contrast between when booting works overall vs. when it later fails: When it works: subsystem f000000 release_aps(0)... Release APs done. When it fails:=20 subsystem f000000 release_aps(0)... Release APs APs not started done. And it well explains why ->pc_curthread ends up NULL for secondaries (in particular cpu =3D=3D 1), init_secondary had never executed the assignments show below:=20 while (!aps_ready) __asm __volatile("wfe"); /* Initialize curthread */ KASSERT(PCPU_GET(idlethread) !=3D NULL, ("no idle thread")); pcpup->pc_curthread =3D pcpup->pc_idlethread; pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; The subsystem messages are from: static void release_aps(void *dummy __unused) { =20 int i; =20 /* Only release CPUs if they exist */ if (mp_ncpus =3D=3D 1) return; intr_pic_ipi_setup(IPI_AST, "ast", ipi_ast, NULL); intr_pic_ipi_setup(IPI_PREEMPT, "preempt", ipi_preempt, NULL); intr_pic_ipi_setup(IPI_RENDEZVOUS, "rendezvous", ipi_rendezvous, = NULL); intr_pic_ipi_setup(IPI_STOP, "stop", ipi_stop, NULL); intr_pic_ipi_setup(IPI_STOP_HARD, "stop hard", ipi_stop, NULL); intr_pic_ipi_setup(IPI_HARDCLOCK, "hardclock", ipi_hardclock, = NULL); atomic_store_rel_int(&aps_ready, 1); /* Wake up the other CPUs */ __asm __volatile("sev"); printf("Release APs\n"); for (i =3D 0; i < 2000; i++) { if (smp_started) return; DELAY(1000); } =20 printf("APs not started\n"); } =20 SYSINIT(start_aps, SI_SUB_SMP, SI_ORDER_FIRST, release_aps, NULL); init_secondary has an example or two of not using atomic_load_acq_int when atomic_store_rel_int is in use. One is: while (!aps_ready) __asm __volatile("wfe"); /* Initialize curthread */ KASSERT(PCPU_GET(idlethread) !=3D NULL, ("no idle thread")); pcpup->pc_curthread =3D pcpup->pc_idlethread; pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; where aps_ready was declared via: /* Set to 1 once we're ready to let the APs out of the pen. */ volatile int aps_ready =3D 0; where release_aps has the use of atomic_store_rel_int: atomic_store_rel_int(&aps_ready, 1); /* Wake up the other CPUs */ __asm __volatile("sev"); There is also in init_secondary: atomic_add_rel_32(&smp_cpus, 1); if (smp_cpus =3D=3D mp_ncpus) { /* enable IPI's, tlb shootdown, freezes etc */ atomic_store_rel_int(&smp_started, 1); } where smp_cpus is accessed without being explicitly atomic. mp_ncpus seems to have no atomic use at all. Where: /usr/src/sys/sys/smp.h:extern int smp_cpus; /usr/src/sys/kern/subr_smp.c:int smp_cpus =3D 1; /* how many cpu's = running */ So no "volatile", unlike the earlier example. /usr/src/sys/kern/kern_umtx.c: if (smp_cpus > 1) { /usr/src/sys/kern/subr_smp.c:SYSCTL_INT(_kern_smp, OID_AUTO, cpus, = CTLFLAG_RD|CTLFLAG_CAPRD, &smp_cpus, 0, /usr/src/sys/sys/smp.h:extern int mp_ncpus; /usr/src/sys/kern/subr_smp.c:int mp_ncpus; The smp_started is not explicitly accessed as atomic in release_aps but in init_secondary has its update to 1 via: mtx_lock_spin(&ap_boot_mtx); atomic_add_rel_32(&smp_cpus, 1); if (smp_cpus =3D=3D mp_ncpus) { /* enable IPI's, tlb shootdown, freezes etc */ atomic_store_rel_int(&smp_started, 1); } mtx_unlock_spin(&ap_boot_mtx); where: /usr/src/sys/sys/smp.h:extern volatile int smp_started; /usr/src/sys/kern/subr_smp.c:volatile int smp_started; ("volatile" again for this context.) I'll also note that for the sparc64 architecture there is some code like: if (__predict_false(atomic_load_acq_int(&smp_started) =3D=3D 0)) that is explicitly matched to the atomic_store_rel_int in its mp_machdep.c . I do not have enough background aarch64 knowledge to know if it is provable that atomic_load_acq_int is not needed in some of these cases. But getting "APs not started" at least sometimes suggests an intermittent failure of the code as it is. Another difference is lack of explicit initialization of smp_started but explicit initialization of aps_ready and smp_cpus . I have no clue if the boot sequence is supposed to handle "APs not started" by reverting to not being a symmetric multiprocessing boot or some other specific way instead of trying to avoiding use of what was not initialized by: pcpup->pc_curthread =3D pcpup->pc_idlethread; pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; in init_secondary. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sat Sep 16 23:08:09 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 4CE3EE0EE39 for ; Sat, 16 Sep 2017 23:08:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (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 0F95966ED6 for ; Sat, 16 Sep 2017 23:08:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6494 invoked from network); 16 Sep 2017 23:08:07 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 16 Sep 2017 23:08:07 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 16 Sep 2017 19:08:07 -0400 (EDT) Received: (qmail 3174 invoked from network); 16 Sep 2017 23:08:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Sep 2017 23:08:07 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id AA922EC770C; Sat, 16 Sep 2017 16:08:06 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: Pine64+ 2GB (so A64) booting and non-debug vs. debug kernel: "APs not started" for failure cases only, possible missing atomic_load_acq_int's? Date: Sat, 16 Sep 2017 16:08:06 -0700 References: <1C18FF04-6772-4E9C-88C5-B8D5478C5809@dsl-only.net> <6D63486A-E933-4CC2-9A24-0688BE01A0DA@dsl-only.net> <8E15A747-3413-4537-9ECA-5EDAD1285351@dsl-only.net> <256CF612-1D52-4BCC-981B-E476F6EEC9AB@dsl-only.net> To: Emmanuel Vadot , freebsd-arm , freebsd-hackers In-Reply-To: <256CF612-1D52-4BCC-981B-E476F6EEC9AB@dsl-only.net> Message-Id: <2FC8A531-5E8F-4765-A1F3-A8D6A6AA0C14@dsl-only.net> 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: Sat, 16 Sep 2017 23:08:09 -0000 [Adding a couple of numbers that help interpret what I found as far as what specifically did not work as expected.] On 2017-Sep-16, at 3:17 PM, Mark Millard wrote: > A new finding: >=20 > When verbose boot messages are enabled > there is an earlier contrast between when > booting works overall vs. when it later > fails: >=20 > When it works: >=20 > subsystem f000000 > release_aps(0)... Release APs > done. >=20 > When it fails:=20 >=20 > subsystem f000000 > release_aps(0)... Release APs > APs not started > done. >=20 > And it well explains why ->pc_curthread > ends up NULL for secondaries (in particular > cpu =3D=3D 1), init_secondary had never executed > the assignments show below:=20 >=20 > while (!aps_ready) > __asm __volatile("wfe"); >=20 > /* Initialize curthread */ > KASSERT(PCPU_GET(idlethread) !=3D NULL, ("no idle thread")); > pcpup->pc_curthread =3D pcpup->pc_idlethread; > pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; >=20 > The subsystem messages are from: >=20 > static void > release_aps(void *dummy __unused) > { =20 > int i; >=20 > /* Only release CPUs if they exist */ > if (mp_ncpus =3D=3D 1) > return; >=20 > intr_pic_ipi_setup(IPI_AST, "ast", ipi_ast, NULL); > intr_pic_ipi_setup(IPI_PREEMPT, "preempt", ipi_preempt, NULL); > intr_pic_ipi_setup(IPI_RENDEZVOUS, "rendezvous", = ipi_rendezvous, NULL); > intr_pic_ipi_setup(IPI_STOP, "stop", ipi_stop, NULL); > intr_pic_ipi_setup(IPI_STOP_HARD, "stop hard", ipi_stop, NULL); > intr_pic_ipi_setup(IPI_HARDCLOCK, "hardclock", ipi_hardclock, = NULL); >=20 > atomic_store_rel_int(&aps_ready, 1); > /* Wake up the other CPUs */ > __asm __volatile("sev"); >=20 > printf("Release APs\n"); >=20 > for (i =3D 0; i < 2000; i++) { > if (smp_started) > return; > DELAY(1000); > } >=20 > printf("APs not started\n"); > } =20 > SYSINIT(start_aps, SI_SUB_SMP, SI_ORDER_FIRST, release_aps, NULL); >=20 >=20 > init_secondary has an example or two of not using > atomic_load_acq_int when atomic_store_rel_int is in > use. One is: >=20 > while (!aps_ready) > __asm __volatile("wfe"); >=20 > /* Initialize curthread */ > KASSERT(PCPU_GET(idlethread) !=3D NULL, ("no idle thread")); > pcpup->pc_curthread =3D pcpup->pc_idlethread; > pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; >=20 > where aps_ready was declared via: >=20 > /* Set to 1 once we're ready to let the APs out of the pen. */ > volatile int aps_ready =3D 0; >=20 > where release_aps has the use of atomic_store_rel_int: >=20 > atomic_store_rel_int(&aps_ready, 1); > /* Wake up the other CPUs */ > __asm __volatile("sev"); >=20 > There is also in init_secondary: >=20 > atomic_add_rel_32(&smp_cpus, 1); >=20 > if (smp_cpus =3D=3D mp_ncpus) { > /* enable IPI's, tlb shootdown, freezes etc */ > atomic_store_rel_int(&smp_started, 1); > } >=20 > where smp_cpus is accessed without being explicitly > atomic. mp_ncpus seems to have no atomic use at all. >=20 > Where: >=20 > /usr/src/sys/sys/smp.h:extern int smp_cpus; > /usr/src/sys/kern/subr_smp.c:int smp_cpus =3D 1; /* how many cpu's = running */ >=20 > So no "volatile", unlike the earlier example. >=20 > /usr/src/sys/kern/kern_umtx.c: if (smp_cpus > 1) { > /usr/src/sys/kern/subr_smp.c:SYSCTL_INT(_kern_smp, OID_AUTO, cpus, = CTLFLAG_RD|CTLFLAG_CAPRD, &smp_cpus, 0, >=20 > /usr/src/sys/sys/smp.h:extern int mp_ncpus; > /usr/src/sys/kern/subr_smp.c:int mp_ncpus; >=20 >=20 > The smp_started is not explicitly accessed as atomic > in release_aps but in init_secondary has its update > to 1 via: >=20 > mtx_lock_spin(&ap_boot_mtx); >=20 > atomic_add_rel_32(&smp_cpus, 1); >=20 > if (smp_cpus =3D=3D mp_ncpus) { > /* enable IPI's, tlb shootdown, freezes etc */ > atomic_store_rel_int(&smp_started, 1); > } >=20 > mtx_unlock_spin(&ap_boot_mtx); >=20 > where: >=20 > /usr/src/sys/sys/smp.h:extern volatile int smp_started; > /usr/src/sys/kern/subr_smp.c:volatile int smp_started; >=20 > ("volatile" again for this context.) >=20 > I'll also note that for the sparc64 architecture > there is some code like: >=20 > if (__predict_false(atomic_load_acq_int(&smp_started) =3D=3D 0)) >=20 > that is explicitly matched to the atomic_store_rel_int > in its mp_machdep.c . >=20 > I do not have enough background aarch64 knowledge to > know if it is provable that atomic_load_acq_int is not > needed in some of these cases. >=20 > But getting "APs not started" at least sometimes > suggests an intermittent failure of the code as > it is. >=20 >=20 > Another difference is lack of explicit initialization > of smp_started but explicit initialization of aps_ready > and smp_cpus . >=20 >=20 >=20 > I have no clue if the boot sequence is supposed to > handle "APs not started" by reverting to not being > a symmetric multiprocessing boot or some other > specific way instead of trying to avoiding use of > what was not initialized by: >=20 > pcpup->pc_curthread =3D pcpup->pc_idlethread; > pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; >=20 > in init_secondary. Example mp_ncpus and smp_cpus figures from a failed Pine64+ 2GB boot: db> print/x *smp_cpus 1 db> print/x *mp_ncpus 138800000004 But that should be a 4 byte width. Showing some context for reference: db> x/bx mp_ncpus-4,4=20 rebooting: 0 0 0 0 db> x/bx mp_ncpus,4 mp_ncpus: 4 0 0 0 db> x/bx mp_ncpus+4,4=20 scsi_delay: 88 13 0 0 For completeness: db> x/bx smp_cpus-4,4 sysctl___kern_smp_disabled+0x5c: 0 0 0 0 db> x/bx smp_cpus,4 smp_cpus: 1 0 0 0 db> x/bx smp_cpus+4,4=20 smp_cpus+0x4: 0 0 0 0 So smp_cpus was not incremented in memory. This goes along with no occurances of: pcpup->pc_curthread =3D pcpup->pc_idlethread; pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; updates happening in init_secondary: /* Spin until the BSP releases the APs */ while (!aps_ready) __asm __volatile("wfe"); =20 /* Initialize curthread */ KASSERT(PCPU_GET(idlethread) !=3D NULL, ("no idle thread")); pcpup->pc_curthread =3D pcpup->pc_idlethread; pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; . . . mtx_lock_spin(&ap_boot_mtx); atomic_add_rel_32(&smp_cpus, 1); if (smp_cpus =3D=3D mp_ncpus) { /* enable IPI's, tlb shootdown, freezes etc */ atomic_store_rel_int(&smp_started, 1); } mtx_unlock_spin(&ap_boot_mtx); Which seems to imply that the aps_ready update: atomic_store_rel_int(&aps_ready, 1); /* Wake up the other CPUs */ __asm __volatile("sev"); in release_aps was not seen in the: while (!aps_ready) __asm __volatile("wfe"); in init_secondary. My guess is that "while (!aps_ready)" needs to be explicit about its atomic status. aps_ready is already volatile but apparently that is not enough for this context to be reliable. The other potential needs for explicit atomics are for later execution but may be required overall as well. =3D=3D=3D Mark Millard markmi at dsl-only.net