Re: Armv7 panic on -current, rpi2 buildworld
- In reply to: Mark Millard : "Re: Armv7 panic on -current, rpi2 buildworld"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 20 Feb 2023 23:21:15 UTC
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: > >> 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