Re: earmv7hf panic

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Thu, Jul 18, 2019 at 10:02:48PM +0200, Manuel Bouyer wrote:
> On Thu, Jul 18, 2019 at 03:45:46PM +0200, Manuel Bouyer wrote:
> > Hello,
> > I updated a olimex lime2 board (allwinner A20) with an up to date kernel,
> > and it panics with:
> > 
> > [   4.6949594] panic: VFP fault at 0x80073d78 in non-user mode
> > [   4.6949594] cpu1: Begin traceback...
> > [   4.7049580] 0x99eebb9c: netbsd:db_panic+0x14
> > [   4.7049580] 0x99eebbb4: netbsd:vpanic+0x194
> > [   4.7149586] 0x99eebbcc: netbsd:snprintf
> > [   4.7149586] 0x99eebc7c: netbsd:vfp_attach
> > [   4.7249615] 0x99eebd34: netbsd:undefinedinstruction+0x10c
> > [   4.7249615] 0x99eebdf4: netbsd:address_exception_entry+0x5c
> > [   4.7349674] 0x99eebe54: netbsd:pcu_load+0x17c
> > [   4.7349674] 0x99eebef4: netbsd:vfp_handler+0x50
> > [   4.7449618] 0x99eebfac: netbsd:undefinedinstruction+0x10c
> > [   4.7549647] cpu1: End traceback...
> > Stopped in pid 2.1 (sh) at      netbsd:cpu_Debugger+0x4:        bx      r14
> 
> I added some more informations to the panic:
> [   4.6958882] panic: VFP fault 0 isn 0xeee93a10 at 0x80073f18/0x80073f18 in non-user mode, fpexc 0x40000000
> [   4.6958882] cpu0: Begin traceback...
> [   4.6958882] 0x99f2bb9c: netbsd:db_panic+0x14
> [   4.6958882] 0x99f2bbb4: netbsd:vpanic+0x194
> [   4.6958882] 0x99f2bbcc: netbsd:snprintf
> [   4.6958882] 0x99f2bc7c: netbsd:vfp_attach
> [   4.6958882] 0x99f2bd34: netbsd:undefinedinstruction+0x10c
> [   4.6958882] 0x99f2bdf4: netbsd:address_exception_entry+0x5c
> [   4.6958882] 0x99f2be54: netbsd:pcu_load+0x17c
> [   4.6958882] 0x99f2bef4: netbsd:vfp_handler+0x54
> [   4.6958882] 0x99f2bfac: netbsd:undefinedinstruction+0x10c
> [   4.6958882] cpu0: End traceback...
> Stopped in pid 2.1 (sh) at      netbsd:cpu_Debugger+0x4:        bx      r14
> db{0}> x/x 0x80073f18
> netbsd:vfp_state_load+0xe4:     eee93a10
> 
> So we're entering vfp_handler() with the VFP_FPEXC_EN actually set.
> 
> The addresses printed by ddb seems wrong; pcu_load+0x17c should be
> 0x8045a8cc not 0x99f2be54. A x/x from ddb shows that the correct
> instruction for pcu_load+0x17c is indeed at 0x8045a8cc and not 0x99f2be54.
> 
> I don't know if we can trust the address_exception_entry in the stack trace.
> If it's indeed the entry point of the fault handler it may be a hint.

I think I made good process.
The faulting instruction is armreg_fpinst_write(fregs->vfp_fpinst)
near the end of vfp_state_load().
With some more prinfs:
        if (fregs->vfp_fpexc & VFP_FPEXC_EX) {
                /* Need to restore the exception handling state.  */
                printf("case ex 0x%x\n", armreg_fpexc_read());
                printf("case ex: 0x%x\n", fregs->vfp_fpinst);
                armreg_fpinst_write(fregs->vfp_fpinst);
                if (fregs->vfp_fpexc & VFP_FPEXC_FP2V) {
                        printf("case ex2\n");
                        printf("case ex2: 0x%x\n", fregs->vfp_fpinst2);
                        armreg_fpinst2_write(fregs->vfp_fpinst2);
                }
        }

I get:
[   4.7798678] undefined_handlers coproc 11
[   4.7904942] case ex 0x40000000
[   4.7904942] case ex: 0x80426dcc
[   4.7904942] undefined_handlers coproc 10
[   4.7904942] panic: VFP fault 0 isn 0xeee93a10 at 0x80073f38/0x80073f38 in non-user mode, fpexc 0x40000000

So:
- we have VFP_FPEXC_EX in fregs->vfp_fpexc
- we just wrote fregs->vfp_fpexc back to the fpexc register
- reading back the fpexc register, VFP_FPEXC_EX is not set
- also, the saved fpinst doens't looks like a valid FP instruction

from the armv7 manual, this is a reliable way to know that the
fpinst is not implemented. We're probably faulting because we try
to write an unimplemented register.

But how did we get VFP_FPEXC_EX set in the first place, if this bit is always
0 in the register ? This, and the saved fpinst value, makes me suspect that
the saved state is corrupted or not properly initialized.

I'll investigate this tomorow but ideas are welcome :)

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--