Date: Mon, 20 Feb 2023 13:32:08 +0000 From: Andrew Turner <andrew@fubar.geek.nz> To: =?utf-8?Q?Kornel_Dul=C4=99ba?= <kd@FreeBSD.org> Cc: Mark Millard <marklmi@yahoo.com>, bob prohaska <fbsd@www.zefox.net>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Armv7 panic on -current, rpi2 buildworld Message-ID: <1572483E-D0CD-4384-BF73-A00FB3640F91@fubar.geek.nz> In-Reply-To: <85ed9a05-e4ea-2811-1701-b8f2e982e3b1@FreeBSD.org> References: <20230215025741.GA32086@www.zefox.net> <CANCZdfou0s5Xz4_0pPdNSQnFH9qk9NAY=GyB7pBwnVNPvGS4Qw@mail.gmail.com> <A81B272C-8AE0-4DB8-A399-6862A13E4394@yahoo.com> <A137339C-683A-42B6-95CA-0EE5B4156562@yahoo.com> <CCE79CB7-BA79-4682-AC7C-4D5E8EC0A21A@fubar.geek.nz> <85ed9a05-e4ea-2811-1701-b8f2e982e3b1@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <kd@FreeBSD.org> 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
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: =
after-white-space;"><br><div><br><blockquote type=3D"cite"><div>On 20 =
Feb 2023, at 13:15, Kornel Dul=C4=99ba <kd@FreeBSD.org> =
wrote:</div><br class=3D"Apple-interchange-newline"><div>
=20
<meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3DUTF-8">
=20
<div>
<blockquote type=3D"cite" =
cite=3D"mid:CCE79CB7-BA79-4682-AC7C-4D5E8EC0A21A@fubar.geek.nz">
<meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3DUTF-8">
Can you try with 24abb6b82102eec577eff9bd8dd7726e8cab89f4? =
There
were conditional branch instructions that may mean the function to
save the VFP state was not being run.</blockquote><p>I'm currently =
debugging this and applying
24abb6b82102eec577eff9bd8dd7726e8cab89f4 didn't quite help.<br>
(I've tested it with dbl_and_ull_via_async that Mark shared in
another thread.)<br>
The root cause is located in vfp_save_state. It's called during
the dump, right before the assert is triggered:<br>
<br>
359 /*<br>
360 * =
savectx() will be called on panic with dumppcb as
an argument,<br>
361 * =
dumppcb doesn't have pcb_vfpsaved set, so set it to
save<br>
362 * the =
VFP registers.<br>
363 */<br>
364 if =
(pcb->pcb_vfpsaved =3D=3D NULL)<br>
=
365  =
; pcb->pcb_vfpsaved =3D
&pcb->pcb_vfpstate;<br>
<br>
Here pcb_vfpsaved =3D=3D NULL, since the VFP has never been used =
in
the kernel.<br>
This triggers the KASSERT in get_vfpcontext, causing the =
panic.<br>
Note that arm64 has very similar logic, so I wonder if a similar
panic could be observed there.<br>
Any thoughts?<br>
</p>
</div></div></blockquote><br></div><div>It looks =
like cpu_copy_thread is missing setting pcb_vfpsaved so is =
likely to be invalid.</div><div><br></div><div>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.</div><div><br></div><div>Andrew</div><br></body></html>=
--Apple-Mail=_3F5E9888-8ACF-4672-84A7-D484E2587056--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1572483E-D0CD-4384-BF73-A00FB3640F91>