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>