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>