From owner-freebsd-toolchain@freebsd.org Sun Sep 10 08:34:39 2017 Return-Path: Delivered-To: freebsd-toolchain@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 EE426E04553 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 ABDF26B28B for ; Sun, 10 Sep 2017 08:34:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26566 invoked from network); 10 Sep 2017 08:36:28 -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:36:28 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Sun Sep 10 17:43:44 2017 Return-Path: Delivered-To: freebsd-toolchain@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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Sun Sep 10 19:51:15 2017 Return-Path: Delivered-To: freebsd-toolchain@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 51525E24195 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 146478425C for ; Sun, 10 Sep 2017 19:51:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12590 invoked from network); 10 Sep 2017 19:53:09 -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:53:09 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Sun Sep 10 20:18:01 2017 Return-Path: Delivered-To: freebsd-toolchain@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 180B9E005EF for ; Sun, 10 Sep 2017 20:18:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 D9FAA79E for ; Sun, 10 Sep 2017 20:18:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22c.google.com with SMTP id o200so13193204itg.0 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=uWTbx2750qWIydzo13zfzgYM6xpbKN+6964JHtNYMFjtOAINXL2hmeNqt33o/IZ5du q9Xt04IuvMTJtMtJ8Thg/6iPgPJ1Jt51Xb27LSStyUASFZqjZvqAawnFkTxrJahe//Qp Wh5pW2ueE6/vLNiokcOU8xBlSeXZWz1tQvitPUJkhC5uU5c8GSYJ92Wda/Pvd5aIGOFS mwfq3T2xFOX+Sro1BPwgtD06a/91lZ1j2C4neg0nrSNoaNSZ4Gxz3yBP2sGNSB3B6UoI DRbXq8lH1Esrmd1fjCq9RnHw7bdL2qsfdyF+xCQ4HwWopmEFlb74CeRlqBH1KN2Zt3r+ qDAQ== X-Gm-Message-State: AHPjjUi0MVoKlIveLRn3R5rKcx7kh9vHsgJSVrNrOSAW4kr0RCgJBzQX Go7CuinbpTjRaP30hZeT+7RtFzTxQuXi 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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Sun Sep 10 21:18:31 2017 Return-Path: Delivered-To: freebsd-toolchain@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 ED02AE034A1 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 98F982438 for ; Sun, 10 Sep 2017 21:18:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15360 invoked from network); 10 Sep 2017 21:23:53 -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:23:53 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Sun Sep 10 22:17:41 2017 Return-Path: Delivered-To: freebsd-toolchain@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 0C35FE0625F for ; Sun, 10 Sep 2017 22:17:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 BFCE03FE2 for ; Sun, 10 Sep 2017 22:17:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22f.google.com with SMTP id o200so13512052itg.0 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=K/uZ8EnawnCA4tRDO4VyoQyhU5XrIFTPuNfT43jGgdgEulBNbqpVkDr09GLiyjB32W hfE9a8SUaRvREQwIxTo7MiOl6xTc3Yelgt9Z1sK840o234jwxzxanqYlTtbIUwMyOVsO HhKHHgT6F9PASVV8tQkFbyw+ZG1X0XGuPCMxoBoJ9y0TUpXXL1AfyO7mikknc0Qw/rPe fI2z7OHLEW99QD2kP07mwn/kSgBkIuXVS8eKKi2sHdLhVosNAF+zEkfGGVoNpJz6nRyF ZbwC5sy6+5hpRiapp61iCEOqOVXfThTk1m7+9WF/IAi7Flp2Y+s7r60U+6TRJuK4D2FB cMng== X-Gm-Message-State: AHPjjUgedtjjM8YlMQTNcZ/6bme09pbg0yGXfvhDai/p9wAbD/WeaGCC ME5YVzMek7QzCktor/uUasYtCkm0P1HlHbkhS4jzlA== 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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Sun Sep 10 22:25:29 2017 Return-Path: Delivered-To: freebsd-toolchain@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 66D74E06A11 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 29CC9636A3 for ; Sun, 10 Sep 2017 22:25:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 699 invoked from network); 10 Sep 2017 22:25:27 -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:25:27 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Mon Sep 11 07:01:55 2017 Return-Path: Delivered-To: freebsd-toolchain@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 51F0CE1FE5A 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 0D5E273683 for ; Mon, 11 Sep 2017 07:01:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27901 invoked from network); 11 Sep 2017 07:07:18 -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:07:18 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Mon Sep 11 08:48:59 2017 Return-Path: Delivered-To: freebsd-toolchain@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 AB1C2E23865 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 560C577B1E for ; Mon, 11 Sep 2017 08:48:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8836 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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Mon Sep 11 08:56:47 2017 Return-Path: Delivered-To: freebsd-toolchain@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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Mon Sep 11 09:21:38 2017 Return-Path: Delivered-To: freebsd-toolchain@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 D1381E00042 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 906D57D484 for ; Mon, 11 Sep 2017 09:21:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25495 invoked from network); 11 Sep 2017 09:23:33 -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:23:33 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Mon Sep 11 19:40:51 2017 Return-Path: Delivered-To: freebsd-toolchain@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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Wed Sep 13 10:36:00 2017 Return-Path: Delivered-To: freebsd-toolchain@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 F0704E19536 for ; Wed, 13 Sep 2017 10:36:00 +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 D5A2D81BB8 for ; Wed, 13 Sep 2017 10:36:00 +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 v8DAa0ia033875 for ; Wed, 13 Sep 2017 10:36:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 222280] www/firefox: 57.0 crashes clang 5.0 during build Date: Wed, 13 Sep 2017 10:36:00 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status keywords 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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 10:36:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222280 Bug ID: 222280 Summary: www/firefox: 57.0 crashes clang 5.0 during build Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Keywords: needs-qa Severity: Affects Only Me Priority: --- Component: bin Assignee: freebsd-toolchain@FreeBSD.org Reporter: jbeich@FreeBSD.org /usr/bin/c++ -std=3Dgnu++11 -o Compression.o -c -Iobj-x86_64-unknown-freebsd12.0/dist/system_wrappers -include config/gcc_hidden.h -DNDEBUG=3D1 -DTRIMMED=3D1 -DIMPL_MFBT -Imfbt -Iobj-x86_64-unknown-freebsd12.0/mfbt=20 -Iobj-x86_64-unknown-freebsd12.0/dist/include=20 -Iobj-x86_64-unknown-freebsd12.0/dist/include/nspr -Iobj-x86_64-unknown-freebsd12.0/dist/include/nss -fPIC -DMOZILLA_CL= IENT -include obj-x86_64-unknown-freebsd12.0/mozilla-config.h -MD -MP -MF .deps/Compression.o.pp -Qunused-arguments -I/usr/local/include -Qunused-arguments -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wunreachable-code-return -Wwrite-strings -Wno-invalid-offsetof -Wclass-varargs -Wloop-analysis -Wc++11-compat-pedant= ic -Wc++14-compat -Wc++14-compat-pedantic -Wc++1z-compat -Wcomma -Wimplicit-fallthrough -Wstring-conversion -Wno-inline-new-delete -Wno-error=3Ddeprecated-declarations -Wno-error=3Darray-bounds -Wformat -Wno-gnu-zero-variadic-macro-arguments -Wformat-security -Wno-unknown-warning-option -Wno-return-type-c-linkage -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -pipe -O -fno-omit-frame-pointer -Wno-error=3Dshadow -Wno-unused-function mfbt/Compression.cpp Assertion failed: (!Old || Old->getCachedLinkage() =3D=3D D->getCachedLinka= ge()), function getLVForDecl, file /usr/src/contrib/llvm/tools/clang/lib/AST/Decl.= cpp, line 1434. c++: error: unable to execute command: Abort trap c++: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 5.0.0svn) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin Regressed by: https://hg.mozilla.org/mozilla-central/rev/9a4077eda5d8 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Sep 13 10:36:56 2017 Return-Path: Delivered-To: freebsd-toolchain@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 D6B8FE195C9 for ; Wed, 13 Sep 2017 10:36:56 +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 C4DBC81BFD for ; Wed, 13 Sep 2017 10:36:56 +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 v8DAauI6035255 for ; Wed, 13 Sep 2017 10:36:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 222280] www/firefox: 57.0 crashes clang 5.0 during build Date: Wed, 13 Sep 2017 10:36:56 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: 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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 10:36:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222280 --- Comment #1 from Jan Beich --- Created attachment 186324 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D186324&action= =3Dedit mfbt/Compression.cpp (preprocessed, compressed) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Sep 13 10:37:11 2017 Return-Path: Delivered-To: freebsd-toolchain@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 E5B57E19635 for ; Wed, 13 Sep 2017 10:37:11 +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 D36B381C2A for ; Wed, 13 Sep 2017 10:37:11 +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 v8DAbBWx035592 for ; Wed, 13 Sep 2017 10:37:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 222280] www/firefox: 57.0 crashes clang 5.0 during build Date: Wed, 13 Sep 2017 10:37:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.mimetype Message-ID: In-Reply-To: References: 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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 10:37:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222280 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #186324|text/plain |application/x-xz mime type| | --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Sep 13 10:37:47 2017 Return-Path: Delivered-To: freebsd-toolchain@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 0B03FE196AA for ; Wed, 13 Sep 2017 10:37:47 +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 ED15081C91 for ; Wed, 13 Sep 2017 10:37:46 +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 v8DAbkT2036522 for ; Wed, 13 Sep 2017 10:37:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 222280] www/firefox: 57.0 crashes clang 5.0 during build Date: Wed, 13 Sep 2017 10:37:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: 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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 10:37:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222280 --- Comment #2 from Jan Beich --- Created attachment 186325 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D186325&action= =3Dedit command line args (for clang 5.0) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Sep 13 10:41:45 2017 Return-Path: Delivered-To: freebsd-toolchain@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 6D466E19A28 for ; Wed, 13 Sep 2017 10:41:45 +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 5BC5381F22 for ; Wed, 13 Sep 2017 10:41:45 +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 v8DAfjVT046266 for ; Wed, 13 Sep 2017 10:41:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 222280] www/firefox: 57.0 crashes clang during build Date: Wed, 13 Sep 2017 10:41:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: 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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 10:41:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222280 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|www/firefox: 57.0 crashes |www/firefox: 57.0 crashes |clang 5.0 during build |clang during build --- Comment #3 from Jan Beich --- Reproducible on Clang 4.0 and 3.9. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Sep 13 11:01:29 2017 Return-Path: Delivered-To: freebsd-toolchain@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 B0304E1A784 for ; Wed, 13 Sep 2017 11:01:29 +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 9EAA783082 for ; Wed, 13 Sep 2017 11:01:29 +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 v8DB1Tka016587 for ; Wed, 13 Sep 2017 11:01:29 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 222280] www/firefox: 57.0 crashes clang during build Date: Wed, 13 Sep 2017 11:01:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: see_also Message-ID: In-Reply-To: References: 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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 11:01:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222280 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.mozilla.or | |g/show_bug.cgi?id=3D1399412 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Sep 13 16:34:28 2017 Return-Path: Delivered-To: freebsd-toolchain@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 824DDE0491C for ; Wed, 13 Sep 2017 16:34:28 +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 703626D048 for ; Wed, 13 Sep 2017 16:34:28 +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 v8DGYSL7001197 for ; Wed, 13 Sep 2017 16:34:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 222280] www/firefox: 57.0 crashes clang during build Date: Wed, 13 Sep 2017 16:34:28 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status bug_severity assigned_to cc Message-ID: In-Reply-To: References: 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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 16:34:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222280 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open Severity|Affects Only Me |Affects Some People Assignee|freebsd-toolchain@FreeBSD.o |dim@FreeBSD.org |rg | CC| |davide@FreeBSD.org, | |dim@FreeBSD.org --- Comment #4 from Dimitry Andric --- This can be reduced to just: // clang -cc1 -triple x86_64 -S bug222280.cpp namespace { extern "C" union LZ4_stream_u *LZ4_createStream(); LZ4_stream_u *LZ4_createStream(); } It's apparently a long-standing problem upstream, as there are multiple bugs about it, but no conclusive fix: https://bugs.llvm.org/show_bug.cgi?id=3D18964 https://bugs.llvm.org/show_bug.cgi?id=3D19995 https://bugs.llvm.org/show_bug.cgi?id=3D21854 https://bugs.llvm.org/show_bug.cgi?id=3D23090 https://bugs.llvm.org/show_bug.cgi?id=3D33503 I'll see if I can get some movement on this upstream, and close off a bunch= of duplicates. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Sep 14 17:43:22 2017 Return-Path: Delivered-To: freebsd-toolchain@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 418ECE00999 for ; Thu, 14 Sep 2017 17:43:22 +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 2F68F2D0C for ; Thu, 14 Sep 2017 17:43:22 +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 v8EHhLcr021004 for ; Thu, 14 Sep 2017 17:43:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 219289] security/clambc: fails to build with lang/gcc6 or later Date: Thu, 14 Sep 2017 17:43:22 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-patch, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rene@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jbeich@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: resolution bug_status cc Message-ID: In-Reply-To: References: 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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 17:43:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219289 Rene Ladan changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Overcome By Events Status|New |Closed CC| |rene@FreeBSD.org --- Comment #8 from Rene Ladan --- Expired port removed. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Sep 15 10:57:03 2017 Return-Path: Delivered-To: freebsd-toolchain@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 745C3E0DE29 for ; Fri, 15 Sep 2017 10:57:03 +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 620702E4F for ; Fri, 15 Sep 2017 10:57:03 +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 v8FAv3PH079481 for ; Fri, 15 Sep 2017 10:57:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 221880] lang/gcc5: py-numpy/python2.7 core dump on FreeBSD 11.1-RELEASE amd64 Date: Fri, 15 Sep 2017 10:57:03 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: gerald@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: 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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 10:57:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221880 Gerald Pfeifer changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|gerald@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg --- Comment #2 from Gerald Pfeifer --- Do you also get this with lang/gcc6 which is the new default? It occurs to me there is something going on with FreeBSD 11.1? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Sep 16 09:39:10 2017 Return-Path: Delivered-To: freebsd-toolchain@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 DD7DFE0B102 for ; Sat, 16 Sep 2017 09:39:10 +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 CB1576FC89 for ; Sat, 16 Sep 2017 09:39:10 +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 v8G9dAIY092474 for ; Sat, 16 Sep 2017 09:39:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 221880] lang/gcc5: py-numpy/python2.7 core dump on FreeBSD 11.1-RELEASE amd64 Date: Sat, 16 Sep 2017 09:39:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: la5lbtyi@aon.at X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: 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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Sep 2017 09:39:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221880 Martin Birgmeier changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |la5lbtyi@aon.at --- Comment #3 from Martin Birgmeier --- I have a hunch that building py-numpy with gcc produces bad code which lead= s to coredumps. For example, since several months I cannot build py-matplotlib consistently any more - on most machines it fails, on one it succeeds. And graphics/qgis always dies with a signal 11. See bug #221622. And yes, I have already upgraded to gcc6, and it is the same - py-matplotlib cannot be recompiled except on one machine, and graphics/qgis (freshly recompiled) dies with a signal 11 after a few seconds. It would be interesting to have a py-numpy port which does not pull in gcc6= but rather uses the system's clang (which should be capable enough on 11.1). As a first try, running python2.7 setup.py build -j 4 install --prefix /tmp/z seems to compile o.k. (but not install due to complaints about PYTHONPATH). So, could the maintained of py-numpy create a version of the port which does not use gcc? -- Martin --=20 You are receiving this mail because: You are the assignee for the bug.=