Date: Mon, 20 Feb 2023 15:21:15 -0800 From: Mark Millard <marklmi@yahoo.com> To: Andrew Turner <andrew@fubar.geek.nz> Cc: =?utf-8?Q?Kornel_Dul=C4=99ba?= <kd@FreeBSD.org>, bob prohaska <fbsd@www.zefox.net>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Armv7 panic on -current, rpi2 buildworld Message-ID: <61F904C8-5F01-4E55-B93F-84A569539F43@yahoo.com> In-Reply-To: <71350653-9B4B-4570-A2E4-06CF25A66923@yahoo.com> 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> <71350653-9B4B-4570-A2E4-06CF25A66923@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 20, 2023, at 09:08, Mark Millard <marklmi@yahoo.com> wrote:
> On Feb 20, 2023, at 04:32, Andrew Turner <andrew@fubar.geek.nz> 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.
>>=20
>> Andrew
>=20
> I had eventually produced 3 programs showing different failed
> results, 2 KASSERT panics and one example of floating point
> data from the wrong thread eventually showing up (but no
> KASSERT for the test sequence).
>=20
> I've tested the later one via an armv7 kernel that
> has:
>=20
> c0681a2c <savectx>:
> c0681a2c: e92d4000 stmdb sp!, {lr}
> c0681a30: e24dd004 sub sp, sp, #4
> c0681a34: e2803000 add r3, r0, #0
> c0681a38: e883fff0 stm r3, {r4, r5, r6, r7, r8, r9, r10, r11, =
r12, sp, lr, pc}
> c0681a3c: e1a01000 mov r1, r0
> c0681a40: e3a00000 mov r0, #0
> c0681a44: eb000b10 bl 0xc068468c <vfp_save_state> @ imm =3D =
#11328
> c0681a48: e28dd004 add sp, sp, #4
> c0681a4c: e8bd8000 ldm sp!, {pc}
>=20
> and it still fails:
>=20
> # g++12 -std=3Dc++20 -pedantic -g -O3 -pthread =
-Wl,-rpath=3D/usr/local/lib/gcc12 dbl_and_ull_multithread.cpp
> # ./a.out
> Thread 1: 23618687.000000 !=3D 4503599659991211
> ^C
>=20
> The left hand side for Thread 1 should have had the huge value
> too. Thread 0 has the smaller floating point/unsigned long long
> values (that should be mathematically equal in the thread at
> the point that they are tested). The two threads are independent
> of each other but are doing the same type of loop --over
> different numeric ranges.
>=20
> So it looks like "necessary but not suffient" for that
> test. (I'll leave the code change in place, as I doubt that
> it is wrong.)
>=20
> Given Kornel D.'s already existing notes, I did not expect
> either KASSERT failure to be fixed by just this "fixed to be bl"
> change.
>=20
> (This test was done as part of my already started multi-system
> environment upgrade sequence from 1400079 based to 1400081 based
> after a tmpfs fix. So I patched the kernel source that I'd
> already synchronized the source tree to [somewhat older from
> yesterday].)
>=20
> . . .
>=20
With the savectx blne -> bl change, D38696.diff, and D38698.diff all =
applied, all
the activities with all 3 of my small example programs for the armv7 =
floating
point related problems look to be working just fine: no KASSERT's ( =
simple_dbl.c
and dbl_and_ull_via_async.cpp activities) and no odd values showing up =
in a
thread ( dbl_and_ull_multithread.cpp runs for minutes at a time).
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?61F904C8-5F01-4E55-B93F-84A569539F43>