panic: Unregistered use of FPU in kernel

[Alan Somers]

On Thu, Sep 26, 2019 at 11:29 AM Konstantin Belousov <kostikbel at gmail.com>
wrote:

> On Thu, Sep 26, 2019 at 11:20:51AM -0600, Alan Somers wrote:
> > On Thu, Sep 26, 2019 at 11:02 AM Konstantin Belousov <
> kostikbel at gmail.com>
> > wrote:
> >
> > > On Thu, Sep 26, 2019 at 09:45:43AM -0600, Alan Somers wrote:
> > > > The latest VM snapshot
> > > (FreeBSD-13.0-CURRENT-amd64-20190920-r352544.qcow2)
> > > > instapanics on boot:
> > > >
> > > > panic: Unregistered use of FPU in kernel
> > > >
> > > > stack trace:
> > > > ...
> > > > sse42_crc32c
> > > > readsuper
> > > > ffs_sbget
> > > > g_label_ufs_taste_common
> > > > g_label_taste
> > > > g_new_provider_event
> > > > g_run_events
> > > > fork_exit
> > > > ...
> > > >
> > > > Has anybody touched this area recently?  I'll try to narrow down the
> > > commit
> > > > range.
> > >
> > > Start with disassembling the faulting instruction.  I suspect that
> somehow
> > > vital compiler switches like -mno-sse got omitted in the build.
> > >
> >
> > No problem with compiler switches here.  The C file uses inline assembly
> to
> > generate a crc32q instruction, in crc32_sse42.c:257.  But why would that
> > generate a floating point exception?  The instruction doesn't appear to
> be
> > using any floating point registers.  This is on a Kaby Lake CPU.
> >
> > crc32q %rsi, %rbx
>
> No idea, this instruction does not generate #NP at all.
>
> Provide exact script of the panic and backtrace,
> together with the disassembly of the function which contained the faulted
> instruction.  Do disassemble from ddb, in case text was corrupted.
>

Ok, here's the full stack trace:
 #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1  doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:392
#2  0xffffffff804a1edb in db_dump (dummy=<optimized out>,
    dummy2=<optimized out>, dummy3=<unavailable>, dummy4=<unavailable>)
    at /usr/src/sys/ddb/db_command.c:575
#3  0xffffffff804a1c8f in db_command (last_cmdp=<optimized out>,
    cmd_table=<optimized out>, dopager=1) at
/usr/src/sys/ddb/db_command.c:482
#4  0xffffffff804a1a04 in db_command_loop ()
    at /usr/src/sys/ddb/db_command.c:535
#5  0xffffffff804a4cbf in db_trap (type=<optimized out>, code=<optimized
out>)
    at /usr/src/sys/ddb/db_main.c:252
#6  0xffffffff80c1e55c in kdb_trap (type=3, code=0, tf=<optimized out>)
    at /usr/src/sys/kern/subr_kdb.c:692
#7  0xffffffff811957df in trap (frame=0xfffffe00907e8d20)
    at /usr/src/sys/amd64/amd64/trap.c:621
#8  <signal handler called>

Your guess about corrupted text was prescient.  Here is the disassembly
according to ddb:
https://people.freebsd.org/~asomers/Screenshot_fbsd-head_2019-09-26_13%3A51%3A34.png
And here is the disassembly of the same section according to gdb:
   0xffffffff8113b2e0 <sse42_crc32c+96>: mov    %rsi,%r9
   0xffffffff8113b2e3 <sse42_crc32c+99>: sub    $0xffffffffffffff80,%r9
   0xffffffff8113b2e7 <sse42_crc32c+103>: add    $0x100,%rsi
   0xffffffff8113b2ee <sse42_crc32c+110>: mov    %r11,%rbx
   0xffffffff8113b2f1 <sse42_crc32c+113>: xor    %eax,%eax
   0xffffffff8113b2f3 <sse42_crc32c+115>: xor    %r11d,%r11d
   0xffffffff8113b2f6 <sse42_crc32c+118>: nopw   %cs:0x0(%rax,%rax,1)
   0xffffffff8113b300 <sse42_crc32c+128>: mov    %rsi,%rdx
   0xffffffff8113b303 <sse42_crc32c+131>: mov    -0x100(%rsi),%rsi
   0xffffffff8113b30a <sse42_crc32c+138>: mov    -0x80(%rdx),%rdi
   0xffffffff8113b30e <sse42_crc32c+142>: crc32q %rsi,%rbx
   0xffffffff8113b314 <sse42_crc32c+148>: crc32q %rdi,%rax
   0xffffffff8113b31a <sse42_crc32c+154>: mov    (%rdx),%rsi
   0xffffffff8113b31d <sse42_crc32c+157>: crc32q %rsi,%r11
   0xffffffff8113b323 <sse42_crc32c+163>: lea    0x8(%rdx),%rsi
   0xffffffff8113b327 <sse42_crc32c+167>: add    $0xffffffffffffff08,%rdx
   0xffffffff8113b32e <sse42_crc32c+174>: cmp    %r9,%rdx
   0xffffffff8113b331 <sse42_crc32c+177>:
    jb     0xffffffff8113b300 <sse42_crc32c+128>
   0xffffffff8113b333 <sse42_crc32c+179>: movzbl %cl,%r9d
   0xffffffff8113b337 <sse42_crc32c+183>: movzbl %ch,%edi
   0xffffffff8113b33a <sse42_crc32c+186>: mov    %ecx,%edx

Care to guess what's causing the corruption?
-Alan