From nobody Thu Feb 16 19:35:45 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PHlYH4dgmz3rQ71 for ; Thu, 16 Feb 2023 19:36:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PHlYF6GGtz3qQx for ; Thu, 16 Feb 2023 19:36:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=cBaJmcGm; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676576159; bh=4bF34YbLhuPC4JjnoP4zCxWAxpxE/nbflcKabf9itgo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=cBaJmcGmkPJyeE1p1Apl/Y2GvKgncYeGxLX9fouI7y+gaiezyijX00soNAT1st6KbEe5cvcW5Exdfx9ybBh68mS255ucbxw11AeBs1bmWj6dOuH6Iuop3p6k+yKjl5UGJCIE2TdxjCn2GsKgeN/5r+5gIWRvkwp6ERSryotxDvef8rSFjHbKwBl+ruwhuYIx54rwAlB2ECvhvUKfpfZ/QLqnYQ328JldWJZAljWGxIZNxoRNDuejSDdUHrDw9ySjcX8/x/yAHB8lnKj69/svjiN9MqtN3/ePPzSPnahCn3nf0F0nJxenf4i4HZC5xvUBzYbELxd5Tk3fQl/eqm6TZw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676576159; bh=UkY28YIEjRgoz32wJJVzdPmv1eOISDjCcRlOLs164BF=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=i/F/0I8JbTteeO1cb/tERGsqITNYsywUilOvo5RTSE2X4KOC4YUl/uFs/Qxm3gHYzZbIgFC662Gyx9Kp0v5qCP8L+9F5ajfFTbmwKDLVz1yo3tzvXHc6dlPTpF5jNKauAznEJGWNISeKTRLMACcSkM6YaMrXJmgC9hrQkqmGK0N1GEc3Ya7JHOOAUEJhr3ewRXwX/E9IlIYxCL8ChD1MaHOGAiCaYGM+dZ39QWFwxubengHJa7YCUh7YcosFe8+2LiX/yqFvo69v2KXreit0yd9ZQEUBeRuxR8JJ5JRWXR5Jx22PPeAjBY98FFdP3QXm8swT+REillC891LDwzFptw== X-YMail-OSG: s7gfGlgVM1muLdnv0lMtKJ73sqj9KWtf5FVydBvPpZgN7mOZFdAVxK5Gg2LV6jD RiXzEC4kVXLHjFZdicTAHmcYbNeL5O10sErSF4FaLZPgqCbYu_dSx7cRD__8OFV0b5C5rNRk6oFh kLVWJa50QF3IMJYnFs463ppyhVp297.Ty9BusIwAchxV.TQZI3W4QMV_LYicEWrglRcgcnTTOfLQ K3qYP38BaxcliEjIB7IkdQIxj339SRMfPQ9rtIPORH9obBus62qEaQKf4JvOo9Kx.i2x2fvWIRKY 70ERxaDYkPp0E7_pWRE_hnC3xrIDtggClgqF6krI9vQ6OscvjwCng.hdFKb9eJVXYlBR6fe9nas4 wjVK6C6GlNDIKJK3HXhH4wOctzEB2TcYfz3N9sXbZ8cntGVPNzZ58TKgRp1I5qV6vH8MaIVpKCCB cH7I99uuz553crWQegZwOOZ_rXjfFSLRyX73EJJHPLHKzsYWagS8SWD1mxvDpJiAYEzsMKT_1VV_ 7JOSqzCOzaFyNwJjEntRWq0qikS7CIoiucoSp.SlSskslgW7JTGuvPHRWnVwitpZFyZbyFLapmW9 _Oms8bdzAhijLQwZkv.tXBunwOHGIbGB8eCjEKKqNXO2cKhdGculAmHtixhWF.dEh.dnV3rb2ZWO A1WvDbXenwCfGBtTCNESoc.C54bddJRn.TC8oOcuAi_8zbTx_mUlQq_b96iO.7laLThdDsHZQsaW K3V7csEmplHNizItLmDr7RNxuQ.tDXBJzEaF6bjOALZbr1YHhujpGLwdLsj2GzGg9qZoS.O8O6OX kT2cM7j42o7nhns2xGKnyayNzEWkwzHuKwysMQ4UwX9_qgjM.QJQ5pYHBo0UxfajhxL4H.IOE7vt Gh1zdLQdGKBjkBlHxNAwPjDyhBQu6Odv5eMMRiVMONiZ96Mq6Y2YaYPvxQlQs8jALJXGvJt2YaDD SJk2hKHvmNTWHPmglSQX8V147RBDDMh1Y5w4wWKpTYqoK3oB3CXw_jzGyzbZ5rfYDOszSS_hNEzh UsBmsR8Dna683L8_e4D2B0ccJ6wRGvCl1snmdidn7TiLkcwu.WoUp5IXsWN_2iSWa50vl6itH7X8 .Ox2UoNTSnki5xrX5UMEvSzL87Dsa3.EMZPZpiYVKGrsY6wzRM2vxzN0kMvnZ3W72X0RwaWnmiid O8lEHrLFubB4FnzVfv0BRvaknD5RMQM1h5G_aLI1p4eRrKPCzHJTJT3Y4iMR0PAI_8mpKA0ktMOv yyVCvkZW_E2KNvdnlQigsP7C9dSqzClwiZ57xSjAw8rmRbL90Bd2bu4GEGLMOlaTR_CMk5W.WPkb vaBfMOH5hjeasYgmxYpBpvurXK1VIs2q3Hbu0ufzywkkLFjBHNRtFNZ1D.ry.LOWDbWnbOnB1sBM uZfRzw4ywfx6fEZO8pbn05iLCpB1_GDF6E6bMxSQ_NaOe0V.oIh4kY5rv9mUImvf2Xd9ArMflJXN POo94e7BhGTZ_9TwD7pnOi9fjN4_MK4ufOUycnoc64SSN.z1YfUx.BtE4751T_bkZ_M9PAwoykcg AFir1wmVc0w1kytonkjEeuTm4Ss5TYxBL.9w7Vf5HtXqd8kG3dlrf4b4gM3f.BHXfCdrqBrXRDZ2 QZ82zOMedJk2BBWO7baJhZKjP5.CuKi.1Ne_OdE7BVpnPzscM.eQa7nGeo2BaprSDD7i9uA9nxq6 dnzGk3wjw130MIXZ.UC.jrIluqtEtfq_CNFp6AFisy_NhDTJuKq9C7Uh73u5Gf1euq90roAJYGq1 6UskbBBRTHCqOlyaIOQmTolvlJ9TgkJRP3qQ2HpIaXZ1fhkc6CrF.vt2eV0uOltndVjloysy09JZ YA1J33_0eXCb5SvTyvN.oqGYeI1YH4ZcIfekAcoDpVANcA94ls5PUWSxgYV7W_RSppZ5nCELkTB6 DGenhM.CmJoXafxVXcfeGFnmxiOKRW03tkXgaczsWz3zkAweF4ZOquPCxdEz7ABUx5Y63u01IdCV jBOry0.wBN0wCxoSY5b_zjYU8K4HsWciT6tp.IoWaPvAOTFl_5zeXLxWYzLQtAovYN2yvpqn2nPw 9zqHtP9D6RaRqOhsojY1tHkGWQbUOLKukH04Boie6wjUQ7CjGoZi3NkZD05lZGYo0jVJ0_Ws5uJ_ .1Z9smwF4IGXiOMUHZLIbn4ZaWhtkBCLaerejD89M9oFLPGOIT.1hmnHZhqNQPmlyAYUOJjUNjdD p9IrrJl82fW0ImhItf0ykwaqWeDJ4Ca9LoZIqzury4VTqM4z9LL8JEyJhSbBx_PLMBswsIgMEKOl J X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Thu, 16 Feb 2023 19:35:59 +0000 Received: by hermes--production-ne1-746bc6c6c4-fgv82 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5f8f2c94dda217484ad54b40297c502c; Thu, 16 Feb 2023 19:35:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: Armv7 panic on -current, rpi2 buildworld From: Mark Millard In-Reply-To: Date: Thu, 16 Feb 2023 11:35:45 -0800 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20230215025741.GA32086@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Spamd-Result: default: False [-3.47 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.971]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4PHlYF6GGtz3qQx X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Feb 14, 2023, at 23:16, Mark Millard wrote: > On Feb 14, 2023, at 20:16, Warner Losh wrote: >=20 >> Sorry to top post... what program was dumping core? Looks like a too = strict assert >=20 > Just a possible point, given recent kernel floating > point work: >=20 > Because of Bob's note, I tried to do a typical build > and test of some benchmark programs that I sometimes > use that involve floating point in some of the > programs, some use with multithreading involved. (As > FreeBSD and g++ progress I tend to do this once and > a while, not as often on armv7 as on aarch64.) >=20 > On armv7, I now get a message about a failure of an > internal cross-check, which also leads to the program > being stopped early. The messaging from run to run > varies what the failure is, but the runs should not > vary and should not fail the cross-checks --and > previously did not, including when I last tried armv7. > (Not recently.) >=20 > For the specific example failure, the initial serial > (single thread) test with float involved works but the > following multi-thread test in the same program fails > and causes the program to stop when it notices there > is a problem. >=20 > The programs that do not test floating point do not > fail. These can involve floating point outside the > algorithm benchmarked, but with no multi-threading > involved for such and no floating point based cross- > checks involved. >=20 > At this point it is far from obvious to me how I > would trackdown the specifics of what leads to the > failed cross-checks. But the above is suggestive of > there being problems for armv7 handling of saving > and restoring floating point context for > multi-threading. I've no clue if such are limited > to the floating point values or not. >=20 >> Warner >>=20 >> On Tue, Feb 14, 2023, 7:57 PM bob prohaska = wrote: >> Building world on an RPi2 armv7, buildworld stopped with >> bob@www:/usr/src % panic: Called fill_fpregs while the kernel is = using the VFP >> cpuid =3D 0 >> time =3D 1676427410 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self >> pc =3D 0xc05e8160 lr =3D 0xc007aa04 = (db_trace_self_wrapper+0x30) >> sp =3D 0xde2c5790 fp =3D 0xde2c58a8 >> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >> pc =3D 0xc007aa04 lr =3D 0xc02e9c54 (vpanic+0x140) >> sp =3D 0xde2c58b0 fp =3D 0xde2c58d0 >> r4 =3D 0x00000100 r5 =3D 0x00000000 >> r6 =3D 0xc07372ef r7 =3D 0xc0b13968 >> vpanic() at vpanic+0x140 >> pc =3D 0xc02e9c54 lr =3D 0xc02e9a34 (dump_savectx) >> sp =3D 0xde2c58d8 fp =3D 0xde2c58dc >> r4 =3D 0xd70c8600 r5 =3D 0xde2c5e90 >> r6 =3D 0xc3398090 r7 =3D 0xe0cfc440 >> r8 =3D 0xc3398080 r9 =3D 0xd70c8600 >> r10 =3D 0xde2c5960 >> dump_savectx() at dump_savectx >> pc =3D 0xc02e9a34 lr =3D 0xc05f51dc (set_regs) >> sp =3D 0xde2c58e4 fp =3D 0xde2c58f8 >> set_regs() at set_regs >> pc =3D 0xc05f51dc lr =3D 0xc026f8f0 = (elf32_get_fpregset+0x2c) >> sp =3D 0xde2c5900 fp =3D 0xde2c5908 >> r4 =3D 0xc3398090 r5 =3D 0xc026f8c4 >> elf32_get_fpregset() at elf32_get_fpregset+0x2c >> pc =3D 0xc026f8f0 lr =3D 0xc026d848 (elf32_coredump+0x308) >> sp =3D 0xde2c5910 fp =3D 0xde2c5988 >> r4 =3D 0xc0902a7c r10 =3D 0xde2c5960 >> elf32_coredump() at elf32_coredump+0x308 >> pc =3D 0xc026d848 lr =3D 0xc02eea74 (sigexit+0xce0) >> sp =3D 0xde2c5990 fp =3D 0xde2c5cf8 >> r4 =3D 0x0000004e r5 =3D 0xdf580b60 >> r6 =3D 0xdf580a78 r7 =3D 0xc026d540 >> r8 =3D 0xdddcb2bc r9 =3D 0xdf580ad4 >> r10 =3D 0x00000000 >> sigexit() at sigexit+0xce0 >> pc =3D 0xc02eea74 lr =3D 0xc02ef36c (postsig+0x128) >> sp =3D 0xde2c5d00 fp =3D 0xde2c5d88 >> r4 =3D 0x00000006 r5 =3D 0xdd43fba0 >> r6 =3D 0xde2c5d20 r7 =3D 0xde2c5d18 >> r8 =3D 0xdddcb1f8 r9 =3D 0xdf3d9ab8 >> r10 =3D 0x00000005 >> postsig() at postsig+0x128 >> pc =3D 0xc02ef36c lr =3D 0xc02f316c (ast_sig+0x11c) >> sp =3D 0xde2c5d90 fp =3D 0xde2c5e08 >> r4 =3D 0xdd43fba0 r5 =3D 0xdddcb2bc >> r6 =3D 0xc0734d22 r7 =3D 0x00000000 >> r8 =3D 0xdddcb1f8 r9 =3D 0x00000ab8 >> r10 =3D 0x22530384 >> ast_sig() at ast_sig+0x11c >> pc =3D 0xc02f316c lr =3D 0xc035444c (ast_handler+0xe0) >> sp =3D 0xde2c5e10 fp =3D 0xde2c5e28 >> r4 =3D 0xde2c5e40 r5 =3D 0x0000000e >> r6 =3D 0x00004000 r7 =3D 0xc096b59c >> r8 =3D 0xdd43fba0 r9 =3D 0x00000001 >> ast_handler() at ast_handler+0xe0 >> pc =3D 0xc035444c lr =3D 0xc035435c (ast+0x20) >> sp =3D 0xde2c5e30 fp =3D 0xde2c5e38 >> r4 =3D 0xde2c5e40 r5 =3D 0xdd43fba0 >> r6 =3D 0x00000000 r7 =3D 0x000001b1 >> r8 =3D 0x22c4b500 r9 =3D 0x00000000 >> ast() at ast+0x20 >> pc =3D 0xc035435c lr =3D 0xc05eaa88 (swi_exit+0x3c) >> sp =3D 0xde2c5e40 fp =3D 0xbb9fbe38 >> r4 =3D 0x60000013 r5 =3D 0xdd43fba0 >> swi_exit() at swi_exit+0x3c >> pc =3D 0xc05eaa88 lr =3D 0xc05eaa88 (swi_exit+0x3c) >> sp =3D 0xde2c5e40 fp =3D 0xbb9fbe38 >> KDB: enter: panic >> [ thread pid 81621 tid 101111 ] >> Stopped at kdb_enter+0x54: ldrb r15, [r15, r15, ror r15]! >> db> bt >> Tracing pid 81621 tid 101111 td 0xdd43fba0 >> db_trace_self() at db_trace_self >> pc =3D 0xc05e8160 lr =3D 0xc00774a0 (db_stack_trace+0x140) >> sp =3D 0xde2c55d8 fp =3D 0xde2c55f0 >> db_stack_trace() at db_stack_trace+0x140 >> pc =3D 0xc00774a0 lr =3D 0xc00770f0 (db_command+0x310) >> sp =3D 0xde2c55f8 fp =3D 0xde2c56a0 >> r4 =3D 0xc0745722 r5 =3D 0x00000062 >> r6 =3D 0x00000000 r10 =3D 0x00000000 >> db_command() at db_command+0x310 >> pc =3D 0xc00770f0 lr =3D 0xc0076db8 (db_command_loop+0x64) >> sp =3D 0xde2c56a8 fp =3D 0xde2c56b8 >> r4 =3D 0xc07ac186 r5 =3D 0xc07ab7fe >> r6 =3D 0xc0986f5c r7 =3D 0xc0b13968 >> r8 =3D 0xc0b23738 r9 =3D 0x00000000 >> r10 =3D 0x00000001 >> db_command_loop() at db_command_loop+0x64 >> pc =3D 0xc0076db8 lr =3D 0xc007ab88 (db_trap+0x128) >> sp =3D 0xde2c56c0 fp =3D 0xde2c57d8 >> r4 =3D 0x00000000 r5 =3D 0xc0986f50 >> r6 =3D 0xc0b23758 r10 =3D 0x00000001 >> db_trap() at db_trap+0x128 >> pc =3D 0xc007ab88 lr =3D 0xc033bb84 (kdb_trap+0x258) >> sp =3D 0xde2c57e0 fp =3D 0xde2c5808 >> r4 =3D 0xc078390c r5 =3D 0xc08d5270 >> r6 =3D 0xc0b23758 r7 =3D 0xc0b13968 >> kdb_trap() at kdb_trap+0x258 >> pc =3D 0xc033bb84 lr =3D 0xc05eaab8 (exception_exit) >> sp =3D 0xde2c5810 fp =3D 0xde2c58a8 >> r4 =3D 0x200000d3 r5 =3D 0x00000000 >> r6 =3D 0xc07372ef r7 =3D 0xc0b13968 >> r8 =3D 0xc093fa0c r9 =3D 0xde2c58e4 >> r10 =3D 0xc0b13a68 >> exception_exit() at exception_exit >> pc =3D 0xc05eaab8 lr =3D 0xc033b044 (kdb_enter+0x50) >> sp =3D 0xde2c58a0 fp =3D 0xde2c58a8 >> r0 =3D 0x00000000 r1 =3D 0x00000001 >> r2 =3D 0x00000012 r3 =3D 0x00000000 >> r4 =3D 0xc0b23748 r5 =3D 0x00000000 >> r6 =3D 0xc07372ef r7 =3D 0xc0b13968 >> r8 =3D 0xc093fa0c r9 =3D 0xde2c58e4 >> r10 =3D 0xc0b13a68 r12 =3D 0x00000000 >> kdb_enter() at kdb_enter+0x58 >> pc =3D 0xc033b04c lr =3D 0xc02e9ca0 (vpanic+0x18c) >> sp =3D 0xde2c58b0 fp =3D 0xde2c58d0 >> r4 =3D 0x00000100 r10 =3D 0xc0b13a68 >> vpanic() at vpanic+0x18c >> pc =3D 0xc02e9ca0 lr =3D 0xc02e9a34 (dump_savectx) >> sp =3D 0xde2c58d8 fp =3D 0xde2c58dc >> r4 =3D 0xd70c8600 r5 =3D 0xde2c5e90 >> r6 =3D 0xc3398090 r7 =3D 0xe0cfc440 >> r8 =3D 0xc3398080 r9 =3D 0xd70c8600 >> r10 =3D 0xde2c5960 >> dump_savectx() at dump_savectx >> pc =3D 0xc02e9a34 lr =3D 0xc05f51dc (set_regs) >> sp =3D 0xde2c58e4 fp =3D 0xde2c58f8 >> set_regs() at set_regs >> pc =3D 0xc05f51dc lr =3D 0xc026f8f0 = (elf32_get_fpregset+0x2c) >> sp =3D 0xde2c5900 fp =3D 0xde2c5908 >> r4 =3D 0xc3398090 r5 =3D 0xc026f8c4 >> elf32_get_fpregset() at elf32_get_fpregset+0x2c >> pc =3D 0xc026f8f0 lr =3D 0xc026d848 (elf32_coredump+0x308) >> sp =3D 0xde2c5910 fp =3D 0xde2c5988 >> r4 =3D 0xc0902a7c r10 =3D 0xde2c5960 >> elf32_coredump() at elf32_coredump+0x308 >> pc =3D 0xc026d848 lr =3D 0xc02eea74 (sigexit+0xce0) >> sp =3D 0xde2c5990 fp =3D 0xde2c5cf8 >> r4 =3D 0x0000004e r5 =3D 0xdf580b60 >> r6 =3D 0xdf580a78 r7 =3D 0xc026d540 >> r8 =3D 0xdddcb2bc r9 =3D 0xdf580ad4 >> r10 =3D 0x00000000 >> sigexit() at sigexit+0xce0 >> pc =3D 0xc02eea74 lr =3D 0xc02ef36c (postsig+0x128) >> sp =3D 0xde2c5d00 fp =3D 0xde2c5d88 >> r4 =3D 0x00000006 r5 =3D 0xdd43fba0 >> r6 =3D 0xde2c5d20 r7 =3D 0xde2c5d18 >> r8 =3D 0xdddcb1f8 r9 =3D 0xdf3d9ab8 >> r10 =3D 0x00000005 >> postsig() at postsig+0x128 >> pc =3D 0xc02ef36c lr =3D 0xc02f316c (ast_sig+0x11c) >> sp =3D 0xde2c5d90 fp =3D 0xde2c5e08 >> r4 =3D 0xdd43fba0 r5 =3D 0xdddcb2bc >> r6 =3D 0xc0734d22 r7 =3D 0x00000000 >> r8 =3D 0xdddcb1f8 r9 =3D 0x00000ab8 >> r10 =3D 0x22530384 >> ast_sig() at ast_sig+0x11c >> pc =3D 0xc02f316c lr =3D 0xc035444c (ast_handler+0xe0) >> sp =3D 0xde2c5e10 fp =3D 0xde2c5e28 >> r4 =3D 0xde2c5e40 r5 =3D 0x0000000e >> r6 =3D 0x00004000 r7 =3D 0xc096b59c >> r8 =3D 0xdd43fba0 r9 =3D 0x00000001 >> ast_handler() at ast_handler+0xe0 >> pc =3D 0xc035444c lr =3D 0xc035435c (ast+0x20) >> sp =3D 0xde2c5e30 fp =3D 0xde2c5e38 >> r4 =3D 0xde2c5e40 r5 =3D 0xdd43fba0 >> r6 =3D 0x00000000 r7 =3D 0x000001b1 >> r8 =3D 0x22c4b500 r9 =3D 0x00000000 >> ast() at ast+0x20 >> pc =3D 0xc035435c lr =3D 0xc05eaa88 (swi_exit+0x3c) >> sp =3D 0xde2c5e40 fp =3D 0xbb9fbe38 >> r4 =3D 0x60000013 r5 =3D 0xdd43fba0 >> swi_exit() at swi_exit+0x3c >> pc =3D 0xc05eaa88 lr =3D 0xc05eaa88 (swi_exit+0x3c) >> sp =3D 0xde2c5e40 fp =3D 0xbb9fbe38 >> db>=20 >>=20 >> The machine was last updated about a week ago, the >> sources were updated earlier today. This panic is >> new to me. >=20 I now have a small C++ program that, when aborted by SIGABRT on armv7 (say via control-\), gets the above type of FreeBSD crash while trying to produce the *.core file (debug style armv7 kernel in use). I've sent the authors of the recent VFP-use-in-armv7-kernel changes the details, also: Warner L. . I previously sent them a small C program that gets a KASSERT based panic for a debug armv7 kernel when run under gdb or lldb with a breakpoint at a specific routine. In general, looks like armv7 floating point use is now problematical on main's [so: 14's] armv7 kernel until more work is done. =3D=3D=3D Mark Millard marklmi at yahoo.com