Re: Armv7 panic on -current, rpi2 buildworld

On Feb 20, 2023, at 09:08, Mark Millard <[email protected]> wrote:

> On Feb 20, 2023, at 04:32, Andrew Turner <[email protected]> wrote:
> 
>> Can you try with 24abb6b82102eec577eff9bd8dd7726e8cab89f4? There were conditional branch instructions that may mean the function to save the VFP state was not being run.
>> 
>> Andrew
> 
> 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).
> 
> I've tested the later one via an armv7 kernel that
> has:
> 
> 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 = #11328
> c0681a48: e28dd004      add     sp, sp, #4
> c0681a4c: e8bd8000      ldm     sp!, {pc}
> 
> and it still fails:
> 
> # g++12 -std=c++20 -pedantic -g -O3 -pthread -Wl,-rpath=/usr/local/lib/gcc12 dbl_and_ull_multithread.cpp
> # ./a.out
> Thread 1: 23618687.000000 != 4503599659991211
> ^C
> 
> 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.
> 
> 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.)
> 
> 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.
> 
> (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].)
> 
> . . .
> 

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).


===
Mark Millard
marklmi at yahoo.com