From nobody Mon Feb 20 13:32:08 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 4PL3Hx42p8z3spJq for ; Mon, 20 Feb 2023 13:32:29 +0000 (UTC) (envelope-from bT.76ezg8od30=anxr0ibkqrgo=87og0k8ent@em790814.fubar.geek.nz) Received: from e2i580.smtp2go.com (e2i580.smtp2go.com [103.2.142.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PL3Hx3WjQz3p9g for ; Mon, 20 Feb 2023 13:32:29 +0000 (UTC) (envelope-from bT.76ezg8od30=anxr0ibkqrgo=87og0k8ent@em790814.fubar.geek.nz) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpservice.net; s=mgy720.a1-4.dyn; x=1676900849; h=Feedback-ID: X-Smtpcorp-Track:To:Date:Subject:Message-Id:From:Reply-To:Sender: List-Unsubscribe; bh=gXhCe45N/3A8l/ZV5mX4O1w0h9PYRczMZiXtpOiSYto=; b=E9ZEnD7a OKGKcAipSZ3QOyi8fl1vgT5kKMScWS3mSLpHrXB/kwhds499nGoZkeBZl9P2GuSGKE/yXDnacuY4x u1VlounVdMcE/97c5WjYvyun46sC+hmQozLObbj6+A/SroSioxAR2yyc+u7WiYoQXK9qwEYpWG5/l KaRCf59r4DOQjFkVKyVmIlagtKFxYqojYvBEQT8ETJjBkCK2yjQbK6y2oQVtrP7XZyy2zOe0m5EtT vKA3csnAdBwcCVaxamch53kKDMgSn+OQniMGYHe+hAB9eKRPGJMAbeysZMpoby2qRK4l9Ktx0D438 Ymq4C+RTVhVqSmk2Xo9NfjcbgA==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; i=@fubar.geek.nz; q=dns/txt; s=s790814; t=1676899949; h=from : subject : to : message-id : date; bh=gXhCe45N/3A8l/ZV5mX4O1w0h9PYRczMZiXtpOiSYto=; b=TwP6Z6uwMweaflkUsZa9/4J1PUmGzJi89zJKa7Sy+GVTngjuNFS7tqpgjSiZ0me6sWNw9 szYydT/o0opSnttUjPtTEdeZg9nbdQ9zuCJut1PEWnnQc/qp6ZERzUhTRMcip31kMOQkBVJ xRM7eym0itIBu2LjKkuVLd2/Xmf8FxAPpOC3boBJpN+tHFyvFhp6cyqq98NFwnG1+6m1LWO TUG/ounTrXGU9hzOcGfYrWHV3C7IJtFM5gSyw6u0QqpVzp7M6rZg17FUSr53q0luLaPsz8K W/DxpHXBdA5p36FsTvUHGIHiehswgmG99rkYJBqCCyyJHqVfCm3A6Xch1RtA== Received: from [10.176.58.103] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2-S2G) (envelope-from ) id 1pU6HK-qt4IeL-Ej; Mon, 20 Feb 2023 13:32:26 +0000 Received: from [10.162.55.164] (helo=morbo.fubar.geek.nz) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96-S2G) (envelope-from ) id 1pU6HK-9EIKpW-0i; Mon, 20 Feb 2023 13:32:26 +0000 Received: from smtpclient.apple (cpc91210-cmbg18-2-0-cust37.5-4.cable.virginm.net [81.102.44.38]) by morbo.fubar.geek.nz (Postfix) with ESMTPSA id BAEE91D59E; Mon, 20 Feb 2023 13:32:21 +0000 (UTC) From: Andrew Turner Message-Id: <1572483E-D0CD-4384-BF73-A00FB3640F91@fubar.geek.nz> Content-Type: multipart/alternative; boundary="Apple-Mail=_3F5E9888-8ACF-4672-84A7-D484E2587056" 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.400.51.1.1\)) Subject: Re: Armv7 panic on -current, rpi2 buildworld Date: Mon, 20 Feb 2023 13:32:08 +0000 In-Reply-To: <85ed9a05-e4ea-2811-1701-b8f2e982e3b1@FreeBSD.org> Cc: Mark Millard , bob prohaska , "freebsd-arm@freebsd.org" To: =?utf-8?Q?Kornel_Dul=C4=99ba?= References: <20230215025741.GA32086@www.zefox.net> <85ed9a05-e4ea-2811-1701-b8f2e982e3b1@FreeBSD.org> X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Smtpcorp-Track: 1pl6HK9EmKpW0i.86ZrB2d0iktzu Feedback-ID: 790814m:790814amQcrys:790814seVw_yQjFp X-Report-Abuse: Please forward a copy of this message, including all headers, to X-Rspamd-Queue-Id: 4PL3Hx3WjQz3p9g X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:23352, ipnet:103.2.140.0/22, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_3F5E9888-8ACF-4672-84A7-D484E2587056 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 20 Feb 2023, at 13:15, Kornel Dul=C4=99ba wrote: >=20 >> Can you try with 24abb6b82102eec577eff9bd8dd7726e8cab89f4? There were = conditional branch instructions that may mean the function to save the = VFP state was not being run. > I'm currently debugging this and applying = 24abb6b82102eec577eff9bd8dd7726e8cab89f4 didn't quite help. > (I've tested it with dbl_and_ull_via_async that Mark shared in another = thread.) > The root cause is located in vfp_save_state. It's called during the = dump, right before the assert is triggered: >=20 > 359 /* > 360 * savectx() will be called on panic with dumppcb as an = argument, > 361 * dumppcb doesn't have pcb_vfpsaved set, so set it to = save > 362 * the VFP registers. > 363 */ > 364 if (pcb->pcb_vfpsaved =3D=3D NULL) > 365 pcb->pcb_vfpsaved =3D &pcb->pcb_vfpstate; >=20 > Here pcb_vfpsaved =3D=3D NULL, since the VFP has never been used in = the kernel. > This triggers the KASSERT in get_vfpcontext, causing the panic. > Note that arm64 has very similar logic, so I wonder if a similar panic = could be observed there. > Any thoughts? >=20 It looks like cpu_copy_thread is missing setting pcb_vfpsaved so is = likely to be invalid. On arm64 we set the needed data in vfp_new_thread. This was added to = simplify adding SVE support, but could be reused on arm if it=E2=80=99s = useful. Andrew --Apple-Mail=_3F5E9888-8ACF-4672-84A7-D484E2587056 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 20 = Feb 2023, at 13:15, Kornel Dul=C4=99ba <kd@FreeBSD.org> = wrote:

=20 =20
Can you try with 24abb6b82102eec577eff9bd8dd7726e8cab89f4? = There were conditional branch instructions that may mean the function to save the VFP state was not being run.

I'm currently = debugging this and applying 24abb6b82102eec577eff9bd8dd7726e8cab89f4 didn't quite help.
(I've tested it with dbl_and_ull_via_async that Mark shared in another thread.)
The root cause is located in vfp_save_state. It's called during the dump, right before the assert is triggered:

359         /*
360          * = savectx() will be called on panic with dumppcb as an argument,
361          * = dumppcb doesn't have pcb_vfpsaved set, so set it to save
362          * the = VFP registers.
363          */
364         if = (pcb->pcb_vfpsaved =3D=3D NULL)
= 365            = ;     pcb->pcb_vfpsaved =3D &pcb->pcb_vfpstate;

Here pcb_vfpsaved =3D=3D NULL, since the VFP has never been used = in the kernel.
This triggers the KASSERT in get_vfpcontext, causing the = panic.
Note that arm64 has very similar logic, so I wonder if a similar panic could be observed there.
Any thoughts?


It looks = like cpu_copy_thread is missing setting pcb_vfpsaved so is = likely to be invalid.

On arm64 we set the = needed data in vfp_new_thread. This was added to simplify adding = SVE support, but could be reused on arm if it=E2=80=99s = useful.

Andrew

= --Apple-Mail=_3F5E9888-8ACF-4672-84A7-D484E2587056--