From owner-freebsd-current@freebsd.org Wed Mar 10 06:00:17 2021 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CF0C057E458 for ; Wed, 10 Mar 2021 06:00:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-22.consmr.mail.ne1.yahoo.com (sonic315-22.consmr.mail.ne1.yahoo.com [66.163.190.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DwLym6Zpcz4Yvl for ; Wed, 10 Mar 2021 06:00:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1615356015; bh=ZZrUBs3zRbN0QxEymX+Av1ZuYY/oPGvWJKZwT6RVrcT=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=OP6wB2lbOn618Nnu8W+ULkbx2hiIEgGR5QKso+/uZKQgb7gYFY1jF0a3MnZBWlcUSSRikuSABzePGdYdUsJjfUBwj9BSbDS5m6LPPD2BNH+5P6cjF/rfpsmlxUV6Z4g0FMLLEdf6wHR/b4yZP9VhRAdt+V2OACN3BUtleV3Z1hrVq8kDPh3nJWCF1957WOSRL+cbifR0/o/btV2dlyh2Bl6hSVkQd2D57zMjhCrk5hZzVTWoON9p3ZoyKLhdAGKMD3O0PHMC78tX8eXifczTutBnjbtYrfXv60UmxgFabLWB/4+rr0fiAABZiBBbN2S+8VK8Pq4HNstanOfNDx4C5A== X-YMail-OSG: _kcXBMoVM1n8xVMGWTiydHaKYoAxWNRJYyDVJp8IYoFsWgRf_VK2HhEJOZM4SaL 2q4Imc1NkWJ5y2030AX797yR0rYlq44kf0p.bB_DMHvs1bJ.qgG_llSsrBnNdxqWd.72UW18IJ7y .e5G3i1CfD1Qiyc8uW7dgnHsRICq7VQsB22_6LWDIfnCXj_T5b4lhxnVMuq6ULbCsti6kJFwAbE. Q6PyNpINC.kQP_ZCY.nymKp2EUtUVs4IyWh9zEKZfu1tOKBohtOjVjs.8DtiKpkAgthpQBlw.yoK bjAaWLB4WGIRPWOSIZuNVXKf_wJMFHUF2XH1gRW.4QIsYlSMUDB7NYPc6Ko0jp0IAtBn4bI9L0i5 U7_ELrO1pw4LxvR_4KTRqh.ScfMirAokHLDWLofFNuM0ACfT.Ob86lQnGUEox_T_GWVednDrc8Zq NGnZ__ZasMxZ6h6_g8XeUBIHvmpZ7TZXgO.R_46ffbty8k0MeuFR7anHqqsRBb1zEEIUktx_fSjK NQRRp1OGS2muG13zIU7rq81Y96MCeGBdgixH1Fm6IPcFXZLxEsdStu_BmFERr0cYGq1Vvg_cXyLY VQJnmx46.O1kukTADa9SrpJE4gG7rVrifjA4gEg2N2PDtVpTB5MyAqeMDIaxu38CfcqWxJ1o.TFP BOoI9HZZj1gWoAc0HyovGqLafYDwCRmuhbYtfXTu6zeLc70EeBMMWcxf27jg2Od57qkWNQlas5o0 a8CP9pFln3xsWHyWlIjSQcEddPzDf.Ay9NdScRtDuMrFGct1H0hrSJceYB4LfQdlIoIZpsxv2Yyd NWzcRiifsIEQEwjkxVeTaEKMMXpzYVVhCLxzRoVYZy9cgFpvId8vnYmztoN1rRAheDtcNKw80uiY X3Ais03tt5a5nUhnArlDjy.NOjJ2gIbt_05aKlsEEuVzlbjHhCdj00w1Nyv0Rtlv_xmgMoBn.fnh rGkBpnOayKMVO4m.NwFDT_xcQ1_bnX3Wis2KCHW.GIEjkqq2IDSg.zsnPGgbr6.wIOIAoVRc4RZP gLzua2_qMZ.beNS0LsjL9O7YnsOnTOs2N7brsQPGjCrDGPO4vrcvvZ3jVMIvmdkWTYhDVEhgyLNx 1EFd0zkAnCJijJa3iBE_ozhhV72KeJvmgrn7Kx1a7Mrl7tsIvv_JY6YopALisQL9USDC0f2b.dwh jLtQv7.4_ks5.mFGh0ZZR8M_FDJnPKsq5WUDNoHmPdWKEhwKnBXUo5U_upzgiAuyn3D0vRpLbM81 oAV6xUs_tonGekCTA_8mL_JPT9XstkM7e4rOO9uMcKeFXrrus1oJAbkY7gvn7yWm.yPjmgOcr2ly Sf3oxk.Vt_0UgCavFMmEzTvB2dDtTaPc2vxY22096fjYdC7v0MRFCYSKkt7RCHJGeuDCouMhTOaT Agc6ZF5Cg1FkK5J_a9zTyUc08vplDw5FQVaxfURtmjAOWuj9E8.cFGuwrneIeVxNcvoXQ.8QdeKw MOYLBcJgbyVbdBVCcb7gBvAmnGlkrEO5JcKbT45FDeZKdDjKLPFSByAHo1jI5I2J6gL.IU9Ars9P tOo_IR069CQkH_e_DbVdIxSfO72AQFYfkapKB4A9Mw2hcpu7cdKyXA73VYngRL2McEi9xHk8.rQY TDVvROVLU0.GrR5XLu7Ke33LxIhI8bmnZn6IiSnNt5wKCcv2nFLN_U7KtVYDDn14s8pGta5SWVkR 06J6eV4lLusYpoYFgWnsU5yJWlOCr2j7gv8_N4hmqNIOxfSq2xvD8koB075C7aCNaObnN_i20UMl .gzLjgG6ZCU0L5ipmrDQHHc8ZWFieLd6jkYLvRwEJr.SXy7aoBr6IvE5XXRNy1wmSJE1vcHkRMv2 tm_9ljtSX_l_tx3HkOrAWb10yzBDwK7dfEQSj.SlLkiugpJrZMnr2zwN_ShnCYJfbTX3tuBuEIWw Cn6ZOr._BdyZVX3KrRejCZlltxnRWOWPC6xHAonC.5KJiIUslxqiqzNEhcSRRWgX6SmBKACwzjYW RuvkrnToI_1NvQGGZIZGrX9G17l3e.HTFS5daZjasdWIWEyI08FScQYyknFF4TF22ZtMkNXTk.o. Tfom_pAgb_5rimHWiUO4ifGr21Qz6OGkvyPLPTZTnerjcNBWePrBvQHtzEfjtz.B9LBnWY8fjXH3 IZUKQnTEEPmdJljjKetUqJ8t1mjRYOOQmG1b8gx1yilY3vhdMkUsr341j1nuX4nctp3j.aSX2.Bz l0H7qixCwrZw5KcnqEt1KiyS.hMTv8mwTfoC3bbbvuwElDucBexvtyGLDKxbJ_ClKA1FwNs6f7hF R.4qE5rKPypiO8100Bdplamrwm5epaCEHJeFmd6EiVDYjcV_hVMkxV3DNcvARx_Uii5fJtcuQnpP t0aG9dX63nAeS59u.0Qqh8h.6J.5OyEi8wI8C8fIALYleyYwAau3RDP88RUCZJLmsKSqfJ4YklVX jDx6eYukx5fbqYReNBP6N_.9BxM4XrynjGcvnvcoi_Vk6z9851LY6Ker3JQ_LZULzoo5X7XNtFUH FKd_ksBOftWsekkZCxbpcWdtjgQmDJjuhF08_VqmeycHb9tFQF5l.LaEoAHjM7zHC4Vka4W43qjk HsERBI1TLaqR19pJwP6kWNzseIRUJWGCo4EgJWIoftpoKeXK5.CUi3ikb7BGXirdvAg.K7lTOW2D xsp.4yELoWDqWWK5vnq_jTck88j.HHH5yAV5O1d3FLKAWXU3OqhY5 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Wed, 10 Mar 2021 06:00:15 +0000 Received: by kubenode572.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8f91ed7f4fb802b489deff373b9bf435; Wed, 10 Mar 2021 06:00:08 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: FYI: main (bad9fa56620e based): some unexpected SIGSEGV's are tied to interrupted system calls (cortex-a57/a72 fail, cortex-a53/cortex-a7 work) From: Mark Millard In-Reply-To: Date: Tue, 9 Mar 2021 22:00:07 -0800 Cc: Konstantin Belousov Content-Transfer-Encoding: quoted-printable Message-Id: <1C468B92-E53F-4CBC-A6C0-05FEB887F45B@yahoo.com> References: To: freebsd-arm , freebsd-current X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4DwLym6Zpcz4Yvl X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.163.190.148:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[66.163.190.148:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[66.163.190.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.190.148:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 06:00:17 -0000 On 2021-Mar-9, at 21:11, Mark Millard wrote: > On 2021-Mar-9, at 19:17, Mark Millard wrote: >=20 > [My only testing context for this has been main, not 13.0. > But it might be a 13.0 worry.] >=20 >> Using the quickest to so-far-reliably-fail type of example from >> another thread I used truss to see what happens, here filtered >> down to two processes that appear to be involved and only >> near the failure. (The overall truss output is huge from the >> prior activity in the poudriere bulk relatated activity). Also, >> this initiated watching from aarch64 but the failing code is >> armv7. >>=20 >> 83630 100199: #340(0x1,0xffffd18c,0xffffd17c) =3D 0 (0x0) >> 83630 100199: #416(0x14,0xffffd1b4,0xffffd19c) =3D 0 (0x0) >> 83630 100199: #7(0xffffffff,0xffffd178,0x1,0x0) =3D 0 (0x0) >> 83731 100161: #240(0xffffd5f0,0xffffd5f0) =3D 0 (0x0) >> 83731 100161: #1(0x0) =20 >> 83731 100161: process exit, rval =3D 0 >> 83630 100199: SIGNAL 20 (SIGCHLD) code=3DCLD_EXITED pid=3D83731 uid=3D0= status=3D0 >> 83630 100199: #341(0xffffd17c) ERR#4 'Interrupted = system call' >> 83630 100199: SIGNAL 11 (SIGSEGV) code=3DSEGV_MAPERR trapno=3D36 = addr=3D0xffffffe1 >> 83630 100199: process killed, signal =3D 11 (core dumped) >>=20 >> As a reminder of the lldb backtrace of the sh.core >> and the like: >>=20 >> (lldb) bt >> * thread #1, name =3D 'sh', stop reason =3D signal SIGSEGV >> * frame #0: 0xffffe190 >> frame #1: 0x00031aa8 sh`waitcmdloop(job=3D0x00064230) at = jobs.c:608:11 >> frame #2: 0x00031a24 sh`waitcmd(argc=3D, = argv=3D) at jobs.c:554:13 >> frame #3: 0x00028f54 sh`evalcommand(cmd=3D0x400ad0e4, = flags=3D, backcmd=3D0x00000000) at eval.c:1107:16 >> frame #4: 0x00027800 sh`evaltree(n=3D0x400ad0e4, = flags=3D) at eval.c:289:4 >> frame #5: 0x000344d0 sh`cmdloop(top=3D1) at main.c:221:4 >> frame #6: 0x000342f4 sh`main(argc=3D, = argv=3D) at main.c:168:3 >> frame #7: 0x0002480c sh`__start(argc=3D8, argv=3D, = env=3D, ps_strings=3D, obj=3D0x400b4004, = cleanup=3D0x40081aa0) at crt1_c.c:92:7 >> (lldb) up >> frame #1: 0x00031aa8 sh`waitcmdloop(job=3D0x00064230) at = jobs.c:608:11 >> 605 break; >> 606 } >> 607 } >> -> 608 } while (dowait(DOWAIT_BLOCK | DOWAIT_SIG, = (struct job *)NULL) !=3D -1); >> 609 =09 >> 610 sig =3D pendingsig_waitcmd; >> 611 pendingsig_waitcmd =3D 0; >>=20 >> (lldb) disass >> sh`waitcmdloop: >> 0x31a54 <+0>: push {r4, r5, r6, r7, r8, r9, r10, r11, lr} >> 0x31a58 <+4>: add r11, sp, #28 >> 0x31a5c <+8>: sub sp, sp, #4 >> 0x31a60 <+12>: movw r6, #0x3ea0 >> 0x31a64 <+16>: movw r7, #0x3e9c >> 0x31a68 <+20>: movw r9, #0x4040 >> 0x31a6c <+24>: movw r8, #0x3ea4 >> 0x31a70 <+28>: mov r4, r0 >> 0x31a74 <+32>: movt r6, #0x6 >> 0x31a78 <+36>: movt r7, #0x6 >> 0x31a7c <+40>: movt r9, #0x6 >> 0x31a80 <+44>: mov r10, #0 >> 0x31a84 <+48>: movt r8, #0x6 >> 0x31a88 <+52>: cmp r4, #0 >> 0x31a8c <+56>: beq 0x31ab4 ; <+96> at = jobs.c:590:37 >> 0x31a90 <+60>: ldrb r0, [r4, #0x18] >> 0x31a94 <+64>: cmp r0, #2 >> 0x31a98 <+68>: beq 0x31b84 ; <+304> [inlined] = getjobstatus at jobs.c:575 >> 0x31a9c <+72>: mov r0, #3 >> 0x31aa0 <+76>: mov r1, #0 >> 0x31aa4 <+80>: bl 0x32bcc ; dowait at = jobs.c:1142 >> -> 0x31aa8 <+84>: cmn r0, #1 >>=20 >>=20 >> For reference a local context around the >> SIGSEGV looks like (all lines in the range >> selected): >>=20 >> . . . >> 83833 102738: fcntl(2,F_DUPFD_CLOEXEC,0xa) =3D 10 (0xa) >> 83833 102738: = openat(AT_FDCWD,"/dev/null",O_WRONLY|O_CREAT|O_TRUNC,0666) =3D 3 (0x3) >> 83833 102738: dup2(3,2) =3D 2 (0x2) >> 83833 102738: close(3) =3D 0 (0x0) >> 83833 102738: unlink("./.data.json.SYR1bCaL") =3D 0 (0x0) >> 83833 102738: dup2(10,2) =3D 2 (0x2) >> 83833 102738: close(10) =3D 0 (0x0) >> 83833 102738: exit(0x0) =20 >> 83833 102738: process exit, rval =3D 0 >> 77872 100638: wait4(-1,{ EXITED,val=3D0 },0x0,0x0) =3D 83833 = (0x14779) >> 77872 100638: fcntl(0,F_DUPFD_CLOEXEC,0xa) =3D 10 (0xa) >> 77872 100638: = openat(AT_FDCWD,"/var/run/poudriere/lock-poudriere-shared-json_top.pid",O_= RDONLY,00) =3D 3 (0x3) >> 77872 100638: dup2(3,0) =3D 0 (0x0) >> 77872 100638: close(3) =3D 0 (0x0) >> 77872 100638: fcntl(2,F_DUPFD_CLOEXEC,0xa) =3D 11 (0xb) >> 77872 100638: = openat(AT_FDCWD,"/dev/null",O_WRONLY|O_CREAT|O_TRUNC,0666) =3D 3 (0x3) >> 77872 100638: dup2(3,2) =3D 2 (0x2) >> 77872 100638: close(3) =3D 0 (0x0) >> 77872 100638: lseek(0,0x0,SEEK_CUR) =3D 0 (0x0) >> 77872 100638: read(0,"77563",1024) =3D 5 (0x5) >> 77872 100638: read(0,0xffffffffb9e8,1024) =3D 0 (0x0) >> 77872 100638: dup2(10,0) =3D 0 (0x0) >> 77872 100638: close(10) =3D 0 (0x0) >> 77872 100638: dup2(11,2) =3D 2 (0x2) >> 77872 100638: close(11) =3D 0 (0x0) >> 77872 100638: fcntl(2,F_DUPFD_CLOEXEC,0xa) =3D 10 (0xa) >> 77872 100638: = openat(AT_FDCWD,"/dev/null",O_WRONLY|O_CREAT|O_TRUNC,0666) =3D 3 (0x3) >> 77872 100638: dup2(3,2) =3D 2 (0x2) >> 77872 100638: close(3) =3D 0 (0x0) >> 77872 100638: = rmdir("/var/run/poudriere/lock-poudriere-shared-json_top") =3D 0 (0x0) >> 77872 100638: dup2(10,2) =3D 2 (0x2) >> 77872 100638: close(10) =3D 0 (0x0) >> 77872 100638: sigprocmask(SIG_SETMASK,{ },0x0) =3D 0 (0x0) >> 77872 100638: fcntl(2,F_DUPFD_CLOEXEC,0xa) =3D 10 (0xa) >> 77872 100638: = openat(AT_FDCWD,"/dev/null",O_WRONLY|O_CREAT|O_TRUNC,0666) =3D 3 (0x3) >> 77872 100638: dup2(3,2) =3D 2 (0x2) >> 77872 100638: close(3) =3D 0 (0x0) >> 77872 100638: sigaction(SIGINFO,{ 0x239c30 SA_RESTART ss_t },{ = SIG_DFL 0x0 ss_t }) =3D 0 (0x0) >> 83731 100161: #240(0xffffd5f0,0xffffd5f0) =3D 0 (0x0) >> -- UNKNOWN FreeBSD32 SYSCALL 1 -- >> 83731 100161: #1(0x0) =20 >> 83731 100161: process exit, rval =3D 0 >> 83630 100199: SIGNAL 20 (SIGCHLD) code=3DCLD_EXITED pid=3D83731 uid=3D0= status=3D0 >> 83630 100199: #341(0xffffd17c) ERR#4 'Interrupted = system call' >> 83630 100199: SIGNAL 11 (SIGSEGV) code=3DSEGV_MAPERR trapno=3D36 = addr=3D0xffffffe1 >> 83630 100199: process killed, signal =3D 11 (core dumped) >> 83316 100123: #7(0xffffffff,0xffffca58,0x0,0x0) =3D 83630 (0x146ae) >> -- UNKNOWN FreeBSD32 SYSCALL 477 -- >> 83316 100123: = #477(0x0,0x7000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077833728 (0x403e7000) >> -- UNKNOWN FreeBSD32 SYSCALL 552 -- >> 83316 100123: #552(0xffffff9c,0xffffc504,0xffffc908,0x0) ERR#2 'No = such file or directory' >> -- UNKNOWN FreeBSD32 SYSCALL 552 -- >> 83316 100123: #552(0xffffff9c,0xffffc504,0xffffc908,0x0) ERR#2 'No = such file or directory' >> -- UNKNOWN FreeBSD32 SYSCALL 552 -- >> 83316 100123: #552(0xffffff9c,0xffffc504,0xffffc908,0x0) ERR#2 'No = such file or directory' >> -- UNKNOWN FreeBSD32 SYSCALL 552 -- >> 83316 100123: #552(0xffffff9c,0xffffc504,0xffffc908,0x0) ERR#2 'No = such file or directory' >> -- UNKNOWN FreeBSD32 SYSCALL 477 -- >> 83316 100123: = #477(0x0,0x1000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077862400 (0x403ee000) >> -- UNKNOWN FreeBSD32 SYSCALL 4 -- >> 83316 100123: #4(0x2,0x403ee000,0x21) =3D 33 (0x21) >> -- UNKNOWN FreeBSD32 SYSCALL 477 -- >> 83316 100123: = #477(0x0,0x1000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077866496 (0x403ef000) >> -- UNKNOWN FreeBSD32 SYSCALL 477 -- >> 83316 100123: = #477(0x0,0x1000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077870592 (0x403f0000) >> -- UNKNOWN FreeBSD32 SYSCALL 477 -- >> 83316 100123: = #477(0x0,0x1000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077874688 (0x403f1000) >> -- UNKNOWN FreeBSD32 SYSCALL 4 -- >> 83316 100123: #4(0x1,0x403ef000,0x2e) =3D 46 (0x2e) >> -- UNKNOWN FreeBSD32 SYSCALL 542 -- >> 83316 100123: #542(0xffffcd54,0x0) =3D 0 (0x0) >> -- UNKNOWN FreeBSD32 SYSCALL 2 -- >> 83842 100199: >> 83316 100123: #2() =3D 83842 (0x14782) >> -- UNKNOWN FreeBSD32 SYSCALL 6 -- >> -- UNKNOWN FreeBSD32 SYSCALL 6 -- >> 83316 100123: #6(0x7) =3D 0 (0x0) >> 83842 100199: #6(0x5) =3D 0 (0x0) >> . . . >=20 > Turns out that the failure happens on the > processors with out-of-order execution and > the like but works on the strictly in-order > cortex-a53. (For as much testing as I've > done.) >=20 > So it looks like some form of synchronization > is missing that in-order-only does not need. > (This would be the 2nd time I've run into such > for FreeBSD aarch64 if it holds true. The > prior example was fixed a fair time ago.) >=20 >=20 > The testing status . . . >=20 >=20 > Problem replicated using the following contexts > to attempt the textproc/itstool build, targeting > armv7 (cortex-a7): >=20 > cortex-a72 aarch64 MACHHIATObin Double Shot > cortex-a57 aarch64 OverDrive 1000 >=20 > (No successful builds for the above 2, > all stopping in configure the same way.) >=20 >=20 > No problem using the following to build > textproc/itstool, targeting armv7: >=20 > cortex-a53 aarch64 Rock64 (armv7 on aarch64 case) > cortext-a7 armv7 OrangePi+ 2ed (native armv7 case) >=20 >=20 > It will take a long time to run a full > poudriere bulk that will build about > 200 ports, targeting the cortex-a7 on > the slower cortex-a53: days. So > further evidence that the cortex-a53 > does not get the problem will take a > while. I have confirmed that I still get the problem on the cortex-a72 when I substitute the kernel.txz and kernel-dbg.txz content from: = https://artifact.ci.freebsd.org/snapshot/main/bad9fa56620eb82395c5ab66d300= e91a0222dde2/arm64/aarch64/ and boot with it. ( My non-debug build is also of bad9fa56 .) This avoids worries about my kernel build being involved. The debug kernel did not report anything special while the port was building. Earlier it did report the classic: [00:00:06] Mounting system devices for FBSDFSSDjailArmV7-default lock order reversal: 1st 0xffffa0017b9915b0 ufs (ufs, lockmgr) @ = /usr/src/sys/kern/vfs_mount.c:1071 2nd 0xffffa0017bdb8070 devfs (devfs, lockmgr) @ = /usr/src/sys/kern/vfs_mount.c:1083 lock order devfs -> ufs established at: . . . I have not tried substituting base.txz and base-dbg.txz content. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)