Re: panic: Called fill_fpregs while the kernel is using the VFP

In reply to: bob prohaska : "panic: Called fill_fpregs while the kernel is using the VFP"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Mark Millard <marklmi_at_yahoo.com>
Date: Mon, 06 Mar 2023 16:59:03 UTC
On Mar 6, 2023, at 07:19, bob prohaska <fbsd@www.zefox.net> wrote:

> This is new to me. Pi2 running armv7 at 
> main-4b0552d5f4: Thu Feb 16 16:12:46 PST 2023
> 
> panic: Called fill_fpregs while the kernel is using the VFP
> cpuid = 3
> time = 1678112700
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> pc = 0xc05e5aec  lr = 0xc007a684 (db_trace_self_wrapper+0x30)
> sp = 0xdd2de790  fp = 0xdd2de8a8
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> pc = 0xc007a684  lr = 0xc02e9184 (vpanic+0x140)
> sp = 0xdd2de8b0  fp = 0xdd2de8d0
> r4 = 0x00000100  r5 = 0x00000000
> r6 = 0xc07875a1  r7 = 0xc0b12f08
> vpanic() at vpanic+0x140
> pc = 0xc02e9184  lr = 0xc02e8f64 (dump_savectx)
> sp = 0xdd2de8d8  fp = 0xdd2de8dc
> r4 = 0xe05bc900  r5 = 0xc4c19e90
> r6 = 0xdffb6e50  r7 = 0xd70afa40
> r8 = 0xdffb6e40  r9 = 0xe05bc900
> r10 = 0xdd2de960
> dump_savectx() at dump_savectx
> pc = 0xc02e8f64  lr = 0xc05f2ea8 (set_regs)
> sp = 0xdd2de8e4  fp = 0xdd2de8f8
> set_regs() at set_regs
> pc = 0xc05f2ea8  lr = 0xc026ee34 (elf32_get_fpregset+0x2c)
> sp = 0xdd2de900  fp = 0xdd2de908
> r4 = 0xdffb6e50  r5 = 0xc026ee08
> elf32_get_fpregset() at elf32_get_fpregset+0x2c
> pc = 0xc026ee34  lr = 0xc026cd9c (elf32_coredump+0x308)
> sp = 0xdd2de910  fp = 0xdd2de988
> r4 = 0xc09033d4 r10 = 0xdd2de960
> elf32_coredump() at elf32_coredump+0x308
> pc = 0xc026cd9c  lr = 0xc02edfac (sigexit+0xce0)
> sp = 0xdd2de990  fp = 0xdd2decf8
> r4 = 0x0000004e  r5 = 0xddb6883c
> r6 = 0xddb68754  r7 = 0xc026ca94
> r8 = 0xde22e2bc  r9 = 0xddb687b0
> r10 = 0x00000000
> sigexit() at sigexit+0xce0
> pc = 0xc02edfac  lr = 0xc02ee8ac (postsig+0x128)
> sp = 0xdd2ded00  fp = 0xdd2ded88
> r4 = 0x00000006  r5 = 0xde2f5000
> r6 = 0xdd2ded20  r7 = 0xdd2ded18
> r8 = 0xde22e1f8  r9 = 0xd710cab8
> r10 = 0x00000005
> postsig() at postsig+0x128
> pc = 0xc02ee8ac  lr = 0xc02f26dc (ast_sig+0x11c)
> sp = 0xdd2ded90  fp = 0xdd2dee08
> r4 = 0xde2f5000  r5 = 0xde22e2bc
> r6 = 0xc0753a8d  r7 = 0x00000000
> r8 = 0xde22e1f8  r9 = 0x00000ab8
> r10 = 0x23adf040
> ast_sig() at ast_sig+0x11c
> pc = 0xc02f26dc  lr = 0xc0352fb0 (ast_handler+0xe0)
> sp = 0xdd2dee10  fp = 0xdd2dee28
> r4 = 0xdd2dee40  r5 = 0x0000000e
> r6 = 0x00004000  r7 = 0xc096bf9c
> r8 = 0xde2f5000  r9 = 0x00000001
> ast_handler() at ast_handler+0xe0
> pc = 0xc0352fb0  lr = 0xc0352ec0 (ast+0x20)
> sp = 0xdd2dee30  fp = 0xdd2dee38
> r4 = 0xdd2dee40  r5 = 0xde2f5000
> r6 = 0x00000000  r7 = 0x000001b1
> r8 = 0x24006570  r9 = 0x23adf040
> ast() at ast+0x20
> pc = 0xc0352ec0  lr = 0xc05e8410 (swi_exit+0x3c)
> sp = 0xdd2dee40  fp = 0xbfbfcaf0
> r4 = 0x60000013  r5 = 0xde2f5000
> swi_exit() at swi_exit+0x3c
> pc = 0xc05e8410  lr = 0xc05e8410 (swi_exit+0x3c)
> sp = 0xdd2dee40  fp = 0xbfbfcaf0
> KDB: enter: panic
> [ thread pid 8505 tid 100176 ]
> Stopped at      kdb_enter+0x54: ldrb    r15, [r15, r15, ror r15]!
> db> 
> 

See . . .

For the fixes to this armv7/armv6 specific problem:

Mon, 20 Feb 2023
    • git: 24abb6b82102 - main - When saving a context on arm call the vfp handler Andrew Turner

Thu, 23 Feb 2023
    • git: 4d2427f2c445 - main - arm: Unbreak debugging programs that use FP instructions Kornel Dulęba 
    • git: 98c666cf8758 - main - arm: Fix initialization of VFP context Kornel Dulęba 

So you need 98c666cf8758 or later.

For where it was broken:

Sat, 04 Feb 2023
• git: 6926e2699ae5 - main - arm: Add support for using VFP in kernel Kornel Dulęba 
• git: e5d7c5c857f8 - main - arm: mv: Add missing function prototype Kornel Dulęba 

It can be nasty to try to build the kernel via a system
running a broken kernel. Getting an appropriate vintage
kernel via a snapshot can work around such issues.
Another way is using an appropriate kernel.txz from what
is available via looking around in:

https://artifact.ci.freebsd.org/snapshot/main/?C=M&O=D

After renaming/deleting /boot/kernel , that compressed
tar file can be expanded with -C / involved to create a
/boot/kernel/ on the armv7 media. With that kernel
booted, then a normal build/install update can be done.
(The wording does not deal with if you happen to end up
with a temporary kernel that is broken in some other
way: pick a different one in that case.)

===
Mark Millard
marklmi at yahoo.com