Re: earmv7hf panic

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

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.

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